Skip to main content
Delphix

How to Resolve: "Error: Cannot Provision From Snapshot Taken at 'TIME'" (KBA1635)

 

 

KBA

KBA#1635

Issue

When using a dSource which is an Oracle Standby database, you may receive one of the following faults at the completion of a snapsync:

5.1 and later:

Title: Cannot provision database from snapshot

Description: Snapshot "2017-12-18T19:39:57.396Z" of database "XXX" cannot be provisioned. The source database is in Real Time Apply mode and redo from the current online log on the primary may be needed in order to provision from the snapshot.

Action: Force a log switch on the primary or wait for the log to be archived and LogSync to fetch the log from the source. The CLI TimeFlow Log List command can be used to see which logs LogSync has fetched and which are missing.

Or in earlier releases:

Title: Cannot provision database from snapshot

Description: Snapshot "2015-07-16T22:16:20.923Z" of database "XXX" cannot be provisioned. The source database is in Real Time Apply mode and redo from the current online log on the primary may be needed in order to provision from the snapshot.

Action: Force a log switch on the primary or wait for the log to be archived and LogSync to fetch the log from the source. The CLI TimeFlow Log List command can be used to see which logs LogSync has fetched and which are missing.

And prior to 4.2:

Description: Cannot provision database ”XXX" from snapshot taken at "2015-03-07T04:14:12.340Z". SnapSync continued even though you cannot provision from the snapshot. If the source database ”XXX" is a standby database in Real Time Apply mode, then redo from the current online log on the primary may be needed in order to provision from the snapshot. SnapSync continued in order to make progress on the snaps.

Resolution

This fault is raised when a snapshot has been taken from an Oracle Standby database and one of the archive logs needed to allow provisioning from that snapshot has not yet been sent from the Primary site database to the Oracle Standby database.

In a regular dSource (not a physical standby site but a primary site) Delphix can initiate a log switch and the archiving of the current log sequence.  In a Standby database this is not possible as the log switching in a physical standby results from the switching through online logs in the primary site.

As Delphix has the Standby database linked as the dSource it is going to be collecting the archivelogs from the standby site.  If these archivelogs are not present at the time Delphix attempts to collect them during the snapsync creation process, the snapsync will complete and raise this warning.  The missing log in this scenario is typically the current log sequence present in the primary site.

Delphix will retry a few times before reporting the warning, however it will eventually give up and throw the fault.  The snapshot where this fault has been thrown will not be provisionable until the missing log sequence is supplied through a primary site log switch and redo shipping between the primary and standby sites.

As noted in the fault description in later versions, there are two ways to resolve this fault:

  • Wait for the Primary database to perform a log switch and ship the required redo to the standby site 

OR

The following script is a sample only and there are other ways to make the connection from the standby site dSource back to the primary site database and initiate the log switch.

sqlplus sys/delphix@'(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primary_site_host)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = primary_site_servicename)))' as sysdba <<EOF
alter system archive log current;
exit
EOF

Once the archive log is copied to the Standby database, through Oracles redo shipping mechanism, it will be made available to the Delphix Engine for collection, and the fault should resolve itself automatically.

If this issue persists even after the archive log is available at the standby site, Timeflow Repair can be performed to manually locate and apply the missing log files.