Handling a source database reset logs event (Oracle source continuity)
Overview
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 4.1.1.0/4.0.6.0, 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 likely has 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:
The database undergoes a resetlogs operation.
If LogSync is enabled, it generates a fault and stops.
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.
Source Continuity is not supported for VDBs or vCDBs. Any reset logs or flashback performed on a VDB requires a refresh or rewind to resolve.
Creating a new Timeflow
When LogSync detects the restlogs 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.
Once LogSync detects the reset operation and throws the fault, no more changes will 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 dSources view. Previous snapshots and Timeflow will still exist and be visible through the command-line (CLI) Capacity screen.
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 dbdhcp
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.