Thank you for the additional information. The day before I posted this article I was curious to know if the consistent get was undo related, but I did not make any progress confirming that it was an undo block that was responsible for the consistent get. As an experiment I set the undo related events 10201, 10220, 10221 as mentioned here: http://www.juliandyke.com/Diagnostics/Events/EventReference.html#10201

I did not obtain any additional information from the enabled additional events. I might experiment a bit with the session statistics – thank you for the idea.

a bit late to the party – but here’s some additional info:

1. Your guess that the session is re-reading the block while it is still pinned: Doesn’t sound very plausible, because that is exactly the point of a buffer being pinned: You don’t need a logical I/O to access that buffer again, so I would be surprised if Oracle accounted such a buffer re-visit as “consistent get”

2. It looks like that access to the undo segment header (where the transaction slot for the transaction is located) is recorded as “consistent get” but not shown in the 10200 trace. So my best guess is that the consistent get in question for that particular case is the access to the undo segment header

3. Another good additional source for information in such cases is to delta the session statistics – it will give additional clues about what type of activity that is covered by the session statistics has been performed.

Randolf