Seven Deadly Habits of a DBA and how to cure them
Calling widespread bad habits in database administration “deadly” may seem extreme. However, when you consider the critical nature of most data, and just how damaging data loss or corruption can be to a corporation, “deadly” seems pretty dead-on.
Although these habits are distressingly common among DBAs, they are curable with some shrewd management intervention. What follows is a list of the seven habits we consider the deadliest, along with some ideas on how to eliminate them.
Habit #1. THE LEAP OF FAITH: “We have faith in our backup.”
Blind faith can be endearing, but not when it comes backing up a database. Backups should be trusted only as far as they have been tested and verified.
Cures:
- Have your DBAs verify that the backup is succeeding regularly, preferably using a script that notifies them if there’s an issue.
- Maintain a backup to your backup. DBAs should always use at least two backup methods. A common technique is to use those old-fashioned exports as a backup to the online backups.
- Resource test recoveries as often as is practical. An early sign that your DBA team is either overworked or not prioritizing correctly is having a quarter go by without a test recovery. Test recoveries confirm that your backup strategy is on track, while allowing your team to practice recovery activities so they can handle them effectively when the time comes.
Habit #2. GREAT EXPECTATIONS: “It will work the way we expect it to. Let’s go ahead.”
Although not user friendly in the traditional sense, Oracle is very power-user friendly— once you’ve been working with it for a while, you develop an instinct for the way things “should” work. Although that instinct is often right, one of the most dangerous habits any DBA can possess is an assumption that Oracle will “just work” the way it should.
Cures:
- Inculcate a “practice, practice, practice” mentality throughout the organization. DBAs need to rehearse activities in the safe sandbox of a test environment that’s designed to closely mimic the behaviour of the production system. The organization needs to allow the time and money for them to do so.
- Pair inexperienced DBAs with senior ones whenever possible—or take them under your own wing. New DBAs tend to be fearless, but learning from someone else’s experience can help instill some much needed paranoia.
- Review the plans for everything. It’s amazing how often DBAs say, “I’ve done that a hundred times, I don’t need a plan.” If they’re heading into execution mode, they absolutely need a plan.
Habit #3. LAISSEZ-FAIRE ADMINISTRATION: “We don’t need to monitor the system. The users always let us know when something’s wrong.”
If you depend on the users to inform the DBA team that there’s a problem, it may already be too late.
Cures:
- Install availability and performance monitoring systems so that issues are identified and resolved before they cause service-affecting failures.
- Avoid post-release software issues by working with developers and testers to ensure that all production-ready software is stable and high-performance.
Habit #4. THE MEMORY TEST: “We’ll remember how this happened, and what we did to get things going again.”
It may seem impossible that a DBA team would forget a massive procedure that took them weeks to get right, and yet it happens all the time. In order to prevent recurring mistakes and take advantage of gained experience, documentation is essential.
Cures:
- Require that your DBAs maintain a comprehensive documentation library and activity diary, including a significant level of rationale, syntax, and workflow detail.
- Provide your team with groupware on your intranet so that these documents become searchable in an emergency.
- Enforce the discipline of documentation and check it periodically. Ask your DBAs: When was this tablespace created, by whom, and with what SQL? What tasks were performed on a particular day? If they can’t answer quickly, you’ll know they’ve gone back to relying on memory.
Habit #5. THE BLAME GAME: “Don’t look at me, it’s the developer’s fault that SQL is in production”
Some DBAs have a real “us versus them” mentality when it comes to developers in their organization. They see themselves not as facilitators helping the developers develop quality code from a database standpoint, but rather as guardians who prevent poor-quality code from making it into production. This might seem like semantics, but a confrontational relationship between developers and DBAs results in a lack of developer initiative and significant slowdowns in release cycles.
Cures:
- Select DBAs who understand it’s their responsibility to work as an integrated team with the developers they support.
- Cultivate a team attitude by structuring continuous DBA involvement in every project rather than at review milestones.
- Consider assigning an individual DBA in a developer support role. If it’s clearly in the job description, there’s more motivation to do it well.
Habit #6. THE SOLO ACT: “I know what I’m doing and don’t need any help.”
Database administration is increasingly complex and even the most senior DBAs can’t possibly know every last detail. DBAs have different specialties, which need to be culled and utilized. When DBAs feel like they know, or should know, everything, they don’t ask questions and miss out on valuable knowledge they could be gaining from others.
Cures:
- Foster a teamwork culture where it’s acceptable for DBAs to admit they don’t know the answer and to ask for help.
- Encourage your DBAs to seek out an outside peer group as a forum for brainstorming and testing their assumptions. No single person can match the expertise and experience of even a relatively small group.
- Provide a safety net of tech resources such as reference materials, courses, and outside experts or consultants on call.
Habit #7. TECHNO-LUST: “Things would work so much better if only we had…”
DBAs are often on top of the latest technology, which can help them do a superlative job. But when the desire for new technology causes DBAs to recommend unnecessary hardware purchases or software add-ons, costs tend to skyrocket quickly—as do problems.
Cures:
- Never upgrade your hardware infrastructure without first exhausting all tuning opportunities. Remember, ten years ago enormous enterprises were run on servers one-tenth the capacity—all thanks to necessity and skill.
- Never consent to using advanced or new features until you’re well aware of the ongoing maintenance commitment and resulting costs.
- Watch out for DBA support software that presents friendly GUI interfaces for difficult tasks. This type of interface allows a beginner DBA to act as an intermediate DBA under certain circumstances, but simultaneously prevents that beginner from learning the actual skills behind the tasks. Moreover, these tools tend to hide real risks from the DBA, making potentially damaging activities as easy as point-and-click.Whether it takes a twelve-step program or one tiny adjustment, all of these deadly DBA habits can be kicked. Of course, the first step is recognizing the problem. By starting with this list and doing a careful inventory of the successes and failures in your team’s database administration, you’ll be well on your way to finding a cure
