In working on my Preparation for Disaster presentation and doing research, one of the questions that came up early for me was “what is a disaster?” After all, if you can’t answer that question, how do you prepare for it.
I’ve got a list of stuff here, which ones of these qualify as disasters?
- Hard Drive crash
- Hurricane wrecks data center
- Fire in the server room
- Corruption in a clustered index
- DBA deletes a table by running DELETE without a WHERE clause
- User clicks submit on a web page and the database crashed before they get the acknowledgement
- Admin uses Access to update and lock a table, and forgets to save their work before leaving for lunch
- DBA deploys code to production instead of development by accident.
The answer is all of these are disasters. Most people seem to plan for the first 3, and forget to plan for the rest.
Anything that interrupts your system’s ability to serve clients and get work done is a disaster. It’s worth keeping that in mind and planning for all sorts of potential problems. It doesn’t mean you have to be ultra paranoid, but you ought to have thought about the various potential problems and have some ideas about how to deal with them.


Pingback: T-SQL Tuesday #19 – Data Disasters | The Lone DBA