Implementing Siebel Business Applications on DB2 UDB for z/OS > Understanding Siebel Partitioning >

Methods Used for Partitioning

Siebel Systems supports two methods for partitioning:

• Partitioning based on business data
• Partitioning using a column designed for even data distribution

Partitioning Based on Business Data

In this partitioning method, a table is partitioned based on existing columns in the Siebel Schema; for example, S_OPTY is partitioned by columns in the U1 index. In this case, no special action is needed except to define the key ranges and number of partitions.

Partitioning for Even Data Distribution

This partitioning method involves partitioning a table using an additional partitioning column, PARTITION_COLUMN, designed specifically for Siebel partitioning with even data distribution. This column is populated with data using a BEFORE INSERT trigger option to generate the partitioning value for each row based on data from another column.

Most Siebel tables are tied together by the ROW_ID column from a parent table. Columns with an _ID suffix are used to define a parent-child relationship, for example, OU_ID. These columns might seem to be good partitioning candidates because they support the DB2 access path; but, in fact, these columns are poor candidates for partitioning because ROW_IDs are generated in sequential order.

To resolve the limitation caused by the sequential order of ROW_ID, Siebel Systems provides a column, PARTITION_COLUMN, which is based on the ROW_ID. This column is used only for partitioning purposes. It is a physical column defined in a storage control file, but it is not a part of the Siebel repository. It is important that you continue to use the name PARTITION_COLUMN if the Siebel application is to recognize this column. You must also define this column as NOT NULL WITH DEFAULT.

The DB2 BEFORE INSERT trigger used to populate the PARTITION_COLUMN values is defined in the Siebel storage control file. This trigger extracts the last two bytes of a source _ID column and uses it to populate PARTITION_COLUMN. By using a trigger to populate the columns, you can partition tables that do not have good candidate columns for a partitioning key due to their data content. Using a trigger, you can still generate values that distribute the data well.