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

BIC/A00) table. Keep in mind that this table also is
involved in the activation of DataStore object data, so this must also be
considered when deciding a partitioning scheme.
To choose an appropriate partitioning key, you need to understand your data and
know how it is used and how it is managed. You should focus on how the data is
commonly retrieved. Look at which key figure fields the users are using in their
queries. Next look at which of these key figure fields are local predicates on the
DataStore object and which are joins to master data. Only fields in the local
predicates should be considered as columns in the partitioning key.
Unlike InfoCube queries, where SAP keeps a historical record of the InfoObjects
referenced in a query in the table RSDDSTATAGGRDEF, you must trace (for
example, ST05) and examine the SQL of a DataStore object query in order to
analyze how the DataStore object is used by queries.
One common partitioning key for an DataStore object is date. This works if the
data is commonly queried by date, for example, Display the sales volume by
day or month. Partitioning by date also lends itself to data management. As time
goes on, older data can be archived and deleted from the active DataStore
object.
In addition to adding the indexes to improve query performance, we also
recommend partitioning /BIC/AZOSASALE00 by CALMONTH.
If a greater number of partitions is required for reduced partition size or increased
parallelism, then partitioning would be recommended by CURTYPE,
CALMONTH. (Note, however, that the addition of CURTYPE as the leading
partitioning column should only be made if CURTYPE always exists in queries
against this DataStore object.)
After you choose a partitioning key, you need to decide on the number of
partitions and the limit key value for each partition. The number of partitions
should be determined by the anticipated table growth. The limit key value should
be determined by what will give evenly sized partitions.
SAP provides a function (through transaction SE14) that collects limit key data
based on a particular index. You specify an index and the desired number of
partitions, and SAP determines the limit key value for each partition that will give
evenly sized partitions.
Of course, this strategy only works for tables that are populated with data. It also
requires that an index exists that will be the partitioning index. To use this
function with table-controlled partitioning, you may have to define an index for
your partitioning key. After using this index to collect the limit key data, you can
drop the index if it is not needed for data access.
Chapter 7. Best practices for DataStore 111