Editing Durability (database systems) (section)

=== System level ===
At system level, failures happen, by definition,<ref name=":1" /> when the contents of the volatile storage are lost. This can occur in events like system crashes or [[Power outage|power outages]]. Existing database systems use volatile storage (i.e. the [[Computer memory|main memory]] of the system) for different purposes: some store their whole state and data in it, even without any durability guarantee; others keep the state and the data, or part of them, in memory, but also use the [[non-volatile storage]] for data; other systems only keep the state in main memory, while keeping all the data on disk.<ref>{{Cite book |last=Petrov |first=Oleksandr |title=Database internals: a deep dive into how distributed data systems work |date=2019 |publisher=O'Reilly |isbn=978-1-4920-4034-7 |edition=1st |location=Beijing Boston Farnham Sebastopol Tokyo |pages=40–42}}</ref> The reason behind the choice of having volatile storage, which is subject to this type of failure, and non-volatile storage, is found in the performance differences of the existing technologies that are used to implement these kinds of storage. However, the situation is likely to evolve as the popularity of [[Non Volatile Memory Express|non-volatile memories (NVM)]] technologies grows.<ref>{{Cite book |last1=Arulraj |first1=Joy |last2=Pavlo |first2=Andrew |title=Proceedings of the 2017 ACM International Conference on Management of Data |chapter=How to Build a Non-Volatile Memory Database Management System |date=2017-05-09 |chapter-url=https://dl.acm.org/doi/10.1145/3035918.3054780 |series=SIGMOD '17 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1753–1758 |doi=10.1145/3035918.3054780 |isbn=978-1-4503-4197-4|s2cid=648876 }}</ref>

In systems that include non-volatile storage, durability can be achieved by keeping and flushing an immutable sequential [[Transaction log|log of the transactions]] to such non-volatile storage before acknowledging commitment. Thanks to their atomicity property, the transactions can be considered the unit of work in the [[Data recovery|recovery]] process that guarantees durability while exploiting the log. In particular, the logging mechanism is called [[Write-ahead logging|write-ahead log (WAL)]] and allows durability by buffering changes to the disk before they are synchronized from the main memory. In this way, by reconstruction from the log file, all committed transactions are resilient to system-level failures, because they can be redone. Non-committed transactions, instead, are recoverable, since their operations are logged to non-volatile storage before they effectively modify the state of the database.<ref name=":3">{{Cite book |last=Petrov |first=Oleksandr |title=Database internals: a deep dive into how distributed data systems work |date=2019 |publisher=O'Reilly |isbn=978-1-4920-4034-7 |edition=1st |location=Beijing Boston Farnham Sebastopol Tokyo |pages=185–195}}</ref> In this way, the partially executed operations can be undone without affecting the state of the system. After that, those transactions that were incomplete can be redone. Therefore, the transaction log from non-volatile storage can be reprocessed to recreate the system state right before any later system-level failure. Logging is done as a combination of tracking data and operations (i.e. transactions) for performance reasons.<ref>{{Cite journal |last1=Mohan |first1=C. |last2=Haderle |first2=Don |last3=Lindsay |first3=Bruce |last4=Pirahesh |first4=Hamid |last5=Schwarz |first5=Peter |date=1992-03-01 |title=ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging |journal=ACM Transactions on Database Systems |volume=17 |issue=1 |pages=94–162 |doi=10.1145/128765.128770 |s2cid=8759704 |issn=0362-5915|doi-access=free }}</ref>