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

– When not condensing all requests:
i. Drop the secondary indexes on the F- fact table.
ii. Call function module RSDU_INFOCUBE_INDEXES_DROP for the F-
fact table.
iii. Condense the requests.
iv. Call function module RSDU_INFOCUBE_INDEXES_REPAIR.
This speeds up the deletion of the request from the F- fact table, because
the deletion of entries from the secondary indexes is very expensive.
– Activate F- fact table partitioning.
See SAP notes 860830 and 894045.
► Tune the size of the bufferpool for the E- fact table index pages. If the
bufferpool size is too small, it is the bottleneck for the insert into the E- fact
table.
The default bufferpool for all index pages is BP3. The specific setting for fact
table index pages via the RSADMIN parameter is
DB2_FACT_BPOOL_INDEX (see SAP note 536074).
► When condensing many large requests:
a. Drop the secondary indexes on the E- fact table before starting the
condensing.
b. Recreate the secondary indexes after all requests are compressed. Call
function module RSDU_INFOCUBE_INDEXES_DROP and specify the E-
fact table name.
c. Call function module RSDU_INFOCUBE_INDEXES_REPAIR to rebuild
indexes.
Do not drop the secondary indexes if the E- fact table is already very large
and the compression adds less than about 10% of new rows into the E- fact
table.
► Restrict the size of the requests.
– Requests should not be larger than 10 million rows.
– Compression of huge requests results in long-running uncommitted UR
(unit of recovery) and long elapsed time in case of a rollback.
► Use the partitioning of the F- fact table.
– Refer to SAP note 860830 (DB2_PARTITIONED_F_FACT = X).
– Configure the fast deletion of the partition for the request deletion from the
F-Fact able (SAP note 894045).
Chapter 6. Best practices for InfoCubes 101