Locating archive log data sets

To ensure that you can recover your data in the event of a failure, you need to locate archive log data sets.

To locate archive log data sets:

1. Resolve indoubt units of recovery. If Db2 is running with TSO, continue with step 2. If Db2 is running with IMS, CICS®, or distributed data, the following substeps apply:
   1. Ensure that the period between one startup and the next startup is free of any indoubt units of recovery. Ensure that no Db2 activity is going on when you are performing this set of substeps. (To minimize impact on users, consider planning this work for a non-prime shift.) To determine whether indoubt units of recovery exist, issue the following Db2 command:

      -DISPLAY THREAD TYPE(INDOUBT)

      If you find no indoubt units of recovery, skip to step 2.

   2. If one or more indoubt units of recovery exist, take one of the following actions:
      • If IMS or CICS is involved with the indoubt units of work, start IMS or CICS. Starting IMS or CICS causes that subsystem to resolve the indoubt units of recovery. If the thread is a distributed indoubt unit of recovery, restart the distributed data facility (DDF) to resolve the unit of work. If DDF does not start or cannot resolve the unit of work, issue the following command to resolve the unit of work:

        -RECOVER INDOUBT

      • Issue the following Db2 command:

        -RECOVER INDOUBT

   3. Reissue the DISPLAY THREAD TYPE(INDOUBT) command to ensure that the indoubt units have been recovered. When no indoubt units of recovery remain, continue with step 2.
2. Find the startup log RBA. Keep at least all log records with log RBAs greater than the one that is given in this message, which is issued at restart:

   DSNR003I RESTART...PRIOR CHECKPOINT RBA=xxxxxxxxxxxx

   If you suspended Db2 activity while performing step 1, restart Db2 now.

3. Find the minimum log RBA that is needed. Suppose that you have determined to keep some number of complete image copy cycles of your least-frequently copied table space. You now need to find the log RBA of the earliest full image copy that you want to keep.
   1. If you have any table spaces that were created so recently that no full image copies of them have ever been taken, take full image copies of them. If you do not take image copies of them, and you discard the archive logs that log their creation, Db2 can never recover them.
      The following SQL statement generates a list of the table spaces for which no full image copy is available:

      SELECT X.DBNAME, X.NAME, X.CREATOR, X.NTABLES, X.PARTITIONS
        FROM SYSIBM.SYSTABLESPACE X
          WHERE NOT EXISTS (SELECT * FROM SYSIBM.SYSCOPY Y
                              WHERE X.NAME = Y.TSNAME
                              AND X.DBNAME = Y.DBNAME
                              AND Y.ICTYPE = 'F')
        ORDER BY 1, 3, 2;

      
   2. Issue the following SQL statement to find START_RBA values:
      

      SELECT DBNAME, TSNAME, DSNUM, ICTYPE, TIMESTAMP, HEX(START_RBA)
        FROM SYSIBM.SYSCOPY
        ORDER BY DBNAME, TSNAME, DSNUM, TIMESTAMP;

      

      The statement generates a list of all databases and the table spaces within them, in ascending order by date.

   3. Find the START_RBA value for the earliest full image copy (ICTYPE=F) that you intend to keep. If your least-frequently copied table space is partitioned, and you take full image copies by partition, use the earliest date for all the partitions.

      If you plan to discard records from SYSIBM.SYSCOPY and SYSIBM.SYSLGRNX, note the date of the earliest image copy that you want to keep.

4. Use job DSNTIJIC to copy all catalog and directory table spaces. Doing so ensures that copies of these table spaces are included in the range of log records that you plan to keep.
5. Locate and discard archive log volumes. Now that you know the minimum log RBA, from step 3, suppose that you want to find archive log volumes that contain only log records earlier than that. Proceed as follows:
   1. Execute the print log map utility (DSNJU004) to print the contents of the BSDS.
   2. Find the sections of the output titled ARCHIVE LOG COPY n DATA SETS. (If you use dual logging, two sections exist.) The STARTRBA and ENDRBA columns in the output show the range of log RBAs that are contained in each volume. Find the volumes (two, for dual logging) whose ranges include the minimum log RBA that you found in step 3. These volumes are the earliest volumes that you need to keep.

      If no volumes have an appropriate range, one of the following cases applies:

      • The minimum log RBA has not yet been archived, and you can discard all archive log volumes.
      • The list of archive log volumes in the BSDS wrapped around when the number of volumes exceeded the maximum number that is allowed. The maximum number is specified in the RECORDING MAX field (MAXARCH subsystem parameter) of installation panel DSNTIPA. If the BSDS does not register an archive log volume, it can never be used for recovery. Therefore, consider adding information about existing volumes to the BSDS.

        Also, consider increasing the value of the MAXARCH subsystem parameter to change the maximum number of archive log volumes that are to be recorded in the BSDS.

   3. Delete any archive log data set or volume (both copies, for dual logging) whose ENDRBA value is less than the STARTRBA value of the earliest volume that you want to keep.

      Because BSDS entries wrap around, the first few entries in the BSDS archive log section might be more recent than the entries at the bottom. Look at the combination of date and time to compare age. Do not assume that you can discard all entries above the entry for the archive log that contains the minimum log RBA.

   4. Delete the data sets. If the archives are on tape, scratch the tapes. If they are on disks, run a z/OS® utility to delete each data set. Then, if you want the BSDS to list only existing archive volumes, use the change log inventory utility (DSNJU003) to delete entries for the discarded volumes.