“change tracking state change latch”

In my UKOUG 06 presentation on block change tracking internals I assumed that “change tracking state change latch” is, probably, used by DBWR and CTWR to protect access to a buffer area in shared pool. I wanted to verify it and tried to trace this latch.

It turned out that it has nothing to do with what I thought. So far I found only few cases when “change tracking state change latch” is acquired:

during enabling and disabling block change tracking while database is open — session’s shadow process acquires the latch twice and CTWR process takes it once when it starts or stops.So it seems that this latch is used very rarely. Perhaps, there are other cases which I didn’t figure out but as I observed in several databases, the number of gets for this latch is 1 if block change tracking is left enabled from instance startup.

This leaves the open question — how does CTWR determine which blocks have been changed?

Fairlie,
Thanks for correction – it’s definitely v$backup_datafile. Indeed, according to this theory I should be more comfortable with X$ rather than V$. ;-)
Regarding _bct_bitmaps_per_file=8 – I guess it’s 8 because CTWR cleans up 8th past version and older. As I mentioned, I’ll check how it works if I change this parameter.

That’s an interesting idea Jonathan. Correct me if I’m wrong, but latches are to protect local instance memory structures so for RAC I would expect so kind of global enqueue. No?
Unfortunately, I’ve been extremely busy last days to put any time around it but I found out (thanks to one person contacted me from Oracle) that mechanism to pass block changes is indeed similar to a log buffer but it’s going directly from session processes and not DBWR. To be researched…