Lesson 2	Identifying an incomplete recovery situation
Objective	Determine when an earlier recovery endpoint is necessary or appropriate, and distinguish those situations from failures that permit automatic or complete recovery.

Identifying an Incomplete Recovery Situation in Oracle 26ai

An Oracle database failure does not automatically require incomplete recovery. A failed statement, disconnected session, instance crash, and damaged data file can call for different responses. To choose the correct response, identify both the damage and the database state that you need to restore.

Incomplete recovery, also called database point-in-time recovery or DBPITR, returns the recovered database scope to an earlier consistent state. It becomes relevant when the business needs a state before an unwanted change, or when missing recovery information prevents recovery to the required current state. An earlier endpoint must still be achievable with the available backups and recovery history.

This lesson focuses on identifying those situations in Oracle AI Database 26ai. The key distinction is between the failure category and the recovery target. Physical damage may permit complete recovery, while a committed application mistake may justify an earlier target even when every redo log is available.

Classify the Failure Before Choosing Recovery

The following table separates normal recovery behavior from circumstances that may justify an earlier endpoint. The presence of a failure in the first column does not, by itself, establish that database point-in-time recovery is required.

Failure situations and their relationship to incomplete recovery
Situation	Normal response	When incomplete recovery becomes relevant
Statement failure	Investigate the SQL error. Oracle normally undoes the failed statement's effects.	The statement error alone does not require DBPITR. Investigate any separate committed damage.
Client or server process failure	Allow appropriate process cleanup and resolution of uncommitted work; verify the application outcome.	Ordinary process failure does not require an earlier database state.
Instance failure	With required files and redo intact, Oracle performs automatic instance recovery.	Additional file or redo loss may create a separate need to consider DBPITR.
Committed user or application error	Investigate targeted repair, Flashback features, and scoped recovery options.	An earlier state is needed and narrower remedies cannot adequately repair the incident.
Required archived redo missing or corrupt	Locate another usable copy, restore a backup, or evaluate an alternative recovery chain.	The required gap cannot be resolved, but an earlier consistent state remains recoverable.
Data file or storage failure	Repair storage and restore and completely recover affected files when necessary and possible.	The required current state cannot be reached, or separate logical damage requires an earlier target.
Current control-file copies lost	Use an intact current copy if available; otherwise assess backup control-file recovery or reconstruction.	The available recovery information cannot support the required endpoint. Control-file loss alone is insufficient evidence.
Required online redo lost	Check surviving multiplexed members, archive copies, and other usable recovery material.	Necessary redo is genuinely unavailable and complete recovery cannot be achieved.

Failures That Normally Recover Without DBPITR

Statement and process failures

A statement can fail because of invalid input, a constraint violation, or another execution problem. Oracle normally rolls back the effects of that failed statement. Earlier successful statements in the same transaction are not automatically committed or universally rolled back by every statement error. The application must handle the error and decide how to resolve its remaining transaction.

Process failure is different. If a server process terminates abnormally, Oracle performs process recovery and resource cleanup. In current releases, PMON detects abnormal termination and delegates cleanup to CLMN, which can use CLnn helper processes. This recovery of resources and uncommitted work does not normally require restoring the database from backup.

A broken client connection also does not prove that a submitted commit failed. The database may have committed before the client lost its response. Verify the transaction outcome before retrying business operations. Replaying a payment or order without that check can create a duplicate even though the database itself is consistent.

Instance failure

After an instance crash, memory contents are lost, but durable redo can describe changes not yet reflected in the data files. When the required files and redo remain intact, Oracle performs instance recovery by applying necessary redo and resolving uncommitted work. In a single-instance database this occurs during restart; in RAC, a surviving instance can recover a failed instance.

Do not confuse this with restoring files after permanent storage loss. An ordinary crash does not require the DBA to choose a historical endpoint. If the crash also destroys essential files or redo, investigate that additional damage separately. The fact that an instance stopped tells you less than knowing which persistent recovery resources survived.

Missing Archived Redo: Investigate the Gap

Suppose recovery requests ARC_480.ora, the illustrative filename introduced in Lesson 1. Oracle cannot open the expected file. This establishes an access problem at that point in recovery, but it does not establish that the required redo is permanently lost.

Check other archive destinations, the fast recovery area, archived-log backups, suitable standby copies, and online redo where applicable. A log may be present under another pathname or temporarily inaccessible because of storage or permission problems. Identify the required information by redo thread, sequence, incarnation, and SCN coverage rather than trusting a filename alone.

If the missing redo can be supplied, recovery may continue. If it cannot, evaluate whether a different suitable backup or applicable incremental backup changes the required recovery chain. One missing archive does not automatically make every possible recovery path unusable. The relevant question is whether the required endpoint remains reachable.

Within a selected chain, however, you cannot skip required redo and resume with a later log as though nothing were missing. Later changes may depend on the missing interval. If no viable path reaches the intended current state, choose an earlier achievable endpoint. Cancelling at a prompt does not guarantee that every restored file has received enough recovery to permit a consistent open.

Online Redo and Physical Media Failure

Loss of required online redo can be especially serious because the latest committed changes may not yet have been archived. Before concluding that those changes are unrecoverable, determine whether a surviving multiplexed member or another valid copy preserves the redo. Losing one physical member is different from losing the necessary information from every usable source.

Storage failure can affect data files, control files, redo logs, or several file types together. The response depends on what was damaged. A lost data file may be restored from backup and completely recovered when its required history survives. An unavailable storage path may need repair rather than immediate restoration over the existing files.

Physical corruption also does not automatically require an earlier target. Clean backups and valid redo may permit complete recovery, while some isolated block problems may have more targeted repair options. Recovery reconstructs changes from durable material; it does not retrieve committed transactions from memory that disappeared during the failure.

Committed Logical Errors Can Justify an Earlier State

A successful but incorrect operation is fundamentally different from a failed statement. A batch can commit updates to the wrong accounts without producing any Oracle error. Complete media recovery would reproduce those updates because they belong to the database's recorded history. If the desired state excludes them, an earlier recovery endpoint becomes a candidate.

First establish whether a narrower remedy is available. An uncommitted change may still be rolled back. An eligible dropped table may be recovered through Flashback Drop. Flashback Table or RMAN table recovery may address other localized problems. These options have different prerequisites and should not be treated as interchangeable commands.

Flashback Database can avoid restoring data files when usable flashback history and required redo cover the target. It is not a universal remedy for missing archives or damaged storage. If a supported targeted method cannot repair the incident, database or PDB point-in-time recovery may provide the required earlier state.

Match the Recovery Scope to the Incident

In Oracle AI Database 26ai, whole-database DBPITR concerns the entire CDB. That scope can affect multiple PDBs and applications, including those with no original data problem. PDB point-in-time recovery provides a narrower option when the affected application data is confined to an appropriate PDB.

Tablespace point-in-time recovery, or TSPITR, addresses an eligible set of tablespaces. Table recovery addresses selected objects through its own recovery procedure. These methods are alternatives with different dependencies and requirements. They do not mean that arbitrary data files can be independently rewound and placed back into an otherwise current database.

This lesson concerns conventional backup-based PITR in ARCHIVELOG mode. A NOARCHIVELOG database normally lacks the retained redo history needed for arbitrary historical targets. It can still perform ordinary instance recovery using intact online redo. Restoring a consistent backup after unrecoverable media loss is a separate situation, not evidence that every NOARCHIVELOG crash requires DBPITR.

Evidence That Does Not Prove Incomplete Recovery Is Required

A backup control file or RESETLOGS requirement

If one current control-file copy is lost, another multiplexed copy may remain usable. If all current copies are lost, a backup control file may be needed. Even then, complete recovery can remain possible when the necessary data files and redo are available.

Recovery using a backup control file requires RESETLOGS, including when complete recovery is achieved. Therefore, a RESETLOGS requirement does not independently prove that committed transactions were lost. Interpret it together with the recovery procedure and the endpoint actually reached.

Different SCNs or a request for media recovery

