How do you determine volume?

[influx]

Scenario: run db backup, do some maintenance, halt server, restart.

Let's say you corrupted the db and it does not start up. Now you're faced with restoring the db back to the last full you took. But the volhist does not get updated until the server starts (<<< correct?). If that is a true statement, which I think it is, how do you go about restoring the DB to that last db full?

 

[kfiresmith]

I don't know if there's an easier way to do this with an onsite copy, but usually the DR admin schedule does the DB backup last, so it should be on the last tape you wrote to that you sent offsite most recently. You don't have your DB's backed up to local disk as well? Just local and offsite tape?

 

[moon-buddy]

There might be a way before you restore the DB, and assuming you have not fully corrupted or deleted the database. I know this works for 5.2 and up.

Try: "dsmserv auditdb fix=yes" and see what it reports. If TSM can recover or fix whatever went wrong, you can start the TSM Server once more.

 

[thiyagharajan]

dsmserv restore db preview=yes

This should list the name of the last DB backup volume.It actually reads volhist.out file to findout the latest one.

 

[BBB]

Scenario: run db backup, do some maintenance, halt server, restart.

Let's say you corrupted the db and it does not start up. Now you're faced with restoring the db back to the last full you took. But the volhist does not get updated until the server starts (<<< correct?). If that is a true statement, which I think it is, how do you go about restoring the DB to that last db full?

Influx, this is what the "backup volhist" admin command is for.

You should always run this straight after a DB backup, this will ensure the volhist contains the latest db backup tape.

 

[moon-buddy]

Influx, this is what the "backup volhist" admin command is for.

You should always run this straight after a DB backup, this will ensure the volhist contains the latest db backup tape.

Or, if you use DRM, the "prepare" command will save all these information.

 

[n9hmg]

Whenever I do something potentially disruptive, I toss an ad hoc backup db t=f to a file deviceclass, then out of paranoia, scp it to another server.

No help to you at all.

Pray the auditdb gets it up enough for you to q volh.... However, be aware that it's common for an auditdb to take 2 or more days. You could do a lot of wasted restoredb attempts in that time.