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?”
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.
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
And AGs in Azure
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!