I don’t know what’s in the water in IT departments, and it’s definitely not the fact that today is Halloween. No tricks or treats in this blog post! I’ve had a lot of conversations with companies over the past year that are trying to be mission critical. By mission critical, I mean near 24×7 uptime (give or take). While I think that’s great and definitely an area I’m well suited to help them with from a consulting perspective, what I don’t like to hear is one of the following:

• We don’t have any SQL Server DBAs
• Our <insert worker already doing other things> is our part time DBA

I’m finding many companies are simply lacking a wholly owned, full time SQL Server DBA on their staff. I’m perplexed. Those two things – not having a DBA of any sort and being mission critical – are at odds. Let’s dispel some myths and deal with some realities.

SQL Server Manages Itself

I used to work at Microsoft and am lucky to still have a close relationship with them. Years ago Microsoft had a five nines campaign that launched around the same time we were doing a week long SQL Server 2000 high availability event. They were basically trying to show that Windows was ready for the enterprise and five nines (99.999% uptime – 5.24 minutes of downtime per year). The ad I remember most had the picture of a data center with a lone, empty rolling chair and balloons floating around insinuating everyone is out having fun and things managed themselves basically. They couldn’t have picked a worse time to send such, in my opinion, a wrong message. By the way, here is proof of that campaign. I can’t dig up the ad anywhere. If you have it or know where it is, please link below or e-mail it to me! Anyway, anyone who has done any production work knows that message in that campaign is wrong. Ever get paged at 2AM? ’nuff said.

SQL Server marketing has done an excellent job over the years of making it seem like SQL Server manages itself. To a point that is true with some of the stuff internally in the engine such as statistics (although there are cases where you may have to deal with those manually), etc. All IT shops that use SQL Server have the same basic care and feeding needs, but the scale is different in a small shop vs. a large enterprise. If you think you can effectively manage hundreds or thousands of databases and along with their accompanying instances (and all of the associated hardware) with no DBA or at least having someone on staff who knows SQL Server, I have a bridge to sell you in Brooklyn.

Sure, you can automate some tasks like monitoring and some tasks to take care of known issues, but you still need human beings to interpret what that information is saying. Some things are not obvious. A big part of monitoring is noticing trends – it’s not just for break/fix scenarios. A good DBA automates what he or she can, and deals with the rest. A good example is getting a report in the AM telling you what backups ran successfully or failed. You don’t want to connect to every instance to get that information. It’s time consuming. Spend your work hours dealing with the problems (like making sure the backups are done if failed) instead of figuring out of they ran or not.

Let’s talk about maintenance plans for a moment. I know they are popular and certainly have use. Heck, it’s easy to click some checkboxes, click Next a few times, and bam! Instant maintenance. In my estimation, 9 out of 10 times, it’s always better to code that stuff yourself and implement via SQL Server Agent jobs. That way it’s not a black box. Plus, you can easily alter things to meet your needs. For example, do you really need to rebuild ALL of your indexes at whatever interval you specify? Probably not. You most likely need to monitor what’s going on, anticipate the need based on history, and then have a job that is either manual or scheduled to fend off a problem based on that information. A maintenance plan isn’t going to work there.

Bottom line here is that over time, a DBA should be able transform a shop from being reactive to proactive. HUGE benefit and win for all. That’s why you need someone who knows what they’re doing. They make it look easy even when it’s not.

A Multi-Tasker is Better than Dedicated Staff

I think we’ve all been in roles at some point in our career where we’ve worn multiple hats. Knowing different disciplines can help any role, but you should have a primary focus. For example, a DBA should be able to understand Windows, storage, and networking, but they don’t need to be gurus. However, if you are the lone administrator responsible for everything from Active Directory and Exchange to SharePoint, SQL Server, and beyond, do you really think you’ll be efficient and a deep expert at any one of those – let alone all of them? I’m not saying it’s not possible … just improbable.

