Lesson 1

Suppose a media failure damages an Oracle database operating in ARCHIVELOG mode. You restore suitable data file backups and begin media recovery. Oracle applies the available redo, then requests an archived log represented in this example by ARC_480.ora. The file is unavailable at the expected location. Can recovery continue, or must you return the database to an earlier state?

The first step is to investigate the missing redo. An unavailable filename does not necessarily mean that the redo has been lost. Another archive destination, the fast recovery area, a backup, a suitable standby copy, or a surviving online redo log may contain the required information. If you can supply that redo, recovery may continue toward the original target.

If the required redo is permanently unavailable and the selected recovery chain cannot reach the present, you may need to stop at an earlier consistent point. This operation is called incomplete recovery, also known as database point-in-time recovery, or DBPITR. It restores an earlier database state, with the consequence that changes committed after the chosen endpoint are absent from that recovered state.

This module explains how to recognize incomplete recovery situations, choose an achievable endpoint, and understand the implications of reopening the database. In Oracle AI Database 26ai, whole-database examples refer to a multitenant container database, or CDB. Recovery of an individual pluggable database, or PDB, is a separate option with its own scope and prerequisites.

What Makes Recovery Incomplete?

Complete media recovery brings restored data files forward to the current recoverable state using the required recovery information. Incomplete recovery deliberately ends earlier, either because you want to exclude an unwanted change or because essential recovery information cannot be obtained. The word incomplete describes the recovery endpoint. It does not mean that Oracle should open an internally inconsistent database.

For example, suppose an incorrect application operation changes thousands of accounts at 14:30. Recovering the affected database scope to a suitable point before that operation can remove its effects. However, valid payments committed after that endpoint will also be absent. Physical point-in-time recovery does not distinguish desirable business transactions from undesirable ones within the interval being abandoned.

This distinction makes recovery planning a business decision as well as a technical task. The DBA must determine what state can be recovered, while application owners establish whether that state is acceptable. A database that opens successfully may still require reconciliation with payment systems, messages already delivered, reports already issued, or other applications that continued processing.

ARCHIVELOG Mode Provides Recovery History

Redo records describe database changes needed for recovery. Oracle writes redo to online redo logs during normal operation. In ARCHIVELOG mode, completed redo log groups are archived before they are reused. These archived logs preserve recovery history beyond the information currently retained in the online redo logs.

A data file backup supplies a starting state, and recovery information brings that state forward. Archived redo, required online redo, and applicable RMAN incremental backups can contribute to this process. The available combination must support the chosen endpoint. Enabling archiving alone does not guarantee that suitable backups exist or that every required piece of recovery history remains accessible.

Retention and accessibility therefore matter. An archived log recorded in the RMAN repository may have been removed from disk, but still exist in a backup. Conversely, a backup record does not guarantee that its storage is readable. Before accepting an earlier endpoint, distinguish a file-location problem, a storage-access problem, and a genuine gap in the available recovery material.

Investigating the Missing Archived Log

Return to the example of ARC_480.ora. This is an illustrative filename for a simple single-thread scenario, not a required Oracle naming convention. The investigation should establish which redo Oracle needs and whether another usable copy exists. In more complex environments, identification also involves the redo thread, SCN coverage, and incarnation.

If another valid copy can be supplied, the missing pathname need not change the recovery objective. If no copy is available, determine whether a different usable backup and recovery chain can reach the required state. The decision depends on the actual recovery material, not simply on the first error message displayed during recovery.

You cannot normally skip a required redo log in the selected chain and continue with the next one. Later redo may depend on changes contained in the missing interval. An earlier target must also allow the restored files to reach a consistent state. Cancelling when a log prompt appears does not, by itself, prove that the database can be opened.

Situations That May Require an Earlier Endpoint

Required redo cannot be recovered

A missing archived log can prevent complete recovery when its contents are required and no usable copy or alternative recovery chain is available. Loss of required online redo can create a similar problem. Recent committed transactions may exist only in online redo that has not yet been archived.

However, losing one member of a multiplexed online redo group does not automatically require incomplete recovery. Another member may preserve the same redo. The important question is whether the required information has been lost, rather than whether a particular physical file has failed. Preserve surviving recovery material while evaluating the damage.

Logical damage must be excluded

A mistaken update, failed application deployment, or widespread deletion may make an earlier state preferable to the current state. Complete media recovery would reproduce the unwanted changes because they are part of the redo history. Point-in-time recovery instead chooses an endpoint that precedes them.

Not every logical error justifies recovering the whole CDB. A dropped table may be recoverable through Flashback Drop when it remains eligible in the recycle bin. Other localized problems may be better addressed through Flashback Table or RMAN table recovery. Evaluate the affected objects and dependencies before selecting the recovery scope.

Choose the Recovery Scope First

Whole-CDB point-in-time recovery returns the CDB and its included PDBs to a common earlier database state. This can be appropriate for damage affecting the entire environment, but it also affects applications whose data was otherwise correct. The availability impact and the loss of later valid changes can extend well beyond the original problem.

PDB point-in-time recovery provides a narrower option when the incident is confined to a particular PDB. It does not imply that every other PDB must be rewound to the same target. Its preparation and execution depend on the database configuration and the documented PDB recovery procedure, including any auxiliary recovery requirements.

Tablespace point-in-time recovery, or TSPITR, is another specialized operation. It recovers an eligible set of tablespaces to an earlier state while leaving the rest of the database at its existing state. Object dependencies and the recovery set must be evaluated. TSPITR is not accomplished by independently recovering arbitrary files and attaching them to a newer database.

The useful question is: what is the smallest supported recovery scope that fully repairs the incident? A narrow scope can reduce disruption, but only if it preserves the relationships on which the application depends. Related data in another PDB or an external system may still require reconciliation.

Plan the Target Before Restoring Files

A restore operation retrieves backup files. A recovery operation applies changes to move those files forward. These are related but different activities. Ordinary forward media recovery cannot take data files from after an unwanted change and roll them backward to an earlier time.

Select backups that can be recovered to the intended endpoint. The newest available backup is not necessarily suitable for a target in the past. In RMAN workflows, establishing the recovery target before backup selection helps keep restore and recovery aligned. Later lessons explain the corresponding commands and the interpretation of their boundaries.

Before beginning, identify the incident time, the affected data, the required scope, and the available recovery history. Establish how much data loss is acceptable and how the recovered state will be checked. If backups are encrypted, access to the required keys or passwords is also part of recovery readiness.

A recovery point objective describes the business's acceptable loss of recent data, while a recovery time objective describes the desired restoration time. These objectives guide the decision, but they do not manufacture missing backups or redo. The selected plan must reconcile those business requirements with what the available recovery material can actually deliver.

Understand the Recovery Target Methods

Time-based and SCN-based recovery

A time-based target is convenient when incident evidence is expressed as a clock time. An SCN-based target identifies a database change boundary more directly. The correct choice depends on the evidence available and the required precision. Clock settings, time zones, and the relationship between an application event and its database commit all deserve attention.

RMAN supports explicit targets such as a time, SCN, or log sequence. These target forms have defined boundary semantics that should be understood before use. Selecting a number merely because it appears near an error message is insufficient. The target must correspond to the intended state and be reachable from the selected backups.

Cancel-based recovery

User-managed recovery in SQL*Plus includes RECOVER DATABASE UNTIL CANCEL. This form allows the operator to end recovery while supplying redo. It remains relevant to the module's historical missing-log scenario, but it requires a clear understanding of which redo has been applied and whether the resulting files are consistent.

UNTIL CANCEL is not RMAN recovery syntax. RMAN normally expresses this decision through an explicit recovery target. Later lessons separate the two interfaces and provide the necessary preparation. This introduction establishes the choices without presenting an incident-independent sequence of commands.

A Backup Control File Does Not Automatically Mean Data Loss

The control file records essential database structure and recovery information. If one multiplexed current copy is lost, another intact current copy may be available. If all current copies are lost, restoring a backup control file may be necessary, with additional recovery work appropriate to the actual database state.

Using a backup control file does not necessarily force recovery to an earlier endpoint. Complete recovery may still be possible when the required data files and redo are available. Nevertheless, recovery using a backup control file requires opening the database with RESETLOGS. Consequently, the presence of RESETLOGS does not prove that committed data was lost through incomplete recovery.

Verify the Result Before Resuming Service

Review the recovery output and alert log to understand what Oracle applied, where recovery ended, and whether further action is needed. A request for another log, an operating-system access error, and a file-consistency error describe different conditions. Keep the complete recovery transcript so that decisions can be traced to the evidence available at the time.

Where the recovered database meets the requirements for opening read-only, read-only inspection can help verify the selected state before RESETLOGS. This is an optional verification technique, not a way to bypass unresolved recovery requirements. Return the database to mounted state before continuing recovery or performing the final RESETLOGS open.

If recovery stopped too early, further available redo may allow advancement to the intended endpoint. If too much redo was applied, repeating a restore-based recovery generally means restoring suitable backups again. Check application-level evidence as well as database status: representative balances, important records, and the absence of the unwanted changes are more informative than a successful open alone.

RESETLOGS Establishes a New Recovery Branch

After whole-database incomplete recovery, OPEN RESETLOGS creates a new database incarnation and restarts redo log sequencing. The new incarnation distinguishes subsequent database history from the abandoned continuation of the previous history. It does not assign a new DBID or mean that Oracle has created an unrelated database.

RESETLOGS also does not make every earlier backup and archived log unusable. RMAN tracks incarnation relationships and can use suitable material along a valid ancestral recovery path. However, historical redo must not be treated as interchangeable with redo from the new branch. Recovering through RESETLOGS requires the correct history and the required recovery material.

After verification and reopening, take a fresh backup as a practical baseline for future recovery. Preserve older backups and logs according to retention and recovery requirements. Review backup jobs and any standby implications before considering the incident closed. Deleting previous recovery history immediately can remove options needed for further investigation or another recovery attempt.

Consider Flashback and Targeted Recovery Alternatives

Flashback Database can return existing data files to an earlier state without first restoring them from backup, which can shorten recovery when its prerequisites are satisfied. It needs usable flashback history and the required redo. Enabling flashback after an incident does not recreate missing historical flashback information, and flashback is not a universal workaround for a missing archived log.

Flashback Drop, Flashback Table, and RMAN table recovery address different kinds of localized damage. Their prerequisites and limitations differ, so choose them based on the affected objects and available history. The central skill developed in this module is selecting an achievable recovery method whose scope, endpoint, and business consequences are understood.

The next lesson examines situations in which incomplete recovery may be required and the checks to perform before choosing a recovery target.