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.

2.3.5 Usage of data partitioned secondary indexes (DPSI)<br />

Data partitioned secondary indexes (DPSIs) provide the capability to partition an<br />

index according to the table-controlled partitioning specification of the underlying<br />

table. Each partition of a DPSI is a separate B-tree.<br />

DPSI ensures full partition independence at the physical level. For example,<br />

there is no REORG BUILD2 phase <strong>for</strong> these indexes. Deleting a single partition<br />

(via LOAD REPLACE with empty input file) becomes really fast because there is<br />

no need to remove entries from secondary indexes one by one. Recovering can<br />

be done on a per-partition basis, which reduces the amount of data that needs to<br />

be recovered as well as enables a higher degree of parallelism.<br />

The only downside of DPSI is potential access path deficiencies. If a query<br />

includes only predicates <strong>for</strong> the DPSI columns, each of the DPSI partitions<br />

(B-trees) will need to be traversed. With NPSIs (non partitioned index) there is<br />

only a single traversal. On the other hand, if the query includes a column that<br />

allows partition pruning, DPSI can be more efficient than a NPSI. The <strong>DB2</strong><br />

optimizer has been enhanced to take the new indexing structure into account and<br />

selects the optimal access path.<br />

Chapter 2. Overview of <strong>SAP</strong> <strong>BI</strong> and related data 21

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

Saved successfully!

Ooh no, something went wrong!