I thought I would cover significant SQL Server 2019 licensing changes for High Availability and Disaster Recovery. Because it was a big topic of conversation when I spoke at SQL Saturday Edinburgh recently.
Which surprised me a bit because these licensing changes have been in-place for a while now. With this in mind, I thought I would discuss them here to raise awareness about the changes.
To clarify, in SQL Server 2019 there have been some big licensing changes about what you can and can’t do on a passive fail-over instance. Especially if you have Software Assurance.
Which I have to admit I am really excited about. Because it opens up some new possibilities which I will explain below. Of course, there are other significant updates in the licensing guide as well.
Passive fail-over changes
As I pointed out in one of my SQL Saturday sessions at SQL Saturday Edinburgh you can now do the below on SQL Server 2019 passive fail-over (secondary) instance in some licensing situations:
- DBCC CheckDB
- Check Resource Data
As you can imagine, the fact that you may be able to do backups and CheckDB on your secondary databases is a big deal. Especially since this can apply to Log Shipping as well as Always On Availability Groups.
In addition, some of you are probably wondering what exactly the last item check resource data means. I assumed it meant you could query DMV’s.
However, I have since asked elsewhere and it actually covers more than just DMV’s. For instance, it also includes performance counters if required.
I’m guessing performance counters would be useful if you wanted to check why backups or CheckDB were taking too long.
What is a passive fail-over?
Just to clarify, as stated in the licensing guide a passive fail-over instance is one that is not used by clients or doing production related workloads.
If clients are touching this server or you are using it for daily queries for work you will have to license the secondary instance.
One thing I like about the latest licensing guide is that Microsoft have gone into further depth as to what you can and cannot do. As well as making it clearer what exactly a passive fail-over instance is now.
Because in the past there was always some confusion relating to all of this.
Another key point I want to highlight is about using downgrade rights on servers you have purchased SQL Server 2019 for use with.
For example, if you have purchased SQL Server 2019 licenses through Software Assurance and you then decide to install SQL Server 2016 on them. In that scenario the above usage rules for a passive fail-over instance I listed above would still apply.
I also want to point out that this does not just apply for Always On Availability Groups. It also applies to Cluster Instances and Log Shipping.
In fact, I wish these options had been in place for using Log Shipping with SQL Server 2000. It would have made some Log Shipping setups a lot easier to manage back then. Especially ones for larger databases that were very busy.
If this had been in place years ago I would have not had to implement an alternative solution instead. Which I advised as a workaround in the old Connect site before it was closed by Microsoft.
Still, what you can do has changed for the better now. Like I said earlier I want to make sure as many people are aware of that as possible.
Because I want people to be aware what they can potentially do on their secondary instances now without having to license them.
Which is why I also added this as part of one of the sessions I did at SQL Saturday Edinburgh, which you can read about here.
You can read the full SQL Server 2019 licensing guide in detail here. Which will give you a better understanding about the contents in this post. I highly recommend reading this guide instead of the datasheet.
Especially since this licensing guide covers other aspects of SQL Server licensing in detail as well. For instance, how the licensing for Big Data Clusters works.
To clarify, most of this definitely applies if you have Software Assurance. If you are unsure if you have Software Assurance I recommend asking your boss, or whoever deals with SQL Server licenses at work.
Of course, if you are still unsure what applies to you after reading this I recommend discussing things with your license vendor further before changing anything.
I hope the contents of this post helps clear up some confusion about some of the significant SQL Server 2019 licensing changes for High Availability and Disaster Recovery.
Main things I want you to take away from this post is that there are changes and if you are unsure if they affect your SQL Server environment then ask somebody.
As always, you are more than welcome to leave a comment.