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

1. 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

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 VALUE FOR FILE_ID: 9
OLD 3: WHERE FILE_ID=&FILE_ID
NEW 3: WHERE FILE_ID=9
ENTER VALUE FOR BLOCK_ID: 342
OLD 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS-1)
NEW 4: AND 342 BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS-1)
SEGMENT_NAME SEGMENT_TYPE
-------------------------- ------------------
SYS_IL0000032134C00002$$ LOBINDEX
… and now we know precisely the segment that’s in trouble!
Copyright © Howard Rogers 2001 10/18/2001 Page 2 of 2