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

Adam - Database %util is in terms of whole blocks.  Blocks may be partially
       full, which means you have distributed freespace: fragmentation.  In
a database, this isn't necessarily a bad thing, for updating.  In any case,
it's an inevitable thing in a database.  Yes, a non-compact database will be
somewhat slower, but in the long run there's nothing realistic to be done
about that.  You can do the moral equivalent of database reorgs every few days,
taking the server down for hours each time.  Beyond downtime, consider risk.

It's a lot like all the initiatives to reform the tax code...  Let's start
over with a flat rate and greatly simplify things.  Well, sure, but: the
tax code got the way it is because of all the pressures on it to adapt to
real-world circumstances, and it would inevitably end up amended to the
complexity it has now.  Which is to say that it's rather futile to believe
that we can have nirvana.

People who really want compacted databases may well want to submit a SHARE
or independent requirement for the product to be enhanced to have a spare-time
defragmentation process kick off to do the deed, without taking the server
down.

  Richard Sims, BU