This is my ongoing series of answering T-SQL Tuesday posts far too late to be of any use. Click here if you want to read previous entries.
Paul Randal asked us in November 2010 why DBA skills are necessary. As a reminder, DBA stands for Database Administrator, and this unleashes a discussion outside of the scope of this post about what it means to be a DBA. I use the terms “DBA” and “data professional” interchangeably.
For this week’s post, I can think of two problems that directly affect an organization, and I’ll focus on these in this post using example questions Paul provides to align with the theme.
Problem 1: Business continuity
“How can business continuity be affected by lack of DBA skills?”
One of my jobs as a consultant is to ensure business continuity in the face of disaster. In fact, it is my opinion (and the opinion of many others) that being able to design, implement and test a solid recovery strategy is foundational for any DBA.
If you don’t have backups, you shouldn’t be a DBA. If you do have backups but don’t test them, you shouldn’t be a DBA.
If you do have backups and you test them regularly, well done, you have achieved the minimum level of work acceptable for your job description.
Imagine the many organizations that don’t know about backups and recovery until it’s too late, sometimes resulting in closing down their business.
You need a DBA to help you figure this and other things out, and their work starts here.
Problem 2: The accidental DBA
“At what point does a SQL Server installation need a real DBA to look after it?”
The term “real DBA” is overloaded because many of us came into this role accidentally. I was a network support technician, then a software developer, and finally a data professional through realization that I was good at performance tuning and set theory. I had to learn about disaster recovery (the hard way), running out of storage (the hard way), and slow queries (the hard way).
Paul’s question isn’t a trap or exclusionary. What he’s asking is when your organization has to seek a (part-time or full-time) dedicated person or team to look after the database server that is running your application.
Maybe it was designed by your internal software developers and they never had the knowledge to tune it. Maybe it runs a vendor product that is getting slower and slower, and one of your network team is finding themselves working on fixing problems the server causes.
For me this question ultimately goes to “proactive maintenance.” In other words, if you realize that being proactive with the database server will avoid future problems (missing backups, running out of space, slow query performance, and so on), then it’s time to find a real DBA to look at it, or to upskill yourself in order to take care of it.
This doesn’t necessarily mean a full-time person. There are many “set and forget” configuration options you can apply to a server to leave it humming along for weeks or months at a time. As long as you schedule regular maintenance and periodic patching — which can form part of regular network maintenance — SQL Server will keep on trucking.
The really important thing is making sure you set up alerting. You want to know if a DBCC CHECKDB fails, or if a backup fails, or if the data drive runs out of space, and you want to know as soon as possible. You also want to know (before your users yell at you) if the server is running slow, and you can do this with monitoring software that has alerting set.
As I’ve mentioned here on this site — as have many other folks in the Microsoft Data Platform community — you can get by with cheap or free monitoring solutions. Some of the best maintenance solutions are free as well.
It definitely takes time to “level up” your database administration game, whether it be SQL Server or any of the other players in the market. The important thing is to remember that we all start with zero knowledge, and that you can get by with fundamental knowledge that will apply to all databases, even if you don’t know how index tuning works. Make sure your data access is fast. Make sure you run regular statistics updates. Test your backups regularly. Get as much RAM as you can afford.
Even a handful of skills sets you apart as a “real” DBA. Come on in. The water’s great.