Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Does DB2 know in advance which log file to roll forward to?

0 views
Skip to first unread message

Allen

unread,
Feb 6, 2003, 5:21:05 PM2/6/03
to
DB2 UDB 7.2 WE
Linux

When a DB2 database goes into rollforward pending mode, and the
rollforward is then started, does DB2 have a preconceived notion
about what log it should roll forward TO? Or does it simply keep
incrementing the log number until there are no logs left to
process?

I am using the db2uext2.cdisk userexit, and have modified it so
that, rather than using a cp command, it calls a java app (inside a
VM of course) to archive/retrieve the log to/from another server.

I don't think the VM is passing back the proper return code to the
db2uext2 executable, because db2uext2 is trying to retrieve logs
that have not yet been archived. The logs it is looking for are
active logs, those that disappear from the log path dir when
rollforward pending starts.

The C source in db2uext2.cdisk seems to indicate that, if the log
file that was just attempted to be retrieved does not actually exist,
then an RC_OK success return code should be returned..

TIA

allen

Pierre Saint-Jacques

unread,
Feb 6, 2003, 8:24:20 PM2/6/03
to
The db will be in roll forward after a restore. Part of the restore brings
back from the image a file known as SQLOGCTL.LFH which contains the required
info for logging.
It has info, amongst other things, about the logs themselves that were in
the logpath:
Next active, last successfully archived and so on.
As the roll forward starts it looks for the next acive to roll forward as it
is the first it needs. If it is not in the log path, the db2uexit is called
with the retrieve parameter which tells it to bring in the log path. It is
processed and erased and then it all starts again for the next log so to
speak.
When the log is found in the log path, the roll forward will the logs
sequentially from there until the last one and then terminate. This what
"to the end of logs" means.
DB2 doesn't have to know what log; it rolls until there are no more of them
and presumes you're done.
It is quite possible that the roll forward attempts to retrieve a log not
yet archived. If the log was the last one to be used, it would most likely
be in the logpath, not archived but needed to roll forward to end of logs.
HTH, Pierre.
"Allen" <all...@ndr.com> a écrit dans le message de news:
3E42DFD1...@ndr.com...

Allen

unread,
Feb 7, 2003, 10:11:01 AM2/7/03
to
Thanks for the explanation. That clears things up.

One additional observation:
The following messages appeared in my db2diag.log when the
rollforward was done (I removed the timestamps and headers):

Rollforward iteration completed
ExtNum 119 not found. FirstArchNum 4294967295 LastArchNUm 4294967295
DB2 is waiting for log S0000119.LOG to be archived.
(This one above repeats once a minute for 5 ot 6 minutes)
DB2 was unable to confirm log S0000119.LOG was archived.

Log 119 was my last archived log file, and it WAS successfully
archived. It looks like something went wrong, but the rollforward
apparently worked just fine (I checked my last few transactions).
Any idea what is happening here?

TIA

Allen

Allen

unread,
Feb 7, 2003, 2:41:12 PM2/7/03
to
An answer to my own question:

The db2diag.log messages are spurious. Fixpack 8 fixes this...

allen

Pierre Saint-Jacques

unread,
Feb 7, 2003, 7:41:03 PM2/7/03
to
Thanks because I was going to start looking as to what would cause that to
happen!!
I guess one could read the APAR list ans well as release notes to save one
time. Merci for catching that.
Regards Pierre.

"Allen" <all...@ndr.com> a écrit dans le message de news:
3E440BD8...@ndr.com...
0 new messages