Salespeople often spout the Ford Motor Company mantra, "The customer is job one." No doubt, keeping customers happy is a key factor in every company's well-being. However, customer satisfaction isn't—and shouldn't be—the primary job responsibility for all employees in your organization. The DBA version of this slogan, for example, should be "The data is job one."

Your organization's data is its intellectual property, and regardless of the company's business, data is one of its most important assets. The DBA's responsibility is to manage that data. But that responsibility can easily get lost in the day-to-day hassles of handling development requests, fighting fires, and troubleshooting performance problems. With little and not-so-little problems demanding the DBA's attention, the main job of protecting the company's data can get sidelined. However, losing data is one of the few mistakes that can get a DBA fired. In the IT business, you always prepare for the worst—which, according to Murphy's Law, is also the expected. So when database systems or applications go south, the DBA must be able to recover them in a timely fashion.

Solving problems, learning about flashy new technology, or writing SQL stored procedures to address user requests might be more fun, but ensuring database consistency and recoverability comes first. To guarantee that you have this job covered, develop a checklist of steps that brings your database system in line with this goal—and make sure you can check off every step. The first thing on the list is to plan your system's on-disk subsystem and on-disk structures with recoverability in mind. Except perhaps for the smallest databases, you should have overridden SQL Server's installation defaults and put your data and log files on different drives, with log files on mirrored volumes. Next, you need to understand SQL Server's recovery models and how they affect the way your system handles transaction logs. SQL Server's recovery models are part of the database properties. SQL Server 2000's Simple recovery model is suited only to the smallest installations and doesn't allow for point-in-time recovery. The vast majority of applications require Full or Bulk-Logged recovery models.

The checklist needs to include a backup plan that accounts for both backup and disaster-recovery scenarios. In other words, you need to be able to restore the SQL Server system itself as well as the data that resides on the system. Last, but certainly not least, you need to test all aspects of your restore and recovery plans. The absolute worst time to test these plans is when you need them. Ironically, the most important job always seems the least fun. I can think of better ways to spend a Saturday morning than watching a system's backup tapes whir. However, there's no other way to know whether your backup and disaster-recovery plans will work when you need them. If you've already covered these bases, you can sleep well on Saturday night. If you haven't, you're way overdue in taking care of job one before Murphy's Law takes care of you.