Fkconstraint

199 views

Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
199
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Fkconstraint

  1. 1. Causes and Cures of Tablespace Fragmentation Administration TipsTablespace Fragmentation : Causes and CuresFragmentation 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 havent simply shown themas white, empty blocks. Thats because Oracle retains some memory of where DEPT usedto be... specifically, it remembers where the old extent boundaries for the table used toCopyright © Howard Rogers 2001 10/18/2001 Page 1 of 4
  2. 2. Causes and Cures of Tablespace Fragmentation Administration Tipsbe. 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. Thats 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 thats 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 offragmentation 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. Ofcourse, EMP would still have failed to extend at the end, but thats just a question ofrunning 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 neednt worry aboutfragmentation -except that the chances of you never needing to do one of these things iszero!So given that we cant 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 someoneCopyright © Howard Rogers 2001 10/18/2001 Page 2 of 4
  3. 3. Causes and Cures of Tablespace Fragmentation Administration Tipsspecifies an explicit storage clause when creating, say, a table that completely overridesthe tablespaces default storage clause. And theres 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, its 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 youve asked for 724K is 1000K,or 1Mb. So youve still got odd-sized extents, and the possibility of eventual fragmentation.Fortunately, in 8i, theres a perfect cure. You create your tablespaces as "locallymanaged" with a uniform size clause. Nothing can over-ride the uniform size clause, andyou dont 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 youll get 3 500K extents, and soon. And since every extent is always going to be 500K, youve 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 ofAustralia" 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 dont get too many complaints!),and so on.Now lets assume that you didnt know any of all this, and youve housed your tables allover the place, with wildly differing extent sizes, and youre 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) FROMDBA_FREE_SPACE WHERE TABLESPACE = BLAH; youll be counting the total number of piecesof separate free space in a tablespace, and seeing the size of the single biggest piece. Ifcount(*) goes through the roof, but max(blocks) is trivially small, thats 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.Copyright © Howard Rogers 2001 10/18/2001 Page 3 of 4
  4. 4. Causes and Cures of Tablespace Fragmentation Administration Tips(Incidentally, if youre using Oracle Enterprise Manager, the Tablespace Map utility gives anice visual display of extent allocations within a tablespace, and fragmentation leaps outat you as lots of little bits of white space).Curing it is tricky. You can always try this command: ALTER TABLESPACE BLAH COALESCE;That removes extent boundaries from contiguous pieces of free space, thus converting lotsof small pieces that cant be re-used into a giant contiguous chunk that can be. If we didthat to the tablespace described earlier, wed get this sort of picture after doing acoalesce:Notice how the 3+4+4 has become one long piece of 11 blocks. That would allow EMP,requesting a 5 block extent, to acquire it from that piece of free space. Notice whatcoalesce didnt do, though: It did not merge the 11-block chunk with the 2-block chunk atthe end to generate a single 13-block piece of free space. Coalesce only merges adjacentpieces of free space.If you wanted to achieve that sort of complete de-fragmentation, about the only realisticoption is to export EMP with COMPRESS=N, truncate it, perform a coalesce and then re-import with IGNORE=Y. That would indeed achieve the following sort of result:Of course, having to truncate the EMP table means its unavailable for use by anyone untilthe import has finished, so its not exactly a high-availability solution.Which means that we should recognise that preventing fragmentation from happening inthe first place is infinitely cheaper than seeking to fix it up afterwards. And the rules forpreventing it are easy: use consistent extent sizes within a tablespace. (And that in turnmeans, if youve any sense, and are using 8i, use Locally Managed tablespaces, becausewith them, fragmentation simply cannot happen).Copyright © Howard Rogers 2001 10/18/2001 Page 4 of 4

×