Db2

 View Only
  • 1.  point in time recovery and facing issue.

    Posted Tue March 07, 2023 05:28 AM
    Hi Team.
    We are testing point in time recovery and facing issue. Could you please check and help on this..
     
    Are your Db2 databases partitioned: NO Database Partition .
     
    Restoration steps 
    -----------
     
    1> Full online backup 
    db2 backup database <dbname>  online to /DB2/backup_prod_nonec/backup_qa/  compress include logs
     
    2>date ;deleted 1 records : date
     
    3>restore db

    [db2inst1@elmqadb02 backup_prod_nonec]$ db2 "RESTORE DATABASE test8 TAKEN AT 20230306074405 INTO test21 logtarget '/DB2/backup_prod_nonec/over_olg2'"

    DB20000I The RESTORE DATABASE command completed successfully.

    test8 db : archival directory here few logs are copy and trasfer to this directory /DB2/backup_prod_nonec/over_olg2

    4>rollforward db 

    [db2inst1@elmqadb02 C0000001]$ db2 rollforward db test21 to 2023-03-06-07.45.19 using local time and complete overflow log path "(/DB2/backup_prod_nonec/over_olg2)"

    SQL4970N Rollforward recovery stopped on the database named "TEST21" because

    the rollforward utility cannot reach the specified stop point (end-of-log or

    point-in-time) on the following database partitions: "0".



    ------------------------------
    meghana m
    ------------------------------


  • 2.  RE: point in time recovery and facing issue.

    Posted Wed March 08, 2023 01:56 AM

    Hi, try checking the output of db2 "rollforward db test21 query status" for clues.



    ------------------------------
    Jeremy Rickard
    ------------------------------



  • 3.  RE: point in time recovery and facing issue.

    Posted Wed March 08, 2023 10:57 AM

    Meghana

    can you confirm that the rollforward PIT (2023-03-06-07.45.19) is beyond the end of the online backup?

    check the db2diag.log file for more details as to why rollforward failed.



    ------------------------------
    Dale McInnis
    ------------------------------



  • 4.  RE: point in time recovery and facing issue.

    IBM Champion
    Posted Tue March 14, 2023 10:42 AM
    Edited by Michael Krafick Tue March 14, 2023 03:32 PM

    Meghana,

    I don't know if this will help your current situation/error, but I am wondering if the DiscoverDb2 Backup/Restore episodes in this YouTube play list would be helpful to you. 

    Regarding your current problem, I would confirm that there are not any old logs from previous attempted restores in the overflow log path directory. I would also confirm there are not any old logs in the assigned LOGARCHMETH1 directory of this database when you are restoring it. I've seen old logs in the log archive directory cause confusion for Db2 even when specifying a LOGTARGET.  If you are not sure what the archive log directory will be when restoring, you should be able to issue (db2 "get db cfg for TEST21" | grep LOGARCHMETH1 after the restore step but before the rollforward step.

    Edit (adding a few hours later)

    You may also want to adjust your timestamp format in the ROLLFORWARD statement. Your timestamp format looks correct and matches what is in the example through documentation. But I swear the few times I have done this I have specified a timestamp down to a nanosecond with something similar to 2023-03-10-19.00.46.000000. Maybe that makes a difference?



    ------------------------------
    -----------------
    Michael Krafick (Twitter: @mkrafick)
    IBM Champion for Data and AI
    ------------------------------



  • 5.  RE: point in time recovery and facing issue.

    Posted Wed March 15, 2023 09:26 AM

    You ran the backup and it ended at 2023-03-06 07:44:05

    You are doing a: db2 rollforward db test21 to 2023-03-06-07.45.19 using local time
    That time is a little more than a minute later than the backup.
    When Db2 does the rollforward with the provided backup and logs, the latest possible timestamp on a log record is 7:44:05.  The only way Db2 knows that it processed all available logs up to the given timestamp is if a record with a later timestamp is encountered.  In this case that will not happen.  It is not really an error, it is just informing you that it is not sure everything is rolled forward, and you will need to issue "db2 rollforward db test21 complete" in order to tell Db2 everything is ok.

    https://www.ibm.com/docs/en/db2/10.1.0?topic=commands-rollforward-database




    ------------------------------
    Tommy Petersen
    ------------------------------