Death of the Production DBA
-
Yes, my organization has two of us that are DBAs that happen to be data analysts part of the time. We've also got a full time data analyst and she's good, but let's face it, there's just too much work to go around.
We have dedicated VB programmers and web developers, but every so often I'm coding, too (and two of the developers on the team with me are also functioning partially as DBAs). Our team is 8 strong and of the 8, 7 of us (including our manager, who happens to be the VB super wiz of the group) are hybrids. We'd like to be able to specialize more, but this probably isn't happening in the near future.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley -
In my experience, every "DBA" position I've worked at has required a whole lot more than the standard SQL DBA skillset. In fact, at each job, the vast majority of my work has revolved around writing/editing stored procedures, DTS, debugging queries, and other tasks traditionally delegated to the development team.
Server monitoring, backups, logins, and security - even as they relate to SQL Server - are often handled by the network admins. And even still, a lot of work goes undone. The main problem here is *not* that a production DBA is unneeded - but that management and users are ignorant of all that's truly involved in managing databases and keeping them performing optimally.
Often I am so busy responding to end users' complaints of why ASP pages and reports aren't working, that I am unable to stay on top of the finer points of administering the databases. Managers and users are adamant on having their front-end database applications working *right now*; and when I tell them that the real issue is in the design of the database (normalization or lack thereof, indexes, transaction isolation levels, etc.), and that it will take some time for me to get to the root of the problem and fix it, the response I often get is something like, "Well, we can worry about that esoteric stuff later; right now you just need to give the users something that works."
Yes, I believe production DBAs are still needed. Of course, DBAs need to be able to perform development tasks as well, but I believe that if companies keep forcing their DBAs to neglect admin tasks (or worse, firing them because "SQL Server is simple, we don't need a DBA"), then we're going to see a lot of system crashes, downtime, and slow DB performance.
-
Well stated. The problem is that not only are we unlikely to convince them, it's not always realistic anyways. Gotta pay the bills first. I've tried to adopt the dual roles of mentor & critic. I try to see what they are doing, steer them in the right direction early on - then if they don't listen, shift to the more critical mode. It's almost like being a project manager...strange.
Overall it takes the same amount of time or less to do it right the first time. Even people who should know better fall into the trap of doing something in a hurry rather than doing it right. Developers who fail to apply best practices cause pain...just usually to someone else.
My favorite example is I recently watched a junior developer doing some work, adding items to an array inside a loop. Rather than pre-determining the size outside the loop, a counter was being incremented and the array resized EVERY time. Truly horrible technique. Did it matter in this case? No, it was a web page that gets hit about 10 times a week. What happens when the page (or one built using this one as a template..code reuse) gets hit 1000 times an hour? So...junior developer, trying hard, right? Turns out they had asked for help, this solution provided by a SENIOR developer. Feel my pain?
Andy
-
Great article! I'd like to add that I believe that the days of specializing in any one subject in computing are coming to an end - whether it's databases, development, management, help-desk, administration, etc.
-
Well, it depends. The perception that SQL Server is easy will continue the flow of dabbling developers. Access has been used to create some incredibly ugly databases (ugly in many senses of the term). It allowed the "Make it NOW" group to create and alter databases on the fly with little concern about maintenance, performance or other trivial issues. Someone else will do that.
Those developers are stepping up to SQL Server. I was told in a design meeting with a client that "database design should not take more than 8 hours." They decided to go with their developer to design the database because he could "do it in 4 [hours]".
The production DBA spends their time working with younger developers, and giving advice to project managers. It depends on the size of production and the ultimate goal of the company. It also depends on the individual. Once this job ends what does he want to take to the next one?
quote:
Great article! I'd like to add that I believe that the days of specializing in any one subject in computing are coming to an end - whether it's databases, development, management, help-desk, administration, etc.Patrick Birch
Quand on parle du loup, on en voit la queue
-
This is an interesting thread. My 2cents:
I think the production dba will continue to exist in larger shops. Even with the advances and ease of administering SQL Server 2000, quality of software and development processes have not advanced ver much. As a result, there will still be things that need to be done. If you manage 10 databases, then you probably have lots of extra time (unless your apps are really unstable). As a result, you will probably be doing development, modeling, analyzing, etc.
If you manage 500 databases, you might be strictly involved with the production side of things. change control will also probably be a large part of your job. If you deal with Client/server, you might have lots of password issues. I know I did when I did network admin / client server support.
I think SQL 7/2000 has really made the job of the production DBA easier, but it hasn't made the knowledge obsolete. There are plenty of admins who have to be the production dba, and SQL makes it easer to accomplish tasks. But how many of these network admins understand what they are doing? How many of them post in these (and other) forums with basic questions, with confusion, with the "URGENT!! HELP!!!" tag on their message?
Of course, along with this, management often sees SQL Server as an easy to admin solution and wants things done in "Internet" time. Database design is often required quickly. It must be done today to meet deadlines and deliver solutions.
Not that that is bad. Only so much front end work can be done in a short time and often the business model is not set. I know in my current application, the knowledge we used to make a schema change yesterday wasn't even a glimmer in our eye six months ago. Looking back, there is no way we would have thought about it. So we try to keep a fairly open schema, allowing for new changes that we cannot anticipate.
I know I'm rambling a little, but I think that the death of the production dba (exclusive) is more of a business/dollars decision more than SQL has eliminated the need for skilled DBAs.
Steve Jones
-
Sure there's room for production DBAs but I consider them to be allied to the infrastructure depatment rather than development or application support (other than at a superficial level).
I consider a development dba needs to get involved in nearly everything.
Database design and access (i.e. stored procedures + anything else) as the core skills. The database access layer of whatever language is being used (otherwise how can you be sure what is going on), Data architecture (need to know to design the database), systems architecture (if it's based on sql server storage then expertise in that/relational databases/data flow is vital for design).
Also need to be able to team lead/ project manage to police what other developers are doing and to convince managers that the time scales they are suggesting are too risky for the functionality they expect.
Cursors never.
DTS - only when needed and never to control. -
-
The position i was in prior to the current one was a 90% production role in a team of 5 production DBA's. Admittedly that was a large company with a many databases accross more than one platform. My current position is more like DBA/Analyst. I do think that the small company lack of structured implementation can cause some quite nasty problems, and having only been here 4 months i have not yet got the point over to the developers that if they apply things to my production database there will be problems later. I will be changing the SA password on Monday.
-
I liked Steve and Nigel's comments.
My perspective is based on being from one of those >500 database environments. I am a production DBA. We are closely allied with other infrastructure groups. My own team spends most of their day helping developers. The depth of our involvement with the developers varies. If the application is troubled then we get more involved. Also when the project is large and therefore, generally more complicated, we get more involved.
There is a small but elite group of development DBAs. Their SQL skills are very good. They tend to be narrowly focused and just work on the tasks they are funded for. Their knowledge tends to be deeper on the programming side and lighter on the platform/OS side. Now the majority of developers are not highly skilled with SQL. I wish we had more quality Development DBAs. It does take time, skill, and experience to produce a good dev dba.
One of my main responsibilities as a production dba is to keep the lines of communication open and maintain a high degree of responsiveness to people and events. The production side is more interrupt driven than the development side.
Both admins and developers have a tendency to take rather drastic action when they are under pressure and they can fail to communicate with their counterparts in dev or prod. Either circumstance can spell trouble and lead to further rather interesting self-righteous behavior. Neither circumstance is ideal.
-
-
Beware of what you wish for!
Seriously, I think people of experience and talent can work almost anywhere.
So did you have anything to do with getting SQL PASS set up in Denver?
-
I wish, but come say hi when you come. I think the SSC group will have a booth with RedGate. Andy and I will be here.
Steve Jones
-
Sure...though we could have been in FLORIDA. Steve, order some warm weather for that week!
Andy
-
4 ski resorts open now, wearing jeans and a t-shirt, sunny, a dry 60F
Last year, we were wearing jeans and long sleeve shirts during the super bowl!
Steve Jones
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply