Capture: Error reading DB2 log
The DB2 transaction log changes needed by capture process can’t be read
1.1 Error message
ASN0005E The Capture program encountered an error while reading the DB2 log.
The log sequence number is <LSN>, the SQLCODE is <SQLCODE>, and the
reason code is "".
1.2 Possible causes
An error occurred when the Capture program was trying to read the DB2 log. The DB2 transaction log changes needed by capture process can’t be read .
Depending on the SQL error code returned, possible causes are:
SQL2656N The Asynchronous Log Reader has encountered log file
"<name>" which cannot be read.
Explanation:
The Asynchronous Log Reader attempted to read log records from the specified log file. The specified log file has been corrupted and cannot be read.
SQL2657N The Asynchronous Log Reader requires log file "<name>" which does
not currently reside in the database log directory.
Explanation:
The Asynchronous Log Reader requires log records from the specified log file. The specified log file does not currently reside in the database log directory.
SQL2651N The log records associated with the database can not be
asynchronously read.
Explanation:
The asynchronous read log API was used against a connected database which does not have LOG RETAIN or USER EXITS ON. Only databases which are forward recoverable may have their associated logs read.
1.3 Investigating
Step 1: Find the LSN (Log sequence Number) of the log that capture needs
Usually you can find LSN directly from the error message received in the capture log:
The log sequence number is 0000:000:0004:EC58:36C2
If you can not find it, try running the command below:
db2 “SELECT HEX(MIN_INFLIGHTSEQ) FROM ASN.IBMSNAP_RESTART WITH \
UR”00000000004EC5836C2
Step 2: Find out what is the log that corresponds to that LSN
Find which directory the SQLOGCTL.LFH (SQL Log File Header Control) file is in:
Issue a list db directory and get the filesystem name where the database resides:
db2 list db directory
output:
Database 1 entry:
Database alias = CECEMEA2
Database name = CECEMEA2
Local database directory = /db/db2data/cecemea2
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
In this example, the cecemea2 database resides on /db/db2data/cecemea2
Usually the SQLOGCTL.LFH file. will be inside the path below:
/<dbdirectory>/<instance>/NODE0000/SQL00001
If not, you can use the find command to find it, as below:
find /db/db2data./ecemea2 -name SQLOGCTL.LFH -type f
/db/db2data/cecemea2/inst2/NODE0000/SQL00001/SQLOGCTL.LFH
Change directory to where the SQLOGCTL.LFH file is located.
cd /db/db2data/cecemea2/inst2/NODE0000/SQL00001
Issue the db2flsn (db2 find log sequence) command (remember to remove the first 4 or 8 zeros from the lsn that you found in step 1). Make sure your userid has authority to access this file (usually need to be instance owner).
db2flsn 0004EC5836C2
Given LSN is contained in log file S0000950.LOG
CAPTURE IS PROCESSING LOG S0000950.LOG
1.4 Resolution
To solve the problem, when the log file in the active log path is corrupted or missing, you will need to retrieve the log file from an archive (TSM or wherever it is archived). Look in db cfg to find this information:
First log archive method (LOGARCHMETH1) = TSM
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = OFF
Options for logarchmeth2 (LOGARCHOPT2) =
In this case, the log file should be in TSM, so will use db2adutl command to verify and extract the logs that are needed by capture from TSM. For example, to extract the following 10 logs:
db2adutl query logs between S0000950.LOG and S0000960.LOG db CECEMEA2
db2adutl extract logs between S0000950.LOG and S0000960.LOG db CECEMEA2
However, if the transaction logs can’t be restored (either corrupted or lost), a COLD start will be required.