Encyclopedia of Database Systems

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

Crash Recovery

  • Theo HärderEmail author
Reference work entry
DOI: https://doi.org/10.1007/978-1-4614-8265-9_88


Backward recovery; Failure handling; Media recovery; Online recovery; Restart processing; System recovery


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...

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. Proc VLDB Endowment; 2012;5(7):646–55.CrossRefGoogle Scholar
  4. 4.
    Gray J, Reuter A. Transaction processing: concepts and techniques. San Francisco: Morgan Kaufmann; 1993.zbMATHGoogle 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: Proceedings of the German National Database Conference; 2005. p. 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.zbMATHCrossRefGoogle 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. Proc VLDB Endowment; 2013;7(2):121–32.CrossRefGoogle 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: Proceedings of the 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, LLC, part of Springer Nature 2018

Authors and Affiliations

  1. 1.University of KaiserslauternKaiserslauternGermany

Section editors and affiliations

  • Gottfried Vossen
    • 1
  1. 1.Dep. of Inf. SystemsWestf. Wilhelms-UniveristätMünsterGermany