Thank you for your response, Richard.

The reason I believe there is a compelling reason is that before this 5
million file backup, our database was about 43 GB.   When the backup
finished, the database was about 62 GB.  After deleting around 4 million
files, the database is still around 60 GB.  These sizes are from % util.,
which I thought referred to logical internal consumption, although perhaps
I am wrong about that.  If I am not wrong, then it seems like free space
has not been sufficiently reallocated after the deletion, perhaps due to
internal segmentation, or something else.  That's the type of problem I
hoped to resolve with the unload/reload.

While I haven't had time for extended statistics gathering, it seems that
this size increase has also slowed many operations, most obviously the
database backup.

If you still think this is a bad idea, please let me know.  I am always
happy to learn something new, and spare myself an unnecessarily painful
experience.

Thanks,
adam





                    Richard Sims
                    <rbs AT BU DOT EDU>         To:     ADSM-L AT VM.MARIST DOT 
EDU
                    Sent by:             cc:
                    "ADSM: Dist          Subject:     Re: unload/reload db on 
diff.server (same library) --
                    Stor Manager"        disaster waiting         to happen?
                    <ADSM-L AT VM DOT MA
                    RIST.EDU>


                    03/07/2003
                    07:33 AM
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"






>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.

What do you mean  that the database size is not reducing nearly enough?
The database is a fixed-size object used randomly.  You will have free
space
and partially used blocks throughout it.  The filespace delete will reduce
logical internal consumption by the number of db objects involved, and you
will be all set thereafter.  As has been discussed on the list, there is no
compelling reason to do what you were thinking of doing.  It's a database.

  Richard Sims, BU