November 13, 2025 at 3:38 pm
Well, one thing I notice is some apparently conflating the likes of AGs, which are a High Availability solution (HA) with a Disaster Recovery one. They're absolutely not the same thing. DR might be regarded as where you have to go when your HA has failed. So, our HA (multi-site AGs) pulled us out of the fire when someone put a back actor through our power supply into the primary DC, move over to the Secondary DC before the batteries ran out and practically no-one on the HA platforms noticed.
However, in the case of your good old "DELETE without a WHERE clause" situation - your HA does F - no, not going there. But it's of no use. That's when your DR side comes in.
Now, unless your data has absolutely no value (and if so, why are you spending cash on licenses to store it), you MUST have DR options in place. That's not the case with HA though, if your (important, granted) data is held in a small datawarehouse fed by two LOB systems held on other platforms, and folk can do without it for a few days, HA is probably an expensive waste of money. If, however, someone does shear your main power supply, and you're a major hospital group with about 350 systems on SQL Server including 50Tb clinical document processing systems, demographics feeds, dispensary, clinics, Oncology etc., that people's lives literally depend on, then HA is a damn good bet - literally a life saver. The ability to fail over seamlessly is way better than having to wait for a 50Tb restore on a key LOB system - for scenarios where that solution works.
Much of what lies in between those two extremes, it simply depends on what your senior management are prepared to cope with in terms of cost and risk. I don't actually see that as a technical question - but a business one, which has to be framed appropriately by the technical teams in order to support them in making that decision effectively. It's our job to cope with the outcomes of that decision appropriately and to the best of our ability. We don't run HA because I think it's Cool Tech, we run it to protect our patients - and our Board, with guidance, decided that was the best option for doing so.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
November 13, 2025 at 6:16 pm
AOG is great, ...
In a lot of cases, the AOG itself is still available, but the application is trying to hit a specific node that's temporarily offline. So, making all this work seamlessly is not just on the DBA, it also requires that the application / reporting / ETL developers code their connection strings so that they use the AOG listener instead of connecting directly to a specific sever name.
A complexity item that escapes a lot of devs/DBAs. A good reason why you might not want AOAG in a situation
November 13, 2025 at 6:17 pm
...
I feel that a lot of complexity results from situations where someone presents the solution, rather than the problem they are trying to solve. Implementing that solution is the easy path because it is a defined solution. Later on, we find that the person or department providing the solution only had their facts, not the broader picture, thus the solution turns out to be a problem.
Very true. I see lots of people (and vendors, including my employer) presenting a solution before the problem is well defined.
November 13, 2025 at 6:21 pm
...
I don't remember where I read it, but some SQL MVP has recently discussed that VM snapshots and sql backups are most likely all that is needed by the vast majority of SQL Server instances out there. I agree with this person whose name I can't recall.
Depends on RPO/RTO. Certainly can be what you need.
Viewing 4 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply