Voice of the DBA

Category: Editorial

  • Do You Really Need HA?

    I ran across a thought-provoking post from Chrissy LeMaire asking if we should reconsider SQL Server HA. The post actually asks if you’ve considered not using it. The default from Chrissy, for most installations, is to use standalone SQL Servers. This isn’t to say she’s against HA solutions (FCIs or AGs), but that they often cause problems and might not be needed.

    It’s an interesting position to consider. For a long time, I avoided SQL Server clusters as they were hard to setup with a lot of complexity, hardware requirements, etc., and didn’t really provide enough benefits over using log shipping with a second server for me.  These days I have clients with mostly AGs, and they seem to run fine. That being said, Chrissy notes that after she left a job, a network outages caused a bunch of downtime. I could see there being downtime, as the old database mirroring (and the it-will-never-die replication) needed a working network. If you have network issues, you better know how to manage your HA technology’s issues.

    I also Brent reposted this on LinkedIn, with some fun comments. There was one great one, which said, “Can confirm. FCI is literally my friend’s largest downtime cause.” That one got me to stop and think a bit. If I were having stability issues with any of these technologies, I’d certainly look to replace them. I value my time off and my sleep.

    I know people who default to using AGs with most servers, mostly to avoid someone calling when a system is down, but to be fair, I also think these are some of the more talented data people I know, so perhaps they can handle minor issues and prevent them from turning into major ones. However, Chrissy brings up a great point. SQL Server HA (or Oracle, PostgreSQL, Linux, etc.) isn’t simple. If you have staff turning over, are they qualified to keep things running?

    Or do things just happen to run without these people until something breaks?

    There is also the RTO issue. If you have a high RTO, like a day or two, is HA worth any amount of effort? Isn’t it better to rebuild things and restore? Especially in the cloud, where I might be able to redeploy a new VM/db/etc. and put data in it? Note, I’d want to be sure that I can get to my backups. The SLA on getting older files might be slow, and if it is, I’d want separate backups.

    I do think that small to medium companies ought to rely more on backups and tools, like dbatools, to provide the ability to recreate a system. Adding in the complexity of HA certainly shouldn’t be the default, especially if you aren’t sure the staff will be around for the long term. The caveat with that might be if you use a company like ProcureSQL, StraightPath Solutions, Dallas DBAs or someone else, maybe you don’t worry about staff turnover.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Poor Name Choice

    I wrote recently about some work with Redgate Clone, and one of the things I did was start up a blank container instance of SQL Server from the image named empty-sql-current. This image contains SQL Server 2019. Clearly, “current” was a poor choice.

    I see this often in various places, where someone will reference “current”, “new”, “latest”, or some other term that denotes the most recent changes. If everyone reading the reference is doing so with knowledge of the past and at a time close to publication, this works fine. However, a year later, does this make sense? At the same time, I do like consistent names that might be used in scripts. If I always want developers pulling the latest item, I might use latest. However, if versions are important, than “latest” or “current” might not be the best choice. Much of the time, I tend to try and get a version or some other specific indicator in a name.

    It’s like seeing the words “the fastest SQL Server ever” (or pick your technology) in a release announcement. At that time, it might be the fastest SQL Server release, but when the next version is released (hopefully) that won’t be true.

    As I’ve matured, I aim to build things that last for the future, thinking beyond what the world looks like right now. This includes architecture decisions and more, but it also includes naming. Reference specific versions, times, etc., with the idea that I want to convey some information with the name. I even name my containers with the port I use because it makes it really easy to see which database container is running on 1433 and which is 41433.

    The other consideration for naming, for me, is to include data in the name that I will use for searching or sorting. Perhaps means using good date practices, like 2025-05-01 and 2025-10-03 to ensure my files sort correctly. That might be very important for things like backup files. Maybe it’s using something like “Customer_Copy_Delete_After_Year_Close” for a copy of data that might be relevant through our current financial cycle.

    I often do like using names that come to mind first, as this can help me find things, but I also have learned to be more explicit when using names as a way to convey information. With modern computing and support for large names, it sometimes pays to be descriptive.

    The only thing I try to avoid is spaces. For the most part, file explorers and web servers handle spaces, but sometimes things break, so I’ve learned to avoid spaces where possible.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Data > Hype

    There is a ton of hype now about using GenAI for various tasks, especially for technical workers. There are lots of executives who would like to use AI to reduce their cost of labor, whether that’s getting more out of their existing staff or perhaps even reducing staff. Salesforce famously noted they weren’t hiring software engineers in 2025. I’m not sure they let engineers go, but it seems they did let support people go.

    For many technical people, we know the hype of a GenAI agent writing code is just that: hype. The agents can’t do the same job that humans do, at least not for some humans. We still need humans to prompt the AIs, make decisions, and maybe most importantly, stop the agents when they’re off track. I’m not sure anyone other than a trained software engineer can do that well.

    I was listening to a podcast recently on software developers using AI, and there was an interesting comment. “Data beats hype every time, ” which is something I hope most data professionals understand. We should experiment with our hypothesis, measure outcomes, and then decide if we continue on with our direction, or if we need to rethink our hypothesis.

    Isn’t that how you query tune? You have an idea of what might reduce query time, you make a change, and check the results. Hopefully you don’t just rewrite certain queries using a pattern because this has helped improve performance in the past without testing your choice. Maybe you default to adding a new index (or a new key column/include column) to make a query perform better? I hope you don’t do those last two.

    AI technology can be helpful, but there needs to be some thought put into how to roll it out, how to set up and measure experiments, and get feedback on whether it actually produces better code and helps engineers. Or if it’s just hype that isn’t helping.

    Ultimately, I think that this is especially true for data professionals, as the training of models on SQL code isn’t as simple or easy as it might be for Python, Java, C#, etc. For example, I find some models are biased more towards one platform (MySQL) than another (SQL Server). Your experiments should include using a few different models and finding out which ones work well and (more importantly) which ones don’t. We also need to learn where models actually produce better-performing code for our platforms.

    If you’re skeptical of AI, then conduct some experiments. Try to learn to use the tool to help you, rather than replace you. Look for ways to speed up your development, or have an assistant handle tedious tasks. I have found that when I do that, I get benefits from AI that save a bit of typing.

    From the Pragmatic Engineer podcast, the best way to deal with some of the hype on AI is with data, take a structured approach to rolling it out, throw in a lot of AB testing measures with different groups or cohorts, evaluate, and see what works well. One of the things the guest noted was that the most highly regulated and structured groups are having the most success with AI. Because they’re careful about rollout, and they are measuring everything. They’ve been measuring time spent, accuracy of tasks and more. Then they decide where and when to use AI, which might be the best advice you get.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Republish: Practice Until You Don’t Get It Wrong

    I was in the UK last week and since I was gone for a week, I’ve decided to take a day off with my wife.

    You get to read Practice Until You Don’t Get It Wrong, which is something I believe in. Or listen to the podcast: https://traffic.libsyn.com/voiceofthedba/PracticeUntilNotWrong_92_v2915.mp3