Following is a short graphic which I will be using to explain what incarnation is used for in the answer:
restore db +-----+ +-----+ +-----+
recover db | 2>3 | --------> | 3 | --> | 3 | -->
resetlogs +-----+ +-----+ +-----+
^ Incarn. 3 3
/ SCN # 400 500
restore db +-----+ +-----+ +-----+
recover db | 1>2 | -------> | 2 | --> | 2 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn. 2 2 | 2
/ SCN # 300 400 | 500
+-----+ +-----+ +-----+ |
--> | 1 | --> | 1 | --> | 1 | --> ... |
+-----+ +-----+ +-----+ ^ |
Incarn. 1 1 1 | 1 |
SCN # 100 200 300 | 400 |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00
Restore/ (1) (2)
When an Oracle database is created it receives an initial incarnation number. The incarnation number is stored in the database itself, the control file(s) of the database instance and in the central RMAN catalog database (if you have one).
Let's take a look at the above graphic. It is a slight modification of the graphic which Oracle uses to explain what incarnations are.
Reference: RMAN Media Recovery (Oracle Docs)
Archive Log Backups
Now let's assume the Archive Log backups are occuring on an hourly basis. Oh, and the datbase is in the
ARCHIVE_LOGS mode, which allows us to backup and restore archive logs which enables us to recover the database to a certain point in time. We'll also assume that the database has received a FULL backup at 04:00 (a.m.) the same day. Further, the database has nevery been restored since it was initiailly created and the current INCARNATION# of the database is at
We'll further assume that 100 transcations occur each hour so that at the time of the backup the SCN# will be a multiple of 100.
The time is only here to increase the readability of the graphic. It plays a role in understanding why Oracle creates a new incarnation for a database that has been restored to a certain point-in-time.
Restoring the Database to Point-in-Time (1)
Somewhere slightly after 13:00 (1pm) somebody decides that the database has to be restored to 12:00 (12 o'clock midday). The DBA either sets of a bunch of RMAN commands to restore the database to that point-in-time our clicks his way through a fantastic GUI to initiate a restore/recovery from a 3rd-party vendor.
RMAN retrieves the FULL backup of the database and all Archive Log backups from disk/tape and restores them to the disk. In the recovery phase RMAN will check that all relevant information is available and roll-forward all finished transactions to the Point-in-Time and roll-back all unfinished transactions to the Point-in-Time, to ensure the database is in a consistent state.
Before the database can be opened to the general public, the database has to ensure that all future backups don't conflict with the previous backups. This is when a new incarnation should be created and it happens when you execute the following command to open the database:
ALTER DATABASE OPEN RESETLOGS;
Ok. If you look at the graphic, the SCN# for 13:00 (1 pm) in the original INCARNATION# 1 path is 300. We never reached the backup at 14:00 (2pm) which would have recorded the SCN# 400 in the backup. During the restore/recovery process, no backup is going to happen and (let's assume) if the restore process takes an hour, then no new data is going to be inserted. When the database is ready to go back online and the next backup occurs at 14:00 (2pm) then the backup will contain the SCN# 300. This is the same SCN# of the database as it was before the restore/recovery was initiated, which was recorded for the backup at 13:00 (1pm).
How Does Oracle Know Which Backup to Use?
This is why the INCARNATION# is set to a new value. It allows Oracle to discern between the Archive Log backup at 13:00 (1pm) with the following information:
...and the backup at 14:00 (2pm) with the following information:
Restoring the Database to Point-in-Time (2)
Let's assume the database keeps on running after the first restore/recovery action and slightly after 15:00 (3pm) somebody decides there needs to be a new restore/recovery back to 14:00 (2pm) the same day.
RMAN will restore the files, recovery the database and set off an
ALTER DATABASE OPEN RESETLOGS to bring the database back online. The INCARNATION# will be now set to 3 and the first backup at 16:00 will contain the information:
...which would otherwise conflict with the backup of the database at INCARNATION# 2 and SCN#400 from 15:00 (3pm). But, because of the new INCARNATION# everything is fine.
That is the (albeit short) explanation of what the incarnations are used for. It allows RMAN (and the heroic DBA) to determine which path to take to restore and recover the database that has previously been backed up and restored more than once.
This short explanation of incarnations is by no means complete. There are other factors that result in
ORPHANED incarnations and
OBSOLETE backups. Some of these topics will be discussed in a follow up answer either in this thread or in a separate Q & A.
When looking at incarnations on a larger time-scale, then restoring and recovering may require you to set off a
RESET DATABASE TO INCARNATION <number> before you can start recovering the database, because you might be restoring and recovering the database to a point-in-time which is located on the path of the INCARNATION# 1 and which may require you to restore an AUTOBACKUP copy of the control file, before you can start even thinking about restoring and recovering the database.