What is a good way to manage how effective your DBA group is? I have thought of using metrics like how many SQL statements get processed successfully, the number of incidence reports (i.e. problems with databases), and continuity of availability. Any ideas out there?

-- Amy Boyd (amyfboyd@hotmail.com), June 27, 2001

Answers

This is a very intriguing question. It is a hard one to answer though because a DBA has to be a "jack of all trades." Each "trade" can have multiple metrics for measuring success. For example, in your suggested metrics you list "how many SQL statements get processed successfully" but what does "successfully" mean? Returned the correct results or returned the correct results in a reasonable time? And what is a reasonable time? Unless you have established service level agreements it is unfair to measure the DBA on response time. And the DBA must participate in establishing reasonable SLAs (in terms of cost and response time) lest s/he be handed an unachieveable task.

What about "the number of incidence reports" metric? Well, this is fine if it is limited to only true problems that might have been caused by the DBA. The DBA should not be held accountable for bugs in the DBMS (caused by the DBMS vendor), nor for design elements forced on him or her by an overzealous development team (happens all the time with RAD and e-rushing around).

I like the idea of using availability metric, but it should be tempered based upon the environment. In other words, what is the availability required? Once again, back to SLAs. And the DBA should not be judged harshly for not achieving availability if the DBMS does not deliver the possibility of availability (e.g. online reorg and change management) or the organization does not purchase availability solutions from a third party vendor (such as BMC Software).

What about a metric based on response to problems. This metric would not necessarily mean that the problem was resolved, but that the DBA has responded to the "complaining" entity and is working on a resolution. Such a metric would lean toward treating DBA as a service or help desk type of function - way too narrow for measuring DBAs.

You'll probably need to come up with a complex formula of all of the above and more to do the job correctly. Which is probably why I've never seen such a metric-based measurement program put together for DBAs. If you (or anyone else reading this) implements such a program I'd love to hear the details and how it works out...

-- Craig S. Mullins (Craig_Mullins@BMC.com), July 09, 2001.

Hi, i really recognize a good dba when i see that he does his task not alwys manually step by step but has his effective environment build by daily work which helps him to do his job very effective.

And he should be willing to learn the new things/features adn bring them carfully into production.

He has a growing knowlegebase and knowledge-network.

Carl

-- Carl (karl.reitschsuster@web.de), April 09, 2003.

A DBA sould be measured by how many problems they can solve.

-- Tom Kyte (tkyte@us.oracle.com), September 14, 2003.

A good DBA IMHO is one who is more Pro-Active than Re-Active.

If the foundation is well defined with proper TESTED backup and recovery measures, monitoring wait events, error logs, resource limits and an OPEN mind to resolve issues, then it is not a problem at all.

Murali

-- Muralidharan Venkatraman (vsmurali@allstate.com), July 14, 2004.