The Organizational DBA

I posted another entry about a question I received as to the most effective management processes are for a DBA, and in that post I mentioned that the answer was "it depends". There are a lot of ways to slice and dice the information, but I think a convenient one is one the size of your organization. I've covered the Small Shop DBA/Developer, and in this post I thought I might offer some guidance to the DBA who works in a department, medium-sized business or organization.


As you can see from the title of the post, I’ve dropped the “Developer” part. The reason is that in a larger organization you’ll usually have a dedicated set of developers, and perhaps even a developer/DBA. Of course, you might not. In fact, these “growing pains” are a hallmark of a medium-sized organization, one I’ve faced many times. You’re asked to wear the same number of multiple hats as a small-shop DBA, but with a far larger and more complex workload. It can be a painful place to be.


So the first part of the management process I would recommend to the organizational DBA is to work on your documentation. The first set is a status report of some kind. You need to let your management team know what you’re working on, and why. It might surprise them. This doesn’t need to be an everyday thing, just some time period that keeps them in the loop.

The second set of documentation is on your systems. The reason this becomes important at this level is because you’ll probably have multiple machines with different purposes. You also need solid documentation in case you do get some extra help, so that you both have a single point to communicate baselines and configuration changes. This documentation can be electronic, of course, and the Standard Reports I’ve been documenting are useful for that.


The challenges at this level are a deeper knowledge of core features and performance tuning, as well as data retention strategies and disaster recovery.


For the knowledge, it’s essential that you set up a test system of your own to try out things and measure them. Of course the same strategy of reading and staying up with the latest Podcasts and Webcasts holds true at this level. For performance tuning, there are lots of resources available on the web and in the docs to do that, but the key is frequent baselines. Remember, it’s a process, not an action. Data retention – that’s a whole other basket – but the upshot is that you need a deep understanding of what your company is storing, and why. You need to become familiar with your business, so that you can be a partner in that process. Finally, the disaster recovery process is more than just backups and recovery, although that forms the core of it. Once again, documenting your system and storing a copy of that can be essential to recovering.

Comments (4)
  1. I posted another entry about a question I received as to the most effective management processes are

  2. BEACHDBA says:

    I would add to this list that the DBA should have signed retention/recoverability agreements for all of their production databases (or SLA’s for recovery).  This protects the DBA if recovery outside of the normal retention is requested.  Better to have everyone on the same page before such requests are made.

  3. BuckWoody says:

    Good point. I agree with that – and will also bring it up in the "Enterprise DBA" entry I’ll do tomorrow.

  4. Carpe Datum says:

    In a couple of other posts, I’ve covered some of the challenges and strategies for dealing with those

Comments are closed.

Skip to main content