Recovery Through RESETLOGS in Oracle AI Database 26ai

Suppose you perform database point-in-time recovery, open the database with RESETLOGS, and resume normal work. Before another database backup is taken, a second media failure damages the data files. Can RMAN use the backup from before the earlier recovery and preserve work committed afterward?

In Oracle AI Database 26ai, it can, provided suitable backups, the required recovery information, and the incarnation history remain available. RMAN supports recovery across a previous OPEN RESETLOGS. The absence of a newer backup does not automatically make the current database unrecoverable.

This lesson uses a whole CDB in ARCHIVELOG mode. Here, “no backup after incomplete recovery” means no new data file backup after RESETLOGS. An earlier usable backup still supplies the starting data files. This is not a procedure for reconstructing a lost database with no suitable baseline.

The scope matters: another whole-CDB point-in-time recovery can exclude valid later work in multiple PDBs. Recovering one PDB or a tablespace has different prerequisites and procedures. Select the scope with the application owners before treating a database-wide example as the response to an isolated application problem.

OPEN RESETLOGS creates a new database incarnation, or branch of recovery history. Recovering through that operation means starting with data files from an eligible earlier incarnation and applying the recovery information needed to reach a target in the later branch.

A second failure after an earlier point-in-time recovery

Event	Recovery significance
Backup B is taken	B belongs to incarnation A and predates the first recovery target.
An error requires point-in-time recovery	The database is restored and recovered to an earlier point in A.
The database opens with RESETLOGS	Incarnation C begins; A becomes its parent.
New transactions commit in C	Their recovery information belongs to C's redo history.
A second failure damages data files	RMAN can restore B and recover along the A-to-C path if the required material survives.

The letters identify teaching examples, not actual incarnation keys. Recovery follows A only to the branch boundary and then follows C. It does not replay A's abandoned later changes before adding C's transactions. Those histories are not interchangeable, even if some sequence numbers or SCNs overlap.

Complete recovery after the second failure preserves recoverable work on the current branch. It does not undo the data loss accepted during the first point-in-time recovery or merge the abandoned branch back into the database.

Oracle uses online redo logs and archived redo logs to record changes. RESETLOGS establishes a new incarnation and restarts redo sequence numbering. It updates the recovery identity associated with data files and redo so that Oracle can distinguish branches.

The operation can archive accessible current online logs and create missing online redo files as part of initializing the new stream. It does not reconstruct missing historical redo. Required destinations must be available and writable before opening.

Database SCNs and the DBID do not reset to 1. A sequence number by itself is also insufficient to identify an archived log across incarnations. Preserve thread and incarnation information when locating files, and do not overwrite older archives merely because a newer file has the same sequence number.

RESETLOGS does not automatically invalidate earlier backups. Their usefulness depends on their position in the selected history and the available recovery chain. A backup taken on an abandoned portion of a parent branch is different from a backup taken before the branch point.

Crossing an old RESETLOGS boundary during recovery does not, by itself, require another RESETLOGS when you open. The opening method depends on the recovery just performed and the control file used.

Choose the opening method for the current recovery

Situation	Opening behavior
Complete recovery using the current control file	Open normally after successful recovery.
Database point-in-time recovery	Open with RESETLOGS.
Recovery using a restored backup control file	Open with RESETLOGS, even after complete recovery.
Flashback Database to a retained earlier state	Use RESETLOGS when opening that state for read/write operation.
Recovery involving a recreated control file	Follow its creation and recovery conditions; recreation alone does not always require RESETLOGS.

A recreated control file is not the same as a restored backup control file. Oracle supports CREATE CONTROLFILE ... NORESETLOGS under its documented conditions, including availability of the current online redo. Creating it with RESETLOGS requires opening with that option.

Before restoring, establish which files were lost, the intended endpoint, and whether the necessary information can actually be read. Preserve surviving files, diagnostic records, and useful recovery evidence before overwriting anything.

Requirements for recovery from an earlier incarnation

Requirement	What to verify
Starting data files	Suitable backups or image copies on the direct ancestral path to the selected target.
Recovery chain	Required archived redo and applicable incrementals before and after the earlier RESETLOGS; required current online redo for complete recovery.
Control file and history	A usable control file and complete incarnation metadata covering the path from the backup to the target.
Access and storage	Readable backup pieces, working media-manager access where needed, sufficient destinations, and required encryption material.
Scope and target	The correct CDB, recovery branch, and a consistent endpoint for all required files.

For the redo portion of the parent history, Oracle's RMAN reference specifies the logs needed from the backup through the SCN immediately before the relevant RESETLOGS SCN. Recovery then needs the appropriate material from the child incarnation to its target. Do not confuse the time of the original error with the earlier point to which the first recovery returned.

