First active logfile+ everything you need for rollforward?

[Willem Fischer]

The database configuration value "First active log file" tells me which transaction log files I need for a rollforward of a database (I need this file and the ones with a higher number).

But would you rely a production system on this parameter? I. e. is it save to move all archived log files away with a lower number and expect to get the cold standby up and running without going to the tape archive? (Where the tapes are stored somewhere where I don't have access to when the storage admin is not around.)

[Willem Fischer]

On Friday, January 7, 2011 9:43:14 AM UTC+1, Willem Fischer wrote:
> The database configuration value "First active log file" tells me which transaction log files I need for a rollforward of a database (I need this file and the ones with a higher number).
>

> But would you rely a production system on this parameter? I. e. is it save to move all archived log files away with a lower number?

It seems that this parameter is not universally reliable, at least the rollforward pending state has to be considered:

$ db2 get db cfg for xx
Rollforward pending = DATABASE
First active log file = S0061239.LOG

$ db2 rollforward db xx stop overflow log path "('/.../logs')" noretrieve

Rollforward Status

Input database alias = xx
Number of nodes have returned status = 1

Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0061233.LOG - S0061238.LOG
Last committed transaction = 2011-01-03-03.29.32.000000 UTC

DB20000I The ROLLFORWARD command completed successfully.

[Pierre StJ]

What you are getting back is correct. After the rollforward to end of
logs the firstactive file should be "1239" as "1238" has been fully
processed.
You can very this another way.
Use the db2ckbkp command to check the image yourestored from. The
proper parms will bring you the values of MinBuffLSN and OldTranLSN.
These two pointers are the 1) The oldest committed externalized
transaction and the oldest in flight transaction (this last will not
show if the backup image was an offline one).
Use the db2flsn command on each of these two pointers. The result
should most likely point to log file "1233" as it is the start point
of the rollforward.
The first command you issue gives you thye db cfg of the db, as it is
on file, as it was last updated which was updated "after" the backup
and roll forward were finished.
The db is now consistent and all transactions have been fully
processed and will the next active log file to be "1239". Looking at
it shoulde show it empty but hfot two 4k pages already holding data
used to identify the log as belonging to that db and that db's current
log chain.
HTH, pierre.