Oracle RMAN Recovery Runbook: Restore, Recover, Prove It

The worst day of an Oracle DBA's career is a restore they've never rehearsed. A datafile is gone, or a DELETE ran without a WHERE, or a storage array quietly corrupted a handful of blocks — and now the only thing between you and a résumé-updating outage is a backup you hope works and a procedure you think you remember.

This is the runbook for that day. It rests on one distinction most people fumble under pressure —

restore is not recover — and it maps each failure to the specific commands that fix it, from a single

corrupt block to a whole database rewound to the second before someone's mistake. Everything targets

Oracle 19c, with notes for 23ai/26ai.

The short version. RESTORE copies datafiles back from your backups; RECOVER rolls them forward by applying redo. Most recoveries are RESTORE DATABASE then RECOVER DATABASE.

To rewind past a human error, use point-in-time recovery: SET UNTIL (time or SCN) at the top of a RUN block, then restore, recover, and OPEN RESETLOGS. For a few bad blocks, block media recovery fixes just those without touching the datafile. Lost the controlfile? NOMOUNT, SET DBID, RESTORE CONTROLFILE FROM AUTOBACKUP. And the rule under all of it: an untested backup is a hope, not a recovery plan.

Restore vs recover — the distinction that saves you

Two verbs, two completely different actions, and confusing them is how people make a bad day worse:

• 
  RESTORE copies datafiles back from your backups. It rewinds those files to whenever the backup was
  taken.


• 
  RECOVER takes those restored files and rolls them forward by applying archived and online redo —
  either all the way to the present, or to a point in time you choose.

You almost never restore alone; a restore on its own throws away every transaction since the backup. The

normal shape of a recovery is restore, then recover:

RMAN> RESTORE DATABASE;    -- copy datafiles back from the most recent backup

RMAN> RECOVER DATABASE;    -- apply redo to roll them forward to now

RMAN> ALTER DATABASE OPEN;

Hold that pair in your head — everything below is a variation on which files you restore and how far

you recover.

The failure → action map

You don't run the same command for a single corrupt block as for a lost database. Match the failure to

the smallest recovery that fixes it — that's what keeps your outage small:

One datafile, without taking the database down

The best-case recovery, and the most common in real life: a single datafile or tablespace is lost while the rest of the database keeps serving. Take just that datafile offline, restore and recover it, bring it back — users on every other tablespace never notice.

RMAN> ALTER DATABASE DATAFILE 7 OFFLINE;

RMAN> RESTORE DATAFILE 7;

RMAN> RECOVER DATAFILE 7;

RMAN> ALTER DATABASE DATAFILE 7 ONLINE;

(Swap DATAFILE 7 for TABLESPACE users to work at the tablespace level.) This is why restore speed matters more than most teams think — the typical recovery is one file, not the whole estate.

The whole database: restore then recover

If the database is down — many files lost, or you're rebuilding on fresh hardware — mount it and run the pair against everything:

RMAN> STARTUP MOUNT;

RMAN> RESTORE DATABASE;

RMAN> RECOVER DATABASE;

RMAN> ALTER DATABASE OPEN;

This is complete recovery: every committed transaction, right up to the moment of failure, is back.

No RESETLOGS needed, because you recovered all the way to the present — the redo timeline is unbroken.

Rewinding past a bad DELETE: point-in-time recovery

Complete recovery brings you back to now — which is useless when now already contains the problem: a DELETE without a WHERE, a bad release, a truncated table that committed an hour ago. For that you need incomplete recovery — stop applying redo just before the mistake.

Here's the rule that catches people out: SET UNTIL goes at the top of a RUN block, before both RESTORE and RECOVER. Set it only before RECOVER and your restored files may already carry

timestamps past your target, and RMAN can't rewind them.

RMAN> RUN {

  SET UNTIL TIME "TO_DATE('2026-07-19 14:29:00','YYYY-MM-DD HH24:MI:SS')";

  RESTORE DATABASE;

  RECOVER DATABASE;

}

RMAN> ALTER DATABASE OPEN RESETLOGS;

You can target a time, an exact SCN (SET UNTIL SCN 12345678 — no ambiguity about "which 14:29"), a log sequence, or a named restore point. When you know the SCN of the damage, use it — it's precise where a timestamp can be a second off in either direction.

OPEN RESETLOGS is mandatory after any incomplete recovery. It resets the online redo logs and starts a new database incarnation — a fresh redo timeline branching off the old one. Two consequences worth internalizing: take a full backup immediately afterward (your old backups now belong to a previous

incarnation), and know that RMAN can still navigate incarnations if you ever need to go back further.

Two faster paths when they apply:

• 
  Flashback Database (if you enabled it) rewinds the entire database in minutes with no restore at all — FLASHBACK DATABASE TO SCN 12345678;. It's the first thing to reach for on a logical error, and it's exactly why [The Oracle HA Decision Tree] .
  
  
  

  
  

  Practice this before you need it. The . I write here in a personal capacity — questions or feedback are welcome via the contact page.

  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen