There is a reference to this on page 16 of Oracle Core. The v$bh structure has a bitmap for various flags, including a bit for “has private redo”. If a session was to view a block that is flagged with private redo it forces the owning session to flush all its in-memory undo and private redo into public memory – which includes the steps to modify the buffered block. I think this event is recorded in x$ktiff under statistic “Contention flushes”.

10g doesn’t apply any changes to data blocks until the commit (for “short” transactions),

I have a question about this. How do other sessions know the changes made by uncommitted transactions when they do “db block get”, that is, how to guarantee the CUR block includes latest changes? This question puzzled me for a while.

Thanks

alter system dump datafile X block Y;

For further reading on this topic, you can always see chapter 2 and the appendix of Oracle Core.

The same sort of oversight happens with the redo and undo, People don’t think about the cost of maintaining the indexes. How many times do you see complaints on OTN from people saying: “My batch job inserts 1,000,000 rows into a table – why is it taking 3 hours and doing 3.5M physical reads?”

There’s probably a very good reason for all those “extra” bytes. One day I may look at them more closely.

My second question was not specific to undo and more of an observation than a question: it just seems amazing that to insert two tiny rows with two tiny indexes you generate 1592 bytes of redo. On the other hand, it would seem appropriate to focus the redo design on keeping redo generation and recovery simple and efficient rather than optimising space usage on a circular file. So perhaps I shouldn’t be that surprised.

An index entry doesn’t have an absolute location – the row directory is adjusted as each entry is inserted and deleted, and leaf blocks can split, moving index entries to a completely different block; so when you insert an index entry the only way you can be sure of finding it to undo the entry is to store the key value. (This also means that when you undo an index insert you have to walk through the root and branch blocks before you can get to the correct leaf block – which makes index undo application more expensive than table undo application.)

I’ve never felt the urge to try and track down the function of every single byte in an undo change vector, so I can’t tell you what all the overheads are for. I’ve just picked out the important bits when I’ve needed to solve particular problems.

A couple of general questions about undo. Firstly, I am intrigued that the undo change vectors for index entries seem to include the column data (e.g. line 130 in 10g example above). This seems to contradict my previous understanding that undo for inserts would be minimal. Indeed, for a large IOT this might be onerous. I can’t see why this data is needed, can you?

The second question relates to the total size of the redo data. In the 10g example above, the length of the redo record is given on line 0 as 0×0638. 1592 bytes seems a lot of overhead; it is an average of over 100 bytes per change vector. I can’t work out where it is all going. Can you explain please?

Every block change is described in the redo – even the changes which are the changes to the undo blocks.
On recovery (instance or media) every redo change vector that needs to be applied to the data files is applied – including the redo changes vectors that describe changes to the undo blocks – that’s how Oracle bring the database up to date on recovery, and the changes to the undo blocks mean that after (forward) recovery any uncommitted transactions that Oracle finds in the undo segments can be rolled back properly.