DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

If explicit clustering for a table is removed (changed to NOT CLUSTER), that index is still used
as the implicit clustering index until a new explicit clustering index is chosen.
5.5.4 DPSI and impact on utilities and queries
With DB2 V7, secondary indexes on partitioned tables are non-partitioned indexes.
Secondary indexes cannot be physically partitioned. They can only be allocated across
multiple pieces to reduce I/O contention. DB2 V8 introduces the ability to physically partition
secondary indexes. The partitioning scheme introduced is the same as that of the table
space. That is, there are as many index partitions in the secondary index as table space
partitions, and index keys in partition “n” of the index reference only data in partition “n” of the
table space. Such an index is called a Data-Partitioned Secondary Index (DPSI).
Description
When an index is created and no additional keywords are specified, the index is
non-partitioned. If the keyword PARTITIONED is specified, the index is partitioned. The index
is both data-partitioned and key-partitioned when it is defined on the partitioning columns of
the table. Any index on a partitioned table space that does not meet the definition of a
partitioning index is a secondary index. When a secondary index is created and no additional
keywords are specified, the secondary index is non-partitioned (NPSI). If the keyword
PARTITIONED is specified, the index is a data-partitioned secondary index (DPSI).
You create a DPSI by specifying the new PARTITIONED keyword in the CREATE INDEX
statement and defining keys on some columns that coincide with the partitioning columns of
the table. When defining a DPSI, the index cannot be created as UNIQUE or UNIQUE
WHERE NOT NULL. This is to avoid having to search each part of the DPSI to make sure the
key is unique.
Benefits of DPSIs are:
► Allow partition-level operation for utilities operating on secondary indexes such as REORG
INDEX, RUNSTATS INDEX
► Eliminate contention on index pages for utilities operating on partition level with DPSI.
► Utilize concurrent LOAD PART more efficiently while inserting DPSI keys
► Eliminate the BUILD2 phase during Online REORG of a partition
► Reduce data sharing overhead
For a detailed description of DPSIs see DB2 UDB for z/OS Version 8: Everything You Ever
Wanted to Know, ... and More, SG24-6079.
Performance
In this section the performance impact of DPSIs on utilities and queries is evaluated.
Performance measurement description
For this measurement we used:
► z/OS V1R3
► DB2 for z/OS V8 in NFM
► IBM z900 Series 2064 4-way processor
► ESS model F20 with FICON channels
Performance measurement result for utilities and DPSIs
We used a partitioned table of 20 M rows with 10 partitions
248 DB2 UDB for z/OS Version 8 Performance Topics