Delphix Toolkits (dxToolkit and dxmToolkit)

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

One more question, what does it mean "Delphix had already collected archived logs for"? Is there anyway to overcome that, say we repeat our restoring one more time while pause "Delphix to collect the archived logs?" until the restoring and point-in-time recovery is done? Again I am not so sure what does Delphix do in term of "Delphix to collect the archived logs"

Thank you

Johnley

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Hi Johnley,

 Thanks for the additional detail.  During normal operation, Delphix will collect any archive logs generated on the database ( or in the case of a standby, applied to the standby ). These logs are subsequently used to either for making a snapshot consistent or for point in time recovery.  Whenever a snapshot is performed there is a check which essentially says "is the current highest archive log for the database less than the latest archive log Delphix fetched".  This is to ensure that the archive logs Delphix has can be applied to the backups we are taking.

 Imagine this scenario.

-> Delphix takes a snapshot, the current archive log is 4.

-> Time moves on, and Delphix collects archive logs 5,6,7,8.

-> You restore your database to the point in time of archive log 4, without performing a reset logs ( the typical method for being able to do this would be using filesystem snapshots )

-> Time moves on again, and Your database now generates a *new* 5,6,7,8

Delphix has no way of knowing which is the "correct" set of 5,6,7,8 logs.

In your case since you are applying logs from a source database, the logs will actually all be the same, but Delphix has no visibility into how or why the database was reset to an earlier point in time, we also have no knowledge of how the changes are being applied to the database. All we know is we saw the database get to log 8, and then suddenly it was reset to log 4.

In your case, when you are performing a restore I would suggest the following

• Disable the dSource, this will stop it attempting to fetch logs, take snapshots, etc.
• Get your DBA team to restore the standby database to either the latest available log from the source database, or at least to a point newer than when you disabled the dSource
• Enable the dSource

This will keep Delphix happy and should prevent the fault you are seeing from being thrown.

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Thank you Matt; The term of "disable the dSource" you mentioned is to unlink the dSource from through the Delphix console, right? And there is no risk and easy to reenable it after the DB restored/opened,and by this approach, "restlog" is not required, right?

Thank you

Johnley

Hi Johnley,

 Thanks for the additional detail.  During normal operation, Delphix will collect any archive logs generated on the database ( or in the case of a standby, applied to the standby ). These logs are subsequently used to either for making a snapshot consistent or for point in time recovery.  Whenever a snapshot is performed there is a check which essentially says "is the current highest archive log for the database less than the latest archive log Delphix fetched".  This is to ensure that the archive logs Delphix has can be applied to the backups we are taking.

 Imagine this scenario.

-> Delphix takes a snapshot, the current archive log is 4.

-> Time moves on, and Delphix collects archive logs 5,6,7,8.

-> You restore your database to the point in time of archive log 4, without performing a reset logs ( the typical method for being able to do this would be using filesystem snapshots )

-> Time moves on again, and Your database now generates a *new* 5,6,7,8

Delphix has no way of knowing which is the "correct" set of 5,6,7,8 logs.

In your case since you are applying logs from a source database, the logs will actually all be the same, but Delphix has no visibility into how or why the database was reset to an earlier point in time, we also have no knowledge of how the changes are being applied to the database. All we know is we saw the database get to log 8, and then suddenly it was reset to log 4.

In your case, when you are performing a restore I would suggest the following

• Disable the dSource, this will stop it attempting to fetch logs, take snapshots, etc.
• Get your DBA team to restore the standby database to either the latest available log from the source database, or at least to a point newer than when you disabled the dSource
• Enable the dSource

This will keep Delphix happy and should prevent the fault you are seeing from being thrown.

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley

Thank you Matt; The term of "disable the dSource" you mentioned is to unlink the dSource from through the Delphix console, right? And there is no risk and easy to reenable it after the DB restored/opened,and by this approach, "restlog" is not required, right?

Thank you

Johnley

Hi Johnley,

 Thanks for the additional detail.  During normal operation, Delphix will collect any archive logs generated on the database ( or in the case of a standby, applied to the standby ). These logs are subsequently used to either for making a snapshot consistent or for point in time recovery.  Whenever a snapshot is performed there is a check which essentially says "is the current highest archive log for the database less than the latest archive log Delphix fetched".  This is to ensure that the archive logs Delphix has can be applied to the backups we are taking.

 Imagine this scenario.

-> Delphix takes a snapshot, the current archive log is 4.

-> Time moves on, and Delphix collects archive logs 5,6,7,8.

-> You restore your database to the point in time of archive log 4, without performing a reset logs ( the typical method for being able to do this would be using filesystem snapshots )

-> Time moves on again, and Your database now generates a *new* 5,6,7,8

Delphix has no way of knowing which is the "correct" set of 5,6,7,8 logs.

In your case since you are applying logs from a source database, the logs will actually all be the same, but Delphix has no visibility into how or why the database was reset to an earlier point in time, we also have no knowledge of how the changes are being applied to the database. All we know is we saw the database get to log 8, and then suddenly it was reset to log 4.

In your case, when you are performing a restore I would suggest the following

• Disable the dSource, this will stop it attempting to fetch logs, take snapshots, etc.
• Get your DBA team to restore the standby database to either the latest available log from the source database, or at least to a point newer than when you disabled the dSource
• Enable the dSource

This will keep Delphix happy and should prevent the fault you are seeing from being thrown.

Thank you very much Matt for the quick reply. Our dSource is a stand-by DB but the case is a bit special; We only refresh the DB 3 times through archive logs the catch up with primary then put it to physical stand-by read-only. On the other word, we only put it to "snapshot standby" 3 times per day to catch up the with primary, it's in standby read-only in between those 3 catch up point.

On Jan 25, we first completely restore the dSource from a RMAN backup copy to a specific point on Jan 24, then apply the archive log to complete the point-in-time recovery to a specific time point on Jan 25 ( the first catch up of our regular daily catch up ), then put the dB to standby read-only -- at this point everything was OK, the we do a regular snapsync through 'dx_snapshot-db' which is also our day routine to keep a snapshot/snapsync for that specific catch up point, but this time we get the error mentioned in this thread.

Thank you

Regards

Johnley

Hi,

 Is the dSource a standby database or a primary database?

 If it is just a standby that you have restored, without performing a reset logs on the primary, then this means that you have restored it to a point in time on the standby that is before the point in time that Delphix had already collected archived logs for. I this case you should be able to just wait until your standby catches up ( which should generally be very quick ). 

If it is a primary database which you have not performed a reset logs on ( eg, restored to a storage snapshot and just performed crash recovery ), then I believe you need to detach / link a new dSource, as the existing one is in a very unexpected state.

We recently restore our ORACLE dSource DB from a RMAN backup , the we run the following command as we regularly did before;

 /data/DLPHX01/Scripts/dxtoolkit2/dx_snapshot_db -name DLPHX01

The following errors returned.

The redo stream of the source database "SOPHIS" appears to have gone backwards. The database may have been restored to a previous time without resetting the logs.

Any straight forward solution for this issue?

If we try to restore the DB from RMAN again and manage it to be opened with "resetlog", would it broken the old snapshot/snapsync ?

Thank you

Regards

Johnley