Last Tuesday I hosted T-SQL Tuesday #012 (see here for the call for participation) and posed the question "why are DBA skills necessary?" This month broke the participation record with 46 people contributing posts – fabulous! Lots of people contributed for the first time too. And what I think is also really cool is that 45 out of these 46 are on Twitter too.
The downside of so many people participating is that it's taken me quite a while to read through all the posts to compile this summary – maybe I should have picked something obscure and boring instead! One of the most interesting things about doing this wrap-up was experiencing a huge variety of blog themes and fonts – a few of which actually made my eyes hurt!
A HUGE thank you to everyone that participated, T-SQL Tuesday doesn't work without you. I really enjoyed reading through everyone's posts and seeing the passion out there for the DBA role. As I've summarized the posts I've added my own comments too.
Here are the posts from all the participants in the order in which their links appeared in my blog post comments (or I dug out additional posts using Google).
Matt tells the story of himself as a database designer making a plethora of hard-to-remedy mistakes 9 years ago before he had DBA skills that would have helped him not make those mistakes. His take is that it's essential to have someone with DBA skills involved in system design as newbie DBAs or developers don't know the impact of design choices on SQL Server. I love this line from his post: "There is a whole world of epic-database-fail out there, and that world needs us."
Noel takes a look at different RDBMS platforms and how the need for DBA skills could change – from Oracle to MySQL to the cloud to NoSQL. Even with automated solutions, he still thinks you wouldn't want to just apply all the default policies and walk away. I'd have to agree.
Pinal's short post focuses on how the line is often blurred between being a database administrator and a database developer. He has a survey in the post which is currently showing 60% of respondents believe they're more a dev than a DBA.
Audrey Hammonds (blog | @Datachix2): T-SQL Tuesday: Why are DBA Skills Necessary? – A Datachix Perspective
Audrey's post is about how some of the knowledge a DBA has is essential for a database developer to have too – but does that make you a DBA? No. I love her medical analogy: "See, asking me, a non-DBA, to attempt to be a DBA is like asking a psychiatrist to perform heart surgery". DBAs are essential to look after SQL Server.
Erik's post explains some of the knowledge DBAs should have as a way of illustrating the problems that can occur if they don't. He also reminds us that one of the major causes of SQL Server being regarded as not requiring a DBA was the marketing around the 7.0/2000 time-frame that proclaimed how easy SQL Server was to use. IMHO that really hurt the image of SQL Server and SQL Server DBAs.
Rob's argument is that you don't necessarily need DBA skills – you need people who can apply the right paradigm to their work. For database work that paradigm is set based.
Aaron (one of my favorite MVP friends) makes a great point that many small business *don't* need a full-time rockstar DBA and that many of the defaults will allow them to continue along happily. But at some point as the business grows and the data/transaction volume grows with it, you cross a line and then a DBA really *is* necessary. I totally agree. When I'm teaching about index fragmentation I always say that at the low end, rebuilding all your indexes every night is probably fine, but as things get larger and downtime becomes important, DBA skills are needed to take a more analytical approach.
Robert Hartskeerl (blog | @rhartskeerl): T-SQL Tuesday #12–Why are DBA skills necessary?
Robert explains how even though there are tools to assist with managing SQL Server, someone has to interpret what the tool is saying and no how to fix the problem. And the tools can be wrong – like the RESTORE bug in SSMS in SQL 20008. Robert also used my favorite phrase… "it depends!"
Erin (my favorite stalker :) recounts some of the problems she's helped with on customer systems that affected business continuity. Her take is that if the data is really important, you need a DBA to make sure it doeesn't get irretrievably damaged or destroyed.
Grant (who scares me sometimes) tells some good stories and preaches the same mantra: at some point you need a DBA who knows how to protect and recover data, perform tuning etc. Even with NoSQL – you're still storing data and you still need to be able to restore it, get at it quickly, etc. Hear, hear.
Steve (who scares me most of the time with his pink cowboy hat) joins the chorus that DBAs aren't always required, but when they are they can save a company a lot of time and money and hence can be a really worthwhile investment.
Jes explains why DBAs should market their skills as a problem-solvers and money-savers, and that a DBA isn't an IT function, it's a business need. Oh yes, and she says that we should all wear super-hero capes!
Bob tells some stories from his DBA past but says that one of the most important DBA skills is to know when to ask others for help. He goes on to say that "presence of DBA skills can make a big difference between just getting something done, and doing something exceptionally well."
Mike lists a bunch of SQL knowledge that most developers wouldn't know or care about, but makes the point that *someone* has to know and care about it, or people are going to get annoyed when performance tanks. He also explains how knowing some DBA skills sets him apart from other developers.
Mark's the first poster to bring up the fact that developers and DBAs often have different priorities – with devs churning out code quickly while DBAs are trying to preserve resources.
Oscar (who I just met at SQL PASS on Monday) lists 14 reasons why DBA skills are necessary and throws down the gauntlet by stating he thinks "most developers have no business in the DB world".
Tamera explains how some DBA skills can help write better T-SQL as you'll know more about how SQL Server is handling the T-SQL you casually throw at it.
Jeremy explains that even with small databases, sometimes a DBA needs to be involved from the get-go, before the hardware is even provisioned.
Kerry explains that databases are hard, and that it takes many different roles to look after a corporations data properly – the DBA being just one of them.
Andy explains how he picked up DBA skills when he became a database developer and how useful they've been for his company.
Portuguese? Google Translate to the rescue! Hmm – Google Translate didn't do such a good job, but I think the gist of Ricardo's post is that too many companies that think that SQL Server doesn't need a DBA.
Andrew makes a very interesting point that consultants know what's best about a product, but only you know what's best for your environment. Totally true – so many clients expect us (consultants) to provide the best answer for them straight away.
Wendy (who I just met at SQL PASS on Monday) says anyone who works with a database needs some DBA skills. And if you don't have anyone with DBA skills, check out the #sqlhelp tag on Twitter. Hear hear!
Pat (who I just met at SQL PASS on Monday) introduces me to an expansion of the DBA TLA I've never heard before: Default Blame Acceptor. While I've never heard it, I totally get it. DBAs are the unsung heroes of countless nasty situations caused by others.
Cade focuses on the skills a DBA has and explains why he thinks troubleshooting is the number-one skill he looks for in a DBA.
Tim (who looks great in a Utilikilt) manages to unite Amish people and brothels in the same post. That takes a different kind of skill.
Geoff's short post tells the tale of someone attempting to use replication as a DR solution without understanding what replication does and does not provide. And that person was a 'DBA', but without DBA skills.
Jason gives some examples of why "what you don't know can hurt you" and then explains three critical things you should know if you're a DBA.
Jason departs from the norm and discusses the NON-technical skills that a successful DBA needs to have. I particularly like the emphasis on a sense of community. I'm a huge community guy and I really like to see those that benefit from the SQL community eventually starting to give back in the form of things like blog posts, tweets, and user group presentations. People really ARE interested in what you've experienced as that will help them when they have the same problem.
Gill tells a story of trying to get an IT department out of the dark ages and under control using his DBA skills.
Brent (our very own Mr Wonderful) talks about when saying 'whoops' isn't code for "oh no, I dropped the database" and how real DBAs need to know enough to fix the junior DBA's "fixes"…
Matt went as far as recording his T-SQL Tuesday message, describing how valuable DBA skills are.
Gethyn Ellis (blog | @SQLGRE): TSQL2SDAY #12 – Why are DBA Skills Necessary?
Gethyn explains some of the problems that can cause business continuity to suffer, all of which could be solved with backups, being taked by someone with DBA skills.
Jack (whose Twitter alias I've been afraid to ask about…) tells a story if disaster and data loss that would have been prevented had someone with DBA skills been involved.
Chris gives some examples of why companies need databases today to stay competitive, and hence need DBAs to keep those databases healthy.
Sal Young (blog | @EmpiricalDataMa): We don’t need no stinking DBAs! (T-SQL Tuesday #12)
Sal describes some of the different DBA specialties there are, and how you need to be prepared to be dealt a hard knock by clueless executives bent on saving company money by laying off employees.
Robert L Davis (blog | @SQLSoldier): T-SQL Tuesday #012 – the DBA as a Modern-day Specialist
Robert (DBM book writer extraordinaire) tells a *really* interesting story of a high-school injury that nearly left him paralyzed because it was mis-diagnosed by GPs rather than a specialist – and draws the analogy to under-qualified people trying to diagnose problems affecting an important database.
Kimberly (lovely wife) highlights a couple of areas where you can get bitten without DBA skills, and explains why *someone* in the organization has to have DBA skills because SQL Server is a *general purpose* RDBMS, and so it needs to be tweaked to work best for your environment.
Kendra draws a very clever analogy between DBAs and veterinarians, saying that both look after birth, death, growth, prevention of illness, and so on.
Jeremiah (who has quite amazing tattoos) says that DBA skills aren't necessary, but instead the ability to learn is what sets the successful apart from the unsuccessful.
Josh recalls how he started out as an involuntary DBA, and thinks about all the mistakes he made that a real DBA would have picked up on. One thing I think we sometimes lose sight of is that *everyone* started with zero SQL Server knowledge…
Josef laments that developers are seen as THE all-knowing entities, which can lead unsuitable designs making it into production and causing problems – which then leads to angst about the database platform which fuels the NoSQL movement.
Jonathan (extended events expert) uses some examples from his work to illustrate some of the problems facing companies without DBAs, and explains how it can take time for a new DBA to earn the respect of the incumbent IT staff.
Cameron reiterates that as the operations you want to do on your database become more advanced, you need someone with higher skills – just like there's a point at which you stop doing maintenance on your car yourself and trust it to a mechanic.
Kelly talks about some of the things a DBA should know, but the most interesting point in his post is about how some vendors seem to have no clue about the database they're running on.
Sean Gallardy (blog | @SeanGallardy): T-SQL Tuesday – Why are DBA skills necessary?
Last but not least, Sean makes the very good point that DBA skills are really necessary when searching for problem solutions on the Internet. Without DBA skills, how do you tell if the advice/solution you're reading is correct and appropriate?