Paul Karman

Ramblings of an ADHD DBA

It is hard to keep priorities straight. As a DBA I should have my priorities lined up like this:

1 I know how to recover my databases.
2 I know how to monitor for bottlenecks so I can prevent them from surfacing.
3 I know how to tune SQL.
4 I know how to tune the system.

Lets go over each point in a bit more more detail, but not too much otherwise I will lose my concentration.

1 Recovery
When all else fails I need to be at least able to return to the last healthy state. So backups are important. Even more obvious should be that a backup is worthless if it cannot be restored. For that reason it is good practice to talk about restore and recovery in all dealings with the subject. Maybe delete the word backup completely out of the vocabulary, use "restore and recovery preparations" instead, talk about recovery reliability (exercises) first, then recovery time and a couple more things a client expects from recovery before I start about "restore and recovery preparations". Backup, as I have found out to be true, is only the first, simplest and cheapest step in this.

2 Monitoring
A stable system should be monitored so that simple growth problems are detected before they become un-managable. Even an unstable system should be monitored if only to prevent it from developing extra obfuscating problems. The second priority after the recovery procedure is in place is a system to monitor the database. Monitor growth in space, cpu, memory, IO, sessions and locks as soon as possible to establish a baseline.

3 SQL Tuning
Maybe remarkably but sometimes it seems SQL tuning is not in the priorities list of a DBA at all! Noticably should be too that SQL tuning is as it should be above system tuning while one often sees in practice that people quickly start to fiddle with memory settings and things like that. Somehow old buzzword items like RAM and MHz still get more attention then they should. Bad SQL can mess things up by a factor of a gazillion while a bit of memory here and a faster cpu there mosttimes does not get me any further then a factor 10 (if I am lucky).

4 System tuning
This is often the simplest part for the DBA. Consequently I can make the stupidest mistakes here.... Often those mistakes concentrate around the impression that I have to do with an "exeptionally special" problem needing ditto exotic settings to correct the problem. Note that system tuning as a priority can mean quite a few things. It's not only the well known instance tuning but it can also mean client, application server, network, web server, system tuning or anything else that could give someone a bad hair day. It is the area where the client thinks DBA means Does Basically Anything.

So if you ever see me wandering away, drowning myself in all kinds of other pitty problems please remind me to read this page again.



Paul Karman