Skip to main content
Delphix

VDB snapshot fails with "The Delphix Engine does not support virtual database snapshots across different database incarnations." (KBA6185)

 

 

KBA

KBA# 6185

 

Issue

Snapshots of Oracle VDBs can fail with an error stating the following:

The Delphix Engine does not support virtual database snapshots across different database incarnations.

Example:

Virtual database incarnation changed from "1040224685" to "1043317435". The Delphix Engine does not support virtual database snapshots across different database incarnations.

 

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.3.0, 6.0.4.0, 6.0.5.0, 6.0.6.0, 6.0.7.0, 6.0.8.0, 6.0.9.0, 6.0.10.0, 6.0.11.0, 6.0.12.0, 6.0.13.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

4.3

4.3.1.0, 4.3.2.0, 4.3.2.1, 4.3.3.0, 4.3.4.0, 4.3.4.1, 4.3.5.0

4.2

4.2.0.0, 4.2.0.3, 4.2.1.0, 4.2.1.1, 4.2.2.0, 4.2.2.1, 4.2.3.0, 4.2.4.0 , 4.2.5.0, 4.2.5.1

4.1

4.1.0.0, 4.1.2.0, 4.1.3.0, 4.1.3.1, 4.1.3.2, 4.1.4.0, 4.1.5.0, 4.1.6.0

Resolution

This error is indicating that the Virtual database has undergone a recovery operation and a possible reset logs has been run against it. Delphix does not currently support these types of operations against VDBs. To resolve the issue, you need to undo the changes. This can be done in either of the following ways:

1. Rewind the VDB back to a time before any reset logs was executed on the database.

2. Refresh the VDB back from the parent.

 

Warning

Warning:

Both of these operations result in potential data loss.

 

Troubleshooting

Evidence of a reset logs event can be obtained by the following SQL command:

SQL> set numwidth 15
SQL> set linesize 400
SQL> select * from V$DATABASE_INCARNATION ;

Example output:

INCARNATION# RESETLOGS_CHANGE# RESETLOGS PRIOR_RESETLOGS_CHANGE#  PRIOR_RES STATUS     RESETLOGS_ID PRIOR_INCARNATION#  FLASHBACK_DATABASE_ALLOWED          CON_ID 
--------------- ----------------- --------- -----------------------  --------- ------- --------------- ------------------  -------------------------- --------------- 
              1            925702 01-JUL-19                       1  24-AUG-13 PARENT       1012494078                  0 NO                                        0 
              2    15507262651169 12-MAY-20                  925702  01-JUL-19 PARENT       1040224685                  1 YES                                       0 
              3    15508111728911 15-JUN-20          15507262651169  12-MAY-20 ORPHAN       1043158789                  2 YES                                       0 
              4    15508111728911 16-JUN-20          15507262651169  12-MAY-20 ORPHAN       1043241666                  2 YES                                       0 
              5    15508111728911 17-JUN-20          15507262651169  12-MAY-20 CURRENT      1043317435                  2 YES                                       0

You can see from this output the exact dates of the reset logs operations, in this instance multiple reset log operations have been issued with the last one being run on the 17-JUN-20.

 

 

 


Related Articles

The following articles may provide more information or related information to this article:

  • n/a