db2 - DETACH & ATTACH PARTITION

Posted 2022-11-25 t0nsha

Detaching data partitions

Table partitioning allows for the efficient roll-in and roll-out of table data. This efficiency is achieved by using the ATTACH PARTITION and DETACH PARTITION clauses of the ALTER TABLE statement.
About this task

Rolling-out partitioned table data allows you to easily separate ranges of data from a partitioned table. Once a data partition is detached into a separate table, the table can be handled in several ways. You can drop the separate table (whereby, the data from the data partition is destroyed); archive it or otherwise use it as a separate table; attach it to another partitioned table such as a history table; or you can manipulate, cleanse, transform and reattach to the original or some other partitioned table.
With DB2 Version 9.7 Fix Pack 1 and later releases, when detaching a data partition from a partitioned table using the ALTER TABLE statement with the DETACH PARTITION clause, the source partitioned table remains online, and queries running against the table continue to run. The data partition being detached is converted into a stand-alone table in the following two phase process:

The ALTER TABLE...DETACH PARTITION operation logically detaches the data partition from the partitioned table.
An asynchronous partition detach task converts the logically detached partition into a stand-alone table.

If there are any dependent tables that need to be incrementally maintained with respect to the detached data partition (these dependent table are referred to as detached dependent tables), the asynchronous partition detach task starts only after the SET INTEGRITY statement is run on all detached dependent tables.

In absence of detached dependent tables, the asynchronous partition detach task starts after the transaction issuing the ALTER TABLE…DETACH PARTITION statement commits.

See the related link at the end of this topic for information about the data partition detach phases.

Restrictions

If the source table is an MDC table created by DB2® Version 9.7 or earlier releases, block indexes are not partitioned. Access to the newly detached table is not allowed in the same unit of work as the ALTER TABLE…DETACH operation. MDC tables do not support partitioned block indexes. In that case, block indexes are created upon first access to the table after the ALTER TABLE…DETACH operation is committed. If the source table had any other partitioned indexes prior to detach time then the index object for the target table is marked invalid to allow for creation of the block indexes. As a result access time is increased while the block indexes are created and any partitioned indexes are recreated.

When the source table is an MDC created by DB2 V9.7 Fix Pack 1 or later releases, the block indexes are partitioned, and partitioned indexes become indexes on the target table of detach without the need to be recreated
You must meet the following conditions before you can perform a DETACH operation:

The table to be detached from (source table) must exist and be a partitioned table.
The data partition to be detached must exist in the source table.
The source table must have more than one data partition. A partitioned table must have at least one data partition. Only visible and attached data partitions pertain in this context. An attached data partition is a data partition that is attached but not yet validated by the SET INTEGRITY statement.
The name of the table to be created by the DETACH operation (target table) must not exist.
DETACH is not allowed on a table that is the parent of an enforced referential integrity (RI) relationship. If you have tables with an enforced RI relationship and want to detach a data partition from the parent table, a workaround is available. In the following example, all statements are run within the same unit of work (UOW) to lock out concurrent updates:

// Change the RI constraint to informational:
ALTER TABLE child ALTER FOREIGN KEY fk NOT ENFORCED;

ALTER TABLE parent DETACH PARTITION p0 INTO TABLE pdet;

SET INTEGRITY FOR child OFF;

// Change the RI constraint back to enforced:
ALTER TABLE child ALTER FOREIGN KEY fk ENFORCED;

SET INTEGRITY FOR child ALL IMMEDIATE UNCHECKED;
// Assuming that the CHILD table does not have any dependencies on partition P0,
//   and that no updates on the CHILD table are permitted until this UOW is complete,
//   no RI violation is possible during this UOW.

COMMIT WORK;

If there are any dependent tables that need to be incrementally maintained with respect to the detached data partition (these dependent tables are referred to as detached dependent tables), the SET INTEGRITY statement is required to be run on the detached dependent tables to incrementally maintain the tables. With DB2 V9.7 Fix Pack 1 or later releases, after the SET INTEGRITY statement is run on all detached dependent tables, the asynchronous partition detach task makes the data partition into a stand-alone target table. Until the asynchronous partition detach operation completes, the target table is unavailable.

To alter a partitioned table and to detach a data partition from the table, issue the ALTER TABLE statement with the DETACH PARTITION clause. The detached partition is renamed with a system-generated name (using the form SQLyymmddhhmmssxxx) so that a subsequent attach can reuse the detached partition name immediately.

