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

DPSI indexes provide an alternative to non-partitioned secondary indexes
(NPSIs). There are some areas where NPSI indexes can cause performance
and contention problems, namely, availability and partition-level operations.
NPSIs can also result in significant contention while executing a query in parallel,
since each parallel task must route through the same single B-tree index
structure to access the separate data partitions. Therefore, DPSIs can improve
parallelism performance. If a table and all its indexes are partitioned, then the
data in separate partitions can be accessed in parallel.
However, DPSIs will not always improve query performance and may, in fact,
cause query performance degradation. Queries against DPSIs that do not
include predicates against the leading partitioning column are likely to
experience performance degradation due to the need to probe each partition of
the index for values that satisfy the predicate. Queries with predicates against
the secondary index that also restrict the query to a subset of the partitions (by
having predicates against the leading partition column) should see a benefit.
So again, you must know the queries that will be executing against your
DataStore object in order to make an informed decision about whether to use
DPSIs. If you do use them, you must decide which columns to include in the
DPSI. The decision to use a NPSI or DPSI must take into account both data
maintenance practices and the access patterns of the data. We recommend
replacing an existing NPSI with a DPSI only if there are perceivable benefits,
such as easier data or index maintenance, improved data or index availability, or
improved performance.
Using DPSIs for DataStore objects
For DataStore objects, DPSIs should only be considered if queries against the
DataStore object generally contain restrictive predicates against the partitioning
columns (most important is the leading column of the partitioning key) or if the
number of partitions is small (for example, 10 or less) and parallelism will be
exploited.
Let us look again at the DataStore object query discussed earlier in this chapter.
Assume that CALMONTH is chosen as the partitioning key. If it always exists in
queries, then we recommend that the index CURTYPE, ACCT_ASGN,
/BIC/ZMATLPLNT, PLANT be created as a data partitioned secondary index.
The local predicates of CALMONTH (and CURTYPE) would restrict the query to
a small subset of partitions.
SAP does not support the creation of DPSI indexes yet. They must be created
with native SQL within DB2. Use the PARTITIONED keyword on the CREATE
INDEX statement to create a data partitioned secondary index.
Chapter 7. Best practices for DataStore 113