“change tracking state change latch”

Posted in: Technical Track

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?

Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

What does it take to be chief technology officer at a company of technology experts? Experience. Imagination. Passion. Alex Gorbachev has all three. He’s played a key role in taking the company global, having set up Pythian’s Asia Pacific operations. Today, the CTO office is an incubator of new services and technologies – a mini-startup inside Pythian. Most recently, Alex built a Big Data Engineering services team and established a Data Science practice. Highly sought after for his deep expertise and interest in emerging trends, Alex routinely speaks at industry events as a member of the OakTable.

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

Alex Gorbachev
November 27, 2006 9:23 am

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.

Jonathan Lewis
December 15, 2006 7:51 am

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 ?

Alex Gorbachev
December 15, 2006 9:37 am

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…


Leave a Reply

Your email address will not be published. Required fields are marked *