Nov 1 ’06
The Laws of Database Administration
How do DBAs set their priorities? Is there a difference between what’s important and what’s urgent? If you change the definition of an object, change a system parameter setting, or make a performance improvement, how do you know what may be affected? What’s the best use of your time?
This article introduces the Laws of Database Administration to assist the DBA in answering these questions. We then show why the laws are ordered by importance and why important is different from urgent. This is followed by several examples that showcase the laws in the context of typical IT support scenarios, including backup and recovery, performance tuning, and regulatory compliance.
Finally, we show that the laws are more broadly useful in IT as tools for directing new hiring and interviewing procedures, implementing best practices, employee performance appraisal, and job rotation.
Importance vs. Urgency
In 1994, Stephen R. Covey, the author of The 7 Habits of Highly Effective People, co-authored a new book titled First Things First. In it, the authors point out the problem with what’s called “the tyranny of the urgent” or the tendency of people to react to short-term emergencies and events to the detriment of more important work.
One way they illustrate addressing the way you manage your time is to consider these two questions:
- What’s the one activity that you know if you did superbly well and consistently would have significant positive results for your work?
- If you know this thing would make such a significant difference, why aren’t you doing it now?
Important tasks tend to involve preparation, prevention, planning and empowerment, while urgent behavior is putting out fires and reacting to emergencies. As a DBA you can use this differentiation of behaviors (important vs. urgent) to prioritize work and move yourself out of the urgency rut. To assist in this endeavor, I introduce the Laws of Database Administration.
Statement of the Laws
In order of their importance, the laws include recoverability, availability, security, and performance. The easiest way to explain the laws is in the negative sense; that is, what you shouldn’t do. In this form, the laws can be stated as “Thou shalt not cause thy …
- Data to become unrecoverable
- Data to become unavailable
- Data to become unsecure
- System to perform poorly.
The first three laws deal with data management, the fourth with system management. These encapsulate the four most important responsibilities of the DBA. Breaking any of the laws is cause for alarm (see sidebar).
The Order of Importance
Some might quibble with the order of the laws. For example, one manager told me: “In our shop, performance is of highest importance. We have service level agreements that we must meet in order to meet our customer’s needs. Performance is more important than backup and recovery.”
Actually, performance is certainly an urgent concern, but recoverability remains the most important. To determine what’s really important, consider an anecdote:
You’re a DBA supporting IT systems for a provider of medical and surgical services. Your systems are used daily by doctors, nurses, and technicians to provide services to patients. In some cases, these services (e.g., diagnosis) may involve life-or-death decisions. Your supervisor asks you to give a presentation to upper management (including the CIO, vice president of IT, and major stockholders or owners) of new enhancements your department will make. Your presentation begins as follows:
“Ladies and gentlemen, the DBA team will be implementing some high-performance features in the near future. We have two implementation plans and we’d like your assistance in choosing between the two.
“Plan A will involve performance changes that will result in up to 95 percent of our online transactions finishing in their required service levels.” You hear some grumbling from the audience, as they realize this means 5 percent of the online transactions will perform poorly. You continue.
“Plan B will involve performance changes resulting in 100 percent of our online transactions finishing in their required service levels.” You hear sighs of relief from your audience, as they are clearly more comfortable with this plan.
“However,” you continue, “if we have a major hardware outage, there’s a good possibility that up to 5 percent of our data will be missing or invalid.”
Your audience now sits in stunned silence. They realize there could be a power outage or other disaster that affects the IT systems. Should this occur, when the systems come back up, every user will know there’s a 5 percent chance that test results are missing, diagnoses are incorrect, or that some patient’s records will have completely disappeared.
Which plan will your audience adopt? Which was more important to them: recoverability or performance?
One can imagine similar anecdotes relating to other combinations of the laws. Do you consider performance more important than data security? Picture a similar situation to the preceding anecdote where the stakeholders are asked to choose between Plan A, in which some transactions will run slowly, and Plan B, where some production data on an employee’s laptop may fall into the hands of criminals. Which plan will your company adopt? What was more important: security or performance?
The Significance of Importance
You may be dealing with concerns that are urgent and require immediate attention. Some of these might include an outage of a production system; slow response time for a critical application; distributed application failures due to unavailable data; or the possibility of inappropriate or illegal access to corporate data.
However, this doesn’t change the relative importance of recoverability or the order of the laws. When we set priorities or adhere to best practices, we do so in accordance with the laws.
The Context of Best Practices
Best practices can be summarized as implementing shared processes, documentation, and standards in an environment of continuous improvement (see additional article references at the end of this article). The laws fit nicely into the context of best practices, guiding you to which practices to develop first and which should receive higher priority.
Best practice implementation begins with requirements for processes, documentation, and process disciplines or standards. Sometimes IT derives requirements by reacting to symptoms. Regrettably, this reactive behavior makes it extremely difficult to concentrate on the real issues (i.e., the important ones).
Certainly, one must deal with some urgent issues. These would include production system outages, for example. They might not include some phone calls, some emails, and some office visitors. True best practice implementation requires moving forward through symptoms to real problems, sometimes called root-cause analysis. One can then perform problem resolution, requirements definition, and cost/benefit analyses of alternatives.
Next, use the laws as a priority scheme. IT will now determine how to codify the alternatives as processes, documentation, or process disciplines and define their quality measures as well as how they’ll be shared and continuously improved. In this way, the laws serve as a gauge of importance and priority for continuous improvements.
Using the Laws in Other IT Contexts
Quite apart from daily use for determining task priorities, the laws are extremely useful in other situations.
Hiring: Your team can use the laws as a starting point for developing or updating DBA job descriptions, team task profiles, and interview questions. Hiring a DBA? Consider questions such as: What are the most important tasks a DBA must perform? Discuss the relative importance of data recovery vs. application performance. When starting a new job as a DBA, what are the first things you’ll need to learn?
Employee training: With a clear sense of what things are most important, the DBA team can more easily determine where they should spend their education and employee development resources. Are all the DBAs fully trained in data recovery (including disaster recovery)? If not, perhaps some training is needed. If there are two offsite classes available on data recovery and SQL tuning, you can use the laws to guide you in making your decision.
Performance appraisal: If you agree with the laws and their hierarchy as stated, they become a foundation for performance standards. The higher the importance of the law, the more weight it can be given when developing appraisal guidelines. One can then extend this to post-appraisal employee development by indicating what further education or experience would be most effective.
Mergers and acquisitions: Centralizing your IT infrastructure? Acquiring (or being acquired by) another company? If so, this will involve merging IT functions from two or more organizations. As you begin planning, the laws can be used as an agenda for discussion. For example, the most important task should be IT-wide consolidation and coordination of data recoverability (i.e., backup and recovery procedures, standardization of backup media and frequency, multi-site disaster recovery planning, and the like).
DB2 version upgrades: As shops have migrated to V8, they’ve experienced various issues. If your shop is contemplating or planning an upgrade, then the laws may give you a beginning point for creating an installation verification test suite. For example, you should consider including before and after tests of backup and recovery utilities, including timings and resource usage.
Of course, the laws can’t apply to every possible IT enterprise. It’s possible that environments exist where the specification or order of the laws differ from that presented in this article.
Still, the point of importance vs. urgency remains. We can’t allow urgent, reactive behaviors to rule our lives at the expense of those tasks that are truly important. This is most obvious in the realm of best practices, where the process of continuous improvement forces IT professionals to concentrate on solving problems rather than reacting to symptoms. Z