Each of the index partitions defined on the source table for the data partition being detached becomes an index on the target table. The index object is not physically moved during the detach operation. However, the metadata for the index partitions of the table partition being detached are removed from the catalog table SYSINDEXPARTITIONS and new index entries are added in SYSINDEXES for the new table as a result of the detach operation. The original index identifier (IID) is kept and stays unique just as it was on the source table.

The index name for the surviving indexes on the target table are system-generated (using the form SQLyymmddhhmmssxxx). The schema for these indexes is the same as the schema of the target table except for any path indexes, regions indexes, and MDC Block indexes, which are in the SYSIBM schema. Other system-generated indexes like those to enforce unique and primary key constraints will have a schema of the target table because the indexes are carried over to the detached table but the constraints are not. You can use the RENAME command to rename the indexes that are not in the SYSIBM schema.

If you wish to have the same constraints on the newly detached stand-alone table, run the ALTER TABLE… ADD CONSTRAINT on the target table after completing the detach operation. Any indexes needed to satisfy the constraint already exist on the target table, if the index was partitioned on the source table.

The table level INDEX IN option specified when creating the source table is not inherited by the target table but rather the partition level INDEX IN (if specified) or the default index table space for the detach partition continues to be the index table space for the target table.
When detaching data partitions, some statistics are carried over from the partition being detached into the target table. Specifically, statistics from SYSINDEXPARTITIONS for partitioned indexes will be carried over to the entries SYSINDEXES for the newly detached table. Statistics from SYSDATAPARTITIONS will be copied over to SYSTABLES for the newly detached table.
Note: You should run RUNSTATS after the completion of the DETACH operation on both the new detached table and the source table since many of the statistics will not be carried over following the completion of the detach operation.
Before you begin
To detach a data partition from a partitioned table you must have the following authorities or privileges:

The user performing the DETACH operation must have the authority needed to ALTER, to SELECT from and to DELETE from the source table.
The user must also have the authority needed to create the target table. Therefore, to alter a table to detach a data partition, the privilege held by the authorization ID of the statement must include at least one of the following authorities or privileges on the target table:
    DBADM authority
    CREATETAB authority on the database and USE privilege on the table spaces used by the table as well as one of:
        IMPLICIT_SCHEMA authority on the database, if the implicit or explicit schema name of the table does not exist
        CREATEIN privilege on the schema, if the schema name of the table refers to an existing schema.

Note: When detaching a data partition, the authorization ID of the statement is going to effectively perform a CREATE TABLE statement and therefore must have the necessary privileges to perform that operation. The authorization ID of the ALTER TABLE statement becomes the definer of the new table with CONTROL authority, as if the user had issued the CREATE TABLE statement. No privileges from the table being altered are transferred to the new table. Only the authorization ID of the ALTER TABLE statement and users with DBADM or DATAACCESS authority have access to the data immediately after the ALTER TABLE…DETACH PARTITION statement.

Attributes of detached data partitions
When you detach a data partition from a partitioned table using the DETACH PARTITION clause of the ALTER TABLE statement, it becomes a stand-alone, nonpartitioned target table. Many attributes of the new target table are inherited from the source table. Any attributes not inherited from the source table are set as if the user executing the DETACH operation is creating the target table.
Data partition detach phases
With DB2 Version 9.7 Fix Pack 1 and later releases, detaching a data partition from a data partitioned table consists of two phases. The first phase logically detaches the partition from the table, the second phase converts the data partition into a stand-alone table.
Asynchronous partition detach for data partitioned tables
For DB2 Version 9.7 Fix Pack 1 and later releases, the asynchronous partition detach task completes the detach of a data partition from a partitioned table that was initiated by an ALTER TABLE...DETACH operation. The task is an asynchronous background process (ABP) that is initiated after the partition becomes a logically detached partition.

Related concepts:
Asynchronous partition detach for data partitioned tables
Data partition detach phases
Task topic
https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.partition.doc/doc/t0021576.html

Guidelines and restrictions on altering partitioned tables

This topic identifies the most common alter table actions and special considerations in the presence of attached and detached data partitions.
The STATUS column of the SYSCAT.DATAPARTITIONS catalog view contains the state information for the partitions of a table.

If the STATUS is the empty string, the partition is visible and is in the normal state.
If the STATUS is 'A', the partition is newly attached and the SET INTEGRITY statement must be issued to bring the attached partition into the normal state.
If the STATUS is 'D', 'L', or 'I', the partition is being detached, but the detach operation has not completed.
    For a partition in the 'D' state, the SET INTEGRITY statement must be issued on all detached dependent tables in order to transition the partition to the logically detached state.
    For a partition in the 'L' state, the partition is a logically detached partition and the asynchronous partition detach task is completing the detach of the partition for DB2® Version 9.7 Fix Pack 1 and later releases.
    For a partition in the 'I' state the asynchronous partition detach task has completed and asynchronous index cleanup is updating nonpartitioned indexes defined on the partition.

