Scary and Dangerous Things in SQL Server
Some things are scary. Other things are dangerous. And in SQL Server, you can have both scary and dangerous at the same time. Scary, that we can deal with. But dangerous, particularly things that are deceptively dangerous, is bad.
Scary things
Let’s start with scary.
Some things give us pause. We see them, think about them, and begin listing all the ways that something could go wrong.
Rappelling. Rappelling is a good example. Backing up to the edge of a rock mountain face with nothing between you and the distant ground. Leaning back as far as your can. Extending out from the safety of the ledge. Jumping backward with only a rope. It’s unnatural. Our instinct tells us we shouldn’t do it. Every fiber of our being screams “Nope!”
It’s scary.
But just because it’s scary doesn’t mean it’s unsafe. Or dangerous. With proper training and gear, rappelling is a great experience. It’s a lot of fun. And it can be done safely. We are aware of what we’re doing. We have a heightened sense and an increased awareness of the things that can wrong. And we purposely take steps to mitigate any danger present.
Scary things in SQL Server
In SQL Server, upgrades and server migrations can be scary. What happens if things go wrong? Can the migration be completed during the maintenance window? Will users be able to login when the time comes? What about performance afterward?
These are very real issues.
But, as with rappelling, we can take steps to mitigate the scary issues. We can meticulously plan the upgrade/migration. We can perform the upgrade/migration in a test environment first, allowing users to validate and approve before production is ever touched. Backups can be taken before the upgrade begins. The VM can snapshotted.
In short, we’ve identified the potential problems that could arise and we’ve taken precautions.
It may be scary, but it’s safe.
Dangerous things
Dangerous things are more concerning, especially if the danger is not recognized.
Walking along the side of a snow-covered mountain on a peaceful day. The sun warms your face. You can see for miles. Beauty abounds. It’s an exhilarating experience, a serene journey, a peaceful adventure.
Yet, it can also be dangerous. A foot or more beneath the crunch of each step, a layer of ice may have formed between two layers of snow. The ice creates a seam, a seam with little friction. It wouldn’t take much for that snow above the ice to begin sliding, creating an avalanche. And as we all know, avalanches are very dangerous for everyone nearby.
Dangerous things in SQL Server
In SQL Server, danger comes in many forms. Everything may seem ok, at least on the surface, but something could go very wrong, very quickly.
- Untested backups. Having backups but not testing them regularly.
- No alerts. A production SQL Server without configured alerts.
- Ignored alerts. Alerts that are ignored because there are too many false positives.
- Untested Disaster Recovery Plan. A crisis is not the time to try to figure out your DR.
- Assumed RPOs and RTOs. Not being able to recover to the right point in time in the allotted time.
- SQL Server health. Uncertainty about how your SQL Server is configured.
- Deferred maintenance. Preventative maintenance jobs take too long to complete so they are disabled.
- Unpatched SQL Servers. Patching is not scheduled regularly.
- Out of Support SQL Servers. There’s simply no time to upgrade so ancient versions of SQL Servers are still hanging around.
- Reacting rather than responding. Addressing the symptom rather than fixing the problem.
- Conflating HA and DR. High Availability and Disaster Recovery are similar but not interchangeable.
- Unmonitored SQL Server environments. SQL Servers are left on their own to report issues.
- Elevated permissions. Too many people with sysadmin or dbo privileges.
Of course, this is not a comprehensive list of all the dangers that can lurk in a SQL Server environment. I’m sure you have some from your experiences. Feel free to share in the comments below; I’d love to hear them.
Mitigating dangers in SQL Server
Recognition is the first step. We must identify and acknowledge the dangers inherent in our SQL Server environment. Then we can do something about them. We can take steps to mitigate the dangers, to reduce or even eliminate the problems we’ve identified.
Here are a few posts that may help.
- How Often Should I Test My SQL Server Backups?
- Is My SQL Server Configured Properly?
- SQL Server Assessments
- When Was the Last Known Good DBCC CHECKDB Integrity Check?
- Should I Upgrade SQL Servers that Are Out of Support?
- High Availability and Disaster Recovery in SQL Server
- DBA as a Service
- Securing Your SQL Servers, What Should You Audit?
And, of course, we’ll be happy to help. It’s what we do.
Want to work with The Sero Group?
Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation.
Schedule a call with us to get started.
(To give credit where it’s due. The idea for Scary vs Dangerous was adapted from Jim Koch’s excellent and entertaining book Quench Your Own Thirst.)