DB2 - Problem description
Problem IT40877 | Status: Closed |
RETRIEVE LOG FILE FAILED WITH SQLP_LOG_NOT_IN_ARCHIVE ERROR DUE TO SEARCHING WITH WRONG LOGCHAINID IN LOG ARCHIVE | |
product: | |
DB2 FOR LUW / DB2FORLUW / B50 - DB2 | |
Problem description: | |
This error can impact various operations that needs to retrieve log files from archive, such as online backup and replication (Qrep or CDC). This problem only exits in version 11.5.6 and 11.5.7. It only impacts databases using the HADR feature. It is triggered when the HADR standby was reinitialized (via restoring a backup image) without first dropping the database. The follow messages in db2diag.log shows an example of this problem, where the particular log file, S1234567.LOG, was successfully archived by Db2, yet the later attempt to retrieve it failed with SQLP_LOG_NOT_IN_ARCHIVE error. 2022-04-28-06.00.02.250144+240 I260277A558 LEVEL: Info PID : 12845548 TID : 5044 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : MYDB HOSTNAME: myhost EDUID : 5044 EDUNAME: db2logmgr (MYDB) 0 FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180 DATA #1 : Completed archive for log file S1234567.LOG to /myarchive/db2inst1/MYDB/NODE0000/LOGSTREAM0000/C0000021/ from ... 2022-04-28-07.08.52.511287+240 I271131A688 LEVEL: Warning PID : 12845548 TID : 5044 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : MYDB HOSTNAME: myhost EDUID : 5044 EDUNAME: db2logmgr (MYDB) 0 FUNCTION: DB2 UDB, data protection services, sqpLogMgrEdu::sqlpgRetrieveLogFile, probe:4062 MESSAGE : ZRC=0x8010019D=-2146434659=SQLP_LOG_NOT_IN_ARCHIVE "Log extent not found in archive." DATA #1 : String, 38 bytes Search on disk did not find any chain. DATA #2 : db2LogStreamIDType, PD_TYPE_DB2_LOG_STREAM_ID, 2 bytes 0 DATA #3 : SQLPG_EXTENT_NUM, PD_TYPE_SQLPG_EXTENT_NUM, 4 bytes 1234567 This happens because there is a mismatch of the log chain subdirectory used by the retrieve with what was used by the archive. In the above example, the log chain subdirectory used by archive is C0000021. The log chain subdirectory used by retrieve is not shown in db2diag.log, but can be identified using trace, or the database control file SQLOGCTL.GLFH.1. The mismatch of the log chain subdirectory would not have occurred if proper steps were followed when initializing the HADR standby, as suggested in "Initializing high availability disaster recovery (HADR)" https://www.ibm.com/docs/en/db2/11.5?topic=availability-initiali zing-hadr, to first issue DROP DATABASE, before RESTORE DATABASE and START HADR AS STANDBY. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * HADR users in 11.5.6 and 11.5.7 * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Update to latest modification/fix pack. * **************************************************************** | |
Local Fix: | |
Use EXCLUDE LOGS option in the backup command | |
Solution | |
Workaround | |
**************************************************************** * USERS AFFECTED: * * HADR users in 11.5.6 and 11.5.7 * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Update to latest modification/fix pack. * **************************************************************** | |
Comment | |
Problem was first fixed in Db2 Version 11.5.8.0 | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 09.05.2022 24.06.2022 26.06.2022 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) |