Results 1 to 13 of 13
  1. #1
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59

    Unanswered: logfiles in new path not found during online restore

    Hi all,

    We're running DB2 V7.2 on solaris and have a homemade script to do a
    online restore. This script, amongst other things, does the
    following:
    restores the database with the newlogpath set to
    "$HOME/restore/db_log_files/<dbname>/"
    completes the restore
    updates the database configuration setting the logpath to the path
    above
    copies the logfiles from a backup area to "$HOME/restore/db_log_files/<dbname>/"
    issues a rollforward on the database

    The rollforward always fails with an error message that one of the log files cannot be found. but instead if i copy the log files to the database/default log file directory("$HOME/db2inst1/db2inst1/<nodename>/SQL0002/SQLOGFILES") then the rollforward completes successfully


    The odd thing is that even when I do a "update db cfg for <dbname> using newlogpath $HOME/restore/db_log_files/<dbname>/ just
    before issuing the restore, it still checks for log files in the default log file directory.

    Any insight will be much appreciated.

    Cheers,
    brat

  2. #2
    Join Date
    Jan 2002
    Posts
    165
    You have to dactivate database,and activate to recognize update of db config.
    Cheers,Zvonimir

  3. #3
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650

    Re: logfiles in new path not found during online restore

    The parameter OVERFLOW LOGPATH in the ROLLFORWARD command will be of help to you, I think ...

    This parameter identifies the directory where the log files for rollforward are present ...

    HTH

    Cheers

    Sathyaram

  4. #4
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59

    Unhappy Re: logfiles in new path not found during online restore

    thanks sathyaram but i have tried that, it still doesnt work. I just cant seem to rollforward based on my log file directory.



    Originally posted by sathyaram_s
    The parameter OVERFLOW LOGPATH in the ROLLFORWARD command will be of help to you, I think ...

    This parameter identifies the directory where the log files for rollforward are present ...

    HTH

    Cheers

    Sathyaram

  5. #5
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59
    thanks, tried and still doesnt work.. *sigh*. any ideas?


    Originally posted by zkajfez
    You have to dactivate database,and activate to recognize update of db config.
    Cheers,Zvonimir

  6. #6
    Join Date
    Mar 2003
    Posts
    343
    I don't think you can update the db or dbm cfg before rolling forward to the minimum point in time because before that point, the database is in rollforward pending state. It's configuration, which it recovered from tells it to go look in the log directory which the restore says it should look in, to rollforward, I think. I will be interested in knowing if you could make it work though.

  7. #7
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59
    when i do a backup it has the same info on the log files..in the exact same directory structure as specified in the overflow log path during restore. So by rights it should go to "my" defined directory to search for the log files, isnt it?
    Will let you know if i break thru.
    The funny thing is during my rollforward operation, i always get an error on the last log file, the first two run smoothly.

    And a more wierd thing is it works if i do a certain sequence of steps, It actually goes to "my" defined logfile path and rollforwards it from there.
    I somehow get the feeling that when i take a backup of the log files during a "online backup" and if one of the log file is in use (while i am actually taking the backup of the active log files) then during a rollforward may or may not work. just a thought..what do u say??

    cheers brat.



    Originally posted by cchattoraj
    I don't think you can update the db or dbm cfg before rolling forward to the minimum point in time because before that point, the database is in rollforward pending state. It's configuration, which it recovered from tells it to go look in the log directory which the restore says it should look in, to rollforward, I think. I will be interested in knowing if you could make it work though.

  8. #8
    Join Date
    Mar 2003
    Posts
    343
    I guess I didn't quite understand what you were doing so I had to read it up. I'm assuming that when the database is backed up, the database configuration is updated with a newlogpath value. Is the database consistent - because the database will not use this path until the database is consistent, meaning all transactions have been committed to disk(deactivating the db would force a consistency point). This might explain the anomaly. In the restore command, you are specifying newlogpath. However, the database will not use the logs in that path until it reaches the point in the logs when it switched to using the new path, I think.

    The other question I have is are you doing filesystem backups of the log directory? I don't think the online backup includes logs, though it does include the files in the database directory. The logs will have to be supplied and if they're backed up using fs backups then it is possible that if the file is in use, that even though it looks like logfilsiz - it hasn't actually used it all - this becomes fairly evident if one issues an archive log for database <dbname> - in a partitioned env, it backups up logfiles of all sizes upto logfilsiz.

    I hope you will continue to update this post with your findings.

  9. #9
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59
    Hi,
    thanks for your reply.
    maybe i have been a bit unclear. i'll explain the scenario
    ::::
    Current config
    Production:
    Userexit : on
    Logretain : on
    New Log Path: $home/my_log_file_directory (this has been set since the beginning i.e almost a year back)
    Online backup: runs every night.
    Failover system:
    Exact same config as production


    I am actually writing a solaris script which will take the online backup image and the appropriate log files from the production and put it into the failover system my_log_file_directory. It will then restore the new image and rollforward the database to bring it out of rollforward pending state.

    the problem arises when i try to do the rollforward. It doesnt access the log files in my_log_file_directory. But if i put the log files in the default log directory. i.e $home/db2inst1/db2inst1/NODE000/SQLmmmmm/SQLOGDIR
    It works.

    As for my database consistency

    Database is consistent = NO
    but deactivating a database beats the whole point of an online back,since i believe it actually forces users off it??

    I am doing a backup of the filesystem log directory.

    am going to try some wierd thing today, will let you know if it works..

    cheers
    brat.



    Originally posted by cchattoraj
    I guess I didn't quite understand what you were doing so I had to read it up. I'm assuming that when the database is backed up, the database configuration is updated with a newlogpath value. Is the database consistent - because the database will not use this path until the database is consistent, meaning all transactions have been committed to disk(deactivating the db would force a consistency point). This might explain the anomaly. In the restore command, you are specifying newlogpath. However, the database will not use the logs in that path until it reaches the point in the logs when it switched to using the new path, I think.

    The other question I have is are you doing filesystem backups of the log directory? I don't think the online backup includes logs, though it does include the files in the database directory. The logs will have to be supplied and if they're backed up using fs backups then it is possible that if the file is in use, that even though it looks like logfilsiz - it hasn't actually used it all - this becomes fairly evident if one issues an archive log for database <dbname> - in a partitioned env, it backups up logfiles of all sizes upto logfilsiz.

    I hope you will continue to update this post with your findings.

  10. #10
    Join Date
    Mar 2003
    Posts
    343
    So what did you try and how did it go?

  11. #11
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59
    It was a crazy thing abt userexits and logretain .. but didnt work (didnt have my concepts right actually)..
    I am finally using userexit program to archive and keeping the failover system updated by rolling forward to the log files generated on a daily basis. I dont issue a "complete and stop command, So the database is always in a rollforward state. In case my prod goes down i just update the failover system with the log files generated one day befre and do a "complete"


    Originally posted by cchattoraj
    So what did you try and how did it go?

  12. #12
    Join Date
    Mar 2003
    Posts
    343
    If you have already recovered (redirected I suppose) the failover system, then why do you have to recover every night - couldn't you just rollforward to a point in time everyday?

  13. #13
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    59
    As I mentioned earlier, I dont do a recovery every night, just copy the log files over and rollforward but i leave the failover system in a rollforward state by issuing
    rollforward database >dbname> to end of logs
    notice that i dont use complete or stop.
    My failover system is an exact copy of the production, so a backup image of the production can be restored on the failover system.


    Originally posted by cchattoraj
    If you have already recovered (redirected I suppose) the failover system, then why do you have to recover every night - couldn't you just rollforward to a point in time everyday?

Posting Permissions

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