Restoring data in a non-data sharing environment

If you are in a non-data sharing environment, you might need to recover from a disaster by restoring data from image copies and logs. The procedure that you follow assumes that all logs, image copies, and reports are available at the recovery site.

Procedure

To recover from a disaster in a non-data sharing environment by using image copies and archive logs:

If an integrated catalog facility catalog does not already exist, run job DSNTIJCA to create a user catalog.
Use the access method services IMPORT command to import the integrated catalog facility catalog.
Restore Db2 libraries.
Some examples of libraries that you might need to restore include:
- Db2 SMP/E libraries
- User program libraries
- User DBRM libraries
- Db2 CLIST libraries
- Db2 libraries that contain customized installation jobs
- JCL for creating user-defined table spaces
Use IDCAMS DELETE NOSCRATCH to delete all catalog and user objects.
(Because step 2 imports a user ICF catalog, the catalog reflects data sets that do not exist on disk.)
Obtain a copy of installation job DSNTIJIN, which creates Db2 VSAM and non-VSAM data sets. Change the volume serial numbers in the job to volume serial numbers that exist at the recovery site. Comment out the steps that create Db2 non-VSAM data sets, if these data sets already exist. Run DSNTIJIN. However, do not run DSNTIJID.
Recover the BSDS:
1. Use the access method services REPRO command to restore the contents of one BSDS data set (allocated in step 5).
  You can find the most recent BSDS image in the last file (archive log with the highest number) on the latest archive log tape.
2. Determine the RBA range for this archive log by using the print log map utility (DSNJU004) to list the current BSDS contents. Find the most recent archive log in the BSDS listing, and add 1 to its ENDRBA value. Use this as the STARTRBA. Find the active log in the BSDS listing that starts with this RBA, and use its ENDRBA as the ENDRBA.
3. Delete the oldest archive log from the BSDS.
4. Register this latest archive log tape data set in the archive log inventory of the BSDS that you just restored by using the change log inventory utility (DSNJU003).
  This step is necessary because the BSDS image on an archive log tape does not reflect the archive log data set that resides on that tape. After these archive logs are registered, use the print log map utility (DSNJU004) to list the contents of the BSDS.
5. Adjust the active logs in the BSDS by using the change log inventory utility (DSNJU003), as necessary:
  1. To delete all active logs in the BSDS, use the DELETE option of DSNJU003. Use the BSDS listing that is produced in step 6.d to determine the active log data set names.
  2. To add the active log data sets to the BSDS, use the NEWLOG statement of DSNJU003. Do not specify a STARTRBA or ENDRBA in the NEWLOG statement. This specification indicates to Db2 that the new active logs are empty.
6. If you are using the Db2 distributed data facility, update the LOCATION and the LUNAME values in the BSDS by running the change log inventory utility with the DDF statement.
7. List the new BSDS contents by using the print log map utility (DSNJU004). Ensure that the BSDS correctly reflects the active and archive log data set inventories.
  In particular, ensure that:
  - All active logs show a status of NEW and REUSABLE.
  - The archive log inventory is complete and correct (for example, the start and end RBAs are correct).
8. If you are using dual BSDSs, make a copy of the newly restored BSDS data set to the second BSDS data set.
Optional: Restore archive logs to disk.
Archive logs are typically stored on tape, but restoring them to disk might speed later steps. If you elect this option, and the archive log data sets are not cataloged in the primary integrated catalog facility catalog, use the change log inventory utility to update the BSDS. If the archive logs are listed as cataloged in the BSDS, Db2 allocates them by using the integrated catalog and not the unit or VOLSER that is specified in the BSDS. If you are using dual BSDSs, remember to update both copies.
Use the DSN1LOGP utility to determine which transactions were in process at the end of the last archive log. Use the following job control language where yyyyyyyyyyyy is the STARTRBA of the last complete checkpoint within the RBA range on the last archive log from the previous print log map:
```
 //SAMP  EXEC PGM=DSN1LOGP
 //SYSPRINT DD SYSOUT=*  
 //SYSSUMRY DD SYSOUT=*
 //ARCHIVE  DD DSN=last-archive, DISP=(OLD,KEEP),UNIT=TAPE, 
               LABEL=(2,SL),VOL=SER=volser1
               (NOTE FILE 1 is BSDS COPY
 //SYSIN    DD *    
  STARTRBA(yyyyyyyyyyyy) SUMMARY(ONLY)  
 /*
```
DSN1LOGP generates a report.
Examine the DSN1LOGP output, and identify any utilities that were executing at the end of the last archive log. Determine the appropriate recovery action to take on each table space that is involved in a utility job.
If DSN1LOGP output showed that utilities are inflight (PLAN=DSNUTIL), examine SYSUTILX to identify the utility status and determine the appropriate recovery approach.
Modify DSNZPxxx parameters:
1. Run the DSNTINST CLIST in UPDATE mode.
  For more information, see Generating tailored Db2 13 installation, migration, or function level activation jobs