Adding or attaching a data partition - locking behavior
For information about locking behavior during an add partition or attach partition operation, see the “Scenarios: Rolling in and rolling out partitioned table data” topic.
Adding or altering a constraint
Adding a check or a foreign key constraint is supported with attached and detached data partitions. When a partitioned table has detached partitions in state ‘D’ or ‘L’, adding a primary or unique constraint will return an error if the system has to generate a new partitioned index to enforce the constraint. For a partition in the ‘L’ state, the operation returns SQL20285N (SQLSTATE 55057). For a partition in the ‘D’ state, the operation returns SQL20054 (SQLSTATE 55019).
Adding a column
When adding a column to a table with attached data partitions, the column is also added to the attached data partitions. When adding a column to a table with detached data partitions in the ‘I’ state, the column is not added to the detached data partitions because the detached data partitions are no longer physically associated to the table.

For a detached partition in the 'L' or 'D' state, the operation fails and an error is returned. For a partition in the 'L' state, the operation returns SQL20285N (SQLSTATE 55057). For a partition in the 'D' state, the operation returns SQL20296N (SQLSTATE 55057).

Altering a column
When altering a column in a table with attached data partitions, the column will also be altered on the attached data partitions. When altering a column in a table with detached data partitions, the column is not altered on the detached data partitions, because the detached data partitions are no longer physically associated to the table.

When dropping or renaming a column when a partition is detached in the 'L' or 'D' state the operation fails and an error is returned. For a partition in the 'L' state, the operation returns SQL20285N (SQLSTATE 55057). For a partition in the 'D' state, the operation returns SQL0270N (SQLSTATE 42997).

Adding a generated column
When adding a generated column to a partitioned table with attached or detached data partitions, it must respect the rules for adding any other types of columns.
Adding or modifying a nonpartitioned index
When creating, recreating, or reorganizing an index on a table with attached data partitions, the index does not include the data in the attached data partitions because the SET INTEGRITY statement maintains all indexes for all attached data partitions. When creating, recreating or reorganizing an index on a table with detached data partitions, the index does not include the data in the detached data partitions, unless the detached data partition has a detached dependent table or staging tables that need to be incrementally refreshed with respect to the data partition, the partition is in the ‘D’ state. In this case, the index includes the data for this detached data partition.
Adding or modifying a partitioned index

When creating a partitioned index in the presence of attached data partitions, an index partition for each attached data partition will be created. The index entries for index partitions on attached data partitions will not be visible until the SET INTEGRITY statement is run to bring the attached data partitions online. Note that because create index includes the attached data partitions, creation of a unique partitioned index may find rows in the attached data partition which are duplicate key values and thus fail the index creation. It is recommended that users do not attempt to create partitioned indexes in the presence of attached partitions to avoid this problem.

If the table has any detached dependent tables, creation of partitioned indexes is not supported on partitioned tables with detached dependent tables. Any attempt to create a partitioned index in this situation will result in SQLSTATE 55019. When creating a partitioned index on a table that has partitions in 'L' state, the operation returns SQL20285N (SQLSTATE 55057).

WITH EMPTY TABLE
You cannot empty a table with attached data partitions.
ADD MATERIALIZED QUERY AS
Altering a table with attached data partitions to an MQT is not allowed.
Altering additional table attributes that are stored in a data partition
The following table attributes are also stored in a data partition. Changes to these attributes are reflected on the attached data partitions, but not on the detached data partitions.

    DATA CAPTURE
    VALUE COMPRESSION
    APPEND
    COMPACT/LOGGED FOR LOB COLUMNS

Related concepts:
Clustering of nonpartitioned indexes on partitioned tables
Data partition detach phases
Data partitions and ranges
Index behavior on partitioned tables
Large object behavior in partitioned tables
Partitioned tables
Related reference:
ALTER TABLE statement
Scenarios: Rolling in and rolling out partitioned table data
SET INTEGRITY statement
Reference topic
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.partition.doc/doc/r0021570.html

Asynchronous partition detach for data partitioned tables

For DB2® Version 9.7 Fix Pack 1 and later releases, the asynchronous partition detach task completes the detach of a data partition from a partitioned table that was initiated by an ALTER TABLE…DETACH operation. The task is an asynchronous background process (ABP) that is initiated after the partition becomes a logically detached partition.

