Death of the Production DBA

  • Comments posted to this topic are about the content posted at

  • The item I will agree with you on is that Production DBA's can not exist in a vacuum. Prior to my taking over the production DBA group, the existing DBA's had a hostile attitude toward many of the developers which were really there customers.

    Given a good working relationship with the development division, your role becomes one more of consultant and less one of hated administrator. Of course you will still get to play bad guy from time to time, but don't start off thinking that it is your role to save humanity!

    Another item of note that in my environment development dba's have to work on specific work tasks due to billing rules. They can not float around and work on whatever is in trouble.

    Thus development DBAs here lead a rather focused existence based on whatever project(s) they are supporting. Many of the development DBAs have great experience but they are not NT Admins, just DBOs and limited SAs.

    My basic message is to manage your relationships with developers and their management. Given a good relationship your advice is more likely to be asked for and listened to!

  • Outstanding article and thought provoking issues. It's obvious from everyone's comments that the DBA field is evolving very rapidly. As an experienced MCSE (NT4.0 and W2K certified), but relative SQL newbie, trying to attain knowledge, excellence in performance and long-term security, where does one begin? Hands-on experience is a given. But, do you leverage experience with MCDBA certification? Followed by XML, VB, or a mastery of DTS? What are prospective employers looking for? Your thoughts?

    Always Learn!

  • Certification is ok - I consider a tiebreaker these days. I'd suggest VB. If you can do VB you'll find "most" of DTS easy to follow and you wont be stuck when DTS can't do what you need. Plus if you can program a little, always another type of job you can look for when jobs are hard to find.


  • I tend to agree with Andy. VB is a great place to learn a new skill. XML is good if you have a need, but it's still a lesser used technology. Growing, but unless you have a need or can get a project going in XML, it doesn't really help you.

    Steve Jones

  • We just went through this cycle again.

    Basically we chose experience and programming over the MCDBA. Had a candidate with the MCDBA, decent experience. No real programming background. He wasn't our first choice.

    We brought on contract a different candidate with a good deal of mainframe programming experience and a bit more DBA experience. Certification credentials were less: only an MCP... having passed SQL Server 7.0 Admin.

    The experience and programming were the deciding factors. Thus far we've not been disappointed in our choice. But I will say this, since we do a lot of Active Scripting and deal with a lot of VB developers, had a third candidate come along with heavy VB experience, he would have probably been chosen ahead of the guy we took. Fundamental understanding of MTS/COM+, ADO, and VB has been crucial to working on a problem app in my organization.

    K. Brian Kelley

    K. Brian Kelley

  • I think it might do all programmers good to spend 6 months as a DBA...and vice versa. Brian, interesting hiring scenario - a great example that the days of calling yourself a DBA and everyone knowing what it meant are over - assuming all candidates have mastered the basics, in most cases I bet the one with a sub-specialty that matches the current tools/problem/etc gets hired. Far from the worst reason.

    Steve, on your comment about XML - totally agree (one resolution shot already). If you're just serving XML there is not a lot to master on the db side. I think XML is great for some things, but as most of us do about new features, programmers fall into the trap of thinking it should be used for EVERYTHING. Will have to rant about this officially soon.


Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply