On Mon, 24 May 1999, Sheelagh Treweek wrote:

> I think the point is that you have already removed all the empty pages
> and the probelem is on making better use of the partially occupied
> pages.  When you look at the "Maximum reduction" that is the empty
> pages; when you study the %used and "used pages" that indicates the
> spread of information over partially occupied pages.

I think that's a good point.  But I'm under the impression, at least based
on my observations, that once you hit some highwater mark you never free
up pages beneath that point to which the database increased.  I was only
able to reduce my database size by the amount of space which hadn't yet
been grown into.

Given that I've got 40GB of database at 62% utilization, I'd be hard
pressed to believe that there aren't at least some pages which are
entirely empty internal to the database.  So although I would certainly
expect a good number of pages to only be partially used, I wouldn't expect
all of them to be that way.  I mean, that is just speculation on my part,
but I think it's reasonable thing to believe.

> When you do a
> restore db the DB is restored exactly as it was on disk at the time of
> the backup db; when you do a loaddb it puts information into the db as
> it thinks best and leaves space in pages for later normal use - i.e. it
> doesn't fill up pages as it goes.

That makes sense.  You wouldn't want all your B-tree buckets to be full
from the get go.  So... would it be safe to also say that doing a
dumpdb/loaddb would also very likely improve the performance on ADSM
database I/O?

-brian.
=========================================================================