The Seven Deadly Habits of a DBA... and how to cure them

Written by Paul Vallee

Calling widespread bad habits in database administration "deadly" may seem extreme. However, when you considerrepparttar 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 ofrepparttar 137552 seven habits we considerrepparttar 137553 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 thatrepparttar 137554 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 torepparttar 137555 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 whenrepparttar 137556 time comes.

Habit #2. GREAT EXPECTATIONS: "It will workrepparttar 137557 way we expect it to. Let's go ahead."

Although not user friendly inrepparttar 137558 traditional sense, Oracle is very power-user friendly— once you've been working with it for a while, you develop an instinct forrepparttar 137559 way things "should" work. Although that instinct is often right, one ofrepparttar 137560 most dangerous habits any DBA can possess is an assumption that Oracle will "just work"repparttar 137561 way it should.

Cures: Inculcate a "practice, practice, practice" mentality throughoutrepparttar 137562 organization. DBAs need to rehearse activities inrepparttar 137563 safe sandbox of a test environment that's designed to closely mimicrepparttar 137564 behaviour ofrepparttar 137565 production system. The organization needs to allowrepparttar 137566 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. Reviewrepparttar 137567 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 monitorrepparttar 137568 system. The users always let us know when something's wrong."

If you depend onrepparttar 137569 users to informrepparttar 137570 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 allrepparttar 137571 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. Enforcerepparttar 137572 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.

The 70% Solution: Practical Testing and Version Control

Written by Steve Pickard

"What do you mean you need to push backrepparttar launch date?" Saysrepparttar 137551 CEO. Saysrepparttar 137552 CFO. Saysrepparttar 137553 user community. CTOs, CIOs, and all officers who oversee major development projects have had to deliverrepparttar 137554 dreaded message. But a deadline forrepparttar 137555 sake of a deadline is a dangerous pitfall that can consume an entire project and stymie it torepparttar 137556 point that it never launches. Overrepparttar 137557 years I've come up with six simple rules that help deadlines become more meaningful, while keepingrepparttar 137558 developers,repparttar 137559 user community,repparttar 137560 CFO andrepparttar 137561 CEO all satisfied. 1.Always have minor version control throughout development. Group functional requirements into minor versions so that core functionality is prioritized and so thatrepparttar 137562 entire development team is generally active onrepparttar 137563 same minor version. 2.Always target minor version releases every 2 to 4 weeks. 3.Always begin testing immediately once each minor version is complete. 4.Always prioritize bug-fixing torepparttar 137564 highest level uponrepparttar 137565 completion of any testing. 5.Never allow a problematic functional enhancement to be a showstopper. Negotiate withrepparttar 137566 user community andrepparttar 137567 CFO or CEO for a delay in, or removal of,repparttar 137568 delivery of that functionality. 6.Always launchrepparttar 137569 product on time - as long asrepparttar 137570 most recent fully completed minor version is functionally equivalent or better thanrepparttar 137571 current production system. Launch it, no matter how far you are from 100% complete.

So I want you to launch an incomplete application? Let's just call it "functionally challenged". This is what I callrepparttar 137572 70% solution. The deadline doesn't move andrepparttar 137573 developers deliver a fully tested, bug-fixed version on time and within budget. This gives managementrepparttar 137574 opportunity to evaluate further investments into application functionality while reapingrepparttar 137575 benefits of any developments to date.

Cont'd on page 2 ==> © 2005
Terms of Use