MS SQL 2017 集群：禁用可用性組的分佈式事務的影響
一家公司擁有一個 Microsoft SQL Server 2017 Enterprise 集群（RTM-GDR，64 位，14.0.2027.2，KB4505224），由一個可用性組 (AG) 和兩台伺服器組成，一個主伺服器和一個輔助伺服器。
這家公司使用的封閉原始碼應用程序似乎執行良好，除了一個功能。使用此功能時，可以在其日誌文件中找到以下錯誤：
Cannot use SAVE TRANSACTION within a distributed transaction根據一個不相關的網站，一種可能的解決方法是通過以下方式禁用分佈式事務：
ALTER AVAILABILITY GROUP MyaAG SET ( DTC_SUPPORT = NONE );經過測試，這似乎可以解決問題。但是，我不確定這種變化的影響。
- 這種變化有什麼影響？
- 集群是否仍處於活動狀態？
- 數據是否仍復製到輔助伺服器？
- 對業績有正面影響還是負面影響？
- 是否剛剛禁用了安全功能？
對您來說不幸的消息是，如果這個封閉原始碼應用程序正在使用SQL Server可能會被棄用，並且它的
SAVE TRANSACTION設計目的不是為屬於可用性組（或任何類型的集群）的數據庫執行，那麼它聽起來像是一個可能已棄用的功能. 更不幸的是，您僅有的三個選擇是：
- 當您使用應用程序的該功能時，徹底驗證它不會破壞任何東西。這應該包括測試該功能並在您的主要節點上測量結果，然後故障轉移到您的次要節點並驗證相同的結果實際上也確實送出到了該節點，並且應用程序仍在次要節點上按預期工作。如果一切順利，那就忍受錯誤。
- 聯繫供應商並與他們溝通，您正嘗試在具有可用性組的集群伺服器上執行他們的應用程序，並且收到關於他們的應用程序的特定功能的錯誤，該功能似乎使用了 SQL Server 的已棄用功能，並且如果可以，您需要他們的確認，和/或他們的應用程序是否支持可用性組。無論如何，如果您選擇選項 1，您可能會想要這樣做。
SET ( DTC_SUPPORT = NONE );如您所見，禁用分佈式事務可以消除錯誤，但它確實會降低您的可用性組的可靠性，我將在下面直接回答您的問題。在這些選項中，您最好的選擇是＃2，這樣您就可以與供應商合作，讓他們了解您嘗試使用他們的應用程序的全部情況。聽起來它不直接支持可用性組，他們可以確認這一點。對您來說不幸的是，這只是供應商的限制，除了我上面提供的選項之外，您無能為力，和/或不使用可用性組/集群，而是有一個替代的高可用性計劃，例如就像維護一個完全解耦的第二台伺服器，您定期將備份還原到該伺服器。（顯然這不太理想。）
要直接回答有關禁用分佈式事務的問題：
這種變化有什麼影響？
當從主節點到輔助節點發生故障轉移事件時，未強化（未送出）的事務存在數據失去的風險。雖然這種風險可能很小，而且我相信只會影響您的分佈式事務本身（例如帶有
SAVE TRANSACTION程式碼的此應用程序功能），但它仍然是一個風險。這在 Microsoft 聯機叢書中為 Always On 可用性組配置分佈式事務進行了討論，特別是當他們說：SQL Server 不會阻止可用性組中數據庫的分佈式事務 - 即使沒有為分佈式事務配置可用性組。但是，如果沒有為分佈式事務配置可用性組，則故障轉移在某些情況下可能不會成功。具體來說，新的主副本 SQL Server 實例可能無法從 DTC 獲取事務結果。若要使 SQL Server 實例能夠在故障轉移後從 DTC 獲取不確定事務的結果，請為分佈式事務配置可用性組。
集群是否仍處於活動狀態？
是的，集群仍然處於活動狀態，您應該能夠通過在主節點上進行微小的數據更改並觀察它在輔助節點上的更新來輕鬆測試它。
數據是否仍復製到輔助伺服器？
是的，和上面的答案一樣。
對業績有正面影響還是負面影響？
與更改無關，並且可能沒有任何區別。
是否剛剛禁用了安全功能？
是的，如果在它們仍然是活動事務時發生故障轉移，您的分佈式事務現在就有數據失去的風險（即，現在成為主要事務的****輔助事務不知道回滾這些事務、前滾或送出它們是否正確），正如我在第一次回答你的問題時所討論的那樣。這對您來說有多大風險將取決於數據對於使用程式碼的功能的重要性，以及您可能明確使用分佈式事務的其他任何地方。
SAVE TRANSACTION