I can’t think of any good way of doing this; although v$sql (and related views) report the number of buffer_gets against an child cursor, there’s nothing similar that allows you to identify the buffer gets that were for undo records, or the number of CR buffers created.

There is event 10201 (trace undo applied for CR), if you enabled this and event 10046 for a session you could get a (very large) trace file that allowed you to count the number of undo application preceding each execution or fetch of a statement.

If you monitored all the sessions for a while, reporting the two stats (and the undos applied per CR created) every few minutes you might find a session responsible for a lot of the undo application – at which point you might be able to check v$open_cursor and v$sqlstats for the statements that the session was running.

Neither strategy sounds particularly viable in a busy production system, though. The former will be more accurate, but introduce a lot of overhead to the critical statement – the latter is a bit hit and miss.

I have this isse and suspect 1 query is generting most of the ‘CR clones’ – bu how to make that join ?

Capturing PQ slave activity isn’t really possible – some of the slave numbers sum back to the co-ordinator, but some may be missing. You really need to run an extract against v$px_sesstat just before the query ends.

PQ Slaves are allocated as the query starts to run – not at parse time; if parallel_min_servers is non-zero they the processes can exist independently of any running query, even if parallel_min_servers there is an “idle time” before they die so one query can pick up the slaves spawned by another.

I belive the PQ slaves get created during query parse time instead of session creation time.

Thanks
Ananda

Thanks for the comment.
Another source of “consistent gets – examination” that I wrote about a few years ago is the special case of access to a single table hash cluster.

Thanks for pointing that out – now fixed.

You say: “data blocks consistent reads – undo records applied” = 1

but the dump of the stats says:
data blocks consistent reads – undo records applied 1,001

Nice work as always.