SQLServerCentral Editorial

The Abstract DBA

,

Today we have a guest editorial from Andy Warren as Steve is out on holiday.

Back when I became a DBA I was involved in everything. I worked on the hardware evaluations and purchase decisions, everything from memory and storage to network cards.  I decided on the RAID type, stripe size, and more. I was a backup to the server team and was a domain admin so I could both provide coverage and just get things done when needed. I did the SQL Server installs, upgrades, and patches, and I consulted with the developers on everything from design to performance to security. I went to class to learn clustering and SAN administration, more to understand how they worked than an expectation that I’d be doing in on any kind of regular basis.

Today I work with a team where I’m a DBA but I don’t do the installs or the service packs. I don’t have anything to do with storage besides asking for more when needed. I don’t build or patch the servers, I don’t build clusters. It’s all handled by the server/operations team, a team that doesn’t contain a single DBA. It’s more and more common, and I think a good thing if you have the staff to do it. I don’t feel like any less of a DBA because someone else does the service packs!

I was struck by a recent conversation with one of those team members who remarked that they didn’t like that the DBA team had direct access to the server because we could make a change that would bring down the server. I had to laugh. I get the urge/need to limit access, and I’ll get by with whatever access I am handed, but in my biased view bringing down the server pales in comparison to the kind of issues that a DBA can cause with a single mistake.

If you think about it, that’s a lot like what we get in cloud solutions today. We’re abstracted from the hardware and the storage and just about everything else that isn’t a direct component of SQL Server. It feels like a loss of control, and it is of course, but it also means that we can just focus on the database. It doesn’t mean that mistakes or under provisioning won’t cause us pain, but as a service we can just identify it and then wait for whatever team owns it to fix it.

If I had a choice, which way would I have it? I’m reluctant to admit it, but I like the way things are today. What about you – do you like being ‘just’ a DBA, or do you yearn for (or still have) your fingers in a lot more pieces of the technology? 

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating