Reset an RMAN Database Incarnation

Lessons 2 and 3 established catalog-aware and NOCATALOG RMAN sessions. This lesson applies those repository choices when a recovery must cross a previous RESETLOGS boundary. RMAN needs the correct database incarnation so that it can interpret the requested SCN, time, backups, and archived redo within the intended branch of database history.

The current Oracle 26ai command is RESET DATABASE TO INCARNATION. It changes the incarnation that RMAN treats as current in its repository. The command does not restore a control file, restore data files, apply redo, flash back the physical database, open the database, or create a new incarnation.

A new incarnation is created when the database opens with ALTER DATABASE OPEN RESETLOGS. That operation begins a new redo branch. Manual incarnation selection is needed only when a restore, recovery, or Flashback Database destination belongs to a noncurrent branch and Oracle has not selected that branch implicitly.

The similar words reset and resetlogs describe different state changes. Confusing them can cause an operator to select a repository branch without completing the physical recovery that makes the database consistent.

Incarnation selection and creation

Operation	Primary effect	What it does not do
RESET DATABASE TO INCARNATION	Selects an existing CDB incarnation in the RMAN repository	Does not restore, recover, open, or create a branch
RESET PLUGGABLE DATABASE ... TO INCARNATION	Selects an existing PDB incarnation for PDB flashback or recovery	Does not perform the PDB recovery itself
ALTER DATABASE OPEN RESETLOGS	Opens the recovered database, starts a new redo branch, and creates an incarnation	Does not select and restore an older branch by itself

An incarnation is not a software-style version number. It is a branch of the database's redo history. An SCN must be interpreted within the correct branch. After incomplete recovery followed by OPEN RESETLOGS, later backups and redo belong to the new branch, while the earlier history remains represented as a parent or an orphaned branch.

Backups from previous incarnations are not automatically deleted or universally unusable. RMAN can use them when their branch, contents, and recovery destination are appropriate. The repository needs the correct branch context before RMAN chooses files and redo for that operation.

The presence of multiple incarnation records is normal after one or more OPEN RESETLOGS operations. Do not issue a reset merely because LIST INCARNATION displays several rows. First determine where the required recovery destination lies.

When to select an incarnation explicitly

Situation	Manual reset?	Reason
Restore or recover within the current incarnation	No	The destination remains in the current redo branch
Restore or recover to an SCN before the current reset SCN	Yes	RMAN must interpret the destination in an earlier incarnation
Flash back into an orphaned incarnation	Yes	The orphan branch must be selected explicitly
Flash back to an SCN in the direct ancestral path	Normally no	RMAN performs the incarnation reset implicitly
Flash back to a restore point	Normally no	RMAN performs the incarnation reset implicitly
Open the recovered database with RESETLOGS	No separate bare reset	Oracle creates and selects the new incarnation automatically
Run DUPLICATE	Not as a generic prerequisite	RMAN manages the duplicate workflow and resulting database identity
Restore a backup control file	Not for that fact alone	The target branch and recovery destination determine the need

The implicit Flashback Database cases still require a valid flashback destination, sufficient flashback logs, and an approved procedure. “Normally no” does not mean that every restore point or ancestor SCN is recoverable. It means that an additional explicit reset is not normally required when Oracle's documented implicit behavior applies.

Connect to the intended target and the recovery catalog when one is used. Compare the connected database name and DBID with the recovery plan before listing any branches. For the example CDB, issue:

LIST INCARNATION OF DATABASE PRODCDB;

Use the value in the Inc Key column as the operand for RESET DATABASE TO INCARNATION. Do not substitute the DB Key, DBID, a log sequence number, the row position, or an assumed sequential version.

Important LIST INCARNATION columns

Column	Meaning	Safety check
DB Key	Recovery-catalog key for the database record	Do not use it as the incarnation operand
Inc Key	Repository primary key for the incarnation record	Use this verified value in the reset command
DB Name	Database name associated with the branch	Compare it with the intended target
DB ID	Durable database identifier	Verify it before changing repository state
STATUS	Relationship such as CURRENT, PARENT, or ORPHAN	Do not select a branch from status alone
Reset SCN	SCN at which the incarnation began	Compare it with the required recovery destination
Reset Time	Time at which the incarnation began	Use it as supporting evidence, not the key

CURRENT identifies the branch RMAN presently uses as its frame of reference. A PARENT is on the direct ancestral path of that branch. An ORPHAN is a recorded branch outside the current direct path. Selecting another branch can change these relationships, so record the complete list before and after the operation.

The target control file exposes incarnation records through V$DATABASE_INCARNATION. A read-only query can provide a second view of branch boundaries, parentage, and container scope:

SELECT incarnation#,
       status,
       resetlogs_change#,
       resetlogs_time,
       prior_incarnation#,
       flashback_database_allowed,
       con_id
FROM   v$database_incarnation
ORDER  BY resetlogs_change#;

RESETLOGS_CHANGE# and RESETLOGS_TIME identify the beginning of a branch. PRIOR_INCARNATION# records parentage, while FLASHBACK_DATABASE_ALLOWED indicates whether some flashback destination is available in that incarnation. CON_ID identifies the container scope.

Use the Inc Key displayed by RMAN as the reset operand. Do not assume that a control-file record identifier is interchangeable with every key shown by a recovery catalog. The RMAN list is also where the operator confirms that the chosen key belongs to the intended DBID and branch.

The command must be entered at the RMAN prompt while RMAN is connected to a target database. The target state and source of incarnation history depend on repository mode.

Prerequisites for resetting a database incarnation

Repository mode	Target state	Required incarnation record	Persistence
Recovery catalog	Target can be mounted or unmounted	The catalog must know the record; a mounted control file must also know it	The catalog records the selected repository branch
NOCATALOG	Target must be mounted	The mounted control file must contain the requested record	The reset persists across RMAN sessions

An old incarnation may have aged out of the current control file. In NOCATALOG mode, RMAN cannot select a key that the mounted control file does not know. The recovery procedure may need to restore and mount an older control file that contains the required incarnation history before running LIST INCARNATION and selecting the key.

A recovery catalog can retain historical branches longer than the current control file, but a mounted target must still have the specified record. Do not use the catalog as a reason to skip target identity, mount-state, branch, and backup checks.

An incarnation record proves that RMAN knows a redo branch. It does not prove that the files required to reach a point in that branch are still available. Before changing the current incarnation, connect the recovery objective to repository and storage evidence.

LIST BACKUP SUMMARY;
LIST COPY SUMMARY;
LIST ARCHIVELOG ALL;

Review whether the repository contains an appropriate control-file backup, data-file backups or copies, and archived redo covering the intended destination. Then verify the actual storage path. Disk records must correspond to files accessible from the recovering host. Tape or external media records require the correct media-management configuration, credentials, and retained media. Encrypted backups require the appropriate wallet or password at recovery time.

Time, SCN, and restore-point evidence must agree. A wall-clock timestamp can be affected by time zones, daylight-saving transitions, and application or host clock differences. Prefer an incident SCN or a tested restore point when the recovery plan provides one. If a timestamp is used, document how it was converted to the database recovery destination and compare it with the incarnation's reset SCN and reset time.

Do not infer recoverability from CURRENT, PARENT, or ORPHAN status. Those values describe branch relationships, not backup completeness. Likewise, LIST reports repository records but does not inspect every backup byte. Use the site's restore-validation and recovery-rehearsal procedures for that evidence.

Avoid running an incidental CROSSCHECK solely to explore the branch during an incident. CROSSCHECK can change repository status to EXPIRED when a file is not found through the channels available to that session. Run it only with the correct device access and an approved maintenance purpose.

Incarnation selection is one step inside a reviewed recovery plan. Before changing repository state, define the recovery objective by SCN, timestamp, or restore point. Confirm the database name, DBID, DB_UNIQUE_NAME, role, container, and repository mode. Preserve diagnostic evidence and verify that the required control-file, data-file, and archived redo backups exist and are accessible.

1. Record the current incarnation list and identify the required ancestor or orphan branch.
2. Compare the branch's reset SCN and parentage with the approved recovery destination.
3. Verify the Inc Key against the intended database name and DBID.
4. Satisfy the catalog or NOCATALOG target-state prerequisite.
5. Select the verified incarnation in the RMAN repository.
6. Set one consistent recovery destination before both RESTORE and RECOVER.
7. Restore and recover the whole CDB according to the tested procedure.
8. Open with RESETLOGS when required, then verify the new current incarnation.

The following block is a relationship skeleton, not a copy-and-run recovery script. Every descriptive placeholder requires a verified numeric value:

LIST INCARNATION OF DATABASE PRODCDB;
RESET DATABASE TO INCARNATION verified_inc_key;

RUN
{
  SET UNTIL SCN verified_recovery_scn;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

ALTER DATABASE OPEN RESETLOGS;
LIST INCARNATION OF DATABASE PRODCDB;

Place SET UNTIL before both restore and recovery so RMAN selects backups and redo for the same destination. A time-based plan must use SET UNTIL TIME and account for timestamp conversion and time-zone interpretation. Do not choose an approximate expression such as an unreviewed number of days before the incident.

The reset command does not prove that recovery is possible. Backup availability, archived redo continuity, encryption credentials, media-manager access, control-file history, and restore validation remain independent requirements.

When NOCATALOG mode depends on an incarnation absent from the current control file, a control-file restore can precede branch selection. The sequence below illustrates the state changes:

STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
LIST INCARNATION OF DATABASE PRODCDB;
RESET DATABASE TO INCARNATION verified_inc_key;

The actual restore form depends on the known DBID, autobackup or tagged backup, device configuration, media management, and required control-file date. Do not assume that a generic command will locate the correct control file. The restored file must contain the incarnation key that the recovery plan intends to select.

Restoring a backup control file requires media recovery of the whole database followed by OPEN RESETLOGS, even when no data file needs to be restored. If an intact current multiplexed control-file copy remains, copying that file or correcting CONTROL_FILES may avoid an unnecessary restore from backup.

After the reset, RMAN interprets later RESTORE, RECOVER, and applicable FLASHBACK DATABASE commands in the selected branch. Stop and review the active branch before continuing, especially in NOCATALOG mode, where the selection persists across sessions.

The command does not perform any of the following actions:

• copy, restore, or recover a data file;
• restore or mount a control file;
• apply archived or online redo;
• change the database DBID or DB_UNIQUE_NAME;
• delete or expire backups from another incarnation;
• create a new database incarnation;
• open the target database; or
• guarantee that the requested recovery destination is reachable.

Do not confuse this operation with CHANGE ... RESET DB_UNIQUE_NAME, which updates backup ownership metadata in a Data Guard context. It is also unrelated to restarting an instance or clearing an application setting merely because each operation uses the word “reset.”

Oracle 26ai uses multitenant architecture, and a PDB can have its own incarnation history. Connect to the CDB root and list the PDB branches before selecting one:

LIST INCARNATION OF PLUGGABLE DATABASE salespdb;

The PDB form of the reset command is:

RESET PLUGGABLE DATABASE salespdb TO INCARNATION verified_pdb_inc_key;

The initial PDB incarnation number is 0. Later values are unique but not necessarily sequential. The reset operation requires SYSDBA, not merely SYSBACKUP, and the PDB form is not supported on a standby database. These restrictions differ from the whole-CDB command.

Do not substitute a CDB incarnation key in the PDB command or a PDB key in RESET DATABASE. Verify the root connection, PDB name, container identity, branch, key, and recovery destination. PDB flashback and recovery also have state, undo-mode, and availability requirements beyond the repository selection shown here.

After recovery and OPEN RESETLOGS, verify that Oracle created a new current incarnation and that RMAN now reports the expected branch:

LIST INCARNATION OF DATABASE PRODCDB;
LIST BACKUP SUMMARY;

Capture the new current incarnation, reset SCN, reset time, database name, DBID, and DB_UNIQUE_NAME in the recovery record. Query V$DATABASE_INCARNATION when a second view of parentage and control-file history is useful. Review the full RMAN and alert-log output before declaring the operation complete.

Create a new full or incremental level 0 backup according to the site's post-recovery policy. Earlier backups may remain usable for their branches, but the new current incarnation needs a verified recovery baseline. Confirm control-file autobackup, archived redo protection, retention, monitoring, and access to encryption or media-management credentials.

In a catalog-aware environment, verify that the recovery catalog represents the new branch correctly. Lesson 5 explains how RMAN resynchronizes the catalog after target control-file, backup, log, and incarnation changes.

1. Confirm the target database name, DBID, role, container, and repository mode.
2. Define an approved recovery destination and identify its redo branch.
3. Record LIST INCARNATION output before changing repository state.
4. Use the verified Inc Key, never the DB key, DBID, or a guessed value.
5. Confirm that a manual reset is required for the requested branch.
6. Meet the catalog or NOCATALOG target-state prerequisite.
7. Use one consistent SET UNTIL destination for restore and recovery.
8. Open with RESETLOGS only after the reviewed recovery completes.
9. Verify the new current incarnation and preserve operational evidence.
10. Create the required post-recovery backup and verify catalog synchronization.