Durability (database systems)

In database systems, durability is the ACID property that guarantees that the effects of transactions that have been committed will survive permanently, even in cases of failures,[1] including incidents and catastrophic events.

[1] Thus, to be durable, the database system should implement strategies and operations that guarantee that the effects of transactions that have been committed before the failure will survive the event (even by reconstruction), while the changes of incomplete transactions, which have not been committed yet at the time of failure, will be reverted and will not affect the state of the database system.

[4] Specifically, a reliability mechanism requires primitives that explicitly state the beginning, the end, and the rollback of transactions,[1] which are also implied for the other two aforementioned properties.

[1] There exist multiple approaches that keep track of the history of changes, such as timestamp-based solutions[5] or logging and locking.

Thanks to their atomicity property, the transactions can be considered the unit of work in the recovery process that guarantees durability while exploiting the log.

Non-committed transactions, instead, are recoverable, since their operations are logged to non-volatile storage before they effectively modify the state of the database.

Therefore, the transaction log from non-volatile storage can be reprocessed to recreate the system state right before any later system-level failure.

[4] Many tools and technologies are available to provide a logical stable memory, such as the mirroring of disks, and their choice depends on the requirements of the specific applications.

[4] In general, replication and redundancy strategies and architectures that behave like stable memory are available at different levels of the technology stack.

[12] In distributed transactions, ensuring durability requires additional mechanisms to preserve a consistent state sequence across all database nodes.

Otherwise, in case of failure, if consistency could not be guaranteed, it would be impossible to acknowledge a safe state of the database for recovery.