分类：
2012-11-08 11:28:23
原文地址：DB2 ROLLFORWARD DB 作者：fyuansheng
情景：
db2 rollforward的时候报以下相关错误信息：
$ db2 "rollforward db ksdbs to end of logs and complete overflow log path (/tmp)"
SQL1268N Roll-forward recovery stopped due to error "SQL1042" while
retrieving log file "S0535131.LOG" for database "KSDBS" on node "0".
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.
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.
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:
