...
>Isn't this getting a little off the mark though?  Last I checked, almost
>every database on the planet (yes even pervasive sql) when allocating
>pages/extents, left an amount of space unutilized at the end.  In fact, if
>you do a "reorg" in SQL server, it specifically asks how much space you want
>to remain free in each page.  Now why would you want that?  So that when you
>add a row to a table with a clustered index (ie. A primary key, where the
>table is physically ordered the same as the index) the database does not
>have to add an extent at the end of the space to house the new row.  This
>cuts down on logical fragmentation which is a far larger killer of databases
>than the fragmentation that these formulas show.  By these formuls, every
>signle one of my SQL database is 25% fragmented (why, because every Sunday
>they do online reorgs to fix their logical fragmentation).  Logical
>fragmentation turns large sequential reads into large random reads.
...

Indeed, Michael.  Distributed free space is a good thing in a random-access
structure where inserts are performed.  Some may believe that reorganization
of a database always packs its contents closely together, yielding excellent
adjacency and seek times.  But the reload phase of a reorganization has to
proceed according to the architecture and algorithms under which the database
operates.  In a B-tree type database, as the TSM db principally is, the
reload insertions may result in a lot of splits and half-occupied pages. As
customers have reported in ADSM-L postings, a reload may require twice as
much space as their original database size.  (This is summarized under topic
"ADSM DATABASE STRUCTURE AND DUMPDB/LOADDB" in
http://people.bu.edu/rbs/ADSM.QuickFacts .)

It takes exceptional circumstance to justify doing such an unload-reload,
and then the effects are typically short-lived.

  Richard Sims, BU