Encyclopedia of Database Systems

2009 Edition

Crash Recovery

  • Theo Härder
Reference work entry
DOI: https://doi.org/10.1007/978-0-387-39940-9_88



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. Because DBMS restart may take too long to be masked for the user, a denial of service can 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 of time the backup copies were created. Archive recovery usually causes much longer outages than system...

This is a preview of subscription content, log in to check access.

Recommended Reading

  1. 1.
    Bernstein P.A., Hadzilacos V., and Goodman N. Concurrency Control and Recovery in Database Systems. Addison-Wesley, Reading, MA, 1987.Google Scholar
  2. 2.
    Davies C.T. Data processing spheres of control. IBM Syst. J., 17(2):179–198, 1978.CrossRefGoogle Scholar
  3. 3.
    Gray H. and Reuter A. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, San Francisco, CA, 1993.zbMATHGoogle Scholar
  4. 4.
    Gray J., McJones P., Blasgen M., Lindsay B., Lorie R., Price T., Putzolu F., and Traiger I.L. The recovery manager of the System R database manager. ACM Comput. Surv., 13(2):223–242, 1981.CrossRefGoogle Scholar
  5. 5.
    Gray J, Michael J. Feynn, Jim Gray, Anita K. Jones, Klans Lagally, Holger Opderbeck, Gerald J. Popek, Brian Randell, Jerome H. Saltfer, Hans-Rüdiger Wiehle. Notes on database operating systems. In Operating Systems: An Advanced Course. Springer, LNCS 60, 1978, pp. 393–481.Google Scholar
  6. 6.
    Härder T. DBMS Architecture – Still an Open Problem. In Proc. German National Database Conference, 2005, pp. 2–28.Google Scholar
  7. 7.
    Härder T. and Reuter A. Principles of transaction-oriented database recovery. ACM Comput. Surv., 15(4):287–317, 1983.CrossRefGoogle Scholar
  8. 8.
    Mohan C., Haderle D.J., Lindsay B.G., Pirahesh H., and Schwarz P.M.1992. ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging. ACM Trans. Database Syst., 17(1):94–162,CrossRefGoogle Scholar
  9. 9.
    Reuter A. Fehlerbehandlung in Datenbanksystemen. Carl Hanser, Munich, p. 456.1981,Google Scholar
  10. 10.
    Stonebraker M., Madden S., Abadi D.J., Harizopoulos S., Hachem N., and Helland P. The End of an Architectural Era (It’s Time for a Complete Rewrite). In Proc. 33rd Int. Conf. on Very Large Data Bases, 2007, pp. 1150–1160.Google Scholar
  11. 11.
    Weikum G. and Vossen G. Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery. Morgan Kaufmann, San Francisco, CA, 2002.Google Scholar

Copyright information

© Springer Science+Business Media, LLC 2009

Authors and Affiliations

  • Theo Härder
    • 1
  1. 1.University of KaiserslauternKaiserslauternGermany