Death of the Production DBA

  • Relates to the future article at :

    http://www.sqlservercentral.com/columnists/bknight/deathoftheproductiondba.asp

    What are your thoughts on the death of the production DBA?

    Brian Knight

    bknight@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bknight

  • Brian,

    Great article and I agree, hybrid is the best way to be to ensure job security today. I too have walked into an environment which demands that type of atmosphere and the developers love the resource.

    My only concern with the hybrid mentality, and the reason I still encourage managers to stay away from this mentality is that the intracacies of the Server and the DBMS are lost as your focus becomes shifted to that of a DBA and DB Developer. Now you have no expert on the system but on the processes. I have strived very hard to maintain both however, at some point something has to give and it is usually the mundane, background work which gets the nod.

    Oh, how to achieve that balance?!

    David

    @SQLTentmaker

    “He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • I've found this article to be very true. We've got three DBAs where I work. One was solely a production DBA, but he's now doing DTS packages and moving more towards a development role like the rest of us. What I've found is similar to what DavidB is saying... it's hard to keep current on both development and production, especially as development becomes more and more diverse.

    The other issue is one of perspective. As a developer, we sometimes want to do things that make our development efforts easier, even if there's a performance hit. There's not someone arguing from the other side of the fence to get a compromise that is the best fit for the developer and for performance.

    K. Brian Kelley

    bk@warpdrivedesign.org

    Edited by - bkelley on 09/04/2001 09:44:35 AM

    K. Brian Kelley
    @kbriankelley

  • The main problem I'm experiencing is that the development manager will call me and demand that something be done in production ASAP. I'm used to defined processes in production, but I'm also used to allowing a little slack in development. When I come back with a resounding NO in production, the development manager freaks because I became the tyrant of the production server room all of sudden.

    When your hand is in both pies, there is no hand off and no defined bad guy. Me as a hybrid kind of becomes two-faced. On one hand I give them DBO rights in development and on the other, I take it away in production and not even let them change data ad-hoc.

    The balance has been hard and I wish I can say I've found it!

    Brian Knight

    bknight@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bknight

  • That's where QA has saved our necks. We have a change control process where the manager wanting the change has to sign off, then it has to be reviewed by a DBA and finally the manager over our DBA group. It then goes to QA. Now, QA has stated that they have up to a 3-day turn around for all production changes that aren't mission critical. QA has to be in the loop, and offers another witness in the process so that changes don't get rammed through without proper scrutiny.

    K. Brian Kelley

    bk@warpdrivedesign.org

    K. Brian Kelley
    @kbriankelley

  • I agree with Brian. That's how we do it here to limit liabilities in production. Of course, our manager also does development and can be a maverick.

    Of course, all I can do is call him on it. Probably can't prevent it until he really breaks something.

    Steve Jones

    steve@dkranch.net

  • We have a similar QA process. The problem comes in where you have enough money at stake to where QA is rushed through with executive overrides. Then when something goes wrong, people blame Microsoft, where in reality, it's not using our own methodologies.

    Brian Knight

    bknight@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bknight

  • I'll have to confess to running a much looser ship than you guys - our two junior developers send changes to me to apply after having tested on their server, the two senior developers do most of their own changes. I think mgmt likes the idea of control, but not really...! Small company, so we can be a bit more relaxed and most of these db's are for small internal apps. Changes to our one critical app (sql changes) I always do.

    So, Im the sorta gatekeeper!

    Im probably a good example of a hybrid. I use VB a lot, spit openly on asp, and am the proponent of best practices with regards to having a plan before building, building components, etc. Anyone wish to join my army of one (well, three if you count Sean and Leon!)? It definitely makes a difference in that our junior developers have tons of questions, its pretty common for them to come to me for help with a sql issue only to find that they need to back up a few steps.

    But the more code I write, the less Im digging into the infernals of merge replication or olap or whatever. Hard to know whats going to be important later vs whats expedient now.

    Andy

  • I would think Andy it's all a matter of resources and corporate culture. My company has an old school mainframe culture where everything has its checks. It also makes us much slower in moving out new releases and companies like yours may pass us (with a potentially unstable product ).

    Brian Knight

    bknight@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bknight

  • Brian,

    I agree with most of what you stated in your article. I believe the Production DBA has been dead since SQL 2000 came out. We just haven’t smelled the body yet. In my current position we have virtually have no QA and our Project Manager will jump in and “help”. Then we (DBA’s) have to come in a clean up the mess. I have always believed that to be a good database professional you must know all phases of database evolution, design, development, administration and production (also throw in VB and ASP). Now add to the mix troubleshooter. Rapid development has led us to take the word “rapid” to the literal sense.

  • You guys keep using words like "process" and "QA". I thought I was an english speaking citizen of the US but, I haven't heard those words before. Obviously kidding! Seriously though being in healthcare these days makes it really hard to invest the proper amount of time and resources towards proper development processes. Very similar to a smaller organization so, any updates on the database and procedures have to be scrutinized. Extremely fortunate to have few developers and even fewer with SQL dev skills so, they look to me to get this done. I get to provide training my way as well. My bad form is trickled everywhere. I keep waiting to hear back from old developers here that made it out to the real world telling me my examples are garbage.

    Before I get way off topic into the woes of the development environment though, I do want to state that we, as SQL Server DBA's, are going to be the driving force as to whether MS SQL Server really has a long hold in the market as a leading DBMS. If they keep taking the market like they have been, and there is not a sufficient amount of true DBA's to support the product in the large scale environments, then they will suffer a bad rap as being a poor performing database in the heavy utilization areas. (So, if there are any MS folks that monitor this site, here is one to review and get some training incentives going.) Just my two cents.

    David

    @SQLTentmaker

    “He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • I think since sql 7.0 came out the MS-DBA role has decreased. I think production dba's will move into more of performance tuneing and the like. That is the most requested thing from me at my current job is to help make apps run faster. With that in mind I rely heavly on my past development work. I don't think there will ever be a "pure" admin dba anymore for SQL 2000 or beyond.

    Wes

  • I'll ditto Wes. One thing that will remain a DBAs role for a while is performance tuning and scalability. Has anyone tried to implement a distributed partitioned view yet? They take tons of planning and time to do and I don't think this could be done by a non-DBA type person.

    Brian Knight

    bknight@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/bknight

  • We set up a fed cluster in the lab with 5 pc's it is pretty simple to setup its making sure all your data that you need is local to the server running the query. At first we setup a little app that would poll any of the servers at random to execute the query but if the data was on another box and it was running a query already ugh.... not pretty. It really leans heavy on the app/com object to be coded correctly. We are just taking baby steps now and really don't have any app that would make use of the technology but we may have some customers comming in that would use it. So, I guess to answer you question on the high end of the Enterprise there will always be DBA's and the likelyhood of single production DBA's is best there.

    Wes

  • Is anyone (else) out there working as a hybrid data analyst / DBA? We do something like that (and of course, our logical data models look pretty physical a lot of the time ). I suppose I'm curious if other SQL Server shops actually use data analysts much. Would anyone care to speculate on whether or not that will change?

Viewing 15 posts - 1 through 15 (of 39 total)

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