Return to Home Page

Keeping Your Database Up to P.A.R.

A day in the life of a DBA is usually quite hectic. The DBA is required to maintain production and test environments while at the same time keeping an eye on active application development projects, attending strategy and design meetings, helping to select and evaluate new products, and connecting legacy systems to the Web. And Joe in Accounting just submitted that "query from hell" again that is bringing the system to a halt. Can you do something about that? All of these things can occur within a single DBA work day.

To add to the chaos, DBAs are expected to know everything about everything. From technical and business jargon to the latest management and technology fads, the DBA is expected to be "in the know." And don't expect any private time. A DBA must always be prepared to be interrupted at any time to answer any type of question - and not just about databases, either.

When application problems occur, the database environment is frequently the first thing blamed. The database is "guilty until proven innocent" instead of the other way around. A DBA will never experience an application developer coming to him for help with a question like "I've got some really bad SQL here, can you help me fix it?" No, instead the developer will barge into the DBA's cubicle stating very loudly that "there's a problem with (insert your favorite DBMS here), fix it so my program can run!"

As such, the DBA is forced to prove that the database is not the source of the problem. Sometimes he must know enough to be able to track down problems and errors to exonerate that which is in his realm: the DBMS and database structures he has designed. But he must also know about IT components with which the DBMS interacts: application programming languages, operating systems, network protocols and products, transaction processors, every type of computer hardware imaginable, and more.

And the DBA must be constantly available to deal with problems, because database applications run around the clock. Most DBAs carry pagers or cell phones so they can be reached at any time. Failure to do so can result in database downtime, and that can completely shut down business processes.
DBAs frequently spend weekends in front of the computer performing database maintenance and reorganizations during off peak hours. You can't bring mission-critical databases down during the nine-to-five day to maintain them. And more and more businesses operate with full 24-hour days.

But, in a nutshell, the entire job of the DBA boils down to keeping databases running up to PAR. In this context, PAR has dual meaning. As in golf, it means an amount taken as an average or norm. But for DBAs PAR can also be an acronym that defines the three primary responsibilities they have for managing databases: Performance, Administration, and Recovery. If the DBA focuses on PAR, applications will be performing according to the service level agreements, databases will be administered appropriately assuring optimal design and good organization, and data will be sufficiently backed up such that it can be recovered in the event of an error or downtime.

If the DBA keeps the databases up to PAR regularly, it can make life a lot less hectic. A well thought out approach to PAR involves instituting a proactive approach to performance management, administration and change management, and database backup and recovery. It can require adopting tools with built-in intelligence and automation capabilities.

But wait a minute… I think I hear your pager going off. So we better stop here so you can go find out what database problem you have to tackle next!

From Database Trends and Applications, September 2002.

© 2002 Craig S. Mullins,  All rights reserved.

Home.