Hello,
If you want to be able to continue the rollforward with new logs from
the main site, the rollforward command on the recovery site is just:
rollforward xxx to end of logs. This keeps the recovery site in
rollfoward pending (rollforward ... query status can be applied on
it). By doing rollforward xxx to end of logs stop, the recovery site
is going out of rollfoward pending state and can not apply new logs
from the main site. By adding stop on the first rollforward
desscribed,S0000009.LOG became a true autonomous log from the recovery
site. When not adding the stop (or complete), S0000009.LOG will be
able to be transfered from the main site ounce it is free on the main
site (see archive logs for xxx that can be executed on the main site
to free the lowest logs where no active transaction are present).
When using exit routines, if the event handling is not correctly done
end to end, how to recover from the "lost" processing? I prefer the
way described here (get first active log and process lower logs) as it
can be recoverd easily (just run the check again and transfer
-again-/apply on the recovery); as additional consistency measure, a
fuser (Unix) can be issued on the logs that are said to be released by
db2 on the production site to be sure it is so. This method is indeed
simple and (by my experience) very solid.
There still is a usage problem on the shadow database: this recovery
database in rollforward pending state can not be used in read-only
mode.
Bernard Dhooghe
pe*********@techemail.com (Peter Sands) wrote in message
news:<6b*************************@posting.google.c om>...
Hi,
I am testing out some restores to a stand-by server, by roll-forwading
the logs.
I have this setup.
There is no user-exit, but logretain is on, for archive logging.
I have 2 DB's on different servers ( a & b), but named the same.
I have done a 'restore into' to create the db on server b, then taken
a on-line dump of that DB, then done a restore, to bring it into a
roll-forward pendind mode.
I fill up the transaction logs on server a. I then use :
db2 "get db cfg for t_DB"|grep First
First active log file = S0000009.LOG
to get the current active log.
I then copy the log(s) that are less than this number to server b,
I then do :
db2 rollforward db t_DB to end of logs stop
SQL1265N The archive log file "S0000009.LOG" is not associated with
the
current log sequence for database "S_DB" on node "0"
OK.. so I do a status:
Rollforward Status
Input database alias = t_DB
Number of nodes have returned status = 1
Node number = 0
Rollforward status = DB working
Next log file to be read = S0000009.LOG
Log files processed = -
Last committed transaction = 2003-12-10-12.00.17.000000
Can some one tell me why this is not working. I think it should be. I
should be able to roll the logs forward.
thanks
Pete.
db2 v8