Chris - Two things:
1. Why are you taking your TSM system out of service for over 24 hours to perform this kind of operation?
2. Do NOT perform "recreational" AUDITDB operations. As I summarize in ADSM QuickFacts, AUDITDB is to be done only when there is a known database problem, and when you are working with TSM Support, and where surgical corrections cannot be made. AUDITDB is a Salvage operation, and can result in the loss of data.
I don't want to see you take pointless risks with your data repository.
Richard Sims
On Feb 18, 2005, at 8:12 AM, Rees, Chris (Corp) wrote:
Hi All
TSM Server 5.2.2.3 on win2k SP4
This weekend I'm going to be doing a unload / load of our 100Gb TSM Database. The steps I'm going to do once I have a couple of DB backups are
Halt TSM Dsmserv unloaddb devc=filedev Delete the log and db volumes from windows Dsmserv loadformat num_log_vols log_file_vols num_db_files db_vol_names Dsmserv loaddb devc=filedev volumename=whatever gets created from unload
I've done this twice on our DR server and not had any issues. The unload took 22hours though ! Both times I got the message saying an auditdb is not required although I am going to schedule this in next month.
The main difference in our live environment as I see it are the storage agents and server-to-server comms. I've read that you need to force a password resync for the other servers that are defined. I guess I just need to do for each server
Upd server 'servername' forcesync=yes
Have I missed anything obvious? Anyone got any other gotchas...
Thanks
Chris
