IOUG Collaborate 07: Oracle Block Change Tracking Internals

Posted in: Technical Track

I first presented on Oracle 10g Block Change Tracking Internals at UKOUG 06 in Birmingham. It was very well received, but there were quite a few gaps in my knowledge, and I later discovered I was incorrect in some places. I’ve done some additional research, filled in the blanks and corrected in a few places.

The wrong part concerned which processes track changes in blocks. I assumed it was database writers when in fact it’s a shadow process changing the block that produces change-tracking entries. I also added details on how this info is passed to CTWR process, which SGA memory areas are used for that, and how both of these impacted by the number of CPUs. In addition, I mentioned hidden parameters that are related to block change tracking.

The presentation and white paper are available for download. If you didn’t happen to be at the presentation itself, I suggest you look at the paper rather than the slides — it has more details and is easier to follow.

Unfortunately, I focused too much while preparing on the new areas I wanted to cover in this session, and didn’t invest enough time in reviewing the whole presentation and old material. Imagine my shame and embarrassment when I actually forgot a few slides and had to actually look at some of them for few seconds to recall what they were about. I also found that the audience was less interested than that at UKOUG in this level of internals. In the end, the presentation didn’t go as well as it did in Birmingham, so I learned an important lesson this day: never overestimate your knowledge of the topic and always vigorously review your presentations, even those repeatedly delivered.

Nevertheless, there were folks very interested in the details and since I was getting those much-needed nods during my session, I had some confirmation that the audience (or at least part of it) was following the thread. I think next time I should include the demo in presentations with a similar level of internal details — that should make it a much better experience and more lively for the audience.

Interested in working with Alex? Schedule a tech call.

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.

5 Comments. Leave new


As per my understanding, RMAN switches the bitmap version of the datafiles at the starting of incremental backups.

If some of the datafile blocks get updated at the time of switching the bitmap version, how does Oracle keep track of those blocks.

In this scenario, these changed blocks will not be there in the current (new) bitmap version as well as previous bitmap version.

How does Oracle make sure that these blocks are backed up during next incremental backups.


I’m writing this by memory so…

When incremental backup starts – there is incremental backup checkpoint SCN – that’s what used. Block with SCN below that – previous bitmal. All others – the following bitmap.

Also, CKPT process is synchronized with incremental backup SCN’s and that’s the process that processes info on the way from processes actually updating the blocks and the bitmap itself.



Hi Alex,

Thanks for your reply. I am doing some tests with BCT on Linux platform. Database is 11.1.0.

I am referring X$KRCBIT view and using DBMS_BACKUP_RESTORE.BCTSWITCH(fileId) procedure.

Total rows in a table:

SQL>select count(*) from qa.tbs10;


Scenario 1:
1] Bitmap version for datafile #8 is 1.
2] update qa.tbs10 set L_ORDERKEY=1000;
3] Dont switch the bitmap version during update.
4] After update is done, query X$KRCBIT view.

SQL>select count(*) from x$krcbit where fno=8 and vercnt=1;


Scenario 2:
1] Switch the bitmap version for datafile #8, so that current version is 2.
2] update qa.tbs10 set L_ORDERKEY=200;
3] Before update completes, switch the bitmap version again. The current version is 3 now.
4] After update query the X$KRCBIT view for bitmap version 2 and 3.
SQL>select count(*) from x$krcbit where fno=8 and vercnt=2;


SQL>select count(*) from x$krcbit where fno=8 and vercnt=3;


==> Total : 50080

5] The total count should be 50102, but it is 50080. There is a loss of 22 blocks.

It seems that datafile blocks which are updated during bitmap version switch are not there in any bitmap version.

During recovery I could see some partial data mismatch. It is not consistent though. I have also raised a TAR with Oracle for this.

Have you ever come across such a scenario?



Some of the block change tracking flows are asynchronous so the you might not have exact block counts in both cases (actually, those are chunk counts as it tracks dirty chunks of 32K so if you are 8K blocks – it’s 4 block per chunk).

I have also never used DBMS_BACKUP_RESTORE.BCTSWITCH procedure but did incremental backup of the tablespace/datafile I’m working with. Maybe you wanna do that.

Also, how do you detect mismatches during the restore?

Oracle Block Change Tracking in 2013
February 15, 2013 12:29 pm

[…] on Oracle Database 10g Release 1. I have also wrote a paper in support of the presentation for Collaborate 2007 (You do come to COLLABORATE 13 in April. Don’t […]


Leave a Reply

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