Please don't throw the concept out.  Like all tools it has it's place.

For example, we are thinking about reorg'ing one of our TSM databases.
Why?

1)  I ran a test reorg of one of our TSM databases on a test system.  The
db was 80gb
in size with 72gb used.  It shrunk to 40gb used.

As discussed -  it won't stay there very long,  BUT . . .

2)  We are changing our policies to cut down the versions we retain.

After   things settle down, I would like to run another test reorg.  It MAY
be
worth our while to do a reorg, or maybe not . . . we'll see . . .

Rick







                      "Hart, Charles"
                      <charles.hart@MED        To:       ADSM-L AT VM.MARIST 
DOT EDU
                      TRONIC.COM>              cc:       (bcc: Richard L. 
Rhodes/OE/FirstEnergy)
                      Sent by: "ADSM:          Subject:  Re: Database 
fragmentation formula (was Re: Online DB
                      Dist Stor                 Reorg)
                      Manager"
                      <[email protected]
                      .EDU>


                      10/21/2003 09:12
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






Thank you for the response, If what you say is true, then I will forgo the
Reorg concept, as it appears to be a waste of time.

-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: Tuesday, October 21, 2003 7:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Database fragmentation formula (was Re: Online DB Reorg)


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






-----------------------------------------
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.