Who’s Caring for Your SQL Servers?
“If three people are responsible for feeding the dog, the dog is going to starve. You must have clear areas of responsibility.” In his book Risk, retired United States Army General Stanley McChrystal shared this quote. It’s from a mentor he had as a young officer. And It helped shape his career.
As a family with pets, I can tell you this quote rings true. If the responsibility for feeding the dog doesn’t rest with one person, everyone will assume that someone else will take care of it. The result? Poor Sadie goes hungry. (This is a picture of our Golden Retrieve, Sadie.)
But, obviously General McChrystal’s mentor wasn’t talking about dogs and their food. He was making a memorable point about the need for clearly defined areas of responsibility.
This applies to business. And, it applies to your SQL Servers.
If no one person is responsible for your SQL Servers, they’ll get ignored. That means backups aren’t tested. Patches aren’t applied. Security isn’t monitored. Integrity isn’t checked.
This puts data at risk.
Who should be caring for your SQL Servers?
That’s the data version of “Who’s buried in Grant’s tomb?”
An experienced Database Administrator is the best person to shoulder the responsibility for the care and feeding of your SQL Servers.
Why can’t a sysadmin?
Sysadmins are smart and skilled at their craft. But, SQL Servers are not like other servers. They aren’t like Domain Controllers, file and print servers, or web servers. They are different.
How?
- Performance. SQL Servers can have performance bottlenecks that have nothing to do with hardware resource constraints. Queries need tuning and indexes need optimizing, among other things.
- Security. SQL Servers have layers of security that extend beyond domain accounts. They have logins, users, schemas, tables, database owners, views, Linked Servers, and much more. All of these affect the security of your data.
- Configuration. SQL Servers have configuration settings that are unique to the platform. MaxDOP, Cost Threshold for Parallelism, etc. There are even best practices for the filesystem format and block size.
- Backups. The standard systems approach to backups may meet your database needs, but often it does not. SQL Server backups must support your Recovery Point Objectives and Recovery Time Objectives. A nightly VM snapshot probably doesn’t.
- High Availability. Using Windows Server Failover Clustering, you can configure the operating system to be highly available. SQL Servers can participate in that, but they take some configuration, too.
- Disaster Recovery. There are a variety of approaches to Disaster Recovery available in SQL Server. These can work in conjunction with DR in the Windows world.
- And more. This list just scratches the surface. But it’s probably enough to highlight that there are nuances to SQL Server, just as there are nuances for sysadmins.
A skilled DBA brings SQL specific experience. They know things like Ola Hallengren’s SQL Server Backup, Integrity Check, Index and Statistics Maintenance are preferred to Microsoft’s built-in Maintenance Plans, and why.
They’ll be able to help prevent outages, detect when something is amiss, and recover more quickly if something does go wrong.
So, DBAs are your first choice.
What if you don’t have a DBA?
Unfortunately, not all companies can justify having a full-time DBA on the payroll. This is especially true for companies that don’t have a vast SQL Server estate. Companies with fewer than 10 or 20 SQL Servers often don’t have enough SQL Server work to keep a full-time DBA busy. Depending on the industry, 50 SQL Server instances may not warrant a full-time DBA.
So, someone else in IT is asked to take care of the SQL Servers in their spare time. This is sometimes called The Accidental DBA.
If that’s your company, set your Accidental DBA up for success.
- Assign one person. As with the dog analogy, make sure that one person is responsible for caring for your SQL Servers.
- Assign a backup. Your Accidental DBA will go on vacation, will have some PTO, may change jobs, or even retire because they picked the winning PowerBall numbers. Assign a backup, someone who is familiar with the responsibilities and who can take over when needed.
- Document Expectations. Your Accidental DBA needs to know what is expected of them. Is it just patching periodically? Or is there more to it? What about monitoring, maintenance jobs, and backup testing? Make sure you define success for them.
- Buy tools and training. To do their job effectively, your Accidental DBA may need some additional software such as monitoring tools. Make sure they know how to use it and how to tune the alerts. I’ve seen a lot of great software become “shelfware” because no one could figure out how to use it effectively.
- Find resources. What happens when things don’t go as planned? Make sure your Accidental DBA knows where to go for information or help.
Some additional resources
Here are some additional resources that may by helpful to your Accidental DBA.
- Working Without A SQL Server DBA? Do These 10 Things Now – The SERO Group
- SQL Server Maintenance: 10 Things to Keep Your SQL Server Running Well – The SERO Group
- 10 Unseen Things Successful DBAs Do – The SERO Group
- Using VM Snapshots to Backup SQL Server? – The SERO Group
- What’s the Difference in SQL Server FCIs and AGs? – The SERO Group
Does your Accidental DBA need some help?
We help a lot of companies that used to depend on sysadmins as Accidental DBAs. We provide expert-level DBA team services without the HR costs associated with a FTE. Our team has SQL Server knowledge, the mature processes, and the SQL Server tools needed to help keep SQL Servers healthy, secure, reliable, and performing well. It’s call SEROShield DBA Team as a Service.
If you’d like to learn more, contact us to schedule a short introductory call.