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 instance startup (when opened) — CTWR process starts and takes the latch once.
- during instance shutdown — CTWR stops and takes the latch once.
- 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?
4 Comments. Leave new
Just skimmed through your presentation. Needless to say it is very informative and excellent.
• I think the number of bitmaps to store for each datafile is 8 because it is governed by _bct_bitmaps_per_file. I wonder what would happen if u were to change it to 0
• On Slide 26 you mention v$datafile_backup. The view name is v$backup_datafile. (It’s good to know that I am not the only person who gets confused with these views ïŠ )
• I remember in earlier versions there was a bug where the direct load used to fail when using BCT. I believe this has been fixed.
One of the current issues I know of is
Bug 5606208
BLOCK CHANGE TRACKING (BCT) LOST AFTER SWITCHOVER
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.
Alex, just an idle thought about the latch: might it be there for RAC systems to ensure that no two RAC systems end up “owning” the same bitmaps in the change tracking log ?
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…