LOB and XML object recovery
The following XML-related objects must always be recovered to the same point:
The following XML-related objects must always be recovered to the same point:
base XML table space — contains the XML base table, where the logical XML column is stored
- DocID index on the DOCID column in the base table
- XML table space — contains the XML auxiliary table, where the data is physically stored
- NodeID index on the XML table space
- XML index on the XML table space
BMC AMI Recovery Manager performs a number of checks and special processing to ensure that LOBs and XML objects are backed up and recovered correctly, as follows:
- Enables you to automatically include all LOB-related or XML-related spaces in the application object sets that you create
- Supports backup and recovery of LOB spaces and XML spaces using BMC or IBM utilities
- Issues warnings if you attempt to recover an object without its LOB or XML-related spaces
- Optionally generates CHECK or REPAIR steps after recovery to remove CHECK-pending, REBUILD-pending, or AUXW statuses
The following table shows the status in which Db2 places LOB or XML-related objects after different types of recoveries. BMC AMI Recovery Manager generates JCL to remove the objects from pending status when possible.
Object | Recovery type | Base table space status | Index on auxiliary table status (ROWID, NodeID, or XML values) | LOB or XML table space status |
|---|---|---|---|---|
Base table space | Current RBA or LRSN | None | None | None |
Base table space | Point-in-time | CHECK-pending | None | None |
Index on the auxiliary table (ROWID, node ID, or XML) | Current RBA or LRSN | None | None | None |
Index on the auxiliary table (ROWID, node ID, or XML) | Point-in-time | None | CHECK -pending 1 | None |
LOB or XML table space | Current RBA or LRSN, LOB, or XML with LOG(YES) | None | None | None |
LOB or XML table space | Current RBA or LRSN, LOB, or XML with LOG(NO) 2 | None | None | Auxiliary warning 3 |
LOB or XML table space | TOCOPY copy was SHRLEVEL REFERENCE | CHECK-pending 1 | REBUILD-pending 4 | None |
LOB or XML table space | TOCOPY copy was SHRLEVEL CHANGE | CHECK-pending 1 | REBUILD-pending 4 | CHECK-pending or auxiliary warning 5 |
LOB or XML table space | TORBA or TOLOGPOINT (not a quiesce point) | CHECK-pending 1 | REBUILD-pending 4 | CHECK-pending or auxiliary warning 5 |
LOB or XML table space | TORBA or TOLOGPOINT (at a quiesce point) | CHECK-pending 1 | REBUILD-pending | None |
1.Dependent table spaces that are related by informational referential constraints are not put into CHECK-pending status.
2.BMC AMI Recovery Manager does not generate REPAIR JCL for a LOB or XML table space defined as LOG(NO) even when you set the Check Action to Repair because doing so would remove the exception status.
3.If a log record is applied to a LOB or XML table space, and the LOB or XML is marked invalid, the LOB or XML table space is set to auxiliary warning status.
4.BMC AMI Recovery Manager generates JCL to remove the index from REBUILD-pending status if the index is in the same object set as the LOB or XML table space
5.BMC AMI Recovery Manager generates JCL to remove the LOB or XML table space from CHECK-pending status if it is in the same object set as the LOB or XML base table space. If the table space was defined as LOG(NO), recovered, and updated since the last image copy, it is placed in Auxiliary Warning status rather than CHECK-pending. In this case, BMC AMI Recovery Manager does not generate REPAIR JCL. Specify CHECK PEND REPAIR if you want the AUXW status repaired.