In the world of Oracle, the COMMIT command is a sacred moment. It is the point where a transaction transitions from "tentative" to "permanent."

To a user, a commit feels instantaneous. But internally, Oracle is performing a high-speed "handshake" between memory and disk to ensure that even if the building loses power one millisecond later, your data is safe.

1. The "Fast Commit" Philosophy

Before we look at the steps, you must understand one rule: Oracle does not write data blocks to the Data Files during a commit. Writing a 2GB table update to a data file is slow. Instead, Oracle uses Write-Ahead Logging. It only writes the record of the change (Redo) to the disk. This is why a commit is so fast.

2. The Internal Chain Reaction

When you type COMMIT; and hit enter, the following four things happen in rapid succession:

Step A: Generating the SCN (System Change Number)

Oracle assigns a unique, ever-increasing number to your transaction called an SCN. Think of this as a precise timestamp. This SCN is the "official" mark that your transaction is now part of the database's history.

Step B: LGWR Flushes the Redo Log Buffer

The Log Writer (LGWR) process immediately wakes up. It grabs all the redo entries for your transaction from the Redo Log Buffer (in RAM) and writes them to the Online Redo Log Files (on Disk).

• Crucial Point: The user's session hangs (waits) until LGWR confirms the write to disk is complete. This is the only physical I/O that must happen for a commit to succeed.

Step C: Releasing Locks

During your transaction, you likely had "locks" on certain rows (preventing others from changing them). Now that the SCN is assigned and the logs are on disk, Oracle releases these locks. Other users who were waiting to update those same rows can now proceed.

Step D: Marking the Undo as "Complete"

The Undo Segments (which stored the "old" version of your data in case you wanted to ROLLBACK) are marked as inactive. Oracle doesn't delete them immediately, but it notes that the space can be reused by other transactions later.

3. What about the actual Data Files?

Notice that the Database Writer (DBWn) hasn't done anything yet. The updated rows are still sitting in the Database Buffer Cache (RAM).

Eventually (seconds or minutes later), DBWn will lazily write those "dirty" blocks to the physical Data Files.

• If the system crashes before DBWn writes: Don't worry! Upon restart, SMON will read the Redo Logs (written by LGWR at commit time) and "replay" your changes into the data files.

Summary Table: The Commit Lifecycle

The "Commit Cleanout"

Interestingly, Oracle also performs a "cleanout" where it goes back to the data blocks in memory and clears the "lock" bits on the headers. If the data blocks were already pushed out of memory, the next user who reads them will perform a "delayed block cleanout."