Converting table spaces to use table-controlled partitioning
Before you can convert a partitioned (non-UTS) table space that uses index-controlled partitioning to a partition-by-range table space, you must convert it to use table controlled partitioning. Table spaces that use index-controlled partitioning, like all non-UTS table spaces are deprecated.
About this task
For partitioned (non-UTS) table spaces, Db2 supports both table-controlled partitioning and index-controlled partitioning. Table-controlled partitioning provides more options and flexibility compared to index-controlled partitioning. Index-controlled partitioning requires partitioning index to control the partitioning.
Non-UTS table spaces for base tables are deprecated and likely to be unsupported in the future.Table-controlled partitioning | Index-controlled partitioning |
---|---|
Requires no partitioning index or clustering index. | Requires a partitioning index and a clustering index. |
Multiple partitioned indexes can be created in a table space. | Only one partitioned index can be created in a table space. |
A table space partition is identified by both a physical partition number and a logical partition number. | A table space partition is identified by a physical partition number. |
The high-limit key is always enforced, which means that key values that are out of range might result in errors or discarded data, depending on the operation involved. | The high-limit key is not enforced for a non-large table space. |
classicpartitioned (non-UTS) table spaces to partition-by-range table spaces, see the white paper Conversion from index-controlled partitioning to Universal Table Space (UTS).
Procedure
Certain index operations always cause Db2 to automatically convert an index-controlled partitioned table space to a table-controlled partitioned table space. To convert a table that uses index-controlled partitioning to use table-controlled partitioning, use one of the following actions:
Results
After the conversion to table-controlled partitioning, Db2 changes the existing high-limit key value for non-large table spaces to the highest value for the key. Db2 also starts enforcing the high-limit key values, which is not the case for tables that use index-controlled partitioning.
Db2 also invalidates any packages that depend on the table in the converted table space.
Db2 places the last partition of the table space into a REORG-pending (REORP) state in the following situations:
- Adding or rotating a new partition
- Db2 stores the original high-limit key value instead of the default high-limit key value. Db2 puts the last partition into a REORP state, unless the high-limit key value is already being enforced, or the last partition is empty.
- Altering a partition results in the conversion to table-controlled partitioning
- Db2 changes the existing high-limit key to the highest value that is possible for the data types of the limit key columns. After the conversion to table-controlled partitioning, Db2 changes the high-limit key value back to the user-specified value and puts the last partition into a REORP state.
Example
- ACCTID is the customer account ID
- POSTED is the date of the transaction
The table space that contains TRANS is divided into 13 partitions, each containing one month of data. Two existing indexes are defined as follows:
- A partitioning index is defined on the transaction date by the following CREATE INDEX statement with a PARTITION ENDING AT clause: The partitioning index is the clustering index, and the data rows in the table are in order by the transaction date. The partitioning index controls the partitioning of the data in the table space.
- A nonpartitioning index is defined on the customer account ID:
CREATE INDEX IX2 ON TRANS(ACCTID);
Db2 usually accesses the transaction table through the customer account ID by using the nonpartitioning index IX2. The partitioning index IX1 is not used for data access and is wasting space. In addition, you have a critical requirement for availability on the table, and you want to be able to run an online REORG job at the partition level with minimal disruption to data availability.
- Drop the partitioning index IX1.
DROP INDEX IX1;
When you drop the partitioning index IX1, Db2 converts the table space from index-controlled partitioning to table-controlled partitioning. Db2 changes the high limit key value that was originally specified to the highest value for the key column.
- Create a partitioned clustering index IX3 that matches the 13 data partitions in the table, as a
replacement for
IX2.
CREATE INDEX IX1 ON TRANS(POSTED) CLUSTER (PARTITION 1 ENDING AT ('01/31/2002'), PARTITION 2 ENDING AT ('02/28/2002'), ... PARTITION 13 ENDING AT ('01/31/2003'));
When you create the index IX3, Db2 creates a partitioned index with 13 partitions that match the 13 data partitions in the table. Each index partition contains the account numbers for the transactions during that month, and those account numbers are ordered within each partition. For example, partition 11 of the index matches the table partition that contains the transactions for November, 2002, and it contains the ordered account numbers of those transactions.
- Drop index IX2,which was replaced IX3.
DROP INDEX IX2; COMMIT;