Task 2: Identify lost work and inconsistent data

In certain recovery situations (such as when you recover by truncating the log), you need to identify what work was lost and what data is inconsistent.

Procedure

To identify lost work and inconsistent data:

Obtain available information to help you determine the extent of the loss.
Db2 cannot determine what units of recovery are not completed, what database state information is lost, or what data is inconsistent in this situation. The log contains all such information, but the information is not available. The steps below explain what to do to obtain the information that is available within Db2 to help you determine the extent of the loss. The steps also explain how to start Db2 in this situation.
After restart, data is inconsistent. Results of queries and any other operations on such data vary from incorrect results to abends. Abends that occur either identify an inconsistency in the data or incorrectly assume the existence of a problem in the Db2 internal algorithms.

Attention: If the inconsistent page sets are not identified and the problems in them are not resolved after starting Db2, be aware that following this procedure and allowing access to inconsistent data involves some risk.
1. Run the print log map utility.
  The report that the utility produces includes a description of the last 100 checkpoints and provides, for each checkpoint the following information:
  - The location in the log of the checkpoint (begin and end RBA)
  - The date and time of day that the checkpoint was performed
2. Locate the checkpoint on the log prior to the point of failure (X).
  Do that by finding the first checkpoint with an end RBA that is less than X.
  Continue with the step 2 unless one of the following conditions exists:
  - You cannot find such a checkpoint. This means that a considerable amount of log has been lost.
  - You find the checkpoint, but the checkpoint is several days old, and Db2 has been operational during the interim.
  In these two cases, use one of the following procedures:
  - Recovering from a failure resulting from total or excessive loss of log data
  - Recovering from unresolvable BSDS or log data set problem during restart
Determine what work is lost and what data is inconsistent.
The portion of the log that represents activity that occurred before the failure provides information about work that was in progress at that point. From this information, you might be able to deduce what work was in progress within the inaccessible portion of the log. If use of Db2 was limited at the time or if Db2 was dedicated to a small number of activities (such as batch jobs that perform database loads or image copies), you might be able to accurately identify the page sets that were made inconsistent. To make the identification, extract a summary of the log activity up to the point of damage in the log by using the DSN1LOGP utility.
- Use the DSN1LOGP utility to specify the BEGIN CHECKPOINT RBA prior to the point of failure, which was determined in the previous task as the RBASTART. Terminate the DSN1LOGP scan prior to the point of failure on the log (X - 1) by using the RBAEND specification.
- Specify the last complete checkpoint. This is very important for ensuring that complete information is obtained from DSN1LOGP.
- Specify the SUMMARY(ONLY) option to produce a summary report.
The following figure is an example of a DSN1LOGP job that obtains summary information for the checkpoint that was described previously.
Figure 1. Sample JCL for obtaining DSN1LOGP summary output for restart
```
//ONE EXEC PGM=DSN1LOGP
//STEPLIB  DD DSN=prefix.SDSNLOADSDSNLOAD,DISP=SHR
//SYSABEND DD SYSOUT=A
//SYSPRINT DD SYSOUT=A
//SYSSUMRY DD SYSOUT=A
//BSDS     DD DSN=DSNCAT.BSDS01,DISP=SHR
//SYSIN    DD *
   RBASTART (7425468) RBAEND (7428FFF) SUMMARY (ONLY)
/*
```
Analyze the DSN1LOGP utility output.