2. To defer processing of all databases, select DATABASES TO START AUTOMATICALLY from panel DSNTIPB.
  Panel DSNTIPS opens. On panel DSNTIPS, type DEFER in the first field and ALL in the second field; then press Enter.
  You are returned to panel DSNTIPB.
3. To specify where you are recovering, select OPERATOR FUNCTIONS from panel DSNTIPB.
  Panel DSNTIPO opens. From panel DSNTIPO, type RECOVERYSITE in the SITE TYPE field. Press Enter to continue.
4. To prevent format conversions during Disaster Recovery, select SQL OBJECT DEFAULTS PANEL 1 from panel DSNTIPB.
  Panel DSNTIP7 opens. From panel DSNTIP7, set the UTILITY_OBJECT_CONVERSION value to NONE. Press Enter to continue. Format conversions complicate the recovery process and can lead to failures. Reset this parameter to its original value after the Disaster Recovery completes.
5. Optional: Specify which archive log to use by selecting OPERATOR FUNCTIONS from panel DSNTIPB.
  Panel DSNTIPO opens. From panel DSNTIPO, type YES in the READ COPY2 ARCHIVE field if you are using dual archive logging and want to use the second copy of the archive logs. Press Enter to continue.
6. Reassemble DSNZPxxx by using job DSNTIJUZ (produced by the CLIST started in the first step of this procedure).
  
  At this point, you have the log, but the table spaces have not been recovered. With DEFER ALL, Db2 assumes that the table spaces are unavailable but does the necessary processing to the log. This step also handles the units of recovery that are in process.
Create a conditional restart control record by using the change log inventory utility with one of the following forms of the CRESTART statement:
- ```
CRESTART CREATE,ENDRBA=nnnnnnnnn000
```
  The nnnnnnnnn000 equals a value that is one more than the ENDRBA of the latest archive log.
- ```
CRESTART CREATE,ENDTIME=nnnnnnnnnnnn
```
  The nnnnnnnnnnnn is the end time of the log record. Log records with a timestamp later than nnnnnnnnnnnn are truncated.
Enter the command START DB2 ACCESS(MAINT).

You must enter this command, because real-time statistics are active and enabled; otherwise, errors or abends could occur during Db2 restart processing and recovery processing (for example, GRECP recovery, LPL recovery, or the RECOVER utility).

Even though Db2 marks all table spaces for deferred restart, log records are written so that in-abort and inflight units of recovery are backed out. In-commit units of recovery are completed, but no additional log records are written at restart to cause this. This happens when the original redo log records are applied by the RECOVER utility.

At the primary site, Db2 probably committed or aborted the inflight units of recovery, but you have no way of knowing.

During restart, Db2 accesses two table spaces that result in DSNT501I, DSNT500I, and DSNL700I resource unavailable messages, regardless of DEFER status. The messages are normal and expected, and you can ignore them.

The following return codes can accompany the message. Other codes are also possible.

00C90081

This return code is issued for activity against the object that occurs during restart as a result of a unit of recovery or pending writes. In this case, the status that is shown as a result of DISPLAY is STOP,DEFER.

00C90094

Because the table space is currently only a defined VSAM data set, it is in a state that Db2 does not expect.

00C90095

Db2 cannot access the page, because the table space or index space has not been recovered yet.

00C900A9

An attempt was made to allocate a deferred resource.
Resolve the indoubt units of recovery.
The RECOVER utility, which you run in a subsequent step, fails on any table space that has indoubt units of recovery. Because of this, you must resolve them first. Determine the proper action to take (commit or abort) for each unit of recovery. To resolve indoubt units of recovery, see Resolving indoubt units of recovery. From an installation SYSADM authorization ID, enter the RECOVER INDOUBT command for all affected transactions.
Recover the catalog and directory.
The RECOVER function includes: RECOVER TABLESPACE, RECOVER INDEX, or REBUILD INDEX. If you have an image copy of an index, use RECOVER INDEX. If you do not have an image copy of an index, use REBUILD INDEX to reconstruct the index from the recovered table space.
1. Recover DSNDB01.SYSUTILX.
  This must be a separate job step.
2. Recover all indexes on SYSUTILX.
  This must be a separate job step.
3. Determine whether a utility was running at the time the latest archive log was created by entering the DISPLAY UTILITY(*) command, and record the name and current phase of any utility that is running.
  (You cannot restart a utility at the recovery site that was interrupted at the disaster site. You must use the TERM UTILITY command to terminate it. Use the TERM UTILITY command on a utility that is operating on any object except DSNDB01.SYSUTILX.)
