Post reply

DBA Responsibilities.

  • June 28, 2007 at 1:29 pm

    #177217

    We are spinning up a new project of migration from Oracle to SQL Server (sql rocks !! ) and i was just curious if you could share the average ratio of DBA to Servers. I remember reading it somewhere that 20 is a good no. Also, it would be great if you can share an approx. time distribution on a monthly/yearly basis for each of the activities below.

    ActivityPercentage Time Spent
    Backup 
    Recovery 
    Security 
    Performance Tuning. 
    Code Reviews 
    Installation and Configuration (Including Patching) 
    Miscellaneous (Troubleshooting client issues) etc. 
    Data Transfers 
    Others 

  • June 28, 2007 at 2:11 pm

    #715981

    DBA to server isn't always a good thing to go by. One server may have multiple instances and/or databases while another may only have one instance and database. Plus critical databases/servers shouldn't have the same 'weight' as non-critical ones.

    -SQLBill

  • June 28, 2007 at 4:05 pm

    #716010

    Thanks bill, i agree that instances would be a better measure.

  • June 28, 2007 at 5:30 pm

    #716029

    I've found that our DBA's don't (have to) do much in the area of performance tuning code, only do cursory reviews of code, don't do much when it comes to troubleshooting code, and don't have to do much with data transfers.  Why?  We don't think it's their job (they are "system" DBA's).  The Sr. Data Analyst and a couple of select senior developers do the code reviews against a set of well known and established written standards, those select developers know performance challenged code when they see it and mentor the other developers into high performance techniques, we have a QA team to die for so far as implementation and integration testing goes and the developers know how to troubleshoot code, and the senior developers take care of writing code for all the data transfers.

    That frees up the DBA's to do their jobs... promote approved code during change controls, do minor "safety check" reviews on code, monitor overall systems' performance and notify as to which code is causing a problem, monitor disk space usage and file allocations and load balancing, do some really good regular maintenance on the systems, troubleshoot connections that went sour and make new conncetions when required, monitor security, and all the other things that "System" DBA's are supposed to do.

    It's a pretty good model for a medium size company and, maybe, big companies... for small companies, the DBA has to wear the "system DBA", "application DBA", ETL, and Master Developer hats.

    So, I'd have to say that the percentage of time you asked for is like anything else in the IT world... "It Depends..."

    --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)

  • June 29, 2007 at 8:39 am

    #716206

    Brilliant answer, Jeff.  I would extend the small-company "hat" out to vendor-battler, DTS-fixer, and occasional OS/Hardware support.

    Jaybee.

  • June 29, 2007 at 7:44 pm

    #716322

    Heh... absolutely agree on that!  And the "Hardware Support" may even include the mundane... like changing toner cartridges on a printer

    --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)

  • July 1, 2007 at 12:20 am

    #716396

    Thanks Jeff for your detetailed response. That is definetely helpful.

  • July 2, 2007 at 12:10 am

    #716444

    I've found that our DBA's don't (have to) do much in the area of performance tuning code, only do cursory reviews of code, don't do much when it comes to troubleshooting code, and don't have to do much with data transfers.  Why?  We don't think it's their job (they are "system" DBA's).  The Sr. Data Analyst and a couple of select senior developers do the code reviews against a set of well known and established written standards, those select developers know performance challenged code when they see it and mentor the other developers into high performance techniques, we have a QA team to die for so far as implementation and integration testing goes and the developers know how to troubleshoot code, and the senior developers take care of writing code for all the data transfers.

    Sounds like heaven. Can I come work with you? (j/k)

    Most of my developers wouldn't know well-performing code if it jumped up in front of them doing the can-can. There are a couple exceptions, but...

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • July 2, 2007 at 12:25 am

    #716448

    Heh... Gail, I'd love it if you could work for us... I'm just not the one doing the hiring.

    Trust me on this, though... we have to constantly hit our developers in the head with the proberbial baseball bat.  Left to their own devices, they would overrun the databases and servers like so many mice on a crib of corn.  The Sr. Data Analyst works his butt off keeping the developers in line with code reviews.  How do I know so much about the Sr. Data Analyst???  I am he.   The DBA's love me... they never have to worry about peformance issues in the code because I take care of most of that through code reviews.  And, the answer to your next question is "YES"... I review ALL code before it ever come close to production implementation.

    Maybe the correct question should be... can I come work for YOU. 

    --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)

  • July 2, 2007 at 12:49 am

    #716451

    I used to code review everything, but I don't have time any longer. The load's spread among a small group who do know well-performing code. However stuff slips through.

    On the subject of responsibilities, in a bigger company a lot of time gets spend on security and compliance. A far higher proportion than in a smaller company.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • July 2, 2007 at 11:42 am

    #716613

    I used to do *full* code reviews also but now with the amount of code that goes/changes daily on my new job that is simple not possible. Developers do their best and we test for performance on QA but it is almost impossible to determine how the systems are going to interact when you have 100s of scripts/programs *interacting* there is where I enter. Monitor, troubleshoot, recommend, fix, propose improvements


    * Noel

Viewing 11 posts - 1 through 10 (of 10 total)

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