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