Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Fragmentation Oracle

Fragmentation Oracle

Ratings: (0)|Views: 147|Likes:
Published by rockerabc123

More info:

Published by: rockerabc123 on Jun 28, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/28/2009

pdf

text

original

 
Causes and Cures of Tablespace Fragmentation Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
1 of 4
 
Tablespace Fragmentation : Causes and Cures
Fragmentation of a tablespace occurs when lots of pockets of free space are availablewithin a tablespace, but none of them are of a sufficient size to house new extents forsegments.Imagine that we are going to create the following tables within a tablespace:EMP - Initial Extent Size 4 blocks, Next Extent Size 5 blocksDEPT - Initial Extent Size 3 blocks, Next Extent Size 4 blocksWe issue those commands, one after the other, and what do we have?(EMP is green-ish, DEPT is orangey).Now we start loading data into DEPT. It runs out of space in its initial extent, and has toacquire some more, and it does that a couple of times. Now our tablespace looks like this:(One Initial, followed by 2 next extents of 4 blocks each).At this point, we now start loading into EMP, and it acquires some extra extents toaccommodate the data, too:(One Initial, followed by 2 extents of 5 blocks each).Now we decide that DEPT would be better off in some other tablespace altogether, so wemove it (or drop it and re-create it elsewhere). That frees up the 11 blocks that DEPT wasusing, like this:Notice that, although the blocks used by DEPT are now free, I haven't simply shown themas white, empty blocks. That's because Oracle retains some 'memory' of where DEPT
used
 to be... specifically, it remembers where the old extent boundaries for the table used to
 
Causes and Cures of Tablespace Fragmentation Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
2 of 4
 
be. So that murky chunk in the middle of the tablespace is actually comprised of a piece 3blocks big, followed by two pieces of 4 blocks each. That's important, because if EMPneeds to acquire another extent of 5 blocks, where is it going to be able to get it?Er, ... at the END of the tablespace. Whilst there are 11 blocks going begging in themiddle of the tablespace, the retention of the old extent boundaries means that it lookslike a 3+4+4... no one piece of which is able to accommodate a new 5-block extent for EMP.Now if EMP wanted to acquire one final 5-block extent, can it do so? Clearly, the answer isno... there are just two blocks at the end of the tablespace, and the old 3+4+4 in themiddle. None of that allows for a new 5-block extent to be allocated. So even thoughthere are 13 blocks going free, none of them can actually be used. The User inserting thenew record that is provoking EMP to extend will instead get a message to the effect thatOracle is "unable to allocate next extent in tablespace BLAH", and the insert will fail.And that's fragmentation. Lots of free space, none of it in large enough contiguous chunks,able to be used. Fragmentation is
NOT
a performance issue. This is not like the sort of fragmentation you get with NTFS or FAT32 which really can slow down a machine to acrawl. Fragmentation is purely a question of using space efficiently, and not wasting it.What did we do to make this happen? Firstly, we freed up extents. Had we not dropped(or moved) DEPT, that chunk of 11 blocks in the middle of the tablespace would have beenin effective use, and there would have been no pockets of free space to worry about. Of course, EMP would still have failed to extend at the end, but that's just a question of running out of space in a tablespace, not of fragmentation. So, if you never, ever droptables or indexes, move tables, rebuild indexes or truncate tables, you needn't worry aboutfragmentation -except that the chances of you never needing to do one of these things iszero!So given that we can't totally avoid ever freeing up extents, what else caused this problem?Simply, that our original table definitions permitted EMP and DEPT to acquire odd-sizedextents. Had both tables always come in, say, 5 block extents, then of course EMP wouldhave been able to re-use one of the ones freed up when we re-located DEPT.Which brings us to how you
prevent 
fragmentation happening in a tablespace in the firstplace: ALWAYS use consistent extent sizes within a given tablespace. Make sure that allsegments within tablespace DATA all have INITIAL equal to NEXT, and all using the samevalues for both parameters. That way, fragmentation can simply never happen.Preventing odd-sized extents being created is not easy, though.In Oracle 7, you can use a 'default storage clause' at the tablespace level to say what youwould like segments to use as their INITIAL and NEXT settings. Unfortunately, if someone
 
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
two 
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
range
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
know
you’ve got fragmentation, and howdo you cure it?Diagnosis is relatively easy. If you issue the command
SELECT COUNT
(*),
MAX
(
BLOCKS
)
FROM DBA 
 _
FREE
 _
SPACE WHERE TABLESPACE
=
 
'BLAH';
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.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->