Glenn Berry

SQL Server Standard Edition High Availability Futures

SentryOne Newsletters

The SQLPerformance.com bi-weekly newsletter keeps you up to speed on the most recent blog posts and forum discussions in the SQL Server community.

eNews is a bi-monthly newsletter with fun information about SentryOne, tips to help improve your productivity, and much more.

Subscribe

Featured Author

Itzik is a T-SQL trainer, a co-founder of SolidQ, and blogs about T-SQL fundamentals and query tuning.

Itzik’s Posts

Recently, there has been a lot of somewhat nervous speculation here and here) about what high availability options will be available for SQL Server Standard Edition, once Database Mirroring (DBM) is actually removed in a future release of SQL Server.

Database Mirroring (DBM) was deprecated in SQL Server 2012, with Microsoft suggesting that you migrate to AlwaysOn Availability Groups (which requires SQL Server Enterprise Edition), and further noting, “If your edition of SQL Server does not support AlwaysOn Availability Groups, use log shipping”.

The exact deprecation language was “The following SQL Server Database Engine features are supported in the next version of SQL Server, but will be removed in a later version. The specific version of SQL Server has not been determined. These features are scheduled to be removed in a future release of SQL Server. Deprecated features should not be used in new applications.”

Does this mean that you should immediately stop using Database Mirroring for new applications? I would say, “Of course not!” Database Mirroring continues to work just as it has in the past, and it will not be removed from the product for quite some time. If it makes sense to use DBM to help meet your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) goals, then go ahead and use that feature for new applications. Unlike a deprecated T-SQL language feature (that could be much more difficult to rewrite, test and deploy), it will be much easier to switch from DBM to some other HA/DR technique in the future.

Historically, a deprecated SQL Server feature has not actually been removed for three major versions after the version when the deprecation was publicly announced. If Microsoft follows that pattern, then Database Mirroring will not actually be removed until “SQL Server 2018” (given SQL Server 2014, a speculative “SQL Server 2016” and an even more speculative “SQL Server 2018”).

According to Mary Jo Foley, SQL Server 2014 should be available in early 2014. Let us assume that “SQL Server 2016” is available in January 2016, and “SQL Server 2018” is available in January 2018. If this entirely speculative version timeline ended up being accurate, that would mean that a SQL Server Standard Edition customer would still be able to use Database Mirroring in “SQL Server 2018”, which would remain in mainstream support from Microsoft until January 2023, and would be in extended support until January 2028. That is quite a long time away!

This gives Microsoft (and their Standard Edition customers) plenty of time to come up with a viable replacement for Database Mirroring. Microsoft has several obvious choices here. First, they could reverse the deprecation decision for DBM. That would require no development and testing work from Microsoft, but it would extend the support burden for DBM further into the future. Second, they could allow a limited version of Availability Groups in SQL Server Standard Edition (restricted to one or two replicas). Third, it seems very likely that there will be some feature related to Azure that will be offered as a replacement for DBM). There could also be some completely new HA/DR technology available by then.

SQL Server Standard Edition customers have several obvious choices for what they will do as DBM gets closer to being removed from the product. First, they could elect to simply stay on a version of SQL Server that still uses Database Mirroring (which could be any version from SQL Server 2005 up to my imaginary “SQL Server 2018”). Currently, there are still a large number of SQL Server customers happily using older versions of SQL Server, such as SQL Server 2000 and SQL Server 2005, and it is likely that trend will continue. In my experience, organizations that choose or need to use SQL Server Standard Edition for whatever reason, tend to also be slower to upgrade to new versions of SQL Server as they are released by Microsoft.

Second, they could move up to SQL Server Enterprise Edition at some point over the next several years. After all, there are plenty of compelling features in SQL Server Enterprise Edition that make very good sense to use for a mission critical application that is actually key to your business. Many organizations may find the means to afford SQL Server Enterprise Edition at some point in the future, for a number of reasons.

Third, I am sure there will be many strong incentives from Microsoft for customers to simply move much of their database infrastructure to Azure over the next several years. This could be a perfectly viable alternative in many situations.

Of course, not everyone will be happy with any of these alternatives. If you are really concerned about the deprecation of Database Mirroring (without a completely viable replacement being publicly announced), you have a number of alternatives.

First, you might consider calming down, and waiting a little longer to see what happens as we learn more about future versions of SQL Server as time goes by. It is very likely that Microsoft has not made any final decisions in this area (but you can bet they have thought about it). You could also try reaching out privately to people you know in the Product Group to make your case. The least effective strategy (at least in my experience) would be to loudly and publicly complain about this issue, especially before Microsoft has announced their intentions for the future. Being the public “squeaky wheel” is sometimes counterproductive…

What do you think about this? Is the deprecation of Database Mirroring (with no announced, viable replacement for Standard Edition) a major concern for you? Is this part of some grand design to force you to use Enterprise Edition or Azure? I would love to hear your thoughts!