Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks

A cost-based optimizer relies on current and correct statistics to ensure
optimal SQL access path selection. In an SAP BI environment, statistics do
not require re-collection unless the object's data content has altered based
upon a load, SAP compression, rollup, deletion, attribute change run, or data
archive. Therefore it is only these activities that require the updating of DB2
statistics, and mostly the RUNSTATS are triggered automatically by the SAP
BI functions itself.
With a load, new packets are loaded into the F- fact table. Without knowledge
of the newly loaded data, the optimizer may not choose an optimal access
path for subsequent reporting queries, aggregate rollups, or SAP
compressions that specify a search criteria for the individual packet number.
Therefore it is important to ensure the RUNSTATS is triggered as part of the
load process by selecting RSA1 → Manage InfoCube → Performance →
Create Statistics (Btch).
For process chains see SAP Note 778437.
5. Keep current with SAP support packs and DB2 maintenance level.
Each new SAP support pack delivers fixes and also performance
enhancements based upon prior customer requirements or identified areas
for improvement by joint DB2 and SAP development.
As with the SAP software, each maintenance release of DB2 provides
additional fixes and enhancements based upon prior customer problems and
requirements. To minimize exposure to known problems, we recommend that
you stay current with the SAP certified maintenance level and apply additional
PTFs identified in SAP note 81737.
6. Utilize SAP compression (E- fact table).
When F- fact table packets are consolidated into the E- fact table via a
process known as InfoCube compression, queries on the E- fact table filter by
meaningful dimension/master data characteristics rather than the arbitrary
packet number. This can result in better exploitation of available indexes on
the E- fact table since the F- fact table must carry an index led by packet
number to improve compression and rollup performance, but not query
performance.
Given the volatility of the F- fact table, RUNSTATS is required more
frequently than on the E- fact table. Therefore keeping the F- fact table a
moderate size by compressing packets to E can improve overall RUNSTATS
performance and cost for the entire InfoCube.
And finally the most important reason for SAP compression is for
non-cumulative key figures whereby an additional row is inserted or updated
in the E- fact table holding for each combination of dimension IDs the most
current key figure values. Rather than requiring to sum all delta values from
Chapter 3. Top ten SAP BI recommendations 31