Encyclopedia of Database Systems

Living Edition
| Editors: Ling Liu, M. Tamer Özsu

Crash Recovery

Living reference work entry
DOI: https://doi.org/10.1007/978-1-4899-7993-3_88-2



In contrast to transaction aborts, a crash is typically a major failure by which the state of the current database is lost or parts of storage media are unrecoverable (destroyed). Based on log data from a stable log, also called temporary log file, and the inconsistent and/or outdated state of the permanent database, system recovery has to reconstruct the most recent transaction-consistent database state. To limit the amount of redo steps after a crash, some form of periodic checkpointing is mandatory. Nevertheless, DBMS restart may take too long to be masked for the user; hence, a denial of service may be observed. Recovery from media failures relies on the availability of (several) backup or archive copies of earlier DB states – organized according to the generation principle – and archive logs (often duplexed) covering the processing intervals from the points...


Data Page Commit Transaction Dirty Data Crash Recovery Forward Recovery 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.
This is a preview of subscription content, log in to check access.

Recommended Reading

  1. 1.
    Bernstein PA, Hadzilacos V, Goodman N. Concurrency control and recovery in database systems. Reading: Addison-Wesley; 1987.Google Scholar
  2. 2.
    Davies CT. Data processing spheres of control. IBM Syst J. 1978;17(2):179–98.CrossRefGoogle Scholar
  3. 3.
    Graefe G, Kuno HA. Definition, detection, and recovery of single-page failures, a fourth class of database failures. PVLDB. 2012;5(7):646–55.Google Scholar
  4. 4.
    Gray J, Reuter A. Transaction processing: concepts and techniques. San Francisco: Morgan Kaufmann; 1993.MATHGoogle Scholar
  5. 5.
    Gray J, McJones P, Blasgen M, Lindsay B, Lorie R, Price T, Putzolu F, Traiger IL. The recovery manager of the System R database manager. ACM Comput Surv. 1981;13(2):223–42.CrossRefGoogle Scholar
  6. 6.
    Gray J. Notes on data base operating systems. Advanced course: operating systems. Berlin: Springer; 1978. p. 393–481. LNCS 60.Google Scholar
  7. 7.
    Härder T. DBMS architecture – still an open problem. In: Proc. German National Database Conference, 2005, pp. 2–28.Google Scholar
  8. 8.
    Härder T, Reuter A. Principles of transaction-oriented database recovery. ACM Comput Surv. 1983;15(4):287–317.MathSciNetCrossRefGoogle Scholar
  9. 9.
    Hvasshovd S-O. Recovery in parallel database systems. 2nd ed. Burlington: Morgan Kaufmann; 1999.CrossRefMATHGoogle Scholar
  10. 10.
    Mohan C, Haderle DJ, Lindsay BG, Pirahesh H, Schwarz PM. ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Trans Database Syst. 1992;17(1):94–162.CrossRefGoogle Scholar
  11. 11.
    Pelley S, Wenisch TF, Gold BT, Bridge B. Storage management in the NVRAM era. PVLDB. 2013;7(2):121–32.Google Scholar
  12. 12.
    Reuter A. Fehlerbehandlung in Datenbanksystemen. Munich: Carl Hanser; 1981. p. 456.Google Scholar
  13. 13.
    Sauer C, Graefe G, Härder T. An empirical analysis of database recovery costs. In: Proc. Sigmod Workshops: RDSS, 2014.Google Scholar
  14. 14.
    Sauer C, Härder T. A simple recovery mechanism enabling fine-granular locking and fast, REDO-only recovery. CoRR abs/1409.3682, 2014.Google Scholar
  15. 15.
    Weikum G, Vossen G. Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery. San Francisco: Morgan Kaufmann; 2002.Google Scholar

Copyright information

© Springer Science+Business Media New York 2016

Authors and Affiliations

  1. 1.University of KaiserslauternKaiserslauternGermany