Why Oracle Performs Crash Recovery Before Rollback: Understanding Instance Recovery

Instance Recovery Overview

When an Oracle database is terminated without a clean shutdown (e.g., power loss or SHUTDOWN ABORT), the next startup automatically performs instance recovery. No manual intervention is required.

SCN Checkpoints and Their Locations

During a clean shutdown ( SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE) Oracle writes the current System Change Number (SCN) to four places:

SYSTEM CHECKPOINT SCN – stored in the control file.

Datafile checkpoint SCN – stored in the control file.

STOP SCN – stored in the control file; set only when the instance is closed cleanly.

START SCN – stored in each datafile header.

After a clean shutdown the three SCNs in the control file and the START SCN in the datafile header are identical, and the STOP SCN is reset to NULL. If the shutdown is abnormal, STOP SCN remains NULL and the SCNs may diverge.

When Recovery Is Required

If STOP SCN = NULL → crash recovery (instance recovery) is required.

If START SCN in a datafile header ≠ DATAFILE SCN stored in the control file → media recovery is required.

Step‑by‑Step Crash Recovery Process

SMON reads the END SCN field for each online datafile from the control file. When the database was shut down cleanly, END SCN contains the checkpoint SCN; after an abnormal shutdown it stays NULL.

SMON obtains the checkpoint position from the redo log files (online redo logs).

SMON forward rolls – it applies every redo entry from the checkpoint forward, reconstructing the buffer cache to the exact state at the moment of the crash.

The database is opened while the buffer cache still holds dirty blocks from uncommitted transactions.

SMON launches a background rollback. If a user requests a block before the rollback finishes, the server process rolls back that block on‑the‑fly before returning the data.

Why Forward Roll Before Rollback?

Undo information resides in the UNDO tablespace, which is stored in datafiles that may be lost during a crash. By first applying redo, SMON restores the UNDO segments (and any other dirty blocks) so that the subsequent rollback can safely use the recovered undo data. This two‑phase approach guarantees consistency:

Redo records every change to the database, including changes to the UNDO tablespace.

Undo is applied only after the redo‑based reconstruction, ensuring that the undo blocks themselves are present.

Key Points

The forward‑roll step brings the buffer cache back to the pre‑crash state by replaying redo.

The rollback step cleans up transactions that were active at the time of the crash but never committed.

The presence of NULL in STOP SCN (or END SCN) is the primary indicator that instance recovery is needed.