Skip to main content

Consider Enabling Block Change Tracking (BCT) to Improve Snapsync Performance Times (KBA1651)



KBA# 1651

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases





How Block Change Tracking (BCT) Can Improve Oracle SnapSync Times

When a virtual database (VDB) is being provisioned, Delphix first creates a virtual copy of the most recent datasource snapshot, and then performs a roll-forward recovery to the specified point-in-time using transaction logs. The more transaction logs (i.e. Oracle redo logs) that need to be applied, then the longer the VDB provision operation will take.

When the underlying datasource is an Oracle dSource, snapshots are created by the SnapSync service, which uses the Oracle RMAN utility to capture changes in the source database. The Oracle RMAN utility is performing an incremental datafile backup to capture datafile changes. Unless BCT is enabled, RMAN must scan the entire database to find the changed data blocks within the database datafiles.

If BCT is enabled, then a list of changed blocks is maintained within a Block Change file outside the database. Incremental backups merely read from the list to locate the changed blocks, reducing the elapsed time of incremental backups substantially. 

For a more detailed explanation please refer to the Oracle online documentation:

Using Block Change Tracking to Improve Incremental Backup Performance

Enabling and Disabling Block Change Tracking

Checking Whether Change Tracking Is Enabled

Block Change Tracking (BCT) and Delphix

The Delphix Engine supports linking both physical and logical standby databases. In general, Delphix recommends enabling Block Change Tracking (BCT) on a primary or standby source database.

For further recommendations regarding enabling BCT on an Oracle Physical Standby Databases please refer to the Delphix Engine online documentation, Linking Oracle Physical Standby Databases.