RMAN can use suitable incremental backups as well as redo. This does not mean a missing required interval can be skipped. Backup records, archive filenames, and an intact control file are not substitutes for readable recovery information.

A control-file autobackup taken after RESETLOGS can be valuable even when no newer data file backup exists. It protects recovery metadata, not the contents of all application data files. Inventory these artifacts separately so that a recent control-file backup is not mistaken for a complete new database backup.

SELECT name, dbid, log_mode, resetlogs_change#, resetlogs_time
FROM v$database;

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

LIST INCARNATION OF DATABASE;

The main example assumes a single-instance CDB, a usable current control file and SPFILE, intact required online redo, and earlier backups covering all required data files. The data file layout is unchanged, and the original destinations remain suitable. The goal is complete recovery after the second failure.

Stop application access, confirm the database identity, and connect RMAN to the CDB root using an authorized account with SYSBACKUP or SYSDBA privileges. For local operating-system authentication, a shell connection can be:

rman target /

If the instance is stopped, start it mounted from RMAN:

STARTUP MOUNT;

If it is already mounted, continue from that state. Handle an open or failed instance according to the incident; do not default to a forced restart. Retain the usable control file instead of replacing it merely because the backup belongs to an earlier incarnation.

Review the backups selected for restoration:

RESTORE DATABASE PREVIEW;

Preview reads repository metadata, not the complete backup contents. Confirm physical availability and use appropriate validation when needed. Resolve missing keys, unavailable media, or destination problems before beginning the restore.

Complete recovery to the current branch

In the mounted CDB, execute:

RUN {
  RESTORE DATABASE;
  RECOVER DATABASE;
}

RMAN restores eligible starting files and applies the required recovery information, crossing the previous RESETLOGS boundary transparently. There is no special “recover through resetlogs” command and no need to open the database at each historical branch point.

Review recovery completion and resolve errors before opening. Under this example's assumptions, recovery is complete and the current control file was used:

ALTER DATABASE OPEN;

The database continues in the existing current incarnation. The second recovery does not create another branch simply because the restored data files came from the parent.

If the second recovery must stop earlier

If complete recovery is impossible, select an achievable target and confirm the accepted data loss. The following alternative assumes that SCN 2800000 is a verified endpoint in the current incarnation, after the earlier RESETLOGS. It is illustrative, not a target to copy into another database.

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

Set the target before both restoration and recovery. The SCN limit is exclusive: changes at SCN 2800000 and later are excluded. Required files must be restored from backups that can reach this target consistently; a file already beyond it cannot be recovered backward with redo.

After successful recovery and confirmation that redo destinations are ready, open with:

ALTER DATABASE OPEN RESETLOGS;

This creates another incarnation because the second recovery was incomplete. This alternative replaces the complete-recovery example; it is not a follow-up block to run against an already opened database.

Correlate RMAN output with the alert log as described in Lesson 5. Successful media recovery, successful opening, and correct application data are separate checks. Header diagnostics alone cannot establish all three.

V$DATAFILE_HEADER reads headers, not every data block. An empty V$RECOVER_FILE result is not a universal success test, and the view is unreliable with a restored control file or one recreated after the relevant media failure. Resolve recovery errors instead of treating a convenient query result as permission to open.

After the CDB opens, open the intended PDBs according to the operating plan. Opening the root does not establish that all application PDBs are available. From a root SQL*Plus session, verify:

SELECT name, open_mode, log_mode FROM v$database;

SELECT name, open_mode FROM v$pdbs ORDER BY con_id;

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

Check representative transactions and relationships in the correct PDBs. Record the achieved target and reconcile any excluded business activity with external systems. Re-entering every apparently missing transaction can duplicate payments or messages that still exist elsewhere.

A fresh database backup can shorten future recovery and is a reasonable operational choice. Oracle 26ai does not require one solely because RESETLOGS occurred. In ARCHIVELOG mode, a fresh online backup need not involve another shutdown:

BACKUP DATABASE PLUS ARCHIVELOG;

Maintain control-file and SPFILE protection, required encryption keys, and appropriate archive retention. Keep older material needed by retained backups; RESETLOGS alone is not a reason to delete it or recatalog every backup. A new backup also does not create a named restore point, which is a separate database feature.

Base retention decisions on the recovery window and dependencies of the backups you keep. An older baseline can require more redo application and more time to recover. A fresh backup can reduce that operational burden, but its value should be assessed together with archive protection and restore testing.

Check any Data Guard follow or recovery requirements against the standby's actual state instead of assuming every standby must be rebuilt. Test the retained recovery chain in an isolated environment so that backup policy is supported by a demonstrated restore and recovery.