Oracle RMAN Reset Database After RESETLOGS Recovery

calendar Jan 9, 2026 / · 8 min read · Oracle Database RMAN Database Recovery Backup and Restore Recovery Catalog Database Administration Incomplete Recovery RESETLOGS  ·
Share on: linkedin copy

Oracle RMAN Reset Database After RESETLOGS Recovery

Purpose

In the Oracle 19c documentation, opening a database with RESETLOGS needs no manual step to register the new incarnation. Oracle creates the incarnation record in the recovery catalog and makes it the current incarnation for you. The RESET DATABASE command in Oracle Recovery Manager (RMAN) has a narrower job today: RESET DATABASE TO INCARNATION moves the target database back to an earlier incarnation in the RMAN repository.

You need it in two cases. One is when you use RESTORE or RECOVER to return the database to an SCN before the current RESETLOGS timestamp. The other is when you use FLASHBACK DATABASE to rewind to an orphaned incarnation. This post explains both cases, shows the command in order, and corrects the older habit of typing a bare reset database; after every RESETLOGS.

Original Code

1-- Reset the catalog after a restlogs on the target
2reset database;

The bare form above comes from older releases. The syntax diagram in the 19c reference lists only one form: RESET DATABASE TO INCARNATION primaryKey. The current form is shown under the procedure below.

Breakdown of Code

The command is short, but each part has a defined meaning:

  • RESET DATABASE: DATABASE specifies the entire database
  • TO INCARNATION primaryKey: changes the current incarnation to a noncurrent incarnation, identified by the primary key of its DBINC record
  • Run LIST INCARNATION OF DATABASE first to get the possible key values
  • Run the command only at the RMAN prompt, with RMAN connected to a target database
  • A recovery catalog is optional. In NOCATALOG mode the target database must be mounted. In CATALOG mode the target can be mounted or unmounted

When to Use This Command

After RESETLOGS Operations

If you open the database with the RESETLOGS option, a new database incarnation record is created automatically in the recovery catalog. The database also issues a RESET DATABASE command for you, which makes the new incarnation the current one. All later backups and log archiving are associated with that new incarnation. This is true whether you run ALTER DATABASE OPEN RESETLOGS as a SQL statement or as an RMAN command.

Recovery Scenarios

Oracle states that you are only required to use RESET DATABASE TO INCARNATION in these cases:

  • When you restore and recover the database to an SCN before the current RESETLOGS timestamp
  • After you use FLASHBACK DATABASE to rewind the database to an orphaned database incarnation

Ordinary incomplete recovery that moves forward from a backup, or recovery with a backup control file, is not on that list. Both of those recoveries end with OPEN RESETLOGS, and the open creates the new incarnation by itself.

Understanding Database Incarnations

What is a Database Incarnation

A database incarnation is created whenever you open the database with the RESETLOGS option. The RESETLOGS operation archives the current online redo logs if they are accessible, erases their contents, and resets the log sequence number to 1. It also updates all current datafiles and online redo logs, and all later archived redo logs, with a new RESETLOGS SCN and timestamp.

The new incarnation exists to avoid confusion when two different redo streams have the same SCNs but occurred at different times. If you apply the wrong redo to a database, you corrupt it.

Incarnation Types

The Oracle 19c documentation describes these relationships:

  • Current Incarnation: the incarnation in which the database is currently operating
  • Parent Incarnation: the incarnation from which the current incarnation branched following an OPEN RESETLOGS operation
  • Ancestor Incarnation: the parent of the parent incarnation. Any parent of an ancestor incarnation is also an ancestor of the current incarnation
  • Direct ancestral path: begins with the earliest incarnation and includes only the branches to an ancestor, the parent, or the current incarnation

Backups from incarnations that are not on the direct ancestral path are called orphaned backups. You can use them when you restore the database to an SCN that is not in the direct ancestral path.

Why Incarnation Tracking Matters

Keeping Backup History Separate

Each incarnation has its own stream of redo. RMAN needs to know which stream is current so that a restore picks backups and archived logs that belong to it. Because Oracle records the new incarnation when you open with RESETLOGS, backups taken afterward are tied to the right stream without extra work from you.

When You Must Intervene

