I didn’t know the answer to the question about log_io myself, so I’ve just done a quick check. FYI – on 10.2.0.3 it seems to be “db block gets” + “db block changes”.

You’ve identified the critical point in the consistent get. When you first arrive at the block it has a history of transactions, some of which may be committed, some uncommitted, and those transactions could have been running concurrently – and you have to reconstruct the right thing.

The db block get, though, doesn’t have to reconstruct anything – it has to be the most recent version of the block, including all changes, whether or not committed.

Is it because a change vector is transaction based, while you may have many transactions taking place at the same time in the block. Later if you re-roll only one transaction, you create a version of the block which reflect only the mutation covered by this transaction. Your block is then a mix of legacy-data – area not in the transaction – and and re-reconstructed – area in transaction.

A ‘db block get’ would then be, by opposition, a block with ALL transactions reconstructed (or present) at a given SCN.

(a) but (see my update) a consistent block can in a state that doesn’t match any point in time (SCN) in it’s history.

(b) All blocks that have been used will have some change vectors that reference them.

Side note: I’ve got a draft note about the difference between “clean” and “cleaned out” – but “clean” simply means that the block in memory is identical to the block on disc. It is possible to do a db block get for a block that is not a clean block.