Hi TSM Gurus,

Due to some misunderstanding, an unnecessary 5 million files was backed up,
bloating our database by about 15 GB.  I have since commenced deleting that
filespace, but it looks like the delete is not reducing the database size
nearly enough.  So I am planning to do an unload/reload, and in order to
eliminate downtime, I thought I'd do it on a different server running
concurrently with the production server,  using the same 3494 and borrowing
one of the 3590 drives from production.

Here's my plan:

1.  Connect a second, temporary TSM server to our 3494.

2.  Allocate one 3590 drive for the temp. TSM server.

3.  After the delete filespace finishes on the production server, backup
the database.

4.  Restore the database onto the temporary TSM server.  Do the
unload/reload.

5.  Backup the unload/reloaded database.

6.  Restore it back to the production server.


The only downside I can think of is that after the reorganized database is
restored to the production server, all transactions made during the
unload/reload will be lost.   But, I am willing to accept that, since if I
absolutely need to, I can restore an older database in order to perform a
restore.

I am wondering if there are some other hidden dangers that I haven't
considered-- possibly involving having two TSM servers accessing a library,
and both thinking they possess the same tapes, etc.    I've thought about
this, and it seems to me that if I stick to database restore, and
load/unload operations, the temporary TSM server shouldn't have a chance to
interfere, or to try to run admin schedules and the like.

Any advice/admonitions are welcome.

Thanks!

adam