Lesson 1

Infrequent Oracle Recovery Situations and Redo Log Maintenance

Imagine that your database server crashes before an online backup finishes. After restarting the instance, you encounter an error when opening the database. Should you restore a backup, recover a datafile, or end backup mode? The answer depends on how the backup was performed and what happened to the original files. An interrupted backup alone does not identify the required recovery procedure.

In Oracle AI Database 26ai, begin by distinguishing an RMAN backup from a user-managed backup that uses BEGIN BACKUP. RMAN does not require that user-managed backup mode. A failed RMAN job therefore does not, by itself, mean that datafiles were left in backup mode. A user-managed backup can leave that condition behind, but you must also establish whether the affected files are still the current files or were restored from an earlier backup.

This module builds on complete and incomplete recovery by examining situations that require additional investigation: a lost datafile without its own backup, an interrupted user-managed backup, damaged online redo, and replacement of redo groups or members. The aim is to recognize the prerequisites for a procedure before applying it. Recovering data and maintaining the files that protect future changes are related tasks, but they solve different problems.

The examples assume a self-managed, single-instance primary container database (CDB) operating in ARCHIVELOG mode. Its pluggable databases (PDBs) share the CDB control files and online redo infrastructure. RAC adds redo threads and instance coordination; ASM, Data Guard, and managed services add their own storage or operational requirements. Use the procedure appropriate to the actual environment rather than transferring a single-instance example unchanged.

Establish What Failed Before Choosing Recovery

First separate an instance failure from media loss. When database files remain intact, instance recovery can resolve changes left incomplete by a crash. A missing or damaged file introduces a different problem. An operating-system access error may also make a surviving file appear unavailable. Preserve the original error messages and investigate storage accessibility before deciding that data has been permanently lost.

Record the database identity, its current state, the affected filenames, and the actions already taken. In particular, ask whether another administrator restored files or replaced the control file. A file copied from backup may have the expected name while representing an earlier database state. Filenames alone cannot establish which recovery procedure applies.

Then assess the recovery material: usable datafile backups, control-file metadata, the required archived and online redo, and any encryption keys needed to read protected backups or data. A successful backup job is useful evidence, but a recovery plan must also account for everything needed between that backup and the intended target.

Initial assessment of unusual recovery situations
Situation	Evidence to obtain	Key distinction
Lost datafile without a backup	Creation history, control-file entry, redo availability, and logging history	An empty replacement still needs its contents reconstructed.
File left in backup mode	Backup method, file provenance, and backup-mode status	Current files and restored files require different treatment.
Missing online redo member	Other members, group status, and storage errors	One missing member does not establish loss of the whole group.
Damaged inactive group	Checkpoint, archive, and backup requirements	Instance recovery and media recovery have different redo needs.
Required redo unavailable	Alternative copies and the last reachable recovery target	Later redo does not automatically bridge a missing interval.
Planned redo replacement	Group inventory, workload, and maintenance eligibility	Creating a new log does not reconstruct lost transactions.

Interrupted User-Managed Backups

A user-managed online backup must account for files changing while they are copied. If the server fails during a backup that used BEGIN BACKUP, inspect the affected files and determine whether they remain in backup mode. Do not assume that every crash during an online backup requires restoring the database.

For files known to be current and not restored from backup, Oracle documents ending backup mode. The database-wide ALTER DATABASE END BACKUP statement requires the database to be mounted but not open. File-level and tablespace-level forms have their own applicable procedures; they should not be confused with the database-wide form.

If any affected file was restored, ending backup mode is not a substitute for recovering it. When you cannot establish whether a restore occurred, follow the recovery procedure rather than assuming that the file is current. This distinction prevents an administrative state change from being mistaken for reconstruction of missing changes.

Ending backup mode also does not finish the interrupted backup, validate a copied file, or repair damaged storage. After resolving the database condition, assess the backup job separately. Determine which backup pieces or copies are usable and whether another backup is needed. Database availability and backup completeness are two different outcomes to verify.

Recovering a Datafile Without Its Own Backup

A lost datafile is not always unrecoverable merely because no backup of that particular file exists. For an eligible non-SYSTEM user datafile, Oracle documents creating an empty replacement and applying recovery to reconstruct its contents. The control file must record the original file, and the archived redo generated since its creation must be available. Reaching the latest recoverable state may also require surviving online redo.

Consider a user datafile added after the last database backup. If the file is lost before the next backup, its creation history and the redo generated since then become essential. The replacement begins empty; assigning the original size and a usable pathname does not restore the tables and indexes that occupied it.

This approach has specific limits. Oracle excludes SYSTEM datafiles from the documented CREATE DATAFILE reconstruction procedure. Operations performed without sufficient redo can also leave content that recovery cannot reconstruct. Running in ARCHIVELOG mode does not manufacture redo for changes that were not fully logged. Assess relevant NOLOGGING operations and use the applicable recovery procedure for special cases such as undo.

The next lesson develops this scenario in detail. For now, remember that the recovery starting point has changed: instead of restoring the file from a backup, recovery must reconstruct it from its creation. That can require a much longer retained redo history.

Assessing Lost or Damaged Online Redo

Online redo protects changes that may not yet be reflected in the datafiles, including committed changes. Its importance is not limited to unfinished transactions. Before considering incomplete recovery, identify the affected group, its thread and sequence, and every member belonging to it. Investigate surviving copies and recoverable storage faults.

A group and a member are different objects. Members provide copies within a group; groups provide the sequence of logs through which the instance writes. Replacing a failed member can restore redundancy, while replacing lost redo contents requires an available copy or a recovery strategy that does not depend on those contents.

