SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Disappearing DBAs

By Sean McCown,

In an article on SQLServerCentral.com recently, Brian Knight wrote a very nice article on the dangers of remaining a production DBA. While I agree that a production DBA should certainly expand his skills, it’s for different reasons. I’ll get to those reasons in a minute. For now, I want to take a minute and state quite clearly that I wholeheartedly disagree with his opinion. See, the problem goes deeper than just whether or not Yukon will be easy to admin.

First of all, the issue of whether Yukon makes a production DBA’s job easier isn’t even a factor. SQL Server has been and will always be the easiest platform to manage, yet we have production DBAs now. The production DBA brings far too much to the table to just dismiss them outright. Until the end of time systems will have problems, developers will write bad code, vendors will have horrendous schemas and incompetent indexing strategies, and HA/DR scenarios will need to be developed and maintained. That’s not all… security will need to be maintained and audited, servers will need to be locked down and questions will need to be answered.

Now, I don’t know about the rest of you, but I’ve never met a developer who could do the same level of job as a production DBA in these matters. That’s the very reason we have different types of DBAs to begin with. We need production DBAs to specialize in these areas of DBs. There’s simply no way around it. No matter how easy they make Yukon or any future release, there will never be a substitute for the experience of a true production DBA. Yukon won’t be able to interpret Perfmon counters, or their significance. Nor will it be able to tell you the best HA/DR scenario to implement in your environment, or best way to split the tables across different RAIDS, or the best way to re-write a query, or how much CPU a particular application will need, or how to recover a suspect database, or how to stop queries from blocking each other, or any of the other many things we get asked every week. The production DBA is in great need, and developers simply can’t do the same level of job.

There’s another aspect that’s gone completely unaddressed here though… compliance.

The audits, particularly Sarbanes-Oxley (SarBox or as some of you call it, SOX), are putting an end to multi-functional roles in a public company. Now, you’re no longer able to be both a developer and a production person. You pretty much have to choose one or the other. There has to be a clear separation of duties and we’re simply not going to get around that. So no matter what Yukon will and won’t bring, companies are stuck with having two separate roles for these positions. That’s not to say that you don’t need to expand your skills though. I completely agree with Brian in that respect. You need to do it though, from the aspect of knowing how to better support it, not from the aspect that you’ll be made obsolete if you don’t. I guess that’s all I’ve got.

Total article views: 9677 | Views in the last 30 days: 1
Related Articles

Yukon Delayed Again and Named

Microsoft confirmed today that it has delayed Yukon yet again. It also announced that Yukon has an o...


Development and Production Database

Insert Into Development and Production Database at the same time


What is the best way to Secure Production Data from Developers SQL2000

Secure Production Data from Developers


production server slower than development server

performance difference between production server and development server


Production Server DB backup Restored on Development Server Backup

Production Server DB backup Restored on Development Server Backup