Question & Answer
Question
When rolling forward a database restored from an online backup image using the INCLUDE LOGS option, you may encounter an error message similar to the following: SQL1268N Roll-forward recovery stopped due to error SQL2062; while retrieving log file S0000659.LOG for database SAMPLE on node 0. This error may be confusing, since you may incorrectly assume that the INCLUDE LOGS option of the BACKUP DATABASE command precludes the need for additional log files.
Cause
The target system you are attempting to restore the backup image to may not have access to the facility used by the source system to archive its transaction logs. This facility may include device, file, Tivoli® Storage Manager (TSM), vendor shared library, etc.
Specifying the INCLUDE LOGS option of the BACKUP DATABASE command does not guarantee that DB2® Universal Database™ (DB2 UDB) will never search for any additional transaction logs when rolling forward a database restored from a backup image with included logs. It is standard rollforward behaviour to continue to search for additional transaction logs until no more logs are found. When no additional logs can be found, the rollforward operation ends successfully. However, if there is an error while searching for additional transaction log files, the aforementioned SQL1268N error is returned.
Why does the rollforward operation need to look for another log file? One of the most typical reasons is, for example, when you are trying to rollforward to "timestamp1". This "timestamp1" is the timestamp of the last change recorded in the last log file included in the backup image. In other words, you are trying to rollforward to the end of the logs included in the backup image. However, the rollforward operation finishes successfully only after a "timestamp2" greater than "timestamp1" has been found. The reason is that there may have been multiple database changes issued at the same time, so all of them would have the same "timestamp1". For this reason the rollforward operation cannot stop after the first such change has been found. Instead, all the changes with "timestamp1" must be processed. The best indicator of the end of processing is when a "timestamp2" greater than "timestamp1" has been found. If such a "timestamp2" cannot be found in any of the current transaction logs, the rollforward operation will attempt to find additional transaction log files (possibly from an archive location), which may result in SQL1268N if there is an error accessing the archive location.
Answer
If you need to override this functionality, for example in order to rollforward only to the end of the logs included in the backup image, then any of the following work-arounds can be used:
- Allow the missing transaction log to be found or retrieved by DB2 UDB, for example by setting up TSM correctly, or by copying the missing log to the log path manually.
- Specify the NORETRIEVE option of the ROLLFORWARD DATABASE command. This will prevent DB2 UDB from trying to obtain potentially missing transaction logs elsewhere.
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21209404