# Navigating Through Incarnations on a Physical Standby Database

We deal a lot with physical standby databases on Standard Edition. Some may call it "poor man's Data Guard." We call it [Deja-Vu](https://www.abakus.si/en/products/software/dejavu), and it's capable of much more than just keeping a database consistently recovered. The main purpose of [Deja-Vu](https://www.abakus.si/en/products/software/dejavu) is to quickly provision clones of production databases.

One thing we haven't quite automated yet is recovery through resetlogs, mostly because it's virtually impossible to *automatically* choose the correct incarnation when it doesn't even exist yet.

Regardless of how you recover your databases, this blog might provide insight on how to handle incarnations on standby databases.

OK, let's go slow. What is an incarnation?

## Incarnation

A new incarnation is created each time a production database is opened using resetlogs (thus not completely recovered). Consider a scenario where a production database needs to be restored to the state it was in at, say, 20:00. But the decision to restore was made at, say, 22:00. So, we need to "discard" the last two hours of data.

On Enterprise Edition one might simply perform `flashback database`. On SE though, we can, by-the-book, do a complete restore and then `recover until 20:00`. Regardless, once the restore/flashback is completed, a resetlogs must occur.

And this creates a new incarnation.

Let's also suppose that a new archived log was created every 15 minutes (which can be achieved using the `ARCHIVE_LAG_TARGET` parameter on a database without many changes).

In the following image, incarnation #1 is shown in green, and incarnation #2 is shown in blue. The numbers that appear at 15-minute intervals are sequence numbers of archived logs:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1752773046880/aafc3bb8-0a4b-4b9d-9252-9cba489a9303.png align="center")

One thing we can observe from this image is that a wall time (e.g., 21:00) determines the exact incarnation (notice how the "blue" one starts only after the "green" one has ended?). This is always true because only one incarnation can be active at a time on the primary database.

## Standby

Suppose that our standby database is currently recovered up to 21:00. So, first of all, we need to go "back in time," to before the "fork"; that is, to at most 19:59 (because the primary was recovered until 20:00 before resetlogs occurred). We can do a simple restore/recover in a classical SE scenario or maybe use the functionality of underlying software/hardware (such as [Deja-Vu](https://www.abakus.si/en/products/software/dejavu)) to revert physical files to a state as they were at some time in the past (before 20:00). Anyway, we’re focused on the incarnations, rather than backup/restore operations in this post.

OK, now we’re at 19:59. If we check the incarnations known to the standby database, we only see incarnation #1 (the green one):

```sql
SQL> select controlfile_time, current_scn from v$database;

CONTROLFILE_TIME    CURRENT_SCN
------------------- -----------
2025-07-17 19:59:00    968507

SQL> select status, incarnation#, resetlogs_time, resetlogs_change# from v$database_incarnation;

STATUS  INCARNATION# RESETLOGS_TIME      RESETLOGS_CHANGE#
------- ------------ ------------------- -----------------
CURRENT            1 2025-07-17 18:32:55                 1
```

So how do we make incarnation #2 (blue one) known to this standby database?

One obvious (although usually unnecessary) solution is to make another backup of production controlfile and use it to replace the current standby controlfile.

Another one is to simply **catalog the first archive log of the (currently) unknown incarnation**.

```sql
RMAN> catalog start with '/path/to/1_1_1206745458.dbf' noprompt;
```

```sql
SQL> select status, incarnation#, resetlogs_time, resetlogs_change# from v$database_incarnation;

STATUS  INCARNATION# RESETLOGS_TIME      RESETLOGS_CHANGE#
------- ------------ ------------------- -----------------
PARENT             1 2025-07-17 18:32:55                 1
CURRENT            2 2025-07-17 21:45:00            968776
```

Great, now our standby controlfile knows about both incarnations and is currently at a time where we can choose either one. Note that instead of querying `v$database_incarnation` we could also use RMAN’s `list incarnations` command to display the same data.

Note that column `RESETLOGS_TIME` tells us when resetlogs occurred (it has nothing to do with `until time` to which incomplete recovery was set). So, according to our image above, this happened at about 21:45.

But how do we make a choice?

## Selecting the Incarnation

```sql
RMAN> reset database to incarnation <incarnation#>;
```

So, if we’ve reset the incarnation to #1, then:

* Oracle will apply archive logs \[ … 36, 37, 38, **39, 40, 41, 42,** …\]
    
* Incarnation #1 becomes `CURRENT` while Incarnation #2 becomes `ORPHAN` (not used)
    

and if we’ve reset to incarnation #2, then:

* Oracle will apply archive logs \[ … 36, 37, 38, **1, 2, 3, 4,** … \].
    
* Incarnation #1 becomes `PARENT` (to incarnation #2) while incarnation #2 becomes `CURRENT`
    

Note that we don’t need to use RMAN to recover the standby database once the incarnation is selected, we can simply use:

```sql
SQL> recover standby database until cancel;
```

## References

* [v$database\_incarnation](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/V-DATABASE_INCARNATION.html) view documentation
    
* [reset database](https://docs.oracle.com/en/database/oracle/oracle-database/19/rcmrf/RESET-DATABASE.html) RMAN command documentation