Support issues can happen at any time of the day or night, but usually at night.

After reading this chapter, you should develop a highly refined sense of empathy for your coworkers, or you will want to stab them in the leg with a pen more than ever.

Nobody will like it if you are right all the time. And everyone is going to want you to be right all the time. Good luck reconciling those two items.

People will always tend to blame something they are aware of but do not fully understand.

No one knows what you really do, not even your boss. They only know what you do not do, or to be more precise, they only remember your failures and easily forget all your success.

When issues arise, and issues will always arise, people will start to blame the pieces of their environment they know the least about.

All of that holds true for DR preparation. You need to practice and keep your skills sharp. When was the last time you tried to recover the master database? Or, better yet, have you ever tried to recover the master database? Believe me, when the pressure is on during a disaster event, the last thing you want to be doing is fumbling around with manuals and pounding your fist against your monitor because you do not know how to get your instance started.

If your company is wise, then it will be conducting regular DR tests.

Q: What will we do if that server melts? A: We have the disks in a RAID 5 array; the chances of two disks failing is minimal. Q: What will we do if two disks fail? A: There is little chance of that happening. Q: Um . . . OK . . . so, what will we do if that does happen? A: Don’t worry about it; it won’t happen.

You simply must plan for a disaster. No scenario is out of the question. Whenever I see a new design, I usually point to a particular section and ask, “What if that server disappears? What then?” Asking those types of questions are the only way to effectively plan for a disaster.