Oracle DBA Lesson 32A - Choose the Recovery Target Before Restoring Files

Before restoring files, identify what failed, choose the state you need back, and verify every destination the recovery will write. A usable backup supports the plan. The selected scope, recovery target, and isolated write boundary decide whether it can proceed.

Oracle DBA Lesson 32A — Choose the recovery target before restoring files

Match the failure, scope, and target

When files and online redo remain intact after an instance failure, restarting can perform automatic instance recovery. Lost or damaged data files require a media-recovery plan. Select the scope from the actual damage: one file, one PDB, or the whole CDB. Combine that choice with the required consistency point and the outage it creates.

Complete recovery needs the surviving changes through the latest committed work, including required online redo. An earlier SCN or time target excludes later work. A backup that precedes a noon disk failure can still support a complete target: the latest committed state. Returning to before an unwanted transaction means identifying the later valid work that will be lost. Record that business decision before you choose recovery commands.

See instance recovery and complete recovery.

Decide whether the plan can proceed

Evidence	Decision it supports
DBID and recovery records agree	The media and target refer to the intended database.
Previewed pieces are accessible, with required redo and keys	The selected recovery state has a supported media path.
All control, data, redo, archive, and FRA destinations resolve into isolated storage	Recovery writes stay within the approved copy.
An apparent lab path resolves onto source storage	Stop and correct the write boundary before restore.
Named application checks and the approved outage are recorded	The recovery result can be assessed against the business goal.

A different path string can still reach the same mount or disk. Verify the actual storage and service routing with a second person. Do not rely on names alone. See data repair concepts and V$DATABASE.

Practice

This planning part performs no mutation. An instructor must first supply a disposable Oracle 19c single-instance recovery VM, full storage isolation, and a known reset method. Match the source database identity for these drills. A new-identity alternate-host clone needs a separate documented DUPLICATE procedure. Confirm the exact release update, edition, platform, capacity, administrative authorization, file and backup ownership, and independent backup, log, and key survival. Do not share source control, data, redo, FRA, or archive paths, and do not register this copy in the recovery catalog. Keep the signed-off plan outside the VM. A directory rename or a second service alias does not establish isolation.

Connect locally only after the lab identity and OS authentication membership are approved. SQL*Plus administrative inventory may use a confirmed OSDBA identity:

sqlplus / as sysdba

SPOOL lab32a_inventory_01.log
SHOW CON_NAME
SELECT dbid, name, db_unique_name, log_mode, open_mode FROM v$database;
SELECT name FROM v$controlfile;
SELECT file#, name FROM v$datafile ORDER BY file#;
SELECT group#, member FROM v$logfile ORDER BY group#, member;
SHOW PARAMETER control_files
SHOW PARAMETER db_recovery_file_dest
SHOW PARAMETER log_archive_dest
SHOW PARAMETER db_create_file_dest
SPOOL OFF

SHOW is a SQL*Plus client command. These queries return inventory only when they run in the designated lab. Match DBID to independently retained backup and autobackup records. If no control file can be mounted, keep the external DBID and the explicit autobackup records for the later control-file lesson. Do not treat mounted views as available.

Use an approved common SYSBACKUP or SYSDBA operator targeting the same isolated CDB$ROOT. For a locally authenticated account confirmed as OSBACKUPDBA, start the log before connecting:

rman log=lab32a_preview_01.log

CONNECT TARGET "/ AS SYSBACKUP";
REPORT SCHEMA;
LIST BACKUP SUMMARY;
RESTORE DATABASE PREVIEW SUMMARY;
EXIT

EXIT closes the client session. These commands inventory files and select backup metadata. PREVIEW leaves the target data files in place. Match piece handles, channel and media access, encryption-key material if it applies, required redo sequence and SCN continuity, and the target consistency requirement. The preview shown here is a whole-database inventory. A narrower execution must preview the selected scope. This part does not authorize backup deletion, repository cleanup, or a database reset. See RESTORE.

Have a second person trace every resolved control, data, redo, archive, and FRA destination through symlinks, mounts, actual volumes or disk groups, attached storage, and service routing. Include automatic archived-log restoration and any configured OMF locations. Verify that nothing can write to source storage. Record the destination evidence. Do not rely only on the SQL strings. Confirm permissions and headroom for restores and log staging.

Record the incident evidence, the failed component, the chosen file, PDB, or CDB scope, the complete or earlier SCN or time target, the expected legitimate data loss, the DBID and control-file state, the backup handles and readable-media evidence from the backup checks, archived and online redo coverage, key access if it applies, every destination mapping, the signed outage, the stop conditions, and the application identity, data, and availability checks. A missing log or an inaccessible key is an unresolved supportability condition. A path that reaches source storage is a stop, even when the media are usable. Go requires a second person's isolation review and a supported target. Lab acceptance stays pending because no database commands were executed in this write-up.

Recap

Choose the affected scope and target state, approve the expected loss and downtime, verify every write destination, and reconcile the required media, redo, and application checks before recovery begins.

Quiz

1. After an instance failure, files and online redo remain intact. Which path may restore service?

Logical import of every object Opening with RESETLOGS before diagnosis Restart with automatic instance recovery Deleting the current control file

2. What distinguishes an earlier SCN or time target from complete recovery?

It deliberately excludes later work, including legitimate changes after the target It always preserves every later commit It removes the need for redo It makes file locations irrelevant

3. Does a valid backup make RESTORE safe on any host?

Yes. RMAN automatically isolates every source path Yes. A different directory name proves isolation Yes. Matching DBID proves storage independence No. Verify all target write destinations and storage isolation first

4. What does RESTORE DATABASE PREVIEW SUMMARY provide?

A completed restore Metadata-based selection of pieces to reconcile with real media and required redo Application acceptance Automatic correction of source-storage mappings

5. The preview selects usable media, but a data-file path reaches source storage. What is the decision?

Proceed because the backup is valid Change only the service alias Stop until the write boundary is resolved and independently verified Remove all backup records

Names, paths, and expected results in this lesson are teaching examples. Run the practice in the designated Oracle Database 19c lab, confirm the exact release update, and record what you actually observe.

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro