Incomplete Recovery with Archiving: Module Conclusion

Recognize when an earlier endpoint is justified

Lessons 1 and 2 established that different failures call for different responses. A failed statement, broken connection, instance crash, and damaged data file are not interchangeable recovery situations.

• Statement or process failure: investigate the error and transaction outcome. Normal rollback and cleanup do not imply a need for DBPITR.
• Instance failure: with the required files and redo intact, Oracle performs automatic instance recovery.
• Physical media failure: restore and completely recover affected files when the available material supports the required current state.
• Committed logical damage: consider targeted repair or an earlier recovery state because complete recovery would reproduce the unwanted changes.
• Required redo permanently unavailable: determine whether another recovery chain works or an earlier consistent endpoint is necessary.

The missing archived log in the introductory example was an investigation lead. Another archive destination, backup, surviving online log, or suitable standby source might preserve the required redo. A filename being unavailable is different from the underlying recovery information being irretrievably lost.

A broken client connection also leaves a transaction question to resolve. It does not prove that a submitted commit failed. Establish what actually happened before retrying business operations or deciding that the database needs to be rewound.

Choose the scope before choosing commands

Whole-CDB recovery affects applications in multiple PDBs. If one table was dropped or a localized batch was incorrect, first assess whether Flashback Drop, Flashback Table, RMAN table recovery, PDB PITR, or TSPITR can meet the need.

The smallest suitable scope must contain the damage and satisfy the relevant restrictions. A smaller recovery that leaves orders inconsistent with invoices may be unacceptable even when its files are internally consistent. Relationships enforced only by application code need review alongside database constraints.

Flashback features depend on retained history and their particular prerequisites. Flashback Query reads earlier versions without itself changing current data. Flashback Table cannot reverse every structural operation, and Flashback Drop requires an eligible recycle-bin object. Flashback Database needs suitable existing data files, flashback history, and required redo.

The selected method should therefore reflect the actual operation, available history, acceptable data loss, and expected outage. A recovery point objective states the acceptable loss; a recovery time objective states the desired restoration time. Neither objective creates missing recovery material.

Keep endpoint methods separate from recovery conditions

Lesson 3 separated three decisions: the recovery endpoint, the control file used, and the scope being recovered. Time, SCN, log sequence, and cancellation identify or control an endpoint. Using a backup control file describes a recovery condition.

In Lesson 6, the time a dropped table was reported differed from the time of the destructive operation. Choose the endpoint from evidence about the change, not its discovery. An explicit date-format mask avoids ambiguity in parsing but does not supply a time zone.

SCNs and sequences also require context. A current SCN queried after the incident is not the historical boundary of the mistake. Sequence numbers can repeat across threads and incarnations. Named restore points simplify target identification, but normal restore points do not preserve missing backups or redo.

Apply the restore-and-recover sequence deliberately

Lesson 4 established the order for whole-CDB RMAN DBPITR. Restoration retrieves starting files; recovery applies incremental changes and redo to move them forward. Ordinary media recovery cannot roll arbitrary newer data files backward.

1. Prepare: identify the target and scope, preserve useful current state and incident evidence, and verify backups, recovery history, storage, and encryption access.
2. Control access: stop application writers and arrange the outage. Connect to the correct root recovery context with appropriate privileges.
3. Mount: establish the database state required by the selected procedure, using the actual control-file and initialization-file situation.
4. Set the endpoint: apply the target to backup selection as well as recovery.
5. Restore and recover: process all required files for the selected scope and investigate any errors before proceeding.
6. Reopen and validate: use the required opening method, open the intended PDBs, and check application data.

This reminder assumes an already mounted CDB in ARCHIVELOG mode, usable current control file and SPFILE, suitable backups, and a verified target in the current incarnation:

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

The SCN is illustrative and excluded. SET UNTIL precedes both operations so they use the same endpoint. After successful whole-CDB incomplete recovery, the reopening step is:

ALTER DATABASE OPEN RESETLOGS;

Review recovery results and prepare required redo destinations before that command. A restore error or unresolved need for recovery is not a reason to attempt opening as a workaround. Opening the CDB also does not establish that every application PDB is open.