4. Run the DIAGNOSE utility with the DISPLAY SYSUTIL option.
  The output consists of information about each active utility, including the table space name (in most cases). This is the only way to correlate the object name with the utility. Message DSNU866I gives information about the utility, and DSNU867I gives the database and table space name in USUDBNAM and USUSPNAM, respectively.
5. Use the TERM UTILITY command to terminate any utilities that are in progress on catalog or directory table spaces.
6. Recover the rest of the catalog and directory objects, starting with DBD01, in the order shown in the description of the RECOVER utility.
Define and initialize the work file database:
1. Define temporary work files. Use installation job DSNTIJTM as a model.
2. Issue the command START DATABASE(work-file-database) to start the work file database.
Use any method that you want to verify the integrity of the Db2 catalog and directory.
Use the catalog queries in member DSNTESQ of data set DSN1310.SDSNSAMP after the work file database is defined and initialized.
If you use data definition control support, recover the objects in the data definition control support database.
If you use the resource limit facility, recover the objects in the resource limit control facility database.
Modify DSNZPxxx to restart all databases:
1. Run the DSNTINST CLIST in UPDATE mode.
2. From panel DSNTIPB, select DATABASES TO START AUTOMATICALLY.
  Panel DSNTIPS opens. Type RESTART in the first field and ALL in the second field, and press Enter.
  You are returned to DSNTIPB.
3. Reassemble DSNZPxxx by using job DSNTIJUZ (produced by the CLIST started in step 3).
Stop Db2.
Start Db2.
Make a full image copy of the catalog and directory.
Recover user table spaces and index spaces.
If utilities were running on any table spaces or index spaces, see What to do about utilities that were in progress at time of failure. You cannot restart a utility at the recovery site that was interrupted at the disaster site. Use the TERM UTILITY command to terminate any utilities that are running against user table spaces or index spaces.
1. To determine which, if any, of your table spaces or index spaces are user-managed, perform the following queries for table spaces and index spaces.
  - Table spaces:
```
SELECT * FROM SYSIBM.SYSTABLEPART WHERE STORTYPE='E'; 
```
  - Index spaces:
```
SELECT * FROM SYSIBM.SYSINDEXPART WHERE STORTYPE='E';
```
  To allocate user-managed table spaces or index spaces, use the access method services DEFINE CLUSTER command. To find the correct IPREFIX for the DEFINE CLUSTER command, perform the following queries for table spaces and index spaces.
  - Table spaces:
    SELECT DBNAME, TSNAME, PARTITION, IPREFIX FROM SYSIBM.SYSTABLEPART WHERE DBNAME=dbname AND TSNAME=tsname ORDER BY PARTITION;
  - Index spaces:
    SELECT IXNAME, PARTITION, IPREFIX FROM SYSIBM.SYSINDEXPART WHERE IXCREATOR=ixcreator AND IXNAME=ixname ORDER BY PARTITION;
  Now you can perform the DEFINE CLUSTER command with the correct IPREFIX (I or J) in the data set name:
```
catname.DSNDBx.dbname.psname.y0001.znnn
```
  The y can be either I or J, x is C (for VSAM clusters) or D (for VSAM data components), and spname is either the table space or index space name.
2. If your user table spaces or index spaces are STOGROUP-defined, and if the volume serial numbers at the recovery site are different from those at the local site, use the SQL statement ALTER STOGROUP to change them in the Db2 catalog.
3. Recover all user table spaces and index spaces from the appropriate image copies.
  If you do not copy your indexes, use the REBUILD INDEX utility to reconstruct the indexes.
4. Start all user table spaces and index spaces for read-write processing by issuing the command START DATABASE with the ACCESS(RW) option.
5. Resolve any remaining CHECK-pending states that would prevent COPY execution.
6. Run queries for which the results are known.
Make full image copies of all table spaces and indexes with the COPY YES attribute.
Compensate for work that was lost since the last archive was created by rerunning online transactions and batch jobs.
If subsystem parameter CDDS_MODE is set to SOURCE_ONLY, populate the compression dictionary data set (CDDS) so that Db2 can use the expansion dictionaries in the CDDS to decompress log records for IFI calls for IFCID 306. Follow these steps:
1. Define the CDDS if it is not already defined. See Storing the expansion dictionary for compressed log records in the compression dictionary data set for an example of the CDDS definition.
2. Issue the -START CDDS command to direct the Db2 subsystem or all data sharing members to allocate and open the CDDS.
3. To populate the CDDS, run REORG TABLESPACE with the INITCDDS option on each compressed table space or partition that contains a table that is defined with DATA CAPTURE CHANGES. You can specify the SEARCHTIME option with the INITCDDS option to allow REORG to populate the CDDS with an earlier dictionary than the dictionary that currently resides in the table space.

What to do next

Determine what to do about any utilities that were in progress at the time of failure.