Recovering a dropped table space or table

The following considerations apply to drop recovery:

• Drop recovery for indexes is not supported.
• When you are performing a drop recovery for a range-partitioned table space, the number of partitions must match. For the drop recovery of a partition-by-growth (PBG) universal spaces where the number of source data sets differs from the number of target data sets, BMC AMI Recover determines the number of source data sets and acts accordingly.
• If the dropped space was versioned, you must recreate the space with the same versions, or in some cases, you can use DB2 REPAIR VERSIONS.
  • If the dropped space has been reorganized after the first alter, you can recreate the space to match the latest version of the space, recover the space, and then run DB2 REPAIR VERSIONS. You cannot rebuild indexes until after you run DB2 REPAIR VERSIONS.
  • If the dropped space has not been reorganized, you must recreate the space as it existed originally, before any alters, perform the alters to create the same versions that the dropped space had, and then recover the space.
• For more information, see Handling-Db2-versioning-information.

 The following figure shows how you can use the BMC AMI Recover product to recover a dropped table space. 

To recover a dropped table space, you must first re-create the Db2 table space and index structures. To simplify the task of re-creating objects, you can use the BMC AMI Catalog Manager for Db2, ALTER, or BMC AMI Change Manager for Db2 products.

BMC AMI Recover rebuilds the data in the table space as it existed at the time of the drop by

• Using the OBIDXLAT clause to translate the old OBIDs
• Using the INCOPY option for image copies that are now unregistered as input
• Using the NOSYSLGRNG option to bypass the SYSLGRNX table when determining which log to scan

This section provides an examples for the recovery of a dropped table space or table.