Remember the difference between selection and validation. RESTORE PREVIEW uses repository metadata to describe the backups RMAN expects to use. Reading and validating backup material answers a different question about its usability. Neither check alone proves that the chosen endpoint satisfies the application. Verify the recovery chain and define representative business checks before overwriting files, when there is still time to revise the plan.

NOLOGGING operations deserve separate attention. Having every expected archive does not guarantee reconstruction of changes that were not fully logged. Determine whether suitable backup material captured those changes and whether the selected target can be reached correctly. Recovery planning must account for the way the data was created, as well as the files currently listed in the repository.

Monitor progress and completion as separate observations

Lesson 5 combined the alert log, recovery-session output, and dynamic performance views. Each contributes evidence, but none independently establishes the complete business outcome.

Locate the correct instance's diagnostic directories through V$DIAG_INFO. The text alert log resides in the diagnostic trace directory; ADRCI can follow recent alert messages. Preserve the relevant recovery interval, including errors and the operations surrounding them.

Use V$RECOVERY_PROGRESS for populated media-recovery measurements and V$SESSION_LONGOPS for suitable RMAN job steps. Read the units and operation identity. A percentage for one restored backup set is not a percentage for the whole recovery, transport, reopening, and validation process.

Empty or unchanged rows do not prove success or failure. Correlate them with RMAN output, alert-log events, and storage activity. Likewise, a media-recovery completion message does not prove that the database is open or that the intended historical data has been recovered.

Preserve the complete transcript. Some ORA messages identify required redo or suggest a pathname during normal recovery interaction. Others report access failures or files needing additional recovery. Their context determines the next action.

Use cancellation and redo boundaries with evidence

Lesson 7 demonstrated user-managed SQL*Plus recovery with RECOVER DATABASE UNTIL CANCEL. The operator supplies redo and enters CANCEL at the justified stopping point. RMAN has no UNTIL CANCEL clause; an explicit RMAN target is often easier to reproduce when the boundary is already known.

A suggested pathname is not an exhaustive search for the required log. Automatic application does not create missing redo or establish that the resulting state is acceptable. A log reported as no longer needed for that recovery is not automatically disposable under the backup-retention policy.

Lesson 9 used a different example: unavailable sequence 482 in thread 1, with recovery through sequence 481. SET UNTIL SEQUENCE 482 THREAD 1 excludes 482. Reaching that boundary still requires a suitable earlier backup and the necessary recovery information leading to it.

One failed online redo member does not establish loss of the entire group. Check every member, storage access, and other usable recovery sources. Group numbers identify reusable groups, while sequence numbers identify their particular use. RMAN does not back up online redo logs, and creating an empty replacement cannot reconstruct lost committed transactions.

A hung or closed database alone does not determine the remedy. CLEAR LOGFILE reinitializes redo storage under specific conditions; it is not a general fix for lost current redo. Resolve destination problems before the planned RESETLOGS open.

Handle control-file loss without assuming data loss

Lesson 8 distinguished surviving current copies, binary backup control files, and control-file reconstruction scripts. An intact multiplexed current copy may avoid the need for older metadata. A trace script helps recreate structure but is not a binary control-file backup.

When restoring a lost control file, start the instance in NOMOUNT, restore the appropriate backup, then mount it before the subsequent recovery. Backup discovery may require the recorded DBID, location, format, device access, or catalog information. A query against an unavailable mounted control file cannot supply that information.

Older metadata may omit later files, backup records, or incarnation history. Review the recovered structure and catalog genuinely available material where appropriate. Cataloging an existing file records it; cataloging cannot recreate a missing backup or redo log.

Complete recovery may still be possible with a backup control file, but recovery using it requires OPEN RESETLOGS. Therefore, RESETLOGS is not proof that the operation lost committed data. Recreated control files have their own conditions, including documented NORESETLOGS cases.

Understand recovery through RESETLOGS

Lesson 10 explained the difference between having no new backup after RESETLOGS and having no usable starting backup. A second failure may still be recoverable from an eligible parent-incarnation backup when the necessary recovery chain and incarnation history survive.

RESETLOGS creates a new database incarnation and restarts redo sequence numbering. It does not reset database SCNs or the DBID to 1. RMAN can follow the appropriate ancestral history across an earlier RESETLOGS operation; it does not merge an abandoned branch's later changes into the current branch.

