Thirteen signs of DBA fudging

If you are a director, manager or project manager who works with DBAs, you probably have had the nagging suspicion at one time or another that a DBA’s assertions regarding his or her practices lack an empirical or scientific basis, or are simply deflections intended to pass the buck.

Manager: Mr. DBA, the application is really slow. Do you have any idea what’s wrong?

DBA: Oracle is very complex. It could be any of 100 different possible causes. I will begin checking each. Anyhow, what makes you think it is the database?

Some DBAs are professional, thoughtful scientific-minded contributors. But the sad truth is that many DBAs lack the skills to professionally manage their systems. To cover, they use deflections such as the example above, or fall back on old, long-disproved practices without the benefit of evidence. Why is this true of DBAs?  One reason is that the standard education options are poor.

To help non-DBAs realize that they are being subjected to misdirection, obsolete advice, or simply ignorance, we have compiled a list of common ways that DBAs cover for their shortcomings, and avoid legitimate empirical investigation and analysis of problems and solutions.

Take notice when a DBA:

1. Cites “best practices,” or advice from a particular guru or website, as the sole reason for doing something.
2. States that “this is how we have always done it” as the sole reason for doing something.
3. Claims that reducing “head movement” by changing file or disk layout will improve performance.
4. Blames “fragmentation” for performance problems and states the database must be taken down for “defragmentation.”
5. Spends lots of time (and compute resources) rebuilding indexes.
6. States he/she must do things to improve the “buffer cache hit ratio.”
7. Discourages the use of RMAN or ASM because they are “too complex.”
8. Insists on separating indexes from tables physically, despite a modern caching SAN.
9. Blames performance problems on a SQL statement’s length, apparent complexity, length of execution plan or number of joins.
10. Says that there is no conclusive way to determine the cause of slowness.
11. Claims certain actions are “dangerous” without having a cogent technical explanation of why.
12. States it is necessary to perform manual tasks upon database startup, or at any regular scheduled interval
13. Accounts for time by listing the procedures/checks he/she manually runs on a daily/weekly/monthly basis

At Blue Gecko, our remote DBA services are based in proven, evidence-based standards.  When we assert that something must be done, we will always be able to provide a cogent reason, and cite evidence for our actions. We don’t do things without a good reason.  We find that pat advice from “gurus” often lacks a basis in evidence.  We deal in databases. We should always be able to cite data!

Related posts:

1. New whitepaper: Common Oracle Misconceptions
2. Jeremiah Wilton published in the latest Oak Table press book!
3. Proactive support