Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

The DBA Dilemma: How Many DBAs Does It Take to Manage an Infrastructure? Expand / Collapse
Author
Message
Posted Tuesday, October 27, 2009 12:43 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Tuesday, December 9, 2014 10:05 AM
Points: 515, Visits: 690
I am the DBA for about 25 servers which are a combination of production and test systems some of which are physical machines and some are in a virtual environment. Seven of these servers are Oracle database servers and four are used in two SQL Server clusters. I was the first, and have been the only DBA here and learned everything I know over the last ten years from the 'school of hard knocks' and through Oracle and Microsoft training classes. I was hired as a systems analyst and took the DBA postilion when the position was created. Fortunately, all of our applications are 'canned' so I do very little developer related work and perform mostly production DBA tasks. I could use some help 'cause I don't always get to check all my servers every day, but there is no way they will hire another DBA here (we are a local government). It is not all that bad, while I am on call 24/7, I have gotten things to the point where I don't get called much at all and as long as I stay on top of things I get very few 'surprises'.


Post #809524
Posted Tuesday, October 27, 2009 5:06 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, May 11, 2010 9:41 PM
Points: 25, Visits: 91
There's no way you can come up with even a ballpark number of DBA's per server. With the right tools, a well set up infrastructure, reliable networks and well written applications, a single DBA could support a very large number. But if the network is flaky and the apps are dodgy, and there's no investment in monitoring and response tools, even a single server can become a handful.

I think a better question would be to ask what a DBA needs to be able to manage a large number of servers well?
Post #809665
Posted Tuesday, October 27, 2009 6:48 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 9, 2014 1:02 PM
Points: 6,032, Visits: 5,284
skelly-806234 (10/27/2009)
There's no way you can come up with even a ballpark number of DBA's per server. With the right tools, a well set up infrastructure, reliable networks and well written applications, a single DBA could support a very large number. But if the network is flaky and the apps are dodgy, and there's no investment in monitoring and response tools, even a single server can become a handful.

I think a better question would be to ask what a DBA needs to be able to manage a large number of servers well?

I think you might have a point there..

CEWII
Post #809680
Posted Tuesday, October 27, 2009 8:00 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
skelly-806234 (10/27/2009)
There's no way you can come up with even a ballpark number of DBA's per server. With the right tools, a well set up infrastructure, reliable networks and well written applications, a single DBA could support a very large number. But if the network is flaky and the apps are dodgy, and there's no investment in monitoring and response tools, even a single server can become a handful.

I think a better question would be to ask what a DBA needs to be able to manage a large number of servers well?


I absolutely agree. It all depends on the factors you state....Even one critical db server can be a constant handful if it is just a design nightmare...A lot depends on what you as the dba inherit when you take on the new job and the environment...and a lot of times the people that created the entire mess in the first place are long gone anyway so you are stuck with cleanng it all up and getting it organized and automated...So the sooner you get started the better your daily life is going to be in the long run...


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #809692
Posted Tuesday, October 27, 2009 8:22 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 8:29 AM
Points: 32, Visits: 611
the last post was a very succinct and accurate analysis of what a lot of DBAs face. I know I came into a SQL infrastructure left by the previous DBA. His last day was Friday and my first day was Monday after. There was little doucmentation, a mix of third party and internally developed applications, no standard monitoring and many dev teams all deploying code in different and non-standard ways. Space was a constant issue and still is in many ways because there was little capacity planning. When you take it all in, the DBA may not have the ultimate say on how changes will be implemented. They can offer advise, code review, standards and best practices but often, unless coming from higher up, it falls on deaf ears. Many SQL developers do not want DBAs to review their code. Many do however, and it ultimately ends up at that, a team effort where everyone offers their knowledge to the betterment of the processes and people that you see everyday. The alternative is to be a consultant I presume. I don't know if I want that. Too much dang travel.
Post #809694
Posted Wednesday, October 28, 2009 12:25 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 2:16 PM
Points: 2,929, Visits: 4,788
I am also in agreement that you cannot put numbers to it. I would say that you need enough to get the job done without burning out the DBAs that work on it. A point that some managers fail to comprehend is that DBAs are human too. A well rested and happy DBA is worth -IMHO- at least 2 or 3 burnt out versions.

Just so readers do not get the wrong opinion - I am extremely happy with my current situation, but, I have been on the other side of the fence in my career.

Joe
Post #810216
Posted Wednesday, October 28, 2009 1:37 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
crookj (10/28/2009)
I am also in agreement that you cannot put numbers to it. I would say that you need enough to get the job done without burning out the DBAs that work on it. A point that some managers fail to comprehend is that DBAs are human too. A well rested and happy DBA is worth -IMHO- at least 2 or 3 burnt out versions.

Just so readers do not get the wrong opinion - I am extremely happy with my current situation, but, I have been on the other side of the fence in my career.

Joe


I definitely agree, but I would also add that when database emergencies happen in most shops, realistically most department managers don't even think about this. All they care about is getting the site back online as soon as possible, and if that means the DBA has to work all night to make that happen then they are not concerned about the human factor or burning out a DBA at that point. They are primarily concerned with not getting their tails chewed out from the CIO or CEO above them...Been there done that many times....Managers don't tend to think DBA's are that important until they don't have access to their data anymore...You don't tend to see them until an emergency happens. Then the DBA is the most important person in the company at that point..... :)


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #810276
Posted Wednesday, October 28, 2009 8:28 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 7:27 AM
Points: 35,769, Visits: 32,437
Heh... if the infrastructure is setup correctly, the correct answer is.... none.... the servers will take care of themselves and on the rare occasion that they can't, they'll call someone who can.

--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #810454
Posted Wednesday, October 28, 2009 9:05 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, December 11, 2014 9:19 AM
Points: 1,046, Visits: 2,739
jjarupan (10/27/2009)
IMHO, reply to the question, How many DBAs Does it take to manage infrastructure? It should be 0 (zero) in nearly future.
No need DBA for infrastructure in the future.
(Some Company still needs Database Developer for the future).
It is possible, let Network guy install server and SQL server. Monitoring Server can detect the new server, install all jobs automatically by itself.


Sure, in a perfect world, database systems would administer themselves, install themselves, optimize themselves, and secure themselves. It is true that these tasks have been made easier, to the point that one database engineer can administer more instances than he/she could a decade ago, but I don't believe they will ever completely replace the need for database folks.




Tim Mitchell, SQL Server MVP
Independent Business Intelligence Consultant
www.TimMitchell.net
@Tim_Mitchell

Post #810470
Posted Wednesday, October 28, 2009 9:18 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 7:27 AM
Points: 35,769, Visits: 32,437
Heh... sorry, Tim... my post was meant to be a wee bit ironic (ok... I really mean sarcastic to the max ). There are so many companies with a lot of servers in desperate need of attention yet these companies think a bunch of well meaning Java or C programmers can handle it because the companies know the cost of everything and the value of nothing.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #810480
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse