Skip to main content
Delphix

Resolving Provision/Refresh Failures Due to "ORA-01152: file 1 was not restored from a sufficiently old backup" Error (KBA7273)

  1. Last updated
  2. Save as PDF
 

 

KBA

KBA# 7273

 

Issue

If a Provision or Refresh operation has failed with the following error:

ERROR at line 1: 
ORA-01152: file 1 was not restored from a sufficiently old backup 
ORA-01110: data file 1:

It is a strong indication that the snapshot required for the operation is inconsistent. 
The purpose of this Knowledge Base Article (KBA) is not to root cause why there may be corruption. There are simply to many variables to cover all possibilities in a single KBA.
The purpose of this KBA is to help the customer take steps to accomplish successful completion of a Provision/Refresh operation.

Theory

In the case of an Oracle dSource, the initial Snapsync and snapshot captures a level 0 (full) RMAN backup of the source database inclusive of archive logs. 
Subsequent Snapsync operations take incremental backups of the source database capturing only those Oracle data blocks which have changed since the previous Snapsync.
In general, Delphix recommends enabling Block Change Tracking (BCT) on a primary or standby source database.
BCT improves the performance of incremental backups by recording changed blocks in the block change tracking file. 
During an incremental backup, instead of scanning all data blocks to identify which blocks have changed, RMAN uses this file to identify the changed blocks that need to be backed up.
This can greatly reduce the length of time it takes to complete an incremental backup.

In a situation where there has been an issue during one of the above processes (leaving an inconsistent copy of the data on the Delphix Engine), the corruption will propagate forward resulting in all subsequent snapshots being un-provisionable. 

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases
6.0 6.0.0.0, 6.0.1.0, 6.0.1.1, 6.0.2.0, 6.0.2.1, 6.0.3.0, 6.0.3.1, 6.0.4.0, 6.0.4.1, 6.0.4.2, 6.0.5.0, 6.0.6.0, 6.0.6.1, 6.0.7.0

5.3

 5.3.0.0, 5.3.0.1, 5.3.0.2, 5.3.0.3, 5.3.1.0, 5.3.1.1, 5.3.1.2, 5.3.2.0, 5.3.3.0, 5.3.3.1, 5.3.4.0, 5.3.5.0, 5.3.6.0, 5.3.7.0, 5.3.7.1, 5.3.8.0, 5.3.8.1, 5.3.9.0

5.2

5.2.2.0, 5.2.2.1, 5.2.3.0, 5.2.4.0, 5.2.5.0, 5.2.5.1, 5.2.6.0, 5.2.6.1

5.1

5.1.0.0, 5.1.1.0, 5.1.2.0, 5.1.3.0, 5.1.4.0, 5.1.5.0, 5.1.5.1, 5.1.6.0, 5.1.7.0, 5.1.8.0, 5.1.8.1, 5.1.9.0, 5.1.10.0

5.0

5.0.1.0, 5.0.1.1, 5.0.2.0, 5.0.2.1, 5.0.2.2, 5.0.2.3, 5.0.3.0, 5.0.3.1, 5.0.4.0, 5.0.4.1, 5.0.5.0, 5.0.5.1, 5.0.5.2, 5.0.5.3, 5.0.5.4

Resolution

To resolve this issue the customer should take a Full Backup (RMAN level 0) of the Source and Refresh/Provision from the new snapshot. 
By default, the Delphix Engine will take an incremental backup, you will need to update the snapshot parameters to force a full backup.

This can be done by an admin account from the CLI as follows:

delphix > database
delphix database > select <dSource>
delphix database "dSource" > sync
delphix database "dSource" sync * > set forceFullBackup=true
delphix database "dSource" sync * > commit

It can also be done from the Delphix UI as follows:

 

Snip20210330_28.png

 

Snip20210330_30.png

 

 

Note

Notes:

  • A Force Full Backup operation is likely to take much longer than an incremental Backup, so it may be prudent to ensure you have plenty of time.
  • A full backup is also likely to consume more space, however all of the data that the Delphix platform manages is stored on ZFS. 
    ZFS will reference the old version of the block if there is no change so the size of the resulting backup from the Force Full Backup operation should be much smaller than the initial Snapsync.

 

You may want to consider using the Double Sync option for Oracle SnapSync. For more information, see Using the Double Sync option for Oracle SnapSync.
 

 

Privacy Policy Terms of Use Legal About
© 2024 Delphix Corp