Good point for reducing size, other than normal growth why would it not last long, is ther other reasons?
Thank you. -----Original Message----- From: Richard Rhodes [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 8:44 AM To: [EMAIL PROTECTED] Subject: Re: Database fragmentation formula (was Re: Online DB Reorg) 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" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 7:44 AM To: [EMAIL PROTECTED] 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.
