Cloned tables

(SPE2010)

You can process tables in a clone relationship only when they are in current mode. If you process tables in a clone relationship when they are in overtime mode, a warning message is displayed, activity for the cloned tables is ignored, and processing continues.

When a clone table is created, a second instance of the physical table space is also created. SYSIBM.SYSTABLESPACE includes only a single entry for the cloned table space. The value of the INSTANCE column in SYSIBM.SYSTABLESPACE is set to either 1 or 2. The value of the column reflects which table space instance is currently the base instance.

When an exchange occurs, the column value is updated to reflect the new base table instance. 

The PSID of instance 2 always has the high bit turned on. The PSID and OBID in the log record are used to determine which object was updated. The PSID for instance 2 of the table space has the high bit turned on.

The OBID of the clone table also has the high bit turned on.

If a row is inserted into the base table, and the current instance for the base table is instance 1, then the OBID in the log is set to x0003 and the PSID is set to x0002. If an exchange occurs, and a row is inserted into the base table, the OBID in the log record is still set to x0003. However, the PSID is set to 0x8002, because the current table space instance was set to 2 after the exchange. For more information, see Cloned tables#Updates to PSID, OBID, INSTANCE, and CREATE RBA.

When a clone table is dropped, SYSCOPY and SYSLGRNX information for the table space instance that is currently related to the clone table is deleted. If the SYSCOPY information is needed to process the log activity for the table space instance that was dropped, the log activity might not be recoverable with a log scan. Log scans for the previous life of the base table is still possible if row completion or decompression is not required, or if SYSCOPY information is available in the Log Master SYSCOPY repository table. Log scans for the previous life of the base table might result in an error if SYSCOPY information is needed for completion, decompression, or version processing. For more information, see Row-completion-processing-and-your-jobs.

The CREATE RBA for the base table is not updated when an exchange occurs. If a clone table is dropped and re-created, the CREATE RBA (RBA1 in SYSIBM.SYSTABLES) is reset and reflects a new life of the clone table.

If a base table is exchanged with the clone table, dropped, and then re-created, the CREATE RBA of the base table is not updated. Running an exchange, dropping, and then re-creating the clone multiple times is equivalent to dropping and re-creating the base table. However, Log Master cannot detect this because there is no update to the base table’s create RBA.  For more information, see Cloned tables#Updates to PSID, OBID, INSTANCE, and CREATE RBA.

Log Master compares the log’s RBA with the table’s create RBA. If the log’s RBA is less than the table’s create RBA, the log record is ignored. Otherwise, it is included in the log scan processing.

Updates to PSID, OBID, INSTANCE, and CREATE RBA

The following table describes the updates to PSID, OBID, INSTANCE, and CREATE RBA: