Skip to main content

Troubleshooting Oracle Provisioning - Understanding dSource Linking and 'double-sync'

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 a dSource, then snapshots are created by the SnapSync service, which uses the Oracle RMAN utility to capture changes in the source database.  When a dSource is initially created or linked, the Oracle RMAN utility performs a FULL (a.k.a. level "0" or zero) incremental database backup which copies the entire source database to the Delphix Engine appliance.

While this full database backup is in progress, the source database continues to operate normally and all changes to the database are logged in the database transaction logs, also known as the Oracle redo logs.  If the full database backup takes a very long time, then it is possible that dozens, hundreds, or thousands of redo logs may be generated.  Therefore, in order to recover a database copy from this full database backup, the restore operation of the datafile images must be followed by a roll-forward operation, where the redo logs are re-applied to the restored datafiles to bring them all to a consistent point-in-time.

Because of this effect, it is usually wise to immediately perform a SnapSync snapshot immediately after a long link of a dSource.  This second snapshot usually completes quickly, providing a faster restore point for provisioning.  For this reason, Delphix has created an automatic operation called a "double-sync", which is explained in a Delphix Support knowledge base article here.