Performing Oracle Advanced Recovery - OCP: Oracle Database 12c Administrator Certified Professional - page 286

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ----------- ------ ---------- ----------
1 1 ORCL 1194923408 PARENT 1 10/15/2012 10:08:59
2 2 ORCL 1194923408 PARENT 886308 10/03/2013 13:24:36
3 3 ORCL 1194923408 CURRENT 904361 10/03/2013 14:05:15
If you wanted to restore the database to a point in time before 10/03/2013 at 14:05:15
(or SCN 904361), you would need to reset the database to one of the previous incarnations.
If, however, you wanted to restore the database to the resetlog time/SCN or after that time,
then you would not need to reset the database incarnation.
To reset the database incarnation, you first need to mount the database. Then you use the
RESET DATABASE TO INCARNATION command. You include the incarnation number that you
want to switch to in the command. This number comes from the INC KEY column displayed
in the LIST INCARNATION command output. Here is an example of switching the database to
incarnation 2:
RMAN> shutdown immediate
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 364081152 bytes
Fixed Size 1333228 bytes
Variable Size 239077396 bytes
Database Buffers 117440512 bytes
Redo Buffers 6230016 bytes
RMAN> Reset database to incarnation 2;
database reset to incarnation 2
Figure 7.1 provides a graphic example of database incarnations. In this graphic, the data-
base crashes at SCN 40000 (shown in point A in the figure). We restore the database from a
backup taken at SCN 10000 (shown in point B in the figure) and recover it to SCN 25000
(shown in point C). Perhaps we have lost the redo logs needed to restore the database beyond
SCN 25000, and so we open the database at SCN 25000 with the ALTER DATABASE OPEN
RESETLOGS command. This creates a new incarnation of the database. Note that the SCNs are
greater than 40000 (because the SCN does not change), but notice that there is a new timeline
with which the changes are being recorded (the tangent line heading to the northeast in the
figure). This is the new incarnation of the database (demonstrated in point D). It's a completely
new life for the database, and everything that happened in the database in the previous life
after the previous SCN 25000 is as if it had never happened. There are now actually two SCN
25000s in the redo stream.