How does Oracle handle crash recovery?
When a server loses power or the Oracle Instance crashes, the memory (SGA) vanishes instantly. However, thanks to Oracle’s Crash Recovery mechanism, your data remains consistent and protected.
The hero of this story is the SMON (System Monitor) process, which uses a two-step process often called "Roll Forward, Roll Back."
Oracle can recover because it follows the Write-Ahead Logging (WAL) protocol.
As we discussed in the LGWR architecture, every change you made was recorded in the Redo Logs on disk before the change was even finalized in the data files.
Therefore, the Redo Logs contain a perfect "play-by-play" of everything that happened right up until the crash.
When you turn the database back on, the SMON process looks at the Control File and notices that the "Checkpoint" SCN (System Change Number) doesn't match the SCN in the headers of the Data Files. It realizes a crash occurred.
Reading the Logs: SMON reads the Online Redo Logs.
Replaying History: It applies all changes found in the logs to the data blocks in memory.
The Result: At the end of this stage, the database is exactly as it was at the microsecond of the crash. This includes both committed and uncommitted data.
Now the database is "current," but it’s "dirty." It contains changes from users who were in the middle of a transaction when the power went out. These users never hit COMMIT, so their data shouldn't be there.
Identifying "In-Flight" Transactions: SMON looks at the Undo Segments (which were also recovered during the Roll Forward).
Undo the Work: It identifies any transaction that didn't have a "Commit" marker and uses the Undo data to reverse those changes.
The Result: The database is now logically consistent. Only committed data remains.
One of the coolest features of Oracle is that it doesn't make you wait for Step 2 to finish!
As soon as Step 1 (Roll Forward) is complete, Oracle Opens the database for users.
Step 2 (Roll Back) happens in the background. If a user tries to access a row that is still waiting to be rolled back, Oracle will prioritize rolling back that specific row so the user can see the correct data immediately. This is called Fast-Start Fault Recovery.
| Phase | Action | Purpose |
| Detection | SMON checks Control Files vs. Data Files. | Identifies that a crash happened. |
| Roll Forward | Applies Redo Logs to Data Files. | Recovers all changes (Committed & Uncommitted). |
| Open | Database becomes available to users. | Minimizes downtime. |
| Roll Back | Uses Undo Segments to reverse uncommitted work. | Ensures logical consistency. |
You can actually tell Oracle how fast you want it to recover using the FAST_START_MTTR_TARGET parameter (MTTR stands for Mean Time To Recover).
Lower Value: Oracle performs "Checkpoints" (disk writes) more frequently. Recovery will be fast, but the database works harder during normal operation.
Higher Value: Less frequent disk writes. Performance is better during the day, but recovery after a crash will take longer.
Peer Tip: If your database takes a long time to start up after a crash, it's usually because your Redo Logs are very large and your Checkpoints are too infrequent.