Recovering Db2-managed data sets for accidentally dropped table spaces
If a consistent full image copy or DSN1COPY file is available, you can use DSN1COPY to recover a dropped table space that resides in Db2-managed data sets.
Procedure
To recover a dropped table space:
- Find the original DBID for the database, the PSID for the table space, and the OBIDs of all tables that are contained in the dropped table space.
- Run the DSN1PRNT utility for the data set that contains the dropped table space, with the FORMAT and NODATA options to locate the following values for the table space:
- DBID
- The first two bytes in the 4-byte field HPGOBID of the header page contain the DBID for the database.
- PSID
- The last two bytes in field HPGOBID of the header page contain the PSID for the table space.
- OBID
- For universal (UTS), partitioned (non-UTS), or LOB table spaces, the HPGROID field of the header page contains the OBID for the single table in the table space.
For segmented (non-UTS) table spaces, field SEGOBID in the space map page contains the OBIDs. If the table space contains more than one table, you must specify all OBIDs from the data set as input to the DSN1COPY utility.
- Convert the hex values in the identifier fields to decimal so that they can be used as input for the DSN1COPY utility.
- Run the DSN1PRNT utility for the data set that contains the dropped table space, with the FORMAT and NODATA options to locate the following values for the table space:
- Re-create the table space and all
tables. This re-creation can be difficult when any of the following
conditions is true:
- A table definition is not available.
- A table is no longer required.
If you cannot re-create a table, you must use a dummy table to take its place. A dummy table is a table with an arbitrary structure of columns that you delete after you recover the dropped table space.
Attention: When you use a dummy table, you lose all data from the dropped table that you do not re-create. - Re-create auxiliary tables and indexes if a LOB table space has been dropped.
- To allow DSN1COPY to access the Db2 data set, stop the table space with the following
command:
-STOP DATABASE(database-name) SPACENAM(tablespace-name) Find the new PSID and OBIDs by querying the SYSIBM.SYSTABLESPACE and SYSIBM.SYSTABLES catalog tables.
The following statement returns the object ID for a table space; this is the PSID.
SELECT DBID, PSID FROM SYSIBM.SYSTABLESPACE WHERE NAME='tablespace_name' and DBNAME='database_name' AND CREATOR='creator_name';The following statement returns the object ID for a table:
SELECT NAME, OBID FROM SYSIBM.SYSTABLES WHERE NAME='table_name' AND CREATOR='creator_name';These values are returned in decimal format, which is the format that you need for DSN1COPY. (Find the OBID of the dummy table that you created in step 2 if you could not re-create a table.)
- Run DSN1COPY with the OBIDXLAT and RESET options to translate
the OBID and to copy data from a previous full image copy data set,
inline copy data set, or DSN1COPY file. Use one of these copies as
the input data set SYSUT1 in the control statement. Specify each of
the input records in the following order in the SYSXLAT file to perform
OBID translations:
- The DBID that you recorded in step 1 as both the translation source and the translation target
- The PSID that you recorded in step 1 as the translation source and the PSID that you recorded in step 5 as the translation target
- The OBIDs that you recorded in step 1 as the translation sources and the OBIDs that you recorded in step 5 as the translation targets
Be sure that you name the VSAM data sets correctly by checking messages DSN1998I and DSN1997I after DSN1COPY completes.
- Use DSN1COPY with the OBIDXLAT and RESET options to apply
any incremental image copies to the recovered table space. You must
apply these incremental copies in sequence, and specify the same SYSXLAT
records that step Recovering user-managed data sets for accidentally dropped table spaces specifies.
Important: After you complete this step, you have essentially recovered the table space to the point in time of the last image copy. If you want to use log records to perform forward recovery on the table space, you must use IBM® Db2 Recovery Expert for z/OS® or IBM Db2 Log Analysis Tool for z/OS at this point in the recovery procedure.
For more information about point-in-time recovery, see Recovery of data to a prior point in time.
- Start the table space for normal use by using the following
command:
-START DATABASE(database-name) SPACENAM(tablespace-name) - Drop all dummy tables. The row structure does not match the table definition. This mismatch makes the data in these tables unusable.
- Reorganize the table space to remove all rows from dropped tables.
- Rebuild all indexes on the table space.
- Execute SELECT statements on each table in the recovered table space to verify the recovery. Include all LOB columns in these queries.
- Make a full image copy of the table space.
See Page set and data set copies for more information about the COPY utility.
- Re-create the objects that are dependent on the table.
See step Recovering an accidentally dropped table for more information.