In earlier versions of the Delphix Engine, when an Oracle database underwent a resetlogs operation, you were required to re-link the Oracle source. This meant that you had to completely back up the Oracle database and store it again on the Delphix Engine. If any virtual databases (VDBs) were provisioned from the dSource and needed to be saved, you had to rename and save the old dSource, resulting in a possible doubling of storage space consumed on the Delphix Engine. The old VDBs could not be refreshed to the relinked dSource.

Beginning with Delphix Engine version, the Oracle database no longer requires you to re-link sources after a resetlogs operation. The Delphix Engine will detect this condition, automatically take a new full backup, and create a new TimeFlow for the next SnapSync of the source. Benefits of the Oracle Source Continuity feature include: 

  • Lower storage costs and easier administration. 
    • Only the changed blocks of the new SnapSync backup will be stored on the Delphix Engine. Because of the way the Delphix Engine handles duplicate blocks, the full backup is likely have a storage requirement similar to an incremental backup.
  • Existing VDBs provisioned from previous snapshots for the source will remain.
    • You can use and refresh those VDBs to the new snapshot.

The improved user workflow replaces the old user workflow, which directed users to troubleshoot when SnapSync would fail. Begin Oracle Source Continuity in the following way:

  1. The database undergoes a resetlogs operation.
  2. If LogSync is enabled, it generates a fault and stops.
  3. Start SnapSync. The SnapSync does a full restore of the database to a new TimeFlow, clears the fault, and restarts LogSync. If you created VDBs prior to the resetlogs operation, they will still exist after the SnapSync; you can refresh them from the new snapshot.

Creating a New TimeFlow

When LogSync detects the resetlogs operation, it will still stop and generate a fault. LogSync must stop, because a new timeline has been created on the database. This usually happens because the database has been rewound to a past point. The transaction logs being generated on the new timeline are out of sync and conflict with logs from the old timeline. The data files are also out of sync with the data files on the Delphix Engine. You must create a corresponding new TimeFlow on the Delphix Engine to store the new logs and new versions of the data files. This requires taking a new backup of the database. The following screenshot shows an example of a fault from a resetlogs operation being detected. Note the fault and that LogSync is inactive. 


Once LogSync detects the resetlogs operation and throws the fault, no more changes will be be retrieved from the database until you start a new SnapSync. This SnapSync will take a full backup, clear the fault, and restart LogSync. Only the new snapshot and TimeFlow will be visible in the dSource TimeFlow view in the graphical user interface (GUI). Previous snapshots and TimeFlow will still exist and be visible through the command line interface (CLI) and the Capacity TimeFlow view of the GUI. The following screenshot shows the same Delphix Engine after a SnapSync has been performed. Note that the fault has been cleared, LogSync is now active, and only the new snapshot is visible in the GUI.


The following CLI output shows that the old and new TimeFlow and snapshots are still available. The name of the original TimeFlow for the database is "default." The name of the new TimeFlow that was created during the SnapSync is "CLONE@2015-01-15T17:07:20."

delphix> /TimeFlow list display=name,container

NAME                         CONTAINER

'CLONE@2015-01-15T17:07:20'  dbdhcp1

default                      dbdhcp1

delphix> /snapshot list display=name,container,TimeFlow

NAME                         CONTAINER  TimeFlow

'@2015-01-16T00:50:08.784Z'  dbdhcp1    default

'@2015-01-16T00:52:13.685Z'  dbdhcp1    default

'@2015-01-16T00:53:46.873Z'  dbdhcp1    default

'@2015-01-16T00:55:18.079Z'  dbdhcp1    default

'@2015-01-16T01:08:02.411Z'  dbdhcp1    'CLONE@2015-01-15T17:07:20'

The old snapshots and TimeFlow will still be subject to logfile and snapshot retention policies. You can also delete the snapshots manually. In addition, you can use the CLI to provision from the old TimeFlow.

Related Links