July 8, 2010 at 9:15 pm
Had a 20 minute chat tonight with the Sql Server practice manager at a local consulting company. He read my resume and saw my skill set is a traditional production DBA (security, design, performance, HA, indexing etc). His response and tone was like "that's it?" He definitely turned his nose up at the fact that I've chosen to specialize in the data engine. This isn't the first time I've encounter that attitude but it is usually a recruiter or HR person. Hearing it from a practice manager surprised me.
More power to folks who want to work other aspects of the product (SSIS, SSRS etc) or mix in a little .NET but is the industry looking respect for the traditional DBA? Been toying with the idea of learning Teredata maybe it is time if the traditional Sql Server DBA role is going the way of the Cobol programmer.
Curious to hear other people's thoughts.
July 8, 2010 at 9:25 pm
I would suspect that's the case for small companies that need more of a jack of all trades type person as they can't afford specialized people. But in large companies, a traditional DBA is common and in fact multiple traditional DBAs are common. Our DBA team has 6 SQL Server DBAs and probably 12 Oracle DBAs. All of them would be considered traditional DBAs, per your definition at least.
Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
Ramblings of a DBA (My SQL Server Blog)[/url]
Subscribe to my blog
July 8, 2010 at 10:09 pm
I think they key point is "consulting company". A typical consulting company will be more targeted towards larger clients, and thus focussing on BI-type projects. The clients will typically already have DBAs on staff who can keep the solution running.
If an organisation is after a DBA, they're likely to either hire a permanent employee, or a contract employee. They would only really go for to a consulting company for a very short term arrangement - less than 3 months.
July 9, 2010 at 6:43 am
The industry had respect for the traditional DBA?
There are a lot of products and processes out these days, specifically targeted at eliminating the need for DBA's. For some reason we've been identified as the problem for rapid development. I'm not sure why completely. I think it's because databases are persistent. Because they're persistent you can't change your mind about them every 47.5 seconds. That seems to be a major stumbling block for lots of development teams. And so, guilt by association, it must be because the DBA's are stupid/mean/recalcitrant/backwards/ignorant/not team players/whatever.
Yeah, I've seen lots of issues with DBA work lately.
Funny thing is, I've also seen that DBA's, while the job is changing, are becoming more and more important because many of these tools dig really deep holes, really quickly, and you need people who truly understand databases to fill the hole in.
"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
July 9, 2010 at 9:26 am
Grant makes an interesting point. I still remember the launch event for Sql 7 and the presenter saying that new features eliminated the need for the DBA role. Auto-grow,auto-stats, maintenance plans would eliminate the need for the care and feeding of the database. Yeah right.
It has gotten better since then but institutionally I think MS has always had some disdain for our role in the technology industry. My concern is that disdain is growing.
I love the product and see myself having another 15-20 years in the field. Maybe a geek needs to pickup another RDBMS to secure his future and employability?
July 9, 2010 at 9:28 am
David O (7/9/2010)
Grant makes an interesting point. I still remember the launch event for Sql 7 and the presenter saying that new features eliminated the need for the DBA role. Auto-grow,auto-stats, maintenance plans would eliminate the need for the care and feeding of the database. Yeah right.It has gotten better since then but institutionally I think MS has always had some disdain for our role in the technology industry. My concern is that disdain is growing.
I love the product and see myself having another 15-20 years in the field. Maybe a geek needs to pickup another RDBMS to secure his future and employability?
Microsoft has made it easier to do the traditional DBA work, and that is a good thing.
At the same time, I have seen a great expansion of the number of SQL Servers in use, so the net result is even more demand for DBAs. We have well over 500 servers running various versions of SQL Server, so just keeping together the basics of backups, space monitoring, etc. still takes a lot of time. When you add in more complex tasks, like helping developers with application problems and specing and setting up new servers, the total DBA work just keeps increasing.
July 9, 2010 at 2:22 pm
David, I think you were just talking to someone who was a bit full of himself and wanted to plug his company .
People who don't understand what production dbas do have always had it in for them and don't understand why we are needed (and often get paid more than them)
and then something goes wrong or they want something done out of hours..............
I do feel MS have a bias to developers but then they market MSSQL on its ease of use and low operating cost.
---------------------------------------------------------------------
July 9, 2010 at 2:43 pm
BTW, first this I should learn about Teradata is how to spell it correctly.
😀
July 26, 2010 at 7:40 am
David O (7/9/2010)
BTW, first this I should learn about Teradata is how to spell it correctly.
Nah. Not knowing how to spell the product will get your resume in the doors of the pointy-haired bosses who don't know how to read anyway. And that's where you'll make your money. @=)
Think Dogbert.
July 28, 2010 at 8:27 am
I would suspect that's the case for small companies that need more of a jack of all trades type person as they can't afford specialized people.
I think Tara is right on the money here. I come mainly from a small shop environment and for databases the size of the ones I'm dealing with a specialized DBA isn't really cost-efficient. A Grant or a Jeff or a Gail would definitely be able to point out a lot of ways I could fine tune my systems, but since we're talking about tables < 500K rows, the times savings would be milliseconds and probably not justify the consulting fees (even when you scale those milliseconds out over thousands of query runs). To keep such an expert on full-time would see them being underchallenged to say the least.
So, I tend to look for SQL Developers who have moderate DBA skills. As Michael points out, with every release MS makes it easier to get away with this. I can't speak to whether this is due to disdain for the DBA, as David suggests or, less provocatively, recognition of a trend, but it certainly helps lower TCO for SQL Server
With that said, I personally have the utmost respect for the engine junkies and would love to have an opportunity to work more closely with some of them -- which is why I'm a lurker on sites such as this.
You may not need a NASCAR crew chief to tune up your Hyundai, or a Michelin chef to make you a ham sandwich, but that doesn't mean that those sorts of geniuses are obsolete; they simply occupy a niche that isn't a requisite for everyone.
So, except for the large shops, the prejudice seems to lean towards Developer/DBA mixes in the 80/20 or 70/30 range. This is an easier sell for most hiring managers and consultants.
Of course, every time someone posts a question here asking how to restore a corrupt database in Full recovery where there were no log backups and the last Full b/u is 3 months old, we see how where this strategy becomes risky (and how easy it is for developers to "fake" the 20% DBA skill set they claim in the interview).
July 28, 2010 at 8:42 am
Steve Thompson-454462 (7/28/2010)
Of course, every time someone posts a question here asking how to restore a corrupt database in Full recovery where there were no log backups and the last Full b/u is 3 months old, we see how where this strategy becomes risky (and how easy it is for developers to "fake" the 20% DBA skill set they claim in the interview).
The cure to this problem is to sit the interviewee down at a test PC and say, "Here's the sitch. Now fix the database."
If they're faking, they'll throw their hands up soon enough. And if they're stretching the truth but willing to tackle it, you might learn something about their troubleshooting skills and whether or not they're trainable.
Heck, you might even find something neat in their skill set that it never occurred to you to look for.
July 28, 2010 at 9:41 am
I like Brandie's idea. Make them show you some skills. Grab a laptop, a VM, break some stuff, and walk through fixes with them.
July 28, 2010 at 9:43 am
That's a good point, Brandie.
It's not hard for a candidate to spend an hour on Google learning some buzz words so they sound like they know how to manage backups, etc., though they easily forget that info ten minutes after the interview.
A hands-on demonstration is much harder to fudge.
And, as you point out, if they were exaggerating their knowledge but can demonstrate the ability to deal with unknowns in a stressful environment, they still may be worth a shot.
July 28, 2010 at 10:43 am
It's been done to me before, though not in SQL. It was an OS thing. They were testing my server admin skills. And in my defense, I'd never told them I was any good with the OS they had me plunking around in.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply