When we open database with RESETLOGS option, the database starts a new incarnation. This new incarnation resets the log sequence number to 1, and then gives the online redo logs a new time stamp and SCN.
When the database starts a new incarnation, are we able to use the old backups taken in previous incarnation for restore and recovery purpose as the present log sequence number is reset to 1.
The present article discusses about the details of how to use the backups in old incarnation for restore and recovery purpose after the database has been opened with resetlogs for many times.
I will explain the details considering a practical approach in our training environment. First i will explain the existing environment and available backups.
Then i will take you to details of how these backups are used to restore and recover to the same server (or to different server) considering that the database has been opened many times with resetlogs option.
Environment Details :
Let us assume that we have a training environment where we have some gold backups for the database. Whenever we do any modification to the database, we will take a new goldbackup and we will keep restoring this latest new backup every week twice( Thursday night and Saturday night).
Following Details shows the different goldbackups available for the training environment.
So everytime when we restore the database from the latest gold backup, we will open the database with resetlogs option and it starts a new incarnation.
These details are shown below ..
As long as i am restoring the latest goldbackups to the training environment, it uses the current incarnation and able to restore the latest backups and able to open the database with resetlogs option.
But if i want to restore any previous backups(backups taken at a different incarnation) to the training environment,i may not be able to restore the backups to the current incarnation.
Let us assume that i have my latest backups available on 09-OCT-2013 as per the above details and my current incarnation is 416836 (on 21-MAR-2013).
Now i have a requirement where i need to restore the backups available on 27-OCT-2012 to the same server. So as long as my current incarnation is 416836, i will not be able to use these backups on 27-OCT-2012 to restore the database.
So i need to first change the incarnation to be able to restore the backups on 27-OCT-2012.
For your easy understanding to identify to which incarnation to change, i have mixed backup details and incarnation details and orderded the details date wise below ....
When a database goes through multiple incarnations, some backups can become orphaned. The simple way to find non-orphaned backups and orphaned backups are to form a table to list the incarnation number and orphaned and non-orphaned backups to each incarnation.
In our case, in simple words, we need to restore backups from 27-OCT-12. So identify the incarnation number for which this backup is non-orphaned.
I am considering the incarnation before and after the 27-OCT-12 to identify orphaned and non-orphaned backups. We have incarnations 357545(on 01-NOV-12) and 355286 (25-OCT-12).
Now we have the details, which incarnation we need to set for restoring the 27-OCT-2012 backups.
Also get the controlfile information from the 27-OCT-2012 backups using
NOTE : In our case the controlfile details are '4vnoosbv_1_1'
Then use the following syntax to restore and recover the database...
So we are able to successfully restore the backups from a different incarnation. The same procedure can be applied if you plan to restore the database to a different server as long as the tsm configuration is properly done.
Hope It Helps