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.
Database Incarnation History
Incarnation 1 of the database starts at SCN 1 and continues through SCN 1000 to SCN 2000. Suppose that at SCN 2000 in incarnation 1, you perform a point-in-time recovery back to SCN 1000, and then open the database with the RESETLOGS option. Incarnation 2 now begins at SCN 1000 and continues to SCN 3000. In this example, incarnation 1 is the parent of incarnation 2.
Suppose that at SCN 3000 in incarnation 2, you perform a point-in-time recovery to SCN 2000 and open the database with the RESETLOGS option. In this case, incarnation 2 is the parent of incarnation 3. Incarnation 1 is an ancestor of incarnation 3.
When DBPITR or Flashback Database has occurred in database, an SCN can refer to more than one point in time, depending on which incarnation is current. For example, SCN 1500 in Figure 13-1 could refer to an SCN in incarnation 1 or 2.
You can use the RESET DATABASE TO INCARNATION command to specify that SCNs are to be interpreted in the frame of reference of a specific database incarnation. The RESET DATABASE TO INCARNATION command is required when you use FLASHBACK, RESTORE, or RECOVER to return to an SCN in a noncurrent database incarnation. However, RMAN executes the RESET DATABASE TO INCARNATION command implicitly with Flashback
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
------ -------- -------- ------ -------
|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
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.
No comments:
Post a Comment