Summary

The recovery cycle begins with the backup of the databases. The ability to survive hardware failure or human error is crucial to the ACID properties of a database. Without the transaction's durability, the database can't be fully trusted. Because of this, recovery planning and the transaction log provide durability to committed transactions. The recovery cycle transfers data from the past to the present.

They key take-away points from this chapter include the following:

  • Invest the time to create a solid backup and recovery plan.
  • Just performing regular backups is not enough. Because the only way to know that the backups are good is by restoring the backups, regularly restore the backups on a test server. This is a boring task but well worth it when a disaster occurs and you need to recover from the backups.
  • A senior SQL DBA must create the backup and recovery plan to ensure that all aspects are taken care of. When the plan is ready, ascertain that the junior DBA can understand it and can perform all the steps in the plan because they will likely be the ones recovering from the backups in the middle of the night when a disaster occurs.
  • Perform a complete recovery to simulate a server and disk subsystem failure at least every 6 months, and update your backup/recovery plan as required.

In the next chapter, you learn how to maintain the database.

Get Microsoft SQL Server 2012 Bible now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.