Al,

 I sent this out a few weeks ago, it seems that upgrading from a 3.x environment
to 4.x has caused multiple scratching behind the head !


 On an NT ADSM V3 -> V4 upgrade we also experienced some frightening phenomena,
 the database becoming twice the size it was, client backups taking longer,
 severe impact on db cache hit (wel below 90%, was 98%) and db backup's taking
to
 long (2 servers were upgraded the older and the one that had undergone previous
 upgrades got the db problems).
 It was as if the db was dragging itself thru mud. What we ultimately did to get
 the db back up to spec's was to backup, dump, reformat, load and audit the db.
I
 must say this was a succes the db returned to it's expected size, db cache hit
 went up and everything seems normal again.
 Be aware we had problems with the audit, a recreate bit vector problem, an
 upgrade to TSM V4.1.3.2 was necessary before the procedure could be completed.
 Below the dump/load procedure we followed for our environment, we let the
 procedure run unattended in the weekend. Because the procedure was running
 unattended and we didn't want any media problems to interfere, all db
operations
 were done to disk.

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * backup the database >>d:\apps\tsm\server1\dsmdump.log
 dsmadmc -id=id -pa=password backup db type=full devcl=file scra=yes wait=yes
 >>d:\apps\tsm\server1\dsmdump.log

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * halt the server >>d:\apps\tsm\server1\dsmdump.log
 net stop "TSM Server1" >>d:\apps\tsm\server1\dsmdump.log

 echo * switch to TSM server dir (where dsmserv.dsk resides)
 >>d:\apps\tsm\server1\dsmdump.log
 d:
 cd \apps\tsm\server1

 echo * delete any previous dump volume >>d:\apps\tsm\server1\dsmdump.log
 del g:\adsm\dblog\dumpdb.vol >>d:\apps\tsm\server1\dsmdump.log

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * dump the db >>d:\apps\tsm\server1\dsmdump.log
 ..\server\dsmserv dumpdb devcl=file vol=dumpdb.vol
 >>d:\apps\tsm\server1\dsmdump.log

 echo * delete existing db & log volumes >>d:\apps\tsm\server1\dsmdump.log
 del f:\adsm\dblog\*.dsm >>d:\apps\tsm\server1\dsmdump.log

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * reinitialize db & log volumes >>d:\apps\tsm\server1\dsmdump.log
 ..\server\dsmserv loadformat 1 f:\adsm\dblog\log1.dsm 601 1
 f:\adsm\dblog\db1.dsm 15001 >>d:\apps\tsm\server1\dsmdump.log

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * load the dumped db >>d:\apps\tsm\server1\dsmdump.log
 ..\server\dsmserv loaddb devcl=file vol=dumpdb.vol
 >>d:\apps\tsm\server1\dsmdump.log

 time /t >>d:\apps\tsm\server1\dsmdump.log
 date /t >>d:\apps\tsm\server1\dsmdump.log
 echo * audit the db as consistency check >>d:\apps\tsm\server1\dsmdump.log
 ..\server\dsmserv auditdb fix=yes >>d:\apps\tsm\server1\dsmdump.log



 regards Walter Ridderhof


-----------------------------------------------------------------
ATTENTION:
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
=========================================================================