6

The Oracle documentation describe incarnation as:

incarnation

A separate version of a database. The incarnation of the database changes when you open it with the RESETLOGS option, but you can recover backups from a prior incarnation so long as the necessary redo is available.

But I still can't fully understand it. Can anyone explain it in a easy-to-understand way to me please?

Thanks,

  • I'm just wondering, would you still like to have an understandable answer to your pretty aged question? – hot2use Jun 26 '18 at 9:30
6

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)                         
Recovery                                                                                    

Basics

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).

New Incarnations

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 1.

SCN

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.

Time

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;

Why?

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:

INCARNATION#    1
SCN#           300
Time......... 13:00

...and the backup at 14:00 (2pm) with the following information:

INCARNATION#    2
SCN#           300
Time......... 14:00

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:

INCARNATION#    3
SCN#           400
Time......... 16:00

...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.

Summary

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.

Next Up

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.

For Example...

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.

Stay tuned...

2

Let's say you start with an Oracle database called PROD, replicated to a physical standby called STNDBY. You refresh your development environment by taking a copy of STNDBY via RMAN† and calling it MASTER. You open MASTER read-write, to do some actions (e.g. deleting sensitive user data) and then copy that for your developers, called DEV1, DEV2 etc. One of your developers wants to do some experiments, so he further clones DEV1 into DEV1A. So there are now many versions of our database, e.g

------    --------      --------       ------      ------- 
|PROD| -> |STNDBY| -*-> |MASTER|  -*-> |DEV1| -*-> |DEV1A|
------    --------      --------       ------      -------

The * indicates points at which you have done OPEN RESETLOGS or created a new controlfile. This means a new incarnation of the database. You could not apply redo logs "backwards" in this chain, e.g. even if you shut down PROD (so its SCN does not increment) before creating MASTER, you could not make changes in a downstream database, for example DEV1, then apply the redo logs back to PROD even tho' they are the "same" DBFs - the incarnation has been incremented.

† this is what it means by recover backups from a prior incarnation

  • 1
    If you watch popular TV show Fringe. Incarnations a bit like parallel universes there. Whenever significant event occurs differently (OPEN RESETLOGS or created a new controlfile + different transactions) , they diverge and different parallels universes (incarnations) occurs. – Atilla Ozgur Dec 8 '11 at 7:42
  • So are they like Git "branches"? – Worthy7 Jul 20 '17 at 1:32
0

well, the incarnation is an especific break point in the life time of the database. To be clear you may look at the database life cycle as it starts its creation through its full and redo log backups, imagine this as a time line, now after several backups you need to go back in time and restore the whole database to an specific point in time or SCN, once you do this you must open the database with resetlogs which creates a new encarnation of the database because the backup chain it used to have from the point of the new incarnation to the point in time where you decided to restore the database, cannot be use any more, this is because new operations are been logged to the redo logs once you open it with reset logs, so a new parallel time line of backups must be generated starting from the incarnation point in time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.