When the ALTER TABLE DETACH operation is used to detach a single data partition from
a partitioned table, at what point does the newly detached data partition become accessible
as a standalone table?
A.
After a truncate table operation is performed in the background.
B.
Immediately after the ALTER TABLE DETACH statement is executed.
C.
Immediately after asynchronous partition detach processing completes for this data
partition.
D.
After a SET INTEGRITY statement is executed.
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.
0
0