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

Partitioning and clustering are both important performance tuning techniques for
DataStore objects. DataStore objects are typically large, containing many rows of
data. Queries against an DataStore object may retrieve thousands or more rows
of data before a DB2 aggregate function, such as SUM, is applied. Queries that
retrieve these large numbers of rows benefit most from partitioning and
clustering.
7.4.1 Choosing the partitioning key
The partitioning key defines how a table is to be partitioned — it dictates which
records are in which partitions. With table-controlled partitioning, the partitioning
index is no longer required. The partitioning key and the limit key values for a
table in a partitioned tablespace can be specified using the PARTITION BY
clause and the PARTITION ENDING AT clause of the CREATE TABLE
statement.
So, how do you choose the partitioning key? You can decide later if you also
want the partitioning key to be a partitioning index. A partitioning index is defined
as an index whose columns are the same as (and have the same collating
sequence) or whose columns start with the columns in the PARTITION BY
clause of the CREATE TABLE statement. In other words, it is an index that
matches the partitioning key.
The characteristics of a good partitioning key are:
► It should provide partition elimination.
Users are not normally interested in all the data in a table. Instead, they are
only interested in a subset of the data. If this subset of data is stored in one or
a few partitions, then DB2 needs only to access these partitions and can
eliminate the others from its search. Accessing and searching less data
improves query performance.
► It should enable parallelism.
Each partition is a separate physical data set and has its own spacemap
page. This allows the partitions to be operated on in parallel. In general, work
done in parallel can be completed quicker than work done serially.
► It should be able to provide similar-sized partitions.
A key reason for partitioning is to handle large tables and to manage the size
of the physical data sets behind the table. Having similar-sized partitions
usually optimizes performance and availability.
In this section of the book we look at choosing the partitioning key to optimize
query performance. Queries are executed against the active DataStore object
table, so we are really discussing choosing the partitioning key for the
110 Best Practices for SAP BI using DB2 9 for z/OS