DB2 10.5 for Linux, UNIX, and Windows

Table partitioning and system-period temporal tables

A system-period temporal table can have its table data divided across multiple storage objects called data partitions. A history table associated with a system-period temporal table can also be partitioned.

When versioning is enabled, the following behaviors apply when attaching a partition to a system-period temporal table or detaching a partition from a system-period temporal table:

Attaching partitions

A table can be attached to a system-period temporal table while versioning is enabled.
The table being attached must contain all three timestamp columns (ROW BEGIN, ROW END, and TRANSACTION START ID). These timestamp columns must have the same definitions as those columns in the system-period temporal table.
The table being attached does not require a SYSTEM_TIME period definition.
While versioning is enabled, the SET INTEGRITY ... FOR EXCEPTION statement cannot be run because moving exception rows into an exception table would result in lost history. Because the exception rows are not recorded in the history table, the auditability of the data in your system-period temporal table and its associated history table is jeopardized. You can temporarily stop versioning, run the SET INTEGRITY ... FOR EXCEPTION statement, and then enable versioning again.

Detaching partitions

A table cannot be detached from a system-period temporal table while versioning is enabled. You can stop versioning and then detach a partition from the base table. The detached partition becomes an independent table. Detaching a partition from a history table does not require that you stop versioning.
A detached partition retains all three timestamp columns (ROW BEGIN, ROW END, and TRANSACTION START ID), but not the SYSTEM_TIME period definition.
The rows in a detached partition are not automatically moved to the history table. If you want to maintain the history, then the rows must be moved manually. If you manually move the rows to the history table, you should change the ROW END timestamp to the point-in-time when the rows changed from being current to being history. Without these changes, time-related queries might return unexpected results.