Post reply

Disappearing DBAs

  • June 1, 2005 at 8:32 pm

    #167358

    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.com
    Blog Author of:
    DBA Rant – http://www.MidnightDBA.com/DBARant

    Minion Maintenance is FREE:

  • June 2, 2005 at 12:28 am

    #562409

    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

  • June 2, 2005 at 1:27 am

    #562418

    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

  • June 2, 2005 at 2:02 am

    #562426

    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

  • June 2, 2005 at 6:16 am

    #562476

    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

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • June 2, 2005 at 6:36 am

    #562484

    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.

  • June 2, 2005 at 9:22 am

    #562597

    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

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

  • June 2, 2005 at 10:05 am

    #562625

    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

  • June 2, 2005 at 10:13 am

    #562628

    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

  • June 2, 2005 at 5:00 pm

    #562745

    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?

  • June 3, 2005 at 6:24 am

    #562845

    I agree that the Production DBA will not be phased out. 

    No matter how much automation of database maintenance is put into SQL Server, evaluation of processes and performance will need to be done by the DBA.  Management will always pose the question "Why does that take so long?"  And unless they are going to delegate that analysis to the developer, the DBA will have a position.

  • June 3, 2005 at 6:42 am

    #562860

    Somewhat agree, it depends on the needs and the size of the company to maintain a DBA, or just hire a "jack of all trades", like I was before I became a full-time DBA. I feel the pressure is on.

    L.

  • June 3, 2005 at 2:41 pm

    #563016

    Sean,

    I absolutely agree with your comments; however the need for as many DBA at any given site can be and has drastically been reduced.

    We have well over 130 database servers at my site and for 18 months I was the sole DBA. If this was SQL 6.5 or heaven forbid an Oracle site I'm sure you would need 10 DBAs. Today’s SQL Server is much easier to manage, you still need and want the professional DBA guarding the data and managing but you don't need that team like you once did.

    I think the biggest impact that has allowed easier DBA maintenance has been the advances in hardware and the O/S. I've clustered Data Generals and Compaq under NT 4.0 and SQL 6.5, believe me the days and time spent preparing the SQL environment have come along way. Today I can crank out new cluster sites in a fraction of the time. Most of our environments have been built by Window administrators who follow a documented plan. 

    IT Managers be forewarned - Just because it appears easy, has nice GUI, and you know how to use a mouse doesn't mean you want your first tier support specialist playing DBA. What are you going to tell that director of sales when they want their 2nd quarter results off that database that just went suspect.

    I've walked into sites (E & something) where they've completely corrupted their database, but that was okay because they can use last nights backup, only to discover that they had hadn't purchase database backup option of that software and of course open files don’t get picked up, and heaven forbid had you looked at those reports you would have known that 2 years ago.

    But go ahead and try to the job without us. It's only your career on the line.

    By the way - the knuckleheads here finally wised up and allow me to hire a backup DBA, because had I walked out the door, the keys to the kingdom would have followed.    

    Zach

     


    John Zacharkan

  • June 6, 2005 at 2:34 pm

    #563337

    As with all things disappearing, the idea that someone else can decide better how a thing should work or run or function or look, that most everything can be defined to a pattern and will be just as good and wonderful based on this predefined form.  No human needs to intervene and get involved.  We think, or more likely are told to believe, that 'out of the can' is just as good.  It doesn't matter where the can comes from.  Information tech still needs the 'human' touch.  The real analytical side of the business still runs with a heart beat and a 'brain' beat.  The rocks have evolved into keyboards, nothing more than that.

     

  • June 2, 2006 at 9:25 am

    #641475

    As a long-time production DBA I fully agree with you. Consider this, in the health care world it is not just SOX (for public companies)  but HIPAA and the other many data privacy regs and laws that make a production DBA critical. The libilities to a health care organization are monumental if the data escapes. In my hospital DBA role, not only do I secure in-house data systems, but I have to force vendors to certify and upgrade their databases to the latest service packs to keep the security up to date.

    In another life as a production DBA for a bank system, I didn't develop but assisted a programmer in reworking a critical database program thereby reducing the 80 minute runtime to 7 minutes under full load. My point is that I can do those important production DBA functions and still get the development done.

    The production DBA will not disappear as long as data availability and data security remain critical to business' bottom line.  

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

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