Master in Oracle Cloud (OCI) | Join us for the demo session on 2nd December 2025 at 7:00 PM IST

How Oracle Performs Crash Recovery – Internals Explained

Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
  • User AvatarPradip
  • 03 Dec, 2025
  • 0 Comments
  • 3 Mins Read

How Oracle Performs Crash Recovery – Internals Explained

Crash recovery is one of the most critical capabilities of the Oracle Database. Whether due to a power failure, OS crash, node reboot, or instance failure, Oracle ensures your data remains consistent, durable, and reliable.


What Is Crash Recovery?

Crash recovery is the automatic process Oracle performs when an instance fails abruptly. Its goal is:

  • To roll forward all committed changes that were not yet written to datafiles.

  • To roll back any uncommitted transactions left in the system.

It ensures the database is brought back to a consistent state, even if the crash happened mid-transaction.

Crash recovery runs automatically during instance startup (Mount phase → Open).


Why Is Crash Recovery Needed?

During normal operation:

  • Transactions generate redo records.

  • Redo is written to redo logs immediately (LGWR).

  • Dirty buffers in memory are written to datafiles later (DBWn).

Since LGWR works faster than DBWn, some committed changes might still be only in the buffer cache when a crash occurs.

So after a crash, the datafiles may not have the latest committed data → this requires REDO (roll forward).

Also, uncommitted changes may exist in the datafiles → this requires UNDO (rollback).


Internal Components Involved in Crash Recovery

Crash recovery depends on three major structures:

1. Redo Logs

Contain a sequential record of all database changes.

2. Undo Segments

Help reverse changes of uncommitted transactions.

3. Data Buffer Cache

Stores dirty blocks not yet written to datafiles.

Oracle uses these to rebuild the database to a consistent state.


How Oracle Performs Crash Recovery (Internals Step-by-Step)

Crash recovery involves two phases:


Phase 1 — Roll Forward (REDO Phase)

Oracle applies all changes recorded in redo logs after the last checkpoint.

Steps:

  1. Identify the checkpoint SCN (System Change Number).

  2. Read redo log files (online redo + possibly archived redo).

  3. Apply all changes from redo to data blocks:

    • Even committed changes not written to datafiles

    • Even some uncommitted updates—these will be rolled back later

  4. Update datafiles to reflect the latest consistent state.

Goal: Bring datafiles “forward in time” to the moment just before the crash.


Phase 2 — Roll Back (UNDO Phase)

After roll-forward, some blocks belong to uncommitted transactions (because Oracle replays redo of all transactions).

Steps:

  1. Identify all transactions that were active and uncommitted during the crash.

  2. Read undo records for those transactions.

  3. Reverse their changes (using undo blocks).

  4. Finalize rollback and mark transactions as aborted.

Goal: Restore transactional consistency.


Important Point:

Crash recovery never replays uncommitted transactions as committed.
Oracle uses transaction tables in undo segments to determine commit status.


How Long Does Crash Recovery Take?

Crash recovery time depends on:

  • Fast-start MTTR Target (primary tunable parameter)

  • Volume of redo generated after the last checkpoint

  • Buffer cache size

  • I/O performance

Setting:

FAST_START_MTTR_TARGET=<seconds>

Helps guarantee predictable crash recovery time.


Example Scenario (Easy to Understand)

Suppose:

  • A user commits data at 12:01

  • LGWR writes redo at 12:01:01

  • DBWn has not yet written blocks to datafiles

  • Crash happens at 12:01:05

During recovery:

Roll Forward

Redo log says:

Block X was updated and transaction committed
Oracle applies redo → block updated

Roll Back

If another transaction was uncommitted:
Oracle uses undo to reverse its partial changes.

This restores ACID compliance.


Automatic vs. Media Recovery

Crash recovery = uses redo logs only (no backups required)

Media recovery = requires datafile restore + archived redo logs

Crash recovery happens automatically during STARTUP.


How to Monitor Crash Recovery

During startup, the alert log shows:

  • Roll forward start/end

  • Roll back start/end

  • Recovery SCN

  • Number of transactions processed

  • Estimated MTTR

Sample alert log snippet:

Instance recovery: rolling forward...
Rolling forward transaction 9, 10, 11
Completed crash recovery at SCN 2847582
Cleanout transactions...
Instance opened

Key Internals Summary

Component Role in Crash Recovery
Redo logs Reapply committed changes (roll forward)
Undo segments Undo uncommitted transactions (rollback)
SCN Determines consistency point
Checkpoint Reduces crash recovery time
FAST_START_MTTR_TARGET Controls recovery speed

Final Takeaway

Oracle crash recovery is powerful, fast, and completely automatic.
It guarantees:

  • No loss of committed data

  • Removal of any uncommitted changes

  • Quick restore of database consistency

This robust mechanism is one of the biggest reasons Oracle is trusted in mission-critical environments.

Explore more with Learnomate Technologies!

Want to see how we teach?
Head over to our YouTube channel for insights, tutorials, and tech breakdowns:
👉 www.youtube.com/@learnomate

To know more about our courses, offerings, and team:
Visit our official website:
👉 www.learnomate.org

Interested in mastering Oracle Database Administration?
Check out our comprehensive Oracle DBA Training program here:
👉https://learnomate.org/oracle-dba-training/ 

Want to explore more tech topics?
Check out our detailed blog posts here:
👉 https://learnomate.org/blogs/

And hey, I’d love to stay connected with you personally!
🔗 Let’s connect on LinkedIn: Ankush Thavali

Happy learning!

Ankush😎

Let's Talk

Find your desired career path with us!

Let's Talk

Find your desired career path with us!