Implementing Siebel Business Applications on DB2 for z/OS > About Siebel Table Partitioning >

About Siebel Partitioning

Partitioning table spaces on DB2 allows tables to be spread across multiple physical partitions based on a partitioning key, a set of key value ranges for each partition, and optionally, a partitioning index. Using partitioned table spaces increases the maximum size of a table and improves the manageability of large tables.

Partitioning EIM table spaces by batch number improves EIM performance for batching and parallel processing, and allows distribution of key ranges across multiple data sets.

Any table can be partitioned during the installation or upgrade process. You can define partitioned table spaces and key ranges for Siebel tables during or after installation, based on your business requirements. For a complete list of prepartitioned Siebel tables, see Prepartitioned Siebel Tables.

You can partition tables yourself by following Oracle's guidelines, or you can take advantage of the default partitioning scheme that Oracle developed, based on customer experience using the Siebel data model with DB2 for z/OS. If you use the Siebel default partitions, you can either accept them as they are, or you can reconfigure them to suit your requirements.

DB2 for z/OS Version 8 introduced a number of new partitioning capabilities. None of these capabilities are required to run Siebel Business Applications, but many of the key features are supported in Siebel releases since 8.0, including the following:

• You can specify up to 1296 partitions for tables partitioned on the last 2 bytes of ROW_ID. For further information, see Partitioning for Even Data Distribution. For tables that use any other partitioning key, up to 4096 partitions can be specified.
• The current Siebel release supports table-controlled and index-controlled partitioning. If you use table controlled partitioning, you do not have to maintain indexes that are used for partitioning only.
• With table-controlled partitioning, clustering is separated from partitioning. The partitioning index is not automatically the clustering index, so data in a partitioned table space does not have to be clustered by the partitioning key. Data can be clustered by partition using a secondary unique index that you choose.

  NOTE:  Clustering related records within a partition generally improves performance and is particularly important for tables with non-unique access paths, for example, intersection tables.

• Partitioning indexes can be defined for indexes if the associated table uses table-controlled partitioning and is not partitioned by ROW_ID. For further information, see Considerations in Partitioning Tables.