Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
Published: May 17, 2016
Updated: July 21, 2016
Applies To: SQL Server 2016
This topic describes cross-database and distributed transactions support for Always On Availability Groups and database mirroring.
Cross-database transactions within the same SQL Server instance are not supported for Always On Availability Groups. This means that no two databases in a cross-database transaction may be hosted by the same SQL Server instance. This is true even if those databases are part of the same Availability Group.
Cross-database transactions are also not supported for database mirroring.
Distributed transactions are supported with Always On Availability Groups. This applies to distributed transactions between databases hosted by two different SQL Server instances. It also applies to distributed transactions between SQL Server and another DTC-compliant server.
Microsoft Distributed Transaction Coordinator (MSDTC or DTC) is a Windows service that provides transaction infrastructure for distributed systems. MSDTC permits client applications to include multiple data sources in one transaction which then is committed across all servers included in the transaction. For example, you can use MSDTC to coordinate transactions that span multiple databases on different servers.
SQL Server 2016 introduces the capability to use distributed transactions where one or more of the databases in the transaction are in an Availability Group. Prior to SQL Server 2016 distributed transactions were not supported for databases in Availability Groups. SQL Server 2016 can register a resource manager per database. This new capability is why distributed transactions can include databases in Availability Groups.
The following requirements must be met:
Availability Groups must be running on Windows Server 2016 or Windows Server 2012 R2. For Windows Server 2012 R2, you must install the update in KB3090973 available at https://support.microsoft.com/en-us/kb/3090973.
Availability Groups must be created with the CREATE AVAILABILITY GROUP command and the WITH DTC_SUPPORT = PER_DB clause. You cannot currently alter an existing Availability Group.
All instances of SQL Server that will participate in the Availability Group must be SQL Server 2016 or later.
Specific cases where distributed transactions are not supported include:
Where more than one database involved in the transaction is in the same Availability Group.
You cannot alter an existing Availability Group to enable distributed transaction.
In production environments you should cluster the DTC service. If you do not cluster the DTC service, SQL Server will use the local DTC service. With the local DTC service, the overall availability of the solution is reduced. When DTC is clustered, in-process transactions can be recovered if the cluster node fails. For an example of how to cluster the MSDTC service, see Cluster MSDTC for SQL Server 2016 Availability Group.
Determine the appropriate default outcome of transactions that DTC is unable to resolve for your environment. For information on how to configure the default outcome see in-doubt xact resolution Server Configuration Option.
The following database mirroring example illustrates how a logical inconsistency could occur. In this example, an application uses a cross-database transaction to insert two rows of data: one row is inserted into a table in a mirrored database, A, and the other row is inserted into a table in another database, B. Database A is being mirrored in high-safety mode with automatic failover. While the transaction is being committed, database A becomes unavailable, and the mirroring session automatically fails over to the mirror of database A.
After the failover, the cross-database transaction might be successfully committed on database B but not on the failed-over database. This would occur if the original principal server for database A had not sent the log for the cross-database transaction to the mirror server before the failure. After the failover, that transaction would not exist on the new principal server. Databases A and B would become inconsistent, because the data inserted in database B remains intact, but the data inserted in database A has been lost.
A similar scenario can occur while using a MS DTC transaction. For example, after failover, the new principal contacts MS DTC. But MS DTC has no knowledge of the new principal server, and it terminates any transactions that are "preparing to commit," which are considered committed in other databases.