Do you think we have enough SQL Server experts? Article from Brain indicate there are shortage in SQL Server experts.
“There are certainly many world-class SQL Server experts, and there have been for quite some time. I suppose it’s more of a matter if there are enough available to satisfy demand. One observation I’ll make is that many of “famous” SQL Server experts I know are consultants who presumably aren’t interested in working full-time for a single company in a DBA capacity. Note that I didn’t say the best SQL Server people are consultants; I used the word “famous.” I’ve long suspected that for every PASS pre-con speaker there are dozens of people who are just as talented on a technical level and don’t desire to be famous or simply haven’t had the break that propels them to attention on the community stage. So, I wonder—am I right about that? If I’m right, then I suspect that the lack of expert and very senior SQL Server technologists is largely perception rather than reality.”
I honestly think that there are more than enough SQL Server “experts”, though personally I dislike the term “expert”; it breaks down as "ex" (has-been) and "spurt" (short lived drip).
ReplyDeleteThe real issue is that most employers seem to think that a database administrator (SQL, Oracle, DB2, etc) must also be an "expert" programmer in multiple programming languages aside from just SQL.
I personally administer over 250 SQL databases (not counting system databases) and normally don't have time to pursue creating programs in C##, VB.Net, Python or Pearl or any of a dozen other languages. Fortunately my boss agrees with me and pays me very well for what I do.
The other issue I see with most employers currently, is that they purchase “off-the-shelf” applications and expect their DBA’s to not only administer the database, but also to “fix” whatever issues there may be with a given vendors solution. As often as not, the issues are caused by very poorly designed databases (tables, indexes, stored procedures, triggers, execution plans, etc.) and applications, not to mention poorly researched solutions.
So to sum it up, I believe there are an adequate number of SQL Server “experts”, just not enough employers who understand just what a true DBA really is.
I believe there are 4 main problems.
ReplyDelete1. Many employers have told me that they've had to delay & even cancel projects because they couldn't find talented people to employ. Usually they are talking to me about SQL Server folks. But the problem is not unique to SQL they are finding it challenging to find talented folks in many technology areas.
2. Many consultants often tell me they can't find work.
So one of the problems is a matching one; helping employers find people with the talent they need.
The other is a cost issue. If the consultants with the skills they need cost $300-400/hour the project may not be feasible.
3. Many employers want talented *employees*, ie: people who will have skin in the game & take a long term view. Famous Consultants / contractors might not be suitable.
4. I've worked alongside many folks with SQL DBA & SQL Consultant on their business card. Some people really impress me with the knowledge they have. I like learning from them. Unfortunately a huge percentage of these folks know the 10% that is used 90% of the time & not much more.
Even elementary things like; analysing Wait States &/or determining how much IO a query causes on each table in the execution plan, seems to be a black art they were unaware of, but are often keen to learn.
I believe that is why we see so many poorly performing & inefficient applications. Common causes are Poor schemas, No indexes, No DRI, Dirty Data, Duplicate rows, Poor production practices. (eg: every developer login-ing in as SA, incorrect backup systems) , Using the NOLOCK hint on every query.
I see this stuff in almost every site I visit.
davidjlean, I disagree with you. If that people doesn't know thats things, they aren't sql experts, maybe they are sql developers, but all that stuff is the important to be an expert. I work as sql expert and my work is just to arrive and detect all the problems, performance, security, etc, audit that problems, messure, and of corse improve the performance. Sorry but that people you said aren't sql experts.
ReplyDeleteSQL Server is very good at hiding the complexity. You can do a vanilla install of SQL Server and run your applications with pretty much no problem, provided you don't have plans to scale your applications and the transaction volume is low.
ReplyDeleteBut SQL Server can scale to a very complex level when you start deploying mission critical high volume transactional or BI applications with it. It is at that stage that we have a shortage of highly skilled Data Services professionals who know how to solve a complex data services issue (the issue could be scaling, performance related, design related or purely architectural)
Many employers don't understand the difference that there are two issues or needs:
ReplyDelete1) sql developers
2) dba
SQL developers or scripters, must understand the flow of the business and have a extra benefit if they have background in computer programming. Substituting a dba for a script-er/programmer is not a fix. There is only so much that can be 'squeezed' out of them. I have had scripts that span over 10 pages long.
You can not substitute a programmer for dba , who has not been a dba before. Or have your programmer time imposed on programming for DBA task. Because DBA is not about using a software and clicking about. It's about running the database smoothly and securily, everyday. Their work does not end just because they reminded someone of their password. That's when the real work begins. How to secure the system? Find the items /modules that are causing the system to not run better.
I agree with the first comment. I have seen dba been imposed on to be the entire IT department. DBA should not be managing staff beyond the sql team. Unless it's a micro(less 5 people) company, where security and system maintenance is not an daily task, it's best to have a deicated DBA.