Counting Extents

Administration Tips

Counting Extents
When you want to determine the total number of extents a table has acquired, issue the following command:
SELECT SEGMENT_NAME, COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_NAME='NAME_OF_TABLE' GROUP BY SEGMENT_NAME;

You'll get a report like this: SEGMENT_NAME COUNT(*) ----------------------------------------- ---------ALBUM 4 If you wish to see physical and size details for each extent, try this one:
SELECT SEGMENT_NAME, EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS FROM DBA_EXTENTS WHERE SEGMENT_NAME='ALBUM';

SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS ----------- ---------- ---------- ---------- ---------- -------ALBUM 0 9 17 65536 16 ALBUM 1 9 321 65536 16 ALBUM 2 9 353 65536 16 ALBUM 3 9 369 65536 16 ...and this starts to show important information -such as the fact that all the extents (in this case) are of consistent size (good), and are all located on the one physical data file (not so good, perhaps -all I/O will be hitting the one device). The block_id column in this report shows you the first block of the relevant extent. From the above report, it is apparent that these four extents are not lying contiguously next to each other within the tablespace. The first extent starts at Block 17, and is 16 blocks long. If the extents were contiguous, that would mean the next extent starting at Block 33 instead of which we see a dirty great 300ish-block gap before the next extent actually starts at Block 321. In fact, the only contiguous extents are the last two: Block 353 plus 16 would mean the next extent should start at Block 369 -which it in fact then proceeds to do. In this way, it's possible to convert a boring old set of raw numbers into a mind's-eye picture of the extent layout of a segment. In our case, the picture (where 'X' marks data and '-' marks something else -perhaps free space, perhaps another segment) would look like this:
Copyright Howard Rogers 2001 10/18/2001 Page 1 of 2

Counting Extents

Administration Tips

|XXXXXXXXXXX|-----------------------------------------------|XXXXXXXX|--------|XXXXXX|XXXXXX| (Incidentally, the fact that extents are not contiguous is not a performance problem at all, and is not what is meant by 'fragmentation'). Knowing where your data is laid out within a tablespace is important when you check you Alert Log and discover error messages along the lines of "Corrupt Block Detected, File 9, Block 331" -since the first thing you'll want to know is "What segment was occupying Block 331 on File 9??!" From the above report, you can probably see that it would be part of the second extent of the ALBUM table that was corrupted. But what if the corruption had been reported for, say, File 9 block 342? There's clearly a need to convert a file and block number into a corresponding segment name, and the query to do that is this: SELECT SEGMENT_NAME,SEGMENT_TYPE FROM DBA_EXTENTS WHERE FILE_ID=&FILE_ID AND &BLOCK_ID BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS-1); When run, this will prompt you for the File Number and Block ID as reported in the Alert Log, and it will then return the name of the affected segment. If it had been File 9, and block 342, we'd get this sort of output: ENTER
OLD NEW

ENTER
OLD NEW

FILE_ID: 9 3: WHERE FILE_ID=&FILE_ID 3: WHERE FILE_ID=9 VALUE FOR BLOCK_ID: 342 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS-1) 4: AND 342 BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS-1)
VALUE FOR

SEGMENT_NAME SEGMENT_TYPE -------------------------- -----------------SYS_IL0000032134C00002$$ LOBINDEX and now we know precisely the segment thats in trouble!

Copyright Howard Rogers 2001

10/18/2001

Page 2 of 2