Hi,

I need to backup an HADR standby database at a remote site.
This appears to be unsupported so I've done a 'db2stop force' and used tar(1) to backup the entire DBPATH.

I've simulated a failed disk, crashed the instance, restored the tar file contents and reestablished HADR Peer status. Great!

I now want to do a PiTR of the standby. I restored the tar file contents but when I try to rollforward it knows that its already at its end of logs and stops there.

db2 => stop hadr on database db2prod
DB20000I The STOP HADR ON DATABASE command completed successfully.

db2 => rollforward db db2prod to end of logs

Rollforward Status

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

Node number = 0
Rollforward status = DB working
Next log file to be read = S0000080.LOG
Log files processed = S0000070.LOG - S0000079.LOG
Last committed transaction = 2011-07-06-21.40.10.000000 UTC

DB20000I The ROLLFORWARD command completed successfully.


I've manually copied over the entire ARCHLOGDIR and db2rhist.asc file and 'list history archive log all for db2prod' shows the logs are there.

rollforward to a specific isotime gives an error

db2 => rollforward db db2prod to 2011-07-06-22.00.00.000000
SQL1274N The database "DB2PROD" requires roll-forward recovery and the
point-in-time must be to the end of logs.

and rollforward to end of logs quits at its own last known archived log

db2 => rollforward db db2prod to end of logs

Rollforward Status

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

Node number = 0
Rollforward status = DB working
Next log file to be read = S0000080.LOG
Log files processed = S0000070.LOG - S0000079.LOG
Last committed transaction = 2011-07-06-21.40.10.000000 UTC

DB20000I The ROLLFORWARD command completed successfully.

Can anyone give me a clue what I need to do to rollfoward?

Thanks,
Darren

Try this command (see Command Reference manual):

db2rfpen ON <dbname>

when hadr is up please provide o/p of db2 get snapshot for database on dbname | grep -ip hadr

Results of ROLLFORWARD and remote catch-up may be different; I think you should allow the HADR catch-up to do the job of replaying missing transactions.

My interpretation was that darrenkinley is trying to create a 3rd stand-alone database using a backup of the HADR standby, but not replacing the current HADR standby. But I am not sure what the requirements are.

I'm setting up HADR to a remote location for the purpose of DR and want to have two full sets of backups (and logs) at both sites.
Since there appears to be no way to run backups on the HADR standby, I'm trying to overcome this limitation by doing OS level backups of a cold database.
This strategy works until I kill the primary and for whatever reason attempt to restore my cold backup and roll forward beyond the log files that were known at the time that the standby was shutdown for backups.

Thanks,D

I have done sort of the same thing using a SAN snapshot of the standby to set up a 3rd reporting database. The db2rfpen command worked for me, and enabled me to roll forward the logs on the new database. In my case I had to deactivate the standby and do a write suspend before the snapshot and write resume after snapshot.

Thanks for your reply.

Sounds like we're doing something very similar.
I'm still fiddling with db2rfpen; it deactivates the standby (converts to standard) and sets rollforward pending.

The problem I'm having is that it only accepts 'to end of logs' and it has already reached the end of logs that it knows about; more logs were generated after the backup was taken and I can't convince it there are additional logs to be applied.

Did you ever try to rollforward any logs generated after taking your snapshot?

D

Yes, we were able to roll forward logs after the snapshot without any problem. Where did you get the logs from, and where did you put them?

I think that my problem has to do with the fact that the control files, dr history or any other critical files have no knowledge of archive logs after the consistent backup (tar). In my scenario the standby is unable to talk to the primary to discover that it is in fact behind in applying its logs.

To answer your question, I have duplicated the ARCHLOGDIR from the primary (rollforward db db2prod to end of logs) but also tried putting them in another directory (rollforward db db2prod to end of logs overflow log path (/home/db2prod/LOGS))

Let me try again; restore *all* database files from tar, db2start, 'stop hadr on database db2prod', 'rollforward to end of logs' goes to the end of the last known logfile but there are more on disk, run db2rfpen, try to rollforward another minute using unspecified or 'overflow log path'.

Nope
db2 => rollforward db db2prod to 2011-07-06-21.41.10.000000
SQL1274N The database "DB2PROD" requires roll-forward recovery and the
point-in-time must be to the end of logs.
db2 => rollforward db db2prod to 2011-07-06-21.41.10.000000 overflow log path (/home/db2prod/LOGS)
SQL1274N The database "DB2PROD" requires roll-forward recovery and the
point-in-time must be to the end of logs.
db2 => rollforward db db2prod to end of logs

Rollforward Status

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

Node number = 0
Rollforward status = DB working
Next log file to be read = S0000080.LOG
Log files processed = S0000070.LOG - S0000079.LOG
Last committed transaction = 2011-07-06-21.40.10.000000 UTC

DB20000I The ROLLFORWARD command completed successfully.

How did your scenario differ?
How did your instance know there were more logs to apply?

Thanks,
Darren

This sounds kind of similar to log shipping. Where is log S0000080.LOG and higher located on this new server? And what's the output from db2 get db cfg for <db name>?

I finally got this working.

rollforward wouldn't let me specify an ISOtime insisting that I had to specify 'end of logs' and it wouldn't go past the last know logfile (at the time the cold backup was taken).

It turns out that HADR standby blindly looks for and applies logs under the ARCHLOGDIR; while I couldn't issue the rollforward command I was able to restore the backup and control what got applied by making sure only the needed logs where under the directory.

I was quite surprised that DB2 applied logs without any knowledge of them, I gather that logfiles have a DBID, instantiation number or log stream ID so it knows whether the logs are finds are legitimate or not.

Thanks for your help,
D

I can assure you that DB2 does not just blindly apply logs. They must be in synch with the database and from the same "log chain."

Not sure what the issue with end of logs is, but you want to try NORETRIEVE option on the rollforward command next time.