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 12»»

Disappearing DBAs Expand / Collapse
Author
Message
Posted Wednesday, June 1, 2005 8:32 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, August 7, 2014 8:23 AM
Points: 318, Visits: 351
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sMcCown/disappearingdbas.asp

Watch my free SQL Server Tutorials at:
http://MidnightDBA.ITBookworm.com

Read my book reviews at:
www.ITBookworm.com

Blog Author of:
Database Underground -- http://www.infoworld.com/blogs/sean-mccown
DBA Rant – http://dbarant.blogspot.com
Post #186843
Posted Thursday, June 2, 2005 12:28 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 24, 2014 3:59 AM
Points: 106, Visits: 328

I strongly agree with you.

DBA role is very specific. This role is not going to be handled by a normal apps developer well.

Even though database will look more easy to maintain in the future, it doesn't mean anyone can do the DBA job.

Thanks.

Leo Leong

Post #186860
Posted Thursday, June 2, 2005 1:27 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, March 13, 2012 9:34 AM
Points: 141, Visits: 61

Agreed. Production DBAs are a very valuable asset who bring much needed experience to the job, and are needed in a professional organisation of any size. Development DBAs rarely cut it when it comes to sorting out the problems you addressed.
Most of the purely development DBAs I've met are more developer than DBA, ie : they are developers who know more than your average developer about databases, ie: not a lot. (apologies to those who do!)
But from personal experience, I think it's actually advantageous to follow a developer -> development DBA -> production DBA route, not least because you can talk to developers in a language they understand, and because you know the sort of shoddy tricks they get up to


I have always felt that it's a role you mature into, being a production DBA, and I don't think you can do it well unless you've got the whole picture.
Purely production DBAs tend to be oblivious to development problems, the few I've met with no development background were pretty arrogant and the developers had no time for them, which isn't a good situation.
I think part of your role as a production DBA is to educate development DBAs as to the problems seen in production, and if possibly, relay that to the development teams too.
Only by communicating the problems that you see developers causing can you educate them as to how, and why, they should do things better.


As to the future of production DBAs, I think they're always going to be around, especially with auditing requirements, but maybe with more knowledge of more recent development tools.
This is where things are changing quickly, I think you can no longer leave your development skills behind as a production DBA, but have to update them too so that you can continue to converse with the development team.


You may also see more production DBAs hiring out their services on an as-needed basis for performance tuning, or moving into information risk and security roles, working alongside the auditors, an overlap which until recently has been pretty non-existant.




Jon
Post #186869
Posted Thursday, June 2, 2005 2:02 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:34 PM
Points: 2,899, Visits: 1,797
I agree with you on the importance of DBAs.

The big problem is that the title DBA has been down-graded in the minds of those hiring them. I am not sure what has caused this but I think that at least some blame has to be laid at the door of recruitment agents.

I saw an advert the other day for a SQL Server DBA that said "must be familiar with stored procedures". That is like asking if Lance Armstrong is familiar with his saddle! The agencies are telling clients that they need a DBA when what they mean is a junior developer. Of course if the client receives a junior developer and doesn't know any better that downgrades the salary that the client is prepared to offer for the role of DBA.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #186879
Posted Thursday, June 2, 2005 6:16 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 4:11 PM
Points: 15,646, Visits: 28,027

I have to say, I think both articles are right. I see the role of Production DBA seeming to shrink in terms of importance even as it becomes a more clearly defined role due to the compliance requirements you outline.

My own experience at our company finds us placing more and more emphasis on the development DBA as the more senior position. Instead of simply writing stored procs, we're the DB designers and the guys that come in to address performance problems, deadlocks & blocking. The production DBA's are managing security, backups and deployments. We've found that instead of releasing garbage and then cleaning it up, we need to take the time to clean it up in design and development, which places the onus of knowledge and skill at that level instead of downstream. We have developers writing procedures that we then review for standards compliance and performance. We're much more DBA than developer, but we really do have to straddle the fence (which can be quite painful at times).

As far as skill set goes, constant improvement and expansion both in terms of breadth & depth has to be the rule, or you will be relegated to being the backup monitor guy.



----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #186945
Posted Thursday, June 2, 2005 6:36 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, October 21, 2013 10:48 AM
Points: 966, Visits: 933
Here's another arguement for the Production DBA (at least in an enterprise environment) - To act as a bridge between the Development group(s) and the System(s) groups. My past has always been both Systems Engineering and DB Administration. I've found that there is always a big divide between the two groups, and someone who knows a bit of both can really help. Stuff like designing storage (Raidsets, cloning, etc.) with the eventual file/filegroup design of the database in mind, etc.


Post #186954
Posted Thursday, June 2, 2005 9:22 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:19 PM
Points: 2,107, Visits: 3,582

I agree with you completely. I have stated this too many times already but SQL Server causes some to believe that the production DBA is not necessary. However, being a production DBA is not just code tuning. That should be done by any good SQL developer. There are far too many other considerations as you mention in your article that a DBA needs to consider and be planning for.

The most interesting aspect of this article is that some believe 2005 is going to make things easier on the DBA. I disagree and believe it will be just the contrary. I guess time will tell. My guess is that you will see a higher end SQL Server production DBA produced with this release and their value will increase to that of the standard Oracle DBA.

Thanks for the article.



David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #187085
Posted Thursday, June 2, 2005 10:05 AM
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: Thursday, August 9, 2007 1:24 PM
Points: 507, Visits: 1

Absolutely 100% wholeheartedly agree with you and your excellent and very overlooked point about Sarbanes-Oxley makes the whole discussion about the demise of production DBA's a moot point. Great article!!!!!

Travis




Post #187114
Posted Thursday, June 2, 2005 10:13 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, July 22, 2014 9:10 AM
Points: 613, Visits: 65

I agree that Production is always needed to keep the business running well. In SQLServer 2005 make things more complex and introuce lots new stuff which needs good expertise.

--

Farhan

 




FS
Post #187117
Posted Thursday, June 2, 2005 5:00 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, November 18, 2012 8:50 PM
Points: 15, Visits: 42
Are production DBA,s important, you bet, but I believe that with the advent of better "automated" management of these systems, full time production DBAs within company IT systems may be whats disappearing, I think this may cause companies to contract out work on their databases as the work is needed?
Post #187264
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse