• Luis Cazares (8/25/2014)


    The sad reality is that "very controlled, monitored and process oriented system" is just a nice wish as there are many things that just get into production and haven't been fully tested. As a matter of fact, I could send one script to validate and change it after validation and it will be deployed into production without problems.

    So even with all the bureaucracy, the process is far from being perfect.

    I wonder if we'll ever get to a point where changes are really controlled and validated without having to waste all that time to everyone involved (developers, dbas, bosses, etc).

    I can't know why such things happen but that whole process sounds more like some silly BSOFH junk.

    I have a process at work where I've given the Dev's SA privs on the Dev box to do just about anything they need to in return for the understanding that they shall not grant privs, create users, linked servers, new databases, or any of the other things that you'd expect a DBA to do. While that sounds a bit care free on my part, it allows them great freedom to try new things, encourages experimentation/innovation, and keeps me from being a roadblock in Dev. I also do Point-in-Time backups on the Dev Box because mistakes will (and have) happen and I'd rather spend a couple of minutes to setup a restore than to have the Devs down because of a mistake.

    The Devs have Read and View Definition privs on the staging and prod boxes so that they can troubleshoot problems. I also sit right in the middle of the Devs so that I can hear can show them "how to" if they have a question. It also helps them understand that we're all part of the same team to get things done and encourages them to approach me with a problem before they've wasted a lot of time doing things the "wrong" way (and yes, we have Company SQL Specs that I wrote that they have to follow, as well). It also allows me to overhear their mumblings when they might be having a problem that I can help with and it also allows me to help protect the devs when a demanding user shows up with an unreasonable request.

    I also do 100% peer reviews (and the auditors love that little nuance) where I check for form, function, and scalability. The Devs cannot promote their own code to Staging or Prod. The peer reviews also give me a chance to do some serious mentoring for the types of things they have to do. There are times that we'll make a change together right there in the peer review. There are also times where I'll send them back to make a change (I don't have the time to fix everything) but with new knowledge (I have lots of demo code I use) on how to better solve a problem.

    Does it take a fair bit of my time? Yeah, but I'm a hybrid DBA (combination of Designer, System, Apps, and a couple of other hats) and, in the long run, I've found that it's much easier and more effective to enable them to do things the right way than it is for me to be just a road block for the wrong way. More shops should figure that out and managers need to get the idea, as well.

    It's all been worthwhile because when I first reported to the company, the 8 CPU box was averaging 40% with several long winded 100% plateaus (causing multiple "outage" reports each day) and Logical Reads where measured in hundreds of Tera-bytes during normal working hours. We now average 5% cpu, Logical Reads are 4 orders of magnitude less, and we haven't had an "outage" report in over a year. And, get this... the devs "get it" and have actually started to brag about improvements and performance problems they've solved during development. It's become a "do it right" culture instead of a "get it off my plate" culture and they're actually turning out code faster than they used to because 1) of the formatting/documentation requirements I put on them (troubleshooting/researching code has become much easier) and 2) they've developed a real sense of pride in their code because I brag about their successes, as well!

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)