Causes and Cures of Tablespace Fragmentation Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
3 of 4
specifies an explicit storage clause when creating, say, a table that completely overridesthe tablespace's default storage clause. And there's nothing you can do about it.In Oracle 8, you can use a 'minimum extent' clause to specify that extents should always beof that size, or a multiple thereof.
And that cannot be over-ridden by something specifiedwhen creating a table.
With a minimum extent of 500K for the tablespace, if someonetries to create a table with, say, an INITIAL of 223K and a NEXT of 398K, then that tablewill actually acquire a 500K initial extent, and its next extent will also be 500K. Two 500Kextents starts sounding like consistent extent sizes, and thus no fragmentation.Unfortunately, it's not perfect: if the table had a next extent size of 724K, then it willactually acquire a 1Mb next extent -because 'minimum extent' means 'minimum extent ormultiples thereof' -and the nearest multiple of 500K when you've asked for 724K is 1000K,or 1Mb. So you've still got odd-sized extents, and the possibility of eventual fragmentation.Fortunately, in 8i, there's a perfect cure. You create your tablespaces as "locallymanaged" with a 'uniform size' clause. Nothing can over-ride the uniform size clause, andyou don't get multiples of it, either. Set it to, say, 500K, and that is the ONLY size thetablespace can dispense. If you now ask for an initial extent of 724K, then you will beallocated
extents of 500K each. Ask for 1398K, and you'll get 3 500K extents, and soon. And since every extent is always going to be 500K, you've now got entirely consistentextent sizes, and zero possibility of ever encountering fragmentation.One more thing to say about this idea of consistent extent sizes: it does mean that youneed to plan your tablespaces more carefully. If all you had was a tablespace allocating500K extents, it would be a bit sad to then use it to house the "States and Territories of Australia" lookup table (which happens to consist of 8 records). That would be a mammothwaste of space -which is all fragmentation itself is at the end of the day. What you reallyneed, of course, is a
of tablespaces, some allocating 16K extents, some 64K, some256K, some 512K and so on. Then all you have to do is house the right segment in the rightsort of tablespace. CUSTOMERS in the 512K tablespace; SALES in the 10Mb tablespace;COMPLAINTS in the 16K tablespace (at least, I hope you don't get too many complaints!),and so on.Now let's assume that you didn't know any of all this, and you've housed your tables allover the place, with wildly differing extent sizes, and you're worried you’ve gotfragmentation. Two questions arise: how do you
you’ve got fragmentation, and howdo you cure it?Diagnosis is relatively easy. If you issue the command
SPACE WHERE TABLESPACE
you'll be counting the total number of piecesof separate free space in a tablespace, and seeing the size of the single biggest piece. If count(*) goes through the roof, but max(blocks) is trivially small, that's a fairly goodindication of fragmentation -lots of little pieces of free space. You can then query thedba_free_space view without the aggregating functions to make absolutely sure.