T-SQL Tuesday #12: DBA Skills

This month's T-SQL Tuesday comes a week early so it doesn't conflict with the PASS Summit, which makes sense since many active bloggers will be in attendance. Sadly I won't be, but there's always next year! Paul Randal (blog | twitter) is hosting this time around, and the question he's asking is "Why are DBA skills necessary?" It didn't take me very long to come up with a lot of examples of when DBA skills have proven necessary, particularly in the form of situations where this was realized after the fact. Hindsight is always 20/20, isn't it? I'm sure we all have tales like this – here's just a few of mine:

Project Planning & Requirements

I can think back to a whole slew of projects where myself or other members of the database team were brought onboard way too late and the project had to be disrupted as a result. These typically dealt not with knowledge of the database, but knowledge of the data itself. While having a good understanding of your data is important to the DBA role, it's not just limited to DBAs – good project managers should also understand what data they're dealing with. When they don't, things can often go something like this:

A week or two before launch, some project manager would invite a DBA to a status meeting and say they needed us to provide data X, Y and Z in order to make everything work. These meetings would get particularly interesting when we would tell them that said data didn't exist or that data wasn't licensed for use by their branch of the company and it would cost them a hefty sum to be able to legally display it. Even better yet was when we'd get listed as "holding up" a project and then have to answer to management as to why the real-time frobnigator feed couldn't launch on time (or at all). I'd be more than happy to tell them that had the PM done their homework and/or brought in a DBA much earlier in the process rather than waiting until the 11th hour, this would not have happened.

Database Design

Schema design is another skill that can fall under the DBA realm depending on your organization. It can also belong to a data architect, though I've yet to work in a shop that has someone dedicated to that role. I've seen some perfectly fine database designs come from application developers who claim to have no DBA skills at all, however I'd argue that their actions prove they do indeed have some. I've also witnessed blunders that prove exactly why DBAs should be involved in order to ensure an effective solution is put into place. One time in particular I can remember being asked to take a look at a database that was performing poorly. The first thing I noticed is that every column of every table was of type CHAR(100). Selecting appropriate data types is very important, and failing to do so can have a wide range of negative effects that can haunt an organization for a long time. Database design is definitely an area where DBA skills are necessary!

Database Maintenance

When explaining the tradeoff between complexity and maintenance, I typically use mechanical devices as an example. A can opener is a rather simple machine typically containing 1 or 2 moving parts: a hinge and a rotating cutter. Can openers typically require zero maintenance (with the exception of washing). A lawnmower is more complex, as it has an engine with a few dozen moving parts. It requires fuel and occasional oil changes, as well as a new air filter and maybe a spark plug every few years – some maintenance, but not a whole ton. Cars are significantly more complex and require yet more maintenance, as there's that much more that can go wrong with them. Race cars kick it up another notch – not only do they require even more maintenance than a normal car would need, but they need it much more frequently in order to maintain top performance. Race cars get new tires several times during a race. In-between races, engines are completely disassembled and re-built.

What does this have to do with a database? Everything! I don't consider databases to be all that different than race cars – they are both high-performance machines built for a specific purpose. To make sure they keep running to the absolute best of their abilities, regular maintenance is necessary. Realizing all this and knowing what to do and how to do it is definitely a DBA skill.

My final story takes place at a city where I've done some consulting in the past. One day the fireman who handles the technology aspects of the department came in with questions about making some changes to the SQL Server database they were using, and how to ensure that data didn't get lost. I advised him to take a full backup of all the databases on the machine and test them to make sure they work before starting. He replied that he didn't like to do that because it was such a pain to stop and restart the SQL Server service. Wha??? He didn't realize there were actual backup commands, and thought the only way to backup a database was to stop the service, copy the .mdf and.ldf files elsewhere, and restart it. He was very happy to learn that the server could remain up and running while backups were taking place.

Not Everyone Needs Them

I think my previous example brings up a great point in that not everyone working with a database needs DBA skills, but it's important to realize at what point you should begin consulting others. I've long thought that being stupid is not doing something poorly or incorrectly, but refusing to ask for help when you know others can offer it. The first priority of the fireman above is fighting fires and helping others – he works with the computers when time allows and he realized that I may be able to lead him to a solution in less time than it would take him to figure it out on his own.

Summing it all up

Computers : DBA :: Medicine : Specialist

Thinking back fondly on my standardized testing years, the above analogy came to mind. I think a lot of DBA tasks, such as performing backups, running integrity checks, schema design and the like can be performed by non-DBAs, but the presence of DBA skills can make a big difference between just getting something done, and doing something exceptionally well. Any doctor (in theory) could perform brain surgery, but to ensure the best possible outcome you would probably want to hire a brain surgeon. Anyone can sit at a piano and make noise by hitting the keys, but a higher level of skill is necessary to produce music that others will enjoy. Such is the same with databases.