07.02.2013 Views

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

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

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

If you specify a partitioning schema <strong>for</strong> the E- fact table when you define an<br />

InfoCube, the E- fact tables of all aggregates defined <strong>for</strong> this InfoCube are also<br />

partitioned according to this schema. However, that partitioning often does not<br />

make sense, especially in the case of small aggregates.<br />

� Partitioning of F-Fact table<br />

• Partitioned by request (DIMID of Requestnumber)<br />

• BW 3.x (new) since SP30 / SP24 / SP16 <strong>for</strong> (3.0 / 3.1 / 3.5)<br />

• by setting RSADMIN parameter <strong>DB2</strong>_PARTITIONED_F_FACT and<br />

<strong>DB2</strong>_AGGR_PARTITIONED_F_FACT as desired. (note #917568)<br />

<strong>for</strong> all cubes (recommended):<br />

<strong>DB2</strong>_PARTITIONED_F_FACT = X<br />

<strong>for</strong> all aggregates:<br />

<strong>DB2</strong>_AGGR_PARTITIONED_F_FACT = X<br />

Or only <strong>for</strong> certain cubes or aggregates:<br />

<strong>DB2</strong>_PARTITIONED_F_FACT_1 = CUBE2<br />

<strong>DB2</strong>_AGGR_PARTITIONED_F_FACT_2 = 100123<br />

<strong>DB2</strong>_AGGR_PARTITIONED_F_FACT_3 = CUBE2<br />

• No manual repartitioning necessary<br />

– Will be done at compression time, when the F-facttable becomes empty after<br />

compression of all requests<br />

Figure 2-7 E- fact table partitioning<br />

The per<strong>for</strong>mance can improve in some areas by partitioning the F- fact table. In<br />

particular, requests can be deleted significantly faster. In addition, you can<br />

restrict the update of database statistics to partitions whose contents have<br />

actually changed. The per<strong>for</strong>mance of queries also increases because access to<br />

partitions can be restricted with relevant data and parallel processing can be<br />

used efficiently.<br />

If an F- fact table is partitioned, it has a dedicated partition <strong>for</strong> each request (that<br />

is, <strong>for</strong> each package dimension ID).<br />

If a package dimension ID that does not yet have a partition is created during the<br />

update into the InfoCube, a new partition is created by the ADD PARTITION SQL<br />

statement. The limit of this new partition is the package dimension ID.<br />

After a request is deleted, a check is carried out on all partitions that exist be<strong>for</strong>e<br />

the partition with the request to be deleted to see whether they are empty. If this<br />

is the case, these partitions are moved to the end of the E- fact table by the<br />

18 <strong>Best</strong> <strong>Practices</strong> <strong>for</strong> <strong>SAP</strong> <strong>BI</strong> <strong>using</strong> <strong>DB2</strong> 9 <strong>for</strong> z/<strong>OS</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!