By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,924 Members | 1,727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,924 IT Pros & Developers. It's quick & easy.

db2LogRead API Error

P: n/a
Hi all:

We see these errors when starting capture. The version we are running
is UDB V8 FP8 64bit AIX 5.2 ML4.

When would capture keep erroring with this LSN?
Any ideas?

2005-05-09-11.13.17.217292 <CWorkerMain> ASN0100I CAPTURE "ASN_P2" :
"WorkerThread". The Capture program initialization is successful.
2005-05-09-11.13.17.217517 <CWorkerMain> ASN0109I CAPTURE "ASN_P2" :
"WorkerThread". The Capture program has successfully initialized and is
capturing data changes for "579" registrations. "0" registrations are
in a stopped state. "0" registrations are in an inactive state.
2005-05-09-11.13.19.839660 <logrd8::readTheLog> ASN8041D "Capture" :
"ASN_P2" : "WorkerThread" : db2LogRead API is sending us backwards in
theDB2 Log: First LSN is "0000:0000:04dc:d383:ec92" while Next Start
LSN is "0000:0000:0000:0000:0000"
2005-05-09-11.13.19.839723 <logrd::readTheLog> ASN0005E CAPTURE
"ASN_P2" : "WorkerThread". The Capture program encountered an error
when reading the DB2 log. The log sequence number is
"0000:0000:04DC:D383:EC92", the SQLCODE is "-2656", and the reason code
is "".
2005-05-09-11.13.19.839723 <logrd::readTheLog> ASN8999D "Capture" :
"ASN_P2" : "WorkerThread" :
2005-05-09-11.13.19.839849 <CWorkerMain> ASN8001D "Capture" : "ASN_P2"
: "WorkerThread" : Unexpected return code "910" from routine
"logtxrdr::getTrans".
2005-05-09-11.13.19.839902 <CWorkerMain> ASN0123I CAPTURE "ASN_P2" :
"WorkerThread". At program termination, the highest log sequence number
of a successfully captured log record is "427F:023A:0000:0001:0000" and
the lowest log sequence number of a record still to be committed is
"0000:0000:04DC:D36F:8D08".
2005-05-09-11.13.20.616812 <asnThread::stop> ASN8045D "Capture" :
"ASN_P2" : "Initial" : Thread "Initial" received return code "910" from
exiting thread "WorkerThread".
2005-05-09-11.13.22.617992 <asnThread::stop> ASN8045D "Capture" :
"ASN_P2" : "Initial" : Thread "Initial" received return code "2011"
from exiting thread "AdminThread".
2005-05-09-11.13.22.618053 <asnThread::stop> ASN8045D "Capture" :
"ASN_P2" : "Initial" : Thread "Initial" received return code "2011"
from exiting thread "PruneThread".
2005-05-09-11.13.22.628373 <Asnenv:delEnvIpcQRcvHdl> ASN8008D
"Capture" : "ASN_P2" : "Initial" : "Destroyed" IPC queue with key(s)
"(0x30000027)".
2005-05-09-11.13.22.628428 <asnThread::stop> ASN8045D "Capture" :
"ASN_P2" : "Initial" : Thread "Initial" received return code "0" from
exiting thread "HoldLThread".
2005-05-09-11.13.22.628534 <erWhatSignal> ASN8004D "Capture" :
"ASN_P2" : "HoldLThread" : Thread "HoldLThread" received "Handled"
signal "SIGUSR2".
2005-05-09-11.13.23.629508 <_asnCapture> ASN0008I CAPTURE "ASN_P2" :
"Initial". The Capture program was stopped.

- Vj

Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a

"UDBDBA" <vi***********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Hi all:

We see these errors when starting capture. The version we are running
is UDB V8 FP8 64bit AIX 5.2 ML4.

When would capture keep erroring with this LSN?
Any ideas?

2005-05-09-11.13.17.217292 <CWorkerMain> ASN0100I CAPTURE "ASN_P2" :
"WorkerThread". The Capture program initialization is successful.
2005-05-09-11.13.17.217517 <CWorkerMain> ASN0109I CAPTURE "ASN_P2" :
"WorkerThread". The Capture program has successfully initialized and is
capturing data changes for "579" registrations. "0" registrations are
in a stopped state. "0" registrations are in an inactive state.
2005-05-09-11.13.19.839660 <logrd8::readTheLog> ASN8041D "Capture" :
"ASN_P2" : "WorkerThread" : db2LogRead API is sending us backwards in
theDB2 Log: First LSN is "0000:0000:04dc:d383:ec92" while Next Start
LSN is "0000:0000:0000:0000:0000"


This looks like a bug. Please contact IBM Support and open a PMR.

--
Matt Emmerton
Nov 12 '05 #2

P: n/a
All:

I found the problem with logreadAPI. First of all SQL2656N is the wrong
error code. We should have got SQL2657N. SQL2656 means that log file
was corrupt but the logs are intact. What i found was that
db2AsyncLogreadAPI could not retrieve logs from TSM (Archive Location).

I had to use db2adutl and extract logs to active log path. Following
which, we recovered from 9 hour latency.

The reason i am thinking that the logreadAPI failed to retrieve logs
from TSM is because of the owner of log files inside tsm. The owner
were all NULL. Which means, when the LOGARCHOPT1 -fromnode and
-fromowner is used, the result set is empty for the given -fromowner.
This was because the old user exit program was under ~/sqllib/adm
directory. Even though I had set LOGARCHMETHD1 = TSM, the userexit code
was causing log file ownership to NULL. On deleting the userexit code,
we started seeing log files owned by -fromowner setting inside TSM.

Beware, V8.2 had lots of changes to db2adutl, rollforward and restore.
We have hit issues/APARs in these categories. 8.2 has awesome options,
but we need to know it all before implementing it. Good luck finding
the documentation for these new changes.
I end up searching and reading doc for a day before opening a PMR for
support to find the same (the support takes a day to make up a
document after discussing with the developers.)

Overall, it's a new day with 8.2 and great job by IBM Support.

- Vijay

Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.