Restoring an older backup does not automatically require RESET DATABASE TO INCARNATION. That RMAN command changes the history used to interpret a target and is appropriate for specified earlier-incarnation recovery objectives. Check LIST INCARNATION and V$DATABASE_INCARNATION instead of guessing a key.

After complete recovery through an old RESETLOGS boundary with the current control file, the database can open normally. A new whole-CDB incomplete recovery requires another RESETLOGS. A recovery using a restored backup control file also requires RESETLOGS, even if complete.

Earlier backups are not automatically invalidated, and a new whole-database backup is optional solely because RESETLOGS occurred. A fresh backup can nevertheless shorten later recovery. Preserve older material required by retained backups and evaluate any standby actions according to the actual standby state.

Apply the special rules for tablespace PITR

Lesson 11 recovered an eligible set of application tablespaces in one PDB. The recovery set consists of the selected tablespace data files. The auxiliary set supplies supporting files needed for the temporary database, including required SYSTEM, SYSAUX, undo, control, and redo components.

For the automatic RMAN procedure, connect to the root with the required privileges and do not connect a user-managed auxiliary. Verify ARCHIVELOG mode, backups for the required files, backups of the CDB root and PDB$SEED, recovery history, keys, and sufficient storage.

Check self-containment with DBMS_TTS.TRANSPORT_SET_CHECK and inspect TRANSPORT_SET_VIOLATIONS. Eligibility also depends on restrictions such as the current default tablespace and SYS-owned or undo objects. An empty containment result does not prove business consistency or backup availability.

RMAN takes the selected target tablespaces offline, restores and recovers in the auxiliary, and opens the auxiliary with RESETLOGS. It transports recovered data files and Data Pump metadata back into the target. This does not require opening the target CDB with RESETLOGS.

After successful transport, the recovered tablespaces are left offline. Back them up before bringing them online, validate their data and relationships, and gather fresh optimizer statistics. This backup step follows TSPITR's particular recovery limitations; it is different from the optional whole-database backup after ordinary RESETLOGS.

AUXILIARY DESTINATION stores auxiliary-set files, not necessarily every recovered file. Recovery-set files now belonging to the target must remain. Review the state reached after an error before retrying or removing temporary material.

Verify the business outcome and retain future options

Technical recovery completion, database opening, and application correctness are separate observations. Check the actual CDB and PDB open states, then inspect the intended objects under the correct owner and container. An object existing or a row count matching is insufficient evidence by itself.

Compare representative keys, balances, relationships, and expected transactions with the selected target. RESETLOGS_TIME records the opening event and does not independently prove the historical recovery endpoint. V$DATAFILE_HEADER examines headers rather than every block. V$RECOVER_FILE is not a reliable completion test with a restored control file or one recreated after the relevant media failure.

If recovery stopped too early before the final RESETLOGS, available redo may permit advancement. If it went too far, restore-based recovery generally requires starting again from suitable backups. Preserve evidence and recovery material so that a retry remains possible.

Reconcile excluded work against authoritative records. Payments, messages, and remote databases can retain effects absent from the recovered scope. Blindly replaying transactions risks duplication. Record outstanding reconciliation work, restore damaged redundancy, review backup protection, and test the revised recovery arrangements.

A useful handoff identifies the database and containers recovered, the selected and achieved endpoint, the opening method, and the validation performed. It also records remaining application restrictions and who owns reconciliation. This lets the next operator distinguish a completed technical recovery from a service that is fully ready for normal business activity.

Review the workflow lessons

Use these lesson links to revisit the decisions and examples supporting the module's learning objectives.

Glossary

Incomplete recovery

Recovery to an earlier consistent endpoint that excludes later changes within the selected scope.

Recovery chain

The suitable starting backups and required recovery information that can reach the chosen state.

SCN

System change number, used to identify a position in database change history within the relevant incarnation.

Redo multiplexing

Maintaining multiple members of an online redo group. It complements archived-log protection and backups.

Database incarnation

A branch of database history established by OPEN RESETLOGS.

Recovery set

The selected tablespace data files being returned to an earlier state during TSPITR.

Auxiliary database

A temporary database used to perform recovery work for supported scoped operations.

Incomplete Recovery - Quiz