The argument, especially in very small shops, is that one person should be able to handle it all. I don’t necessarily disagree. In a small IT shop where there are not a lot of systems, the load is manageable, and nothing is very complex, a jack-of-all-trades may be perfect if they’ve got some experience under their belt. However, if you have complex deployments and numbers, that argument fades fast. For example, do you think your jack of all trades can handle multi-subnet clusters or SAN replication between sites? That’s some heady networking and storage infrastructure that needs proper planning and administration going forward. The wrong person doing the wrong thing could give you lots of downtime and problems.

Look at all of the dimensions of what a person brings to the table, not just the cost in terms of dollars.

Oh, and your developer – not such a good choice for a production SQL Server DBA for numerous reasons. I’ll leave that one alone in this blog post. Could make good fodder for another one.

Yes, Virginia – SQL Server is Mission Critical in Your Environment

That phrase is a spin on “Yes, Virginia – there is Santa Claus”. I’m never surprised anymore that some environments do not consider SQL Server essential. They’ll talk about Oracle or DB2. Yet when I go in and do some work – especially an assessment or consolidation – lo and behold we find out that there tons more SQL Server databases and instances (and the applications that use them) than they thought existed. They only knew about a subset since they were not under any kind of central administration (a different issue I’m not going to touch here). SQL Server may not be powering your Peoplesoft implementation (maybe it is; substitute your favorite application if you’d like), but it’s everywhere else under the sun and used by nearly everyone in one capacity or another. So I would say based on sheer numbers of DBs and instances alone (not even marrying that info to the apps which may be used 24×7), SQL Server is mission critical in your environment whether you like it or not. Welcome to 2011. SQL Server is ready for enterprise class stuff.

As such, it needs to be treated in the same way you do the other RDBMS choices you have. I bet you have Oracle DBAs – why not SQL Server?

The Economics

I also understand the math behind all of this. Hiring folks is not free, be it a FTE, a consultant, or an outsourced DBA service. How much is your data worth to you to ensure you have peace of mind? It’s arguably more important than your applications since your data is a big part of your IP. If you’ve got tight service level agreements (SLAs), recovery time objectives (RTOs), and recovery point objectives (RPOs), having that jack-of-all-trades-master-of-none may work in some cases, but what happens when it doesn’t? The cost to benefit ratio of having someone skilled is not a straightforward calculation that can be done by the bean counters behind a desk .

What I also see is that for whatever reason, SQL Server folks are valued lower than, say, their Oracle counterparts in enterprise IT shops. An enterprise DBA is an enterprise DBA, period. Even in terms of contract work, I sometimes chuckle at what gets sent my way. People want the sun, the moon, and the stars all in one person for very little money. I always tell whoever sends these requests that if they find that person for that rate, hang onto them.

The reality is that someone with a BI background may know very little about relational (outside of data warehouse stuff) and a relational person may know nothing about Analysis Services, Reporting Services, et al. Each one of those things is really a different role that just happens to fall under the banner of SQL Server because that is the branding. An operational DBA may do some of those other tasks, but their primary function is the care and and feeding of your SQL Server environment to ensure it remains up, healthy, and performing. Anything else in my mind is a bonus. SQL Server is a big product – understand that when you set out to find someone for your needs. You may need two or three people, not just one.

EDIT: After I posted, I saw this tweet on the #dba hashtag:

Oops!

Think this means less productivity? That’s a cost … and in this case, having the right person either may have prevented this OR would get them back up and running. Factor that in – you may cost others a lot of time and money with the wrong person, too.

Where Does This Leave Us?

I know this post is going to be a little controversial for some, and you may disagree with me (would love to see you post if so), but in the near 20 years I’ve been involved with SQL Server, I’ve never seen where having someone who really knows what they are doing is a detriment. It’s usually a benefit. 2011 is not different than 1990, 1995, 2000 or any other year – you need to know your stuff as best you can to do a good job. That person coming right out of college with no real world experience may be cheap in terms of cost, but would you trust your 24×7 system to them and no one else? Probably not. Ideally you would have a mix of senior and junior folks because both have value. The senior resources can help and mentor the junior ones.

At the end of the day, realize that if you want to be (or think you are) mission critical, you cannot ignore the simple fact that not having at least one qualified, dedicated SQL Server DBA is a surefire method that will most likely prevent you from ever achieving your goal.