During SQL Server dSource snapsync operation the following error occurs:
The recovery fork GUID "2077A377-3333-4444-5555-17E9B51C9999" of source database "My_Source" does not match recovery fork GUID "2C3C6666-7777-8888-9999-660CBFCB2DEB" of dSource "My_dSource".
The source database's recovery fork GUID can change because source database underwent a full restore that results in a change to its recovery path. This is similar to when an Oracle database incarnation id changes. In the SQL Server instance situation, the source database now requires new backups to remain consistent.
When this occurs, the current timeflow of the dSource has essentially stopped, and no more backups can be applied to it during SnapSync. A new timeflow must be created and currently this process must be performed manually.
- If the dSource has dependents (virtual databases (VDBs)) actively used, you'll need to keep the old timeflow until such a time as the dependents can be refreshed off the newly created timeflow.
- Unlink dSource, in this case
My_dSource, by clicking the
unlinkicon, found on the Configuration panel, in the array of icons on the upper right portion of that windows. If you need to keep the dSource (If active VDB(s) are dependent upon the old dSource), you can rename to something like
My_dSource_old. You do this by pressing the
pencilicon in the upper left portion of the dSource screen. In the edit field simply rename the dSource as you wish.
- Check environment (source) to see that the dSource database item is listed as a database (blue cylinder icon), in which case you can link a new dSource from this source database.
Relink the dSource
- At this point you can relink the dSource.
- When ready to refresh VDB to the new data, delete it from the old dSource and provision from the newly linked My_dSource dSource.