Cash Rules
Most people, when they get through paying for Azure, and SQL Server Enterprise Licensing, are left with a hole in their wallet that could only be filled with something that says “Bugatti”, and has a speedometer with an infinity sign at the end.
Recently, while working with a client, I found out that it’s even worse than I thought.
DBCC CHECKDB and You
When you license SQL Server with SA, you get a free warm standby server. This is true for a FCI, Log Shipping, Mirroring, or AGs. Not combined, of course. I said “one warm standby”, not “every warm standby”.
The second you offload anything to one of those servers, you need to license it like it’s another server. I’m okay with that. It’s totally worth the money to offload some queries. I never quite understood it for maintenance tasks, but hey. It takes all kinds.
Savvy DBAs know that you can’t REALLY offload DBCC CHECKDB to another server unless it’s the recipient of a full backup or SAN snapshot specifically for that task. Running DBCC CHECKDB against a Log Shipped, Mirrored, or Availability Grouped database doesn’t necessarily tell you if the Primary in any of those scenarios is corrupt. Ditto that checking the Primary doesn’t tell you if the Secondary is corrupt.
Those same savvy DBAs may want to run DBCC CHECKDB on a Secondary before failing over.
After all, you restored a Full backup many moons ago, and you’ve just been adding transactions ever since. SQL isn’t sending bad underlying blocks from your data files over the wire.
Who knows what’s been going on over there?
Down and downer
When I found that our client, who has many savvy DBAs on staff, wasn’t running DBCC CHECKDB on their AG secondaries in Azure, I was puzzled, and I asked why.
They mentioned licensing costs, and I said “but that’s just for offloading, not for additional checks, right?”
Wrong.
Lo and behold, they had emails where licensing reps told them that if they run DBCC CHECKDB on a Replica, the server is considered active, and they have to fully license it.
Just to make sure they’re not failing over into corruption.
Choices
This leaves you with one terrible option, assuming you don’t want to double your licensing costs.
You have to wait until you fail over, then run DBCC CHECKDB, and hope it doesn’t find anything.
If you want to automate it in case of unplanned failovers, you’re putting kicking off a DBCC CHECKDB after an unplanned failover in the hands of a piece of code that may need to understand if it’s not in a maintenance window.
This does not give me the warm fuzzies.
How about you?
I’m curious to hear from anyone out there in a similar situation.
If you’re using Azure
[Crickets]
And AGs in Azure
[Crickets Intensify]
Are you running DBCC CHECKDB on Replicas?
[Crickets Block Out The Sun]
And if so, are you fully licensing that secondary?
[Crickets Become The Universe]
Thanks for reading!
24 Comments. Leave new
Nope, and for the reason you mentioned.
Looks like it’s just us and the crickets 🙂
I may have missed something but you mentioned paying for Azure and SQL Server licensing. I assume this article is referring to running SQL Server on an Azure VM? With Azure SQL, you don’t pay for an actual license. How does this change in an Azure SQL environment?
Hi Randy — check with your Azure rep. I don’t have a direct line or any info there.
In Azure SQL DB you pay by the set DTU (by hour), and you can enable up to 4x async secondaries. By default they are RO secondaries, so you can run any RO workloads there. So if you enable say 1x secondary then you pay for that additional server in addition to the primary server. SQL licencing is bundled into the Azure SQL DB costs by hour you run that DB – and you cannot change that model – however the secondary DB can be the same or different DTU as on the primary server, so you have wiggle room to manage costs. In my view Azure SQL DB “AAG” (PaaS) is orders of magnitude easier to config than SQL AAG on a VM (IaaS) (assuming you have what you need in PaaS). https://docs.microsoft.com/en-us/azure/sql-database/sql-database-geo-replication-overview
Instead of avoiding AGs in Azure, just use a very weak machine, and resize it if you actually need to failover. The whole process can be automated. Mind you, this approach does risk missing RPO, since weaker machines might not be able to process incoming data fast enough, and risks missing RTO objectives, since the resize might fail.
That sounds iffy!
“Other than missing your RPO and RTO, it works great!”
Not sure if this is a comedy act or trolling, heh.
That’s just mean and greedy
how is this different in AWs or google cloud? if you set up availability groups you still have to pay for the licensing if you run checkdb on the secondary
Mark — are you SURE about that?
Depends on what your environment is in AWS – RDS or BYOL. RDS with multi-AZ, you’re paying for the privilege of having Amazon take care of replication for you. BYOL – it’s just like having your own servers (EC2s), they just happen to be instances in AWS. You could skate by with taking a snapshot, running an on demand instance based on a restore of the snapshot, run checks against that instance, then shut it down. The multi-AZ has built-in failover, so testing on an AZ member (not the active one) may work, but I don’t know what the impact is on replication vs performance while that is taking place.
Steve – errr, in RDS, how do you propose querying & testing the mirror?
With the intent of breaking the mirror to do that, but after some research on this, I don’t think you can break the mirror on your own in RDS.
Correct. Welcome to Platform as a Service, aka DBA as a Service. It’s like being a developer when someone else is the DBA, heh.
Well, the steps are there to drop an AZ instance, which includes set partner off, but what is the availability of that database outside the of the RDS setup? I was hoping to find that on some site like brentozar.com….
ALTER DATABASE SET PARTNER OFF;
GO
DROP DATABASE ;
GO
…database, not instance…
A separate non-AG machine using MSDN in addition to AG? I did read some licensing details a while back. I survived the brain damage. I seem to recall that if a server is used to test with a copy of production data, it can use MSDN. You can’t process the data and make new production data and then move it back to the production server. If you do that, you need a production license. So, perhaps MSDN is the way to go for a pure CheckDB offload test machine. Would be okay to test production upgrades too.
What I’ve always wondered is about backups – not the user DBs (I know that will cost me licenses), but the system databases. I think it is a good idea to have up-to-date backups of these, but would that count as the secondary as being active?
Maybe if the system database does not have user logins or data?
Not sure if I am missing something here, but how is that different to any other AG deployment? AFAIK the same licensing restriction is also applicable for on-premises setups (tin or VM), in that pretty much any activity on the secondary will necessitate licensing. I don’t think this is an additional restriction for Azure.
Also, my understanding is that if you are licensing the Azure VM inclusively (i.e. not BYOL), you are going to be paying the SQL Server license costs irrespective of whether it is a passive or active AG secondary (ouchy).
Dave — I’m not the final word on licensing, but I’ve seen leeway granted to physical customers running (many millions of dollars in hw/licensing) who want to make sure they’re not failing over into corruption. That’s an important distinction from “offloading” checks.
Dave is spot on – its the way SQL AAG secondary licencing on VM, IaaS, etc has worked for a long time – no surprise there? You deploy that same architecture to AWS, Google, whatever, the licencing is applied the same way. Perhaps there could be an opp here for SQL licencing to include a new “special offload” right for DR only activities? That could make sense for customers in that position.
Yep – we’ve had this statement confirmed to us by a rep here in Oz as well. “Want to check your DR databases do ya? That’s activity, you’re screwed”. I was just as shocked as everyone else in the room.
😐