You step in when you want to leave the current stream. A restore to an SCN before the current RESETLOGS timestamp reads SCNs in the frame of reference of an earlier incarnation. You tell RMAN which one with RESET DATABASE TO INCARNATION.

Resetting to Previous Incarnations

Advanced Use Case

RESET DATABASE TO INCARNATION lets you specify that SCNs are to be interpreted in the frame of reference of a specific database incarnation. Use it when you need to undo the effects of a RESETLOGS operation by recovering to a point before it.

Procedure for Resetting to Old Incarnation

The sequence below follows the example in the Oracle reference. In NOCATALOG mode you must first mount a control file that contains a record of the incarnation you want.

 1# step 1: list available incarnations and note the Inc Key of the old one
 2list incarnation of database;
 3
 4# step 2: reset the database to that incarnation key
 5reset database to incarnation 2;
 6
 7# step 3: restore and recover to a point before the RESETLOGS
 8restore database until scn 154876;
 9recover database until scn 154876;
10
11# step 4: open with RESETLOGS; this creates a new incarnation
12alter database open resetlogs;
13
14# step 5: confirm the new current incarnation
15list incarnation of database;

After step 4, LIST INCARNATION OF DATABASE shows the incarnation you reset to as a PARENT and the new incarnation as CURRENT.

Key Points

  • RMAN must be connected to a target database. A recovery catalog connection is not required
  • In NOCATALOG mode, the target database must be mounted, and the mounted control file must contain a record of the specified incarnation
  • In CATALOG mode, the target database can be mounted or unmounted, and a mounted control file must still contain a record of the incarnation
  • In NOCATALOG mode, RESET DATABASE TO INCARNATION is persistent across RMAN sessions
  • After RESET DATABASE TO INCARNATION you can run RMAN commands such as FLASHBACK DATABASE, RESTORE, and RECOVER
  • For a pluggable database, the initial incarnation number is 0, and later numbers are unique but not always sequential

Best Practices

Catalog Maintenance

Oracle performs a full resynchronization after structural changes to the database, including creating a new incarnation. A manual RESYNC CATALOG is therefore not needed just because you reset the database.

Manual resynchronization is useful for a different reason. If the target runs in ARCHIVELOG mode and you back up infrequently or switch logs at a high rate, the recovery catalog is not updated automatically when a redo log switch occurs or when a log is archived. How often you resynchronize depends on the rate at which the database archives redo logs.

Backup Strategy

Older releases recommended a backup immediately after OPEN RESETLOGS. The Oracle 19c documentation says a pre-RESETLOGS backup can now be recovered like any other backup, so a new database backup is optional. For recovery through RESETLOGS you must have all archived logs generated after the most recent backup and at least one control file (current, backup, or created).

RMAN can restore backups from parent and ancestor incarnations and recover to the current time, even across OPEN RESETLOGS operations, if a continuous path of archived logs exists from the earliest backups to the point you want to recover.

Archive Log Format

The LOG_ARCHIVE_FORMAT parameter must contain %s (sequence), %t (thread), and %r (resetlogs ID). The %r element keeps archived log names unique across incarnations.

Insights

Many runbooks still tell the DBA to type reset database; after every RESETLOGS. That step dates from older releases. In the 19c documentation the open does the work, and the command you reach for is RESET DATABASE TO INCARNATION, only when you must recover to an SCN from an earlier incarnation.

Before you use it, run LIST INCARNATION OF DATABASE and read the Reset SCN and Reset Time columns. Pick the incarnation whose reset point is before the SCN you want to restore. After the recovery and the next RESETLOGS open, list the incarnations again so the record of what you did sits in the output for the next person on call.

Troubleshooting Common Issues

  • The incarnation key is not found: in NOCATALOG mode, the mounted control file has no record of it. Restore a control file that knows the incarnation, as the Oracle example does with restore controlfile from autobackup
  • RMAN refuses the command: confirm it is connected to the target and that you are at the RMAN prompt, not in SQL*Plus
  • Restore picks the wrong backups: run list incarnation of database and check which row is CURRENT before you restore
  • Archived logs from different incarnations overwrite each other: check that LOG_ARCHIVE_FORMAT contains %r

References

Posts in this series