Results 1 to 13 of 13
  1. #1
    Join Date
    Jul 2011
    Posts
    6

    Unanswered: rollforward not working past backup point-in-time

    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
    Last edited by darrenkinley; 07-06-11 at 21:39.

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Try this command (see Command Reference manual):

    db2rfpen ON <dbname>
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    Jul 2011
    Location
    USA
    Posts
    80

    please provide o/p

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

  4. #4
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    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.

  5. #5
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    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.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  6. #6
    Join Date
    Jul 2011
    Posts
    6
    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
    Last edited by darrenkinley; 07-07-11 at 18:46.

  7. #7
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by darrenkinley View Post
    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.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  8. #8
    Join Date
    Jul 2011
    Posts
    6
    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

  9. #9
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by darrenkinley View Post
    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?
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  10. #10
    Join Date
    Jul 2011
    Posts
    6
    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

  11. #11
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,369
    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>?

  12. #12
    Join Date
    Jul 2011
    Posts
    6
    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

  13. #13
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by darrenkinley View Post
    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.
    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.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •