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

► Load impact
– Loading data into the InfoCube will be faster, because it usually involves
inserting into an empty or small F- fact table and its dimension tables.
– Additionally, if indexes on the F- fact table are dropped to improve insert
performance, then REBUILD INDEX time will be much shorter due to a
smaller F- fact table.
► Administration impact
Important: Lack of RUNSTATS on E and F is the major cause of poor
compression performance.
– SAP compression results in a smaller F- fact table.
– SAP compression supports partitioning of the E- fact table.
– Administration of compressed InfoCubes is quicker because a smaller F-
fact table means reduced RUNSTATS runtimes.
– Backups and restores are shorter in situations where SAP compression
has resulted in reduced data storage requirements.
– Backups and restores can be shorter where partitioning of the E- fact table
has been performed and the DBA chooses to back up/restore only
changed partitions (since older partitions will not have changed since last
backup).
– Deleting records from the F- fact table is faster due to the smaller size of
the table.
– Updating of aggregates (rollup) is faster when the source InfoCube has
been compressed due to the smaller size of the F- fact table.
– Reorganization is easier on a smaller F- fact table or current partitions only
of the E- fact table.
► Query impact
– Queries against the InfoCube are faster in situations in which
summarization would normally be performed by the application during
query time.
– The summarized data will have fewer records to access.
– Queries will also be accelerated due to E- fact table partitioning where
queries can be defined against partitioning keys, or the query executes in
parallel.
– Query is also enhanced since compression results in less data being
returned.
Chapter 6. Best practices for InfoCubes 99