In the world of Oracle backups, time is money. If you have a 20TB database but only 100GB of data changes every day, it feels like a waste of resources for Oracle to read through all 20TB just to find those few changes.

Block Change Tracking (BCT) is the feature that solves this. It’s essentially a "shortcut" for RMAN incremental backups.

1. The Problem: The "Full Scan" Headache

By default, when you perform an Incremental Backup, RMAN has to scan every single block in your datafiles to check the "System Change Number" (SCN). It’s looking for blocks that were modified since the last backup.

Even though RMAN only saves the changed blocks to the backup file, it still has to read the entire database to find them. For a large database, this means:

• High Disk I/O.

• Long backup windows.

• Heavy CPU usage.

2. The Solution: The Tracking File

When you enable Block Change Tracking, Oracle starts a new background process called CTWR (Change Tracking Writer).

• How it works: As transactions happen, the CTWR process records the address of every modified block in a small, dedicated Binary File (the Change Tracking File).

• The Result: The next time you run an incremental backup, RMAN doesn't scan the datafiles. Instead, it simply opens the tiny Tracking File, sees exactly which blocks have changed, and goes straight to them.

3. Performance Impact: Before vs. After

Imagine a 10TB database where only 1% of the data changes daily.

4. Key Facts about BCT

• File Size: The tracking file is very small. It typically requires about 1/30,000th of the size of the data blocks it tracks. For a 1TB database, the file is only about 30MB-40MB.

• Space Management: Oracle automatically manages the size. It keeps enough history to cover the last 8 incremental backups.

• Location: It should be placed on shared storage if you are using Oracle RAC so all nodes can reach it.

5. How to Enable It

You can turn this on while the database is open. There is no downtime required:

-- Enable BCT and let Oracle pick the location
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

-- Or, specify a specific location
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 
USING FILE '/u01/app/oracle/admin/orcl/bct/retention.bct';

To check if it’s working:

SELECT status, filename, bytes FROM v$block_change_tracking;

6. Is there a Downside?

There is a tiny "performance tax" on every write operation because Oracle has to update the tracking file. However, for 99% of systems, this overhead is so small it’s impossible to measure. The benefit of reducing a 10-hour backup window to 30 minutes far outweighs the cost.

Peer Tip: BCT is only used for Incremental Backups (Level 1). It does not help with Full Backups (Level 0) because a Level 0 backup has to read every block anyway. If you aren't using an incremental strategy, you don't need to turn this on!