MSDTC in Always On Availability Groups

Question

The company I work for would like to use Always on availability groups architecture in our SQL Server supported application. we have 3 databases straight off of installation and one of those is partitioned by configuration, we currently use MSDTC to coordinate transaction between the three, i.e. if committing to databases A and B, and A commit succeeds, a failure on B means a rollback on A and B as opposed to just B.

We ran into an issue when we saw this article

from my understanding this basically means MSDTC is not supported in an Always on availability group mode. I could not find a replacement for this in SQL server 2012

So my questions are:

1. What options do we have (Shelve or open source Product/Code change)?
2. What is specifically the impact of running MSDTC in this setting (complete crash/missing transactions)?

Thanks in advance, your help is greatly appreciated. Dor

Answer 1

I recently asked a similar question at: https://dba.stackexchange.com/questions/47108/alwayson-ag-dtc-with-failover

> What options do we have (Shelve or open source Product/Code change)?

I think you have two options:

1. Change your app so that it does not need DTC.
2. Change your database setup so that it does not use Availability Groups.

In my circumstance, we're using a commercial app so option 1 is not viable. We are currently using database mirroring and based on recent research I now understand that that is also not supported.

My take away is that it is possible to make it work. But it's not simple to do and it puts you in an unsupported situation - which is not acceptable for us. Therefore, I plan to look at utilizing log shipping and change from having a hot standby (with mirroring) or a warm standby (with log shipping).

What is specifically the impact of running MSDTC in this setting (complete crash/missing transactions)?

If you do decide to make use of DTC with Availability Groups or mirroring you run the risk of having corrupted/inconsistent data in a failover scenario. The article you cited gives a good example of how that can happen.

Admittedly, with Log Shipping the same issue can occur. The argument I plan to make is that with log shipping we'll have the ability to roll to a specific point in time and we can make sure we only move to a point in time where we know everything is consistent.

The commercial app we are using does not support high availability. This is our attempt at making it highly available.