Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Death of the Production DBA

By Brian Knight,

If you see a priest outside your cubical, beware! He could be trying to read you your last rites. If he hasn’t showed up yet, don’t worry, he’ll be over shortly because the production DBA is dead or will be shortly. So how do you avoid becoming obsolete?

Please don’t get me wrong. Speaking from the perspective of an ex-production DBA, I welcome my job’s death and have enjoyed the transition into my new role. Not that I didn’t enjoy watching my backups and CPU utilization on a daily basis, but my new role is much more stable, enjoyable and rewarding.

What ever happened to the production DBA? With every generation of SQL Server, Microsoft makes the management of SQL Server easier and easier; often deceiving many managers into thinking they don’t need a DBA. In Yukon, expect much of the same. Gord Mangione, Vice President of SQL Server at Microsoft was recently quoted in SQL Server Magazine saying "Our goal with ease of use is to let our DBAs concentrate more on working with the software developers-to really become guardians of data…"

As each release of SQL Server passes, a DBA mundane administrative job becomes more obsolete, while the need for a new hybrid DBA grows. The hybrid DBA’s job first came about in SQL Server 7.0 with the introduction of Data Transformation Services (DTS) and has grown even more so with the introduction of XML integration in SQL Server 2000. In Yukon, stored procedures you will be able to write stored procedures in almost any programming language under the sun. So are you a developer at that point or a DBA? My theory is you’re a hybrid.

Shortly after the release of SQL Server 2000, I began to receive call after call from the development staff I support asking how to use certain features. This made me feel like a dinosaur quickly since I hadn’t learned XML yet, nor was it even on my radar. More and more of these types of tasks are being expected of ex-production DBAs. The second you take one of them on, you lower the risk of becoming obsolete, and you’re now a hybrid.

The economy isn’t helping the production DBA either. As the economy worsens, companies can’t afford to have traditional development and production DBAs separated. Instead, many companies are combining the two roles into one. I personally welcome this merging. I was accustomed to not having any input in a project in the beginning and then I was handed the project in disarray when it was ready to enter the production room. Nothing is more embarrassing than trying to explain to a new employee that you didn’t create a database without any relationships in it or nvarchar(1) fields. You had to just grit your teeth and create a backup plan for the ridiculous database.

Now, you have the opportunity to get your hands dirty early. Walk a database up to production and then carry it over the threshold. Now that you’re a hybrid, you have a vested interest in the project from the beginning. If you create a crummy database, then you’re stuck with it. You also may be in charge of training the staff in how to use SQL Server’s XML features, DTS, and in the future the new stored procedure functionality.

Here are a few tips (in order of importance) to becoming a hybrid:

  1. Learn XML – If there is one technology that a DBA must know in the next few years it is XML. SQL Server and other products of all kinds are integrating XML into their system. Not being able to speak this language would be equivalent of not understanding SQL in the next few years.
  2. Learn VBScript – A hybrid DBA will be expected to know at least one other scripting language. These scripting languages will be tightly woven into stored procedures in Yukon and much of SQL Server will go untapped if you’re not up on these.
  3. Learn DTS – The minute you cut a 2-week project into 2 hours by creating a DTS package, your stock rises. Developers will think of you as a peer, not a road block..

I’ll never forget teaching a DTS class a few months ago to a group of mainframe junkies. A few hours into the class, a “mainfraimers” changed their Windows theme to represent a 3270 green screen. I moaned then, but that mainfraimer was one of my best students as the class went on. He saw then that his technology was slowly becoming less and less widely used and was seeking new knowledge. I’m certain there will always be a place for mainfraimers and production DBAs, but what fun will that be?

So what do you think? Post your opinion of what you've seen in the DBA landscape at the forum.

Total article views: 9509 | Views in the last 30 days: 7
 
Related Articles
ARTICLE

The Hybrid

Steve Jones talks about SQL Server Connections, the conference that might be the place to be for hyb...

ARTICLE

Becoming More Productive

Taking a break from SQL Server and DTS, author Haidong Ji shares a few tips and tricks to becoming m...

FORUM

production server slower than development server

performance difference between production server and development server

FORUM

production server slower than development server

performance difference between production server and development server

FORUM

production server slower than development server

performance difference between production server and development server

Tags
career    
other    
rants    
state of the business    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones