Resolving dSource faults after the SQL Server recovery fork GUID changes
While synchronizing your SQL Server database using Validated Sync, the Delphix Engine may raise the following fault if the Source database recovery fork GUID changes:
Title: The recovery fork GUID of the source database has changed from "415FCB99-43CA-40F9-8970-2007BBD6B28A" to "311831BB-2E0A-4491-A5A8-8CAF832D31D1"
Details: Detected a change in recovery fork GUID for source database "My_dSource".
User Action: Perform a manual sync on the dSource using a full or differential database backup from the new recovery fork GUID in order to resume validated sync.
In earlier releases of the Delphix Engine (126.96.36.199 and earlier), one the following faults may be raised instead:
Title: Source database has had a log chain break
Title: Source database was restored
Attempts to take snapshots of affected dSources in Delphix Engine 188.8.131.52 or earlier will also fail with the following error:
Error: The recovery fork GUID "BF730352-0B0F-4FA2-A42C-6C73B3343890" of the provided backupset does not match recovery fork GUID "0E73B4E9-41F7-41A9-9041-F8DC53EFAD7C" of dSource "My_dSource".
Suggested Action: Provide a backupset from the same recovery fork, or if the database was restored detach and link the source database again.
A SQL Server Recovery Fork occurs when SQL Server has to perform recovery on a database, creating a new version or "fork" of the database. This can occur in situations such as:
- The Source Database is restored from a previous backup
- The Source Database experiences a Mirroring or Availability Group forced failover
- The Source Database is migrated between servers
This is usually the result of intentional operations performed by a DBA on the Source Database. Crash recovery, which occurs when a SQL Server instance or server is unexpectedly restarted, does not trigger a recovery fork.
Delphix Engine 184.108.40.206 and later introduced a Source Continuity feature, so that new snapshots can continue to be ingested without re-creating the dSource. In some cases, manual intervention is still required to use this feature.
Resolving Source Continuity Issues (current versions)
dSources linked using the Full, Full or Differential, None or Delphix Managed Backup validated sync modes require no manual intervention. The Delphix Engine will transparently create a new Timeflow when the next full backup is ingested.
dSources linked using the Transaction Log validated sync mode will be unable to process new log backups until a new Full backup is performed manually.
To take a new snapshot, select the appropriate dSource from the Manage → Datasets screen and use the Snapshot (camera) button:
Note that this operation may take some time, depending on the size of the affected database.
To confirm that the new recovery fork has been ingested, check the Timeflow for a note showing that a Source Continuity event has occurred between snapshots.
Subsequent backups should continue to generate snapshots as normal, and the Fault can be marked as Resolved.
Resolving Source Continuity Issues (220.127.116.11 and earlier)
In Delphix Engine 18.104.22.168 and earlier, the affected dSource must be unlinked or deleted, and a new dSource linked.
Where possible, please consider an upgrade to a recent Delphix Engine release where this workaround is no longer required.
If this is not possible, the following steps can be used to relink the dSource:
- Make a note of any configuration which may be relevant when the dSource is re-linked, such as retention policies and backup paths.
- From the Manage → Datasets screen, open the list of advanced dSource operations and select Unlink dSource:
- Once unlinked, this dSource and any dependent VDBs will continue to operate in accordance with the configured retention policies. The most recent snapshot of each container will not be removed.
- Use the Edit (pencil) icon to change the name of the dSource and avoid confusion (e.g. OLD My_dSource).
- From the Manage → Environments screen, link the dSource again.
- When you need to Refresh a VDB to use the newer dSource, the VDB should be deleted and re-provisioned from the new one.
Note that linking a dSource twice will cause the Delphix Engine to store two copies of the Source database, and may significantly increase storage requirements on the Delphix Engine until the original dSource and its VDBs are no longer required.