为什么事务以分布式（DTCXact）方式运行？

Question

我实际上是在尝试分析和解决一些经常发生的死锁，这些死锁都至少包括一个名为“DTCXact”的事务，这让我问。

我对生产服务器重复运行以下查询：

SELECT  DTAT.transaction_id ,
    DTAT.[name] ,
    DTAT.transaction_begin_time ,
    CASE DTAT.transaction_type
      WHEN 1 THEN 'Read/write'
      WHEN 2 THEN 'Read-only'
      WHEN 3 THEN 'System'
      WHEN 4 THEN 'Distributed'
    END AS transaction_type ,
    CASE DTAT.transaction_state
      WHEN 0 THEN 'Not fully initialized'
      WHEN 1 THEN 'Initialized, not started'
      WHEN 2 THEN 'Active'
      WHEN 3 THEN 'Ended' -- only applies to read-only transactions
      WHEN 4 THEN 'Commit initiated'-- distributed transactions only
      WHEN 5 THEN 'Prepared, awaiting resolution'
      WHEN 6 THEN 'Committed'
      WHEN 7 THEN 'Rolling back'
      WHEN 8 THEN 'Rolled back'
    END AS transaction_state ,
    CASE DTAT.dtc_state
      WHEN 1 THEN 'Active'
      WHEN 2 THEN 'Prepared'
      WHEN 3 THEN 'Committed'
      WHEN 4 THEN 'Aborted'
      WHEN 5 THEN 'Recovered'
    END AS dtc_state
FROM    sys.dm_tran_active_transactions DTAT
        INNER JOIN sys.dm_tran_session_transactions DTST
                         ON DTAT.transaction_id = DTST.transaction_id
WHERE   [DTST].[is_user_transaction] = 1
ORDER BY DTAT.transaction_begin_time

它始终显示与此示例类似的结果：

2414848764;DTCXact;2016-01-28 10:24:41.983;Distributed;Committed;Committed 2414896908;DTCXact;2016-01-28 10:26:05.847;Distributed;Committed;2031206-2017Committed; :26:29.017;Distributed;Committed;Committed 2414918503;user_transaction;2016-01-28 10:27:06.823;Read/write;Active;NULL 2414918551;DTCXact;2016-01-27301 ;坚定的

此结果表明大多数事务以分布式方式运行。我真的不知道为什么。一些服务器集群有两个节点。其他人不是。他们的结果是相似的。

事实：

• MSDTC 服务正在所有 SQL 服务器上运行。没有一个 SQL-Servers 有任何链接服务器。
• remote trans proc 在 sys.configurations 中设置为 0。
• 我在代码中没有发现显式Begin DISTRIBUTED Transaction或SET REMOTE_PROC_TRANSACTIONS用法
• TransactionScope在代码中没有定义/用法
• 找到一个描述如下的类： //COM+ Transaction mgr using "Service without Components" model built according to System.Transactions.TransactionScope (NET 2). I don't know what this means.

导致这些事务的 asp.net Web 应用程序通常总是从同一个 SQL-Server 上的同一个数据库中读取和写入数据。可能有一些极少数例外，尤其是在夜间复制一些数据时运行，但我不希望看到大部分事务整天都在分发。

我跟踪了我发现正在运行分布式事务的 SPID 的操作：

这是跟踪的示例结果：我RPC:Completed在一行中看到数十个事件，然后是 2 个DTCTransaction事件（第一个：EventSubClass=" Enlisting in a DTC transaction", 2nd EventSubclass=" Propagate Transaction"）。所有目标都指向同一个数据库。没有TM:Promote Tran xxx事件发生。

我发现这些查询在 .net Windows 服务中的 IIS（托管 Web 应用程序的地方）上运行，该服务也使用相同的数据库并执行作业。这第二个应用程序可能会导致 DTC 吗？？

我在网上搜索，没有找到类似的问题或任何答案。所以我想知道这可能是什么原因？或者我想念什么知识来理解这一点？

Answer 1

您是否尝试分析单个会话以查看其事务是否/何时被提升为分布式？例如，使用服务器端跟踪，例如DTCTransaction（可能还有TM: Promote Tran xxx）事件类。您还可以在 Windows 中监视详细的DTC 活动。

我会分析单个 SPID 的所有可能看起来的连接、执行和与事务相关的事件，同时它执行一些有代表性的工作。注意：由于开销，分析最好在测试系统上完成，使用服务器端跟踪或等效的扩展事件。如果您真的别无选择，请不要在本地测试实例之外使用 Profiler UI。

如果我无法看到应用程序源代码或与开发人员讨论事务的使用，这可能是我开始隔离原因的方式。

也可能是应用程序、其数据访问层或客户端驱动程序设置为在访问第二个本地数据库或在同一事务中使用第二个连接时促进事务。甚至可能有一个明确的BEGIN DISTRIBUTED TRANSACTION. 也许TransactionScope（或类似的）正在 ADO.NET 中使用多个连接。看：

• 使用 System.Transactions
• System.Transactions 与 SQL Server 的集成
• 分布式事务 (.NET Framework)

有很多可能性，但追踪/分析至少会为您提供一些关于将调查重点放在何处的线索。

我的猜测是，这很可能是您的应用程序开发人员使用 .NET 连接和事务的方式的意外副作用，可能与 IIS 的配置方式相结合。

分布式事务似乎确实以某种方式与您的“事务管理器”类相关联。您的代码中不必有明确的TransactionScope，这只是一个常见的向量。

在观察对 DTC 和 SQL Server 的影响的同时逐步执行应用程序代码（和数据访问组件）可能是确定分布式事务被调用或登记到的确切位置、时间和原因的最佳方法。

现在问题已过时，已被编辑，但其他原因包括：

• remote proc transaction promotion设置为 true 的链接服务器。这会导致本地事务被提升为分布式事务。

• sys.configurations 中的旧配置设置remote trans proc，与“远程服务器”一起使用时。另请参阅会话选项。SET REMOTE_PROC_TRANSACTIONS