Since all actions within a transaction are idempotent in crash recovery algorithms like ARIES that use write-ahead logging why do we rollback after a crash during an uncommitted transaction to get back to consistent state rather than just re-doing the entire transaction?

This way we would complete the transaction and we don't need to deal with any undo.


Community wiki answer - please edit to add your contribution:

Generally speaking, there is no guarantee that an uncommitted transaction had actually completed everything it needed to do.

A transaction that withdrew $100 from BankA, but has not deposited the money in BankB is an uncommitted transaction. If a crash occurred between those two processes, there is no way to tell what to redo because we didn't even get to the deposit part of the transaction which could also involve other calculations and updates.

An external application begins a transaction in code and runs several updates, inserts and deletes within that transaction. Somewhere in the middle of that transaction, the server crashes. Now, even if the database could replay and harden all of the updates that had happened up until the crash, how would the application know where to restart in its logic?

In a complete undo, you simply start the external application back at the beginning. The absolute safest way to deal with uncommitted transactions during crash recovery is to roll it back as if it had never occurred.

Atomicity - Transactions are often composed of multiple statements. Atomicity guarantees that each transaction is treated as a single "unit", which either succeeds completely, or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in each and every situation, including power failures, errors and crashes.

In a properly-implemented ARIES - Crash recovery will start from a checkpoint (stored in master record), then it will need to figure out which transactions committed since checkpoint and which failed , then redo all actions and then UNDO effects of failed Transactions. See the answer to What happens when a DBMS crash during the recovery phase of ARIES algorithms? by Remus Rusanu.

Also, remember that during crash "the contents stored in memory (RAM) are assumed to be corrupted or lost" so they have to be rolled back. Only the ones that are written to disk are valid / stable.


It is because an uncommitted transaction by definition did not have all of the logs written out, yet the dirty pages related to the log may have been flushed to disk. Thus, we must undo those changes. In order to undo the changes, we have to redo first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.