Likewise, INACTIVE concerns instance recovery. It does not prove that an older backup can be recovered without the redo in that group. Evaluate archive availability and the intended recovery target before treating an inactive group as disposable.

If required redo is unavailable everywhere you can obtain a usable copy, complete recovery may be impossible. A supported alternative, such as database point-in-time recovery, must have suitable starting backups and a reachable consistent target. The business must understand which later changes will be lost. A standby or Flashback Database may provide another option when its prerequisites are met, but neither should be assumed available merely because the primary uses archiving.

Clearing Redo Is a Conditional Operation

Clearing a damaged online redo group reinitializes it; it does not recover its old contents. Oracle places restrictions on clearing, including cases where the redo is needed for instance recovery. Clearing unarchived redo can also remove a sequence required by older backups. Do not treat it as a shortcut around an archiving delay. See Oracle's redo log maintenance documentation for the applicable conditions.

A new backup after discarding required history provides a new recovery starting point. It cannot retroactively restore the missing sequence or make an older dependent backup recoverable again. Offline datafiles may introduce additional dependencies, so their recovery needs belong in the assessment too.

Opening with RESETLOGS is another operation with a specific recovery context. It starts a new database incarnation and restarts redo sequence numbering; database SCNs do not reset to 1. It does not automatically invalidate all earlier backups. Retain the metadata and recovery history required for the intended recovery path, and consider a fresh backup as protection after recovery.

Plan Redo Maintenance Around Recovery Requirements

Maintenance should preserve usable redo copies, support the workload, retain required recovery history, and make failures easy to diagnose. These goals apply both before an incident and after service has been restored. Document the resulting configuration so that the next administrator can distinguish an intentional design from a missing file.

For redundancy, inspect the actual storage protection behind member locations. Different directory names do not necessarily represent independent disks, controllers, or failure domains. Establish which single failures the design can tolerate. Also distinguish the minimum of two groups per redo thread from the recommendation to maintain redundant members within groups.

For capacity and performance, use measured workload, switch history, checkpoint activity, and archive or standby throughput. Avoid a universal switch interval or group count. A quiet application and a large batch load can create very different requirements. Investigate why reuse is delayed before assuming that adding groups will solve the underlying problem.

For retention, coordinate archive management with backups, recovery objectives, and standby requirements. An archive that appears old may still be necessary for a retained backup. Monitor both the Fast Recovery Area quota and the capacity of its underlying storage. Additional archive destinations need appropriate configuration and monitoring; their presence alone does not guarantee uninterrupted archiving.

For diagnosability, keep a record of member paths, storage changes, alerts, and completed maintenance. After replacement, verify the new configuration and confirm that the intended protection has been restored. Do not use routine sequence-number resets as housekeeping, and do not treat redo as a replacement for a formal auditing configuration.

Verify the ARCHIVELOG Prerequisite

This module assumes that archiving was enabled while the redo needed for recovery was generated. Enabling it after a failure cannot recover redo already overwritten. The mode is a prerequisite, not a guarantee that every desired recovery target is reachable.

Changing a database to ARCHIVELOG requires it to be mounted but not open. There is no interactive YES response to the SQL statement. Plan any configuration change separately, including the necessary outage and RAC coordination where applicable. Oracle's archived redo administration guide describes these requirements and destination management.

Gather Recovery-State Evidence

Use an authorized session and the appropriate container. The following read-only examples assume access to the CDB root with the database mounted or open as appropriate. They inspect state; they neither perform recovery nor prove that a recovery will succeed.

SELECT name, database_role, open_mode, log_mode
FROM v$database;

SELECT con_id, file#, status, change#, time
FROM v$backup
WHERE status = 'ACTIVE'
ORDER BY con_id, file#;

SELECT group#, thread#, sequence#, status, archived, members
FROM v$log
ORDER BY thread#, group#;

SELECT group#, type, member, status
FROM v$logfile
ORDER BY group#, member;

V$BACKUP identifies backup-mode status. An ACTIVE row does not mean that an RMAN job is currently running or that a backup completed successfully. Relate the result to the backup method and the history of the actual files.

V$LOG describes groups, while V$LOGFILE identifies members and their recorded status. A null member status is not a complete health certificate. Correlate these results with file access, storage diagnostics, and messages from the instance.

Additional evidence comes from V$ARCHIVE_DEST, V$ARCHIVED_LOG, V$RECOVERY_FILE_DEST, the alert log, and RMAN output. Recorded archive metadata does not establish that the corresponding file remains accessible. Similarly, an empty V$RECOVER_FILE result does not certify recoverability, particularly when control-file information has been restored or recreated.

When documenting an incident, separate what you observed from what you have verified. For example, “the control file lists the archive” is weaker evidence than “the required archive copy is available and usable.” This habit helps prevent a recovery decision from resting on an outdated inventory.

Module Objectives

After completing this module, you will be able to:

Identify when a lost datafile can be reconstructed without its own backup and explain the required redo and metadata.
Distinguish ending backup mode on current files from recovering restored or damaged files.
Assess when clearing a damaged redo group is permitted and explain its recovery consequences.
Evaluate inactive online redo groups using checkpoint, archive, and backup requirements.
Plan replacement or recreation of online redo groups and members without confusing maintenance with reconstruction of lost changes.
Gather recovery-state evidence from relevant views, diagnostic messages, and RMAN output.

The next lesson examines how to recover a lost datafile when no backup of that file is available.