Recover TSM Server without recovery log files

jharris

ADSM.ORG Member
Joined
May 24, 2004
Messages
166
Reaction score
0
Points
0
Location
Victoria, Australia
Website
Visit site
OK, we did a silly thing ... we've deleted the TSM server recovery log files accidentally, I won't go into how it happened but I want some confirmation and understanding why I can't fix the issue without restoring the database.

Essentially:
1. TSM was correctly shutdown after client processing had completed using the HALT command.
2. The TSM database logmode is set to rollforward
3. Some of the DB log files were deleted after TSM was halted.
4. TSM will not start-up (obviously). We get the typical ANR9969E errors and finally an "ANR0259E Unable to read complete restart/checkpoint information from any database or recovery log volume."


IBM Support said to restore from the last backup, which is fine, but I'm more than curious than anything ... I thought the db changes stored in the recovery logs (even in rollforward mode) are still committed to the database. So if the server was shutdown correctly and the log files are corrupted offline, everything is still in the active database files. Therefore, even without the recovery log volumes, there'd be a way to bring the DB back online (even with an empty recovery log and the logmode set to circular), then rebuild new logfiles etc. once the server was back up and running. I have NO corruption to the current DB files ?

Anyway as time is important, I'll appreciate some discussion, but I'm going to restore the tape and rebuild from the data I'll have that is around 6 hours prior ... but I'm keen to hear the reasons why/why not I can't still use my active 100% error free database files to bring the server online.

Cheers.
 
Last edited:
I'm pretty sure you'll need to restore. The DB doesn't know if there's anything in the log that hasn't been commited if the log can't be read :(.

There is the capability to restore a individual db volume but I don't think this applies to log volumes (?) as you need the log to do it.
 
Well at the time, these were additional volumes dynamically created (hence I was not aware of them) as the spacetigger had created them in the Windows\system32 drive (I've now setup a prefix so that they get created with my other log files).... so of course, there weren't any log copies either ...

I presume that the TSM back end process for rollforward is that although the DB has new entries in it since the last backup they are still flagged somehow as 'new entires' that need to be verified (against the recovery log) due to the fact that no backup has yet been run....
 
I am sure by this point you have recovered your DB but I just went through the same thing last week. We have a migration form a old server to new and we exported the file systems and it ended up corrupting one log volume, well yeah we have to completely re initialize our db and log volumes and restore our DB.

From my understanding it would have been possible to recover had you been in normal mode but not roll forward.

I had the same questions you did as far as recovery our log was rollforward and we ran a full db backup right before the server was halted, so theretically the log files should have contained 0 transactions, but in the end we had to restore from our backup.
 
yep, it's all back up and going .... I might do some more disaster/recovery testing in my test environment as I agree with you ... I might have been able to recover if the logmode was 'normal'.

The other issue I had forgotten about was the hassle with auditing my disk storage volumes and running an audit libv.... this particular machine was a library client, but the library manager seemed to update it's volhist accordingly and we got back to square one ok.
 
We are having the same problem. The log files are not there from a restart (did not delete them).

What is the process to restore the tlogs if we are running in normal mode?

Cheers
 
tsm server crash because of my recovery log full but i dont have backup for recovery log
to recover it . can i recover my tsm
 
If your log is less than the maximum size you can extend it and then restart the database.

If your log is at the maximum size and full, you need to restore the database backup.
 
Back
Top