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.

Posted in Editorial | Tagged | 3 Comments

Monday Monitor Tips: ServiceNow Integration

Earlier this year I visited a customer that was using the Redgate Monitor webhook to integrate with ServiceNow. However, they were also trying to integrate in a richer way to create incidents and a richer experience.

We took that as a bit of feedback and recently released native ServiceNow integration to allow updates to incidents as status changes. Automatically.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

New Native Integration

Redgate Monitor originally only integrated natively with PagerDuty. Over time, we’ve add other ways to connect to other systems and send alerts or data to them. Slack and webhooks were available first , but recently we’ve changed.

If you click the gear icon in the upper right of Redgate Monitor, you’ll go to the configuration screen.

2025-10_line0097

In here, look for the Notification settings. This likely as an “Improved” tag if you look at it in late 2025. Click this.

2025-10_line0098

On the Notifications settings page, you see email settings at the top. Most customers configure this as email is still a great way to capture alerts and handle routing of info to a team.

2025-10_line0099

If you scroll down then you see the other types of notifications. Slack has been there for some time, and if you click this, you see the details you can configure.

2025-10_line0100

The new alert sinks are ServiceNow and Microsoft Teams. If I click the ServiceNow item, I see some details. I can enter my ServiceNow URL and the API key to connect. I can optionally also close an incident if the Alert ends. That’s always helpful.

2025-10_line0101

Microsoft Teams is similar. Here I’m just sending messages, as I do in Slack. I can enter the URL, which would be for the location I want messages sent. I can optionally send a message when the Alert ends.

2025-10_line0102

We still have the Webhook settings as well, so you can send to your orgs messaging system (Slack/Teams) and another location with a Webhook if you want. This might be useful for a different system or perhaps a dashboard where you are tracking information about databases.

2025-10_line0103

Redgate Monitor has grown to add these new options to give you the flexibility you need to handle alerting staff about database issues.

Summary

Managing a large estate is hard, and it is incredibly helpful to have tools to organize, track, and share information. Redgate Monitor is a great platform for this, and with these new integrations, it can be used alongside existing tools to prevent you from missing any of those important alerts.

Redgate Monitor is a world class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Posted in Blog | Tagged , , | Comments Off on Monday Monitor Tips: ServiceNow Integration

T-SQL Tuesday #192 Invitation: SQL Server 2025 Excitement

It’s that time of the month again, and once again, I’m late and I’m hosting. I was traveling a lot in October and didn’t sort out hosting for this month. I have someone for Dec, and am looking for more in 2026. This will be a focus for me in December this.

My apologies, and I’ll try to do better.

Without further ago, …

The Invitation

Next week many of us are expecting to see SQL Server 2025 released to the public. The RC0 has been out for awhile and slowly we see people testing it. Even Brent has a server being monitored that’s a 2025 instance. Between Ignite and the PASS Data Community Summit, it has to release then, right?

We’ll see.

In any case, there are some interesting changes, including some language changes. While SQL Server is a mature product, and you might not be that excited, I’m wondering if there is anything that you’re looking forward to working on?

I’ve got a few ideas, but let me know what things in SQL Server will make your job easier, please your customers/clients, or maybe generate a little excitement in your life.

A few topics:

  • AI capabilities being added to SQL Server
  • Change Event Streaming
  • RegEx
  • JSON enhancements
  • Batch Mode improvements
  • AG enhancements
  • Security changes for managed identities
  • Password policy on Linux
  • ADR in tempdb

There’s plenty more, so start writing and publish next week, Nov 11. Here are a few more rules.

    • Publish the post sometimes on 2025-11-11
    • Include the logo above
    • Link the logo to this invite
    • Make a comment on this post (or trackback/linkback)
Posted in Blog | Tagged , | 14 Comments

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.

Posted in Editorial | Tagged | 2 Comments