The asynchronous partition detach task accelerates the process of detaching a data partition from a partitioned table. If the partitioned table has dependent materialized query tables (MQTs), the task is not initiated until after a SET INTEGRITY statement is executed on the MQTs.

By completing the detach of the data partition asynchronously, queries accessing the partitioned table that started prior to issuing ALTER TABLE…DETACH PARTITION statement continue while the partition is immediately detached.

If there are any dependent tables that need to be incrementally maintained with respect to the detached data partition (these dependent tables are referred to as detached dependent tables), the asynchronous partition detach task starts only after the SET INTEGRITY statement is run on all detached dependent tables.

In the absence of detached dependents, the asynchronous partition detach task starts after the transaction issuing the ALTER TABLE…DETACH PARTITION statement commits.
The asynchronous partition detach task performs the following operations:

Performs hard invalidation on cached statements on which the ALTER TABLE...DETACH operation previously performed soft invalidation.
Updates catalog entries for source partitioned table and target stand-alone table and makes the target table available.
For multidimensional clustering (MDC) tables with nonpartitioned block indexes and no other partitioned indexes, creates an index object for target table. The block indexes are created upon first access to the target table after the asynchronous partition detach task commits.
Creates the system path index on the target table for table containing XML columns.
Updates the minimum recovery time (MRT) of the table space containing the detached partition.
Creates asynchronous index cleanup AIC tasks for nonpartitioned indexes. The AIC task performs index cleanup after asynchronous partition detach completes.
Releases the data partition ID if nonpartitioned indexes do not exist on the table.

Asynchronous partition detach task impact on performance

An asynchronous partition detach task incurs minimal performance impact. The task waits for all access to the detached partition to complete by performing a hard invalidation on cached statements on which the ALTER TABLE…DETACH operation previously performed soft invalidation. Then the task acquires the required locks on the table and on the partition and continues the process to make the detached partition a stand-alone table.
Monitoring the asynchronous partition detach task

The distribution daemon and asynchronous partition detach task agents are internal system applications that appear in LIST APPLICATIONS command output with the application names db2taskd and db2apd, respectively. To prevent accidental disruption, system applications cannot be forced. The distribution daemon remains online as long as the database is active. The tasks remain active until detach completes. If the database is deactivated while detach is in progress, the asynchronous partition detach task resumes when the database is reactivated.
The LIST UTILITIES command indicates whether the asynchronous partition detach task is in one of the following states:

Waiting for old access to the partitioned table to complete
Finalizing the detach operation and making the target table available

The following sample output for the LIST UTILITIES SHOW DETAIL command shows asynchronous partition detach task activity in the WSDB database:

ID = 1
Type = ASYNCHRONOUS PARTITION DETACH
Database Name = WSDB
Partition Number = 0
Description = Finalize detach for partition ‘4’ of table ‘USER1.ORDERS’,
and make table ‘USER1.FEB_ORDER’ available.
Start Time = 07/15/2009 14:52:14.476131
State = Executing
Invocation Type = Automatic
Progress Monitoring:
Description = Waiting for old access to the partitioned table to complete.
Start Time = 07/15/2009 14:52:51.268119

In the output of the LIST UTILITIES command, the main description for the asynchronous partition detach task identifies the data partition being detached and the target table created by the detach operation. The progress monitoring description provides information about the current state of the asynchronous partition detach task.
Note: The asynchronous partition detach task is an asynchronous process. To know when the target table of a detach operation is available, a stored procedure can be created that queries the STATUS column of the SYSCAT.DATAPARTITIONS catalog view and returns when the detach operation completes.
Asynchronous partition detach processing in a partitioned database environment

One asynchronous partition detach task is created for each DETACH operation independent of the number of database partitions in a partitioned database environment. The task is created on the catalog node and distributes work to the remaining database partitions, as needed.
Error handling for the asynchronous partition detach task

The asynchronous partition detach task is transaction based. All the changes made by a task will be rolled back internally if it fails. Any errors during asynchronous partition detach processing are logged in a db2diag log file. A failed task is retried later by the system.
Related concepts:
Asynchronous index cleanup
Related tasks:
Detaching data partitions
Related reference:
ALTER TABLE statement
LIST APPLICATIONS command
SET INTEGRITY statement
SYSCAT.DATAPARTITIONS catalog view
SYSCAT.TABLES catalog view
Concept topic
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.partition.doc/doc/c0056287.html