This deck was presented at SQL Relay 2015 in Bristol; In this deck we will look at some of the new capabilities that are slated for release as part of the Microsoft SQL Server 2016 platform. Demo code for this deck can be found at: http://1drv.ms/1PC8707

1. SQL SERVER 2016 – ALWAYSON
AVAILABILITY GROUPS
New features and enhancements

2. Tuning blog: http://www.sqlperformance.com/
E-mail ebooks@sqlsentry.com for free copies of our $10 e-books:

3. DEMO CODE
Demo code for this slide deck can be found at;
http://1drv.ms/1PC8707

4. YOUR PRESENTER
• John Q Martin
o Sales Engineer for SQL Sentry
o Worked with SQL Server for ~10 years
o Consultant, SQL DBA, Dev & BI Developer
o Former Microsoft Premier Field Engineer
• Contact Information
o Email: Jmartin@SQLSentry.com
o Blog: http://blogs.sqlsentry.com/author/johnmartin
o Twitter: @SQLServerMonkey
o LinkedIn: https://uk.linkedin.com/in/johnqmartin

5. AGENDA
• Introductions
• Enhancements
o Enhanced Availability Configuration
o Load Balanced Active Secondaries
• New Features
o Support for Group Managed Service Accounts
o Distributed Transaction Support
o Database Health events cause failover
• Wrap Up

6. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary

7. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary

8. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary

9. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary

10. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary
SQL Server 2014 & Prior, this
will result in system offline.

11. ENHANCED AVAILABILITY
• SQL Server 2016 Increases the number of Automatic Failover Partners
o Now possible to have two failover partners in addition to the primary.
o True High Availability now possible.
SqlDb01
SqlDb02
SqlDb03
Listener
Primary
SQL Server 2016 the system
will be online as the listener
fails over.

12. DEMO
Improvements in Availability with additional Failover Partners

13. LOAD BALANCED READ-ONLY REPLICA
• SQL Server 2014 routing lists were the order of the secondaries that you
wanted to access in a failure precedent order.
alter availability group [sqlLabAg01]
modify replica on 'sqlLabDb01'
with
(
primary_role(read_only_routing_list = ('sqlLabDb02','sqlLabDb03','sqlLabDb01'))
)
;
go

14. LOAD BALANCED READ-ONLY REPLICA
• SQL Server 2016 allows for groups of replicas to be specified to accessed in a
round robin order.
o Note the additional parentheses in the routing list.
alter availability group [sqlLabAg01]
modify replica on 'sqlLabDb01'
with
(
primary_role(read_only_routing_list =(('sqlLabDb02','sqlLabDb03'),'sqlLabDb01'))
)
;
go

15. LOAD BALANCED READ-ONLY REPLICA
• Allows for scaling out read-only workloads natively
o No need to code bespoke access to secondary replicas
o Workload will adjust in the event of a failover
• Need to be aware of redo latency
o Important to monitor the redo queue as the load balanced replicas could be at different points
in redo process.
• Try to avoid mixing Synchronous and Asynchronous replicas in the same
load balance group for data consistency.

16. DEMO
Distributing load between Secondary Replicas.

17. GROUP MANAGED SERVICE ACCOUNTS
• Managed Service Accounts (MSA) introduced in Windows Server 2008
o Required domain functional level of 2008 or above.
o Remove the need for manual password rotation.
o Domain level object that can be granted access line any other user account.
• Limited to a one to one mapping between MSA and Server
• SQL Server supported MSA from SQL Server 2012 and above
o Great for standalone servers.
o One to One mapping reduced meant no Kerberos for AG configurations.

18. GROUP MANAGED SERVICE ACCOUNTS
• Group Managed Service Accounts (gMSA) introduced with Windows Server
2012
o Require Domain Functional level of 2012 or above
o Same advantages of MSA
• Can be managed by multiple machines
o Machine accounts are added to domain security groups.
• SQL Server 2016 supports the use of gMSA
o Now allows same account on all Availability Group replicas, and Kerberos authentication
against listener.

19. DEMO
Using Group Managed Service Accounts with AlwaysOn Availability Groups.

20. DISTRIBUTED TRANSACTIONS
• AlwaysOn Availability Groups in SQL Server 2012 & 2014 DO NOT
SUPPORT Distributed Transactions.
o Cross Database, intra-instance queries
o Cross Database, inter-instance queries
• Biggest blocker for the adoption of Availability Group technology.
o It functions but will is not supported.
• SQL Server 2016 fixes this problem.

21. DISTRIBUTED TRANSACTIONS
• Requires Windows Server 2016 in order to support the use of Distributed
Transactions.
o Due to a change in the MSDTC that is not presently in Windows Server 2012/R2.
• In-Doubt Transactions can occur in the event that there is a discrepancy
between SQL Server Database Transaction Log and MSDTC Log.
o Can result in SQL Server shutdown or suspect databases.
• In the event of a failover the recovering database will contact the old ‘primary’
server for DTC.
o This will allow the system to complete crash recovery.

22. DATABASE HEALTH MONITORING
• SQL Server 2016 will complete an Availability Group Failover if database
health is degraded.
o SQL Server 2012 & 2014 required an instance level event in order for a failover to take place.
• Availability Group is still the unit of failover in the event of an issue.
o Detection of issues in one database will cause all databases in the Availability Group to
Failover.

23. QUESTIONS

24. THANK YOU!
• Slides will be available at http://blogs.sqlsentry.com/author/johnmartin
• E-mail ebooks@sqlsentry.com for free copies of our e-books:
o Just tell them where you met me
• My contact info for other questions:
o Email: Jmartin@SQLSentry.com
o Twitter: @SQLServerMonkey