Different restored data file checkpoint values can mean that additional recovery is required. Comparing V$DATAFILE_HEADER.CHECKPOINT_CHANGE# directly with V$DATABASE.CONTROLFILE_CHANGE# is not a universal consistency test or a formula for selecting a PITR target. These values describe different aspects of database state.

Similarly, an error requesting media recovery does not decide whether recovery should be complete or incomplete. A command containing UNTIL expresses a target or operating mode, not a measurement of business data loss. Review recovery output, the alert log, file status, and available recovery history together.

Understand What RMAN Diagnostics Establish

RMAN information helps investigate recoverability, but different commands answer different questions. LIST operations show repository records. CROSSCHECK reconciles recorded status with accessibility and may update repository metadata; it does not fully validate backup contents. REPORT NEED BACKUP evaluates backup needs against relevant criteria rather than calculating an exact final recoverable SCN.

RESTORE PREVIEW shows restore selection using metadata. It does not prove that every selected backup byte and every required redo interval can be read. Validation and a tested restore and recovery provide stronger evidence, especially when they address the actual target, storage paths, and credentials that the incident requires.

Oracle AI Database 26ai desupports Data Recovery Advisor and its failure-management commands, including LIST FAILURE and ADVISE FAILURE. Use current documented investigation methods and preserve the full recovery transcript. There is no single replacement report that automatically resolves every recovery decision.

An advanced RMAN option, RECOVER DATABASE UNTIL AVAILABLE REDO, recovers a whole database until a log is missing. It is not supported for an individual data file, tablespace, or PDB. It performs recovery rather than merely inspecting availability, so it does not replace planning an acceptable endpoint.

Confirm That the Earlier Target Is Achievable

Identifying a reason for incomplete recovery is only the first step. The selected target must be reachable. Suitable data file backups provide a starting state, and the required redo or applicable incremental changes bring that state forward. A backup containing later file contents cannot simply be rolled backward by ordinary forward media recovery.

Establish the target before selecting files to restore. Check that the control-file or repository information describes the needed recovery material, that backups are accessible, and that required encryption keys or passwords are available. Recovery also needs sufficient storage and time for restoration, redo application, and verification.

Requirements depend on scope. Whole-CDB recovery, PDB PITR, and TSPITR do not use identical preparation. Avoid treating temporary files and online redo logs as ordinary data file backups. A viable plan identifies what must be restored, what information must be applied, and how the resulting application state will be assessed.

Account for Valid Work After the Target

Suppose a harmful batch commits at 14:30, but the problem is discovered at 15:10. Legitimate orders continue during that interval. Choosing a target immediately before the harmful change excludes the batch, but it also excludes later valid commits within the recovered scope. Recovering to just before discovery would not remove damage already committed earlier.

Application logs, batch records, and transaction evidence help identify the incident boundary. Distinguish the time an operation began, the time it committed, and the time someone noticed its effects. An acceptable target depends on that evidence and the business's tolerance for missing subsequent work.

Do not instruct users simply to re-enter every missing transaction. An external payment may already have settled, a message may already have been delivered, or a downstream service may retain a newer state. Reconcile authoritative records, determine which operations are absent, and prevent duplicate submissions. A technically consistent database can still disagree with surrounding systems.

After recovery, RESETLOGS establishes a new incarnation without making every earlier backup or archive unusable. Preserve valid recovery history according to retention requirements and take a fresh backup as a practical baseline. The recovery decision includes verification and reconciliation, not merely obtaining a successful database open.

Decision Checklist

Before selecting incomplete recovery, confirm that the investigation answers these questions:

What failed or changed, and which database objects or applications are affected?
Can automatic recovery, complete media recovery, or a supported targeted repair meet the need?
If redo appears missing, have usable copies and alternative recovery chains been evaluated?
What earlier endpoint is both technically reachable and acceptable to the business?
What valid work will be excluded, and how will related systems be reconciled?
How will the recovered database and application state be verified?

The next lesson examines incomplete recovery methods and how the recovery target and control-file situation affect the procedure.