Why COMMIT is much faster than ROLLBACK

COMMIT and ROLLBACK have fundamentally different internal behaviors. COMMIT is typically very fast because SQL Server does not need to revisit or reverse modified rows. It only writes a commit log record, flushes the transaction log according to the Write-Ahead Logging protocol, marks the transaction as committed, and releases locks. ROLLBACK, on the other hand, is an active undo process. SQL Server traverses the transaction log backwards, reverses every data modification, updates affected pages and indexes, and writes compensation log records to track the undo operation. Because rollback must process every change made by the transaction, its duration is proportional to the amount of work being undone. A transaction that modifies millions of rows may commit in milliseconds but require minutes or hours to roll back. This distinction is critical in production environments because long-running transactions can create long-running rollbacks, block other sessions, and consume significant transaction log space. Understanding this behavior is essential when designing ETL processes, bulk operations, and error-handling strategies in SQL Server.

We are thing that COMMIT do Save Data and ROLLBACK don't Save Data and therefore both should take similar time but we are wrong. Internally they are completely different operations.

COMMIT SQL Server mainly needs to:

Ø  Generate COMMIT record

Ø  Flush log to disk

Ø  Mark transaction committed

Ø  Release locks

That's it. No data reversal. No row-by-row processing.

Rollback starts SQL Server mainly needs to:

Ø  Find every log record

Ø  Read log backwards

Ø  Undo each modification

Ø  Generate undo records

Ø  Update pages

Ø  Update indexes

Ø  Release locks

Much more work.

For example, in the transaction if we updating the 10 million record it may take few second for the commit but when we rollback this transaction it took several minutes.