What should a DBA do?

I was thinking recently about what a DBA does, and decided to blog about what I think a DBA could/should do. Most DBAs I know are mired in day-to-day firefighting and time-consuming tedium. This forces them to operate in reactive mode (because they don’t have enough time to “get caught up”), and keeps them from more valuable things they could be doing. Here’s my short and incomplete list:

A DBA who’s overworked on tedious tasks gets tunnel vision. He can’t think strategically, he can’t protect the business from risk. Critically, he can’t help the business make the most of other investments, such as the developers. A DBA who’s freed from those things is a resource and an enabler, a critical asset for strategic and tactical planning on upcoming changes to systems, and a risk reducer – able to stop a lot of problems before they get worse, or even before they start.

Some of this is about tools. DBAs with good tools can manage at least an order of magnitude more servers than one with poor/no tools. I know some DBAs who manage hundreds of servers and treat it as unremarkable. They usually have excellent tools to help them, whether self-developed or gotten elsewhere.