On page 38 it is said “Finally, you can see from the uba that if you go to record 5 of block 11,976 of file 6 (which should have sequence number 0×0543)”. My question is where does “block 11,976″ as well as “file 6″ come from ? If you look at uba – 0x01802ec8.0543.05:

05 – undo record number (comes from transaction table)
0543 – sequence number

0x01802ec8 to decimal gives us 25177800 (which is SCN I guess..). How do you manage to get that block and file number info?

Thank you very much in advance!

I don’t think v$undostat really fits in chapter 3 with transactions, it would be more appropriate in the context of chapter 2 (redo and undo) but I didn’t make any comments about how much space had to be allocated for keeping undo and how Oracle managed it.

Here’s an outline that may help answer your questions. We can set (or Oracle can automatically adjust) and “undo retention” time with the intention that no undo block should be overwritten until the transaction(s) that generated the undo records in that undo block have been committed for at least that amount of time. Although this retention time is often spoken of in terms of keeping blocks the actually granularity of the check occurs at the extent level.

Assume a session is changing load of data in a single transaction and the undo_retention is 900 seconds. Assume our transaction is quite large and generates a lot of undo very quickly. At some point we happen to fill the last available block in the current extent and move on to the next extent in the chain that makes up our undo segment, and find that the commit SCN for the most recently committed undo record in that extent happened only 12 minutes ago. This is the scenario where most of these columns are relevant.

We can’t immediately overwrite the next extent, so we have to grow the segment – which is easy if there is free space in the undo tablespace, but if there isn’t we first check to see if there are any other segments which have “expired” extents, i.e. extents with no undo records that were committed less than 900 seconds ago. If we find one (and I believe we pick the oldest such extent we can find) then we have “stolen” an “expired” extent, (EXPSTEALCNT goes up by one) while the other segment has “released” “expired” blocks (EXPBLKRELCNT) – and we record the block count because UNDO extents can be of different sizes.

If we find that no other segment has any expired blocks, we look for the extent with the oldest commit. This isn “unexpired” extent, and we steal it because we have to continue working — this gives us the UNXPSTEALCNT and UNXPBLKRELCNT. One bit of timing I’m not sure about (and would have to research) is whether we overwrite unexpired extents from our own segment before stealing extents from other segments – this overwriting of our own unexpired extents is the UNXPBLKREUCNT (counting blocks from the extent). Of course if we had had some expired extents in our own segment when we got to the end of the current segment we would simply have run the transaction on into the next (i.e. oldest) extent – and this would have shown up under EXPBLKREUCNT.

As for ACTIVEBLKS, UNEXPIREDBLKS and EXPIREDBLKS, I haven’t looked closely at them – I’ve only glanced at the definition and guessed at what they mean and haven’t had to work out whether or not my guess is correct. I suspect that they are snapshots taken either at the beginning or end of the snapshot interval (10 minutes).

Expired blocks are probably blocks in extents where the entire extent has been used and all transactions committed far enough in the past to be outside the retention time.

Unexpired blocks are probably blocks in extents where the entire extent has been used but the extent has some transactions in it that committed in the recent past – i.e. less than “retention time” seconds ago.

Active blocks are probably blocks in extents where there is a transaction that has used blocks in that extent and has not yet committed.

And regarding ACTIVEBLKS, UNEXPIREDBLKS and EXPIREDBLKS, what exactly are active, unexpired and expired blocks in the context of transaction managment?

Sorry about the delay in answering this question. You’re heading in the right direction, but your comment isn’t quite right.
It’s important to remember that when a buffer is written to disc it isn’t cleared from memory (unless dbwr has been called to write it because a session needs some free buffers). With this though in mind:

a) commit cleanout can occur if the block is in the buffer – whether or not it has been written to disc. In fact if I update the block, then something causes it to be flushed from memory, then you re-read it, and then I commit, I can still visit that (back) in-memory copy of the block and apply commit cleanout.

b) delayed block cleanout occurs if commit cleanout hasn’t occured, and the block has been flushed from memory (which means it must have been written to disc); and it occurs the next time someone reads the block into memory. If I only committed after the block was flushed, that would be one reason why commit cleanout hadn’t happened; but possibly I didn’t even commit until the block had been flushed, possibly some other process was pinning the buffer at the moment that I committed and wanted to do a commit cleanout.

Correct – I’ve got the two columns the wrong way round.
(It’s also extremely unlikely that two slots from different segment would be at exactly the same sequence at the same time;)

Interestingly, when oracle performs single session direct path read on table and repeat same query again (at least in same read only transaction), it won’t perform TTR any more, although there is still plenty of data blocks with dirty ITL slots placed on disks (because direct path read didn’t clear them).

Regards
Pavol Babel