Comments on: Change Tracking

By: The Fine Art of Baloney Detection, in honour of Dr. Carl Sagan | The Pythian Blog

Mon, 27 Jun 2011 13:06:34 +0000

[...] really. I’ll use, as an example, another hero of mine Jonathan Lewis (who as a side note said something nice about Pythian recently). You might remember the numerous evidentiary battles championed by Jonathan? Not to [...]

By: Jonathan Lewis

Jonathan Lewis — Wed, 03 Feb 2010 11:34:01 +0000

Here’s an important alert from Oracle for users of 11.1.0.7:

note 756435.1 Block change tracking on physical standby can cause incorrect backups.

Make sure you read the note to cross-check my interpretation – but the gist of it is that if you are using a standby database as the source of your backups, and use block change tracking on the standby to allow fast incremental backups, then those backups can be incorrect.

On the standby server execute sqlplus and run:

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

By: Jonathan Lewis

Jonathan Lewis — Fri, 15 Dec 2006 14:04:06 +0000

I see that Alex has done some further work on the latch activity relating to change tracking, reported at http://www.pythian.com/blogs/317/change-tracking-state-change-latch

By: Alex Gorbachev

Alex Gorbachev — Mon, 27 Nov 2006 04:03:46 +0000

Thanks Fairlie. Indeed, 7 is not fixed anywhere in the structure. I was looking to find this parameter but probably didn’t try hard enough. I’ll test it next days to be sure it controls number of versions.

By: Fairlie Rego

Fairlie Rego — Mon, 27 Nov 2006 01:41:09 +0000

Alex, Jonathan

Haven’t tested this out but the number of bitmaps to be stored for a datafile could be related to _bct_bitmaps_per_file (the default value is 8 )

By: Alex Gorbachev

Alex Gorbachev — Sat, 25 Nov 2006 23:14:46 +0000

My guess about change tracking state change latch was incorrect. Here is a small note about it.

By: Alex Gorbachev

Alex Gorbachev — Fri, 24 Nov 2006 01:48:21 +0000

Mark,
I figured from Tanel how debug latch activity and plan to experiment with it when I have time. Just to confirm.
a dba,
Thanks for sharing you experience. Sounds like a good real life example.

By: dba

dba — Thu, 23 Nov 2006 13:32:19 +0000

Very interesting – looking at one of our 10g databases that sees two incremental’s a day and one weekly full backup.

truely enough, after day 3, backup duration increases more than 2x – and it stays like that until the next full backup.

a dba

By: Jonathan Lewis

Jonathan Lewis — Wed, 22 Nov 2006 07:07:11 +0000

Mark, I think this is covered in Alex' presentation. I think his current conclusions are that there is an in-memory bitmap of the database, protected by a couple of latches, that gets updated by DBWR as part of the process of writing blocks to disc. CTWR picks up the bitmap and dumps it to disc - hence the need for latch protection.

By: Mark Burgess

Mark Burgess — Wed, 22 Nov 2006 01:29:52 +0000

Jonathan,

I could not find any information on the mechanism used for the CTWR to capture the block id’s it needs to write to the change tracking file. Does the implementation use a post by the LGWR to CTWR of the blocks being changed or does it use a log miner/streams mechanism to capture the block id’s?

Regards,

Mark