Home/Error Library/sqlserver-7391-distributed-transaction

SQL Server

SQL Server 2016–2022Linked Servers & DTC

9 min read

Msg 7391, Level 16: OLE DB provider was unable to begin a distributed transaction

SQL Server Msg 7391 — Why Won't the Distributed Transaction Begin?

Diagnosing Msg 7391: MS DTC service states, RPC dynamic port ranges, Kerberos double-hop delegation, and disabling transaction promotion safely.

Reviewed by:Principal Database Reliability Architect

Tested Versions: SQL Server 2022 CU15 & 2019 CU28 (Windows Server 2022 / Docker 29.7)

Operational Verification & Reliability Metadata

Last Technical Review: 30 Ekim 2026

Tested VersionsSQL Server 2022 CU15 & 2019 CU28 (Windows Server 2022)

Required PrivilegesALTER ANY LINKED SERVER, sysadmin (for sp_serveroption), and Windows DTC admin privileges

Risk Assessment

HighDisabling transaction promotion breaks two-phase commit atomicity; local rollback leaves remote writes committed

Expected OutputDecoupling remote calls from local transactions or successfully establishing MS DTC / RPC port range / Kerberos delegation

Rollback Procedure:Transition distributed writes to application-tier queues or replace direct statements with pass-through OPENQUERY

Microsoft Docs: Troubleshoot Linked Server & DTC Errors

First 60 Seconds Emergency Protocol:

The error string is a symptom, not the root cause. Do not restart the server blindly. Run the diagnostic queries below to pinpoint the actual failure mode.

▸Symptom

plaintext

Msg 7391, Level 16, State 1, Line 1
The operation could not be performed because OLE DB provider "SQLNCLI11"
for linked server "ERP" was unable to begin a distributed transaction.

Related linked server provider errors sharing the same underlying failure:

plaintext

Msg 7399: The OLE DB provider "MSOLEDBSQL" for linked server "ERP" reported an error.
Msg 7302: Cannot create an instance of OLE DB provider "SQLNCLI11" for linked server "ERP".
Msg 7411: Server 'ERP' is not configured for RPC.

This failure occurs when a cross-server statement requires coordination via a Two-Phase Commit (2PC) distributed transaction, but the Windows MS DTC (Distributed Transaction Coordinator) daemon, RPC firewall filters, or Kerberos delegation parameters fail to negotiate the session.

▸Why Does It Work Intermittently?

A query like SELECT * FROM ERP.db.dbo.table may execute cleanly on its own, but fail catastrophically when invoked from another workflow.

The Trigger: A distributed transaction is mandated only when the remote call executes inside an active local transaction boundary:

•Inside an explicit BEGIN TRANSACTION block.
•Inside a DML Trigger (triggers are inherently transactional).
•When SET XACT_ABORT ON is enabled during remote stored procedure execution.
•When mutating multiple linked servers within the same transaction scope.

Stand-alone queries run without DTC involvement. The instant a transaction context wraps the statement, SQL Server elevates the call to MS DTC, triggering Msg 7391 if infrastructure prerequisites are unmet.

▸Diagnostic Step: Infrastructure & Kerberos Inspection

1. Review Linked Server Attributes

sql

SELECT name, product, provider, data_source, is_rpc_out_enabled, is_remote_login_enabled
FROM sys.servers
WHERE is_linked = 1;

NOTE

SQLNCLI11 is deprecated. Always standardize modern linked server definitions on MSOLEDBSQL.

2. Verify MS DTC Network Configuration

If distributed transactions are genuinely required:

•Ensure the Distributed Transaction Coordinator service is running on both server nodes.
•In dcomcnfg.exe (Component Services), verify Network DTC Access, Allow Inbound, and Allow Outbound are explicitly enabled.
•RPC Dynamic Port Range: Opening port 135 is insufficient. High RPC dynamic ports (49152–65535) must be bi-directionally open between nodes.
•Kerberos Double-Hop Problem: In multi-tier Windows Authentication setups (Client → SQL A → SQL B), SQL Server A must be trusted for Kerberos Constrained Delegation in Active Directory; NTLM cannot pass credentials past the first hop.

▸Step-by-Step Resolution

1. Disable Distributed Transaction Promotion (If 2PC Is Unnecessary)

If you only need remote procedure calls without distributed two-phase rollback:

sql

EXEC sp_serveroption 'ERP', 'remote proc transaction promotion', 'FALSE';

WARNING

Loss of Atomicity: If transaction promotion is disabled, a local ROLLBACK will not reverse mutations committed on the remote linked server. Never apply this blindly to financial workflows.

2. Decouple Queries via OPENQUERY (Pass-Through)

OPENQUERY executes queries directly on the remote server as an independent session, avoiding DTC transaction enlistment:

sql

INSERT INTO dbo.LocalStaging
SELECT * FROM OPENQUERY(ERP, 'SELECT Id, Total FROM dbo.Invoices WHERE Status = 1');

3. Strategic Best Practice: Retire Linked Servers

Linked servers tightly couple database instances, propagating remote lock escalations and network latencies. Modern enterprise architecture decouples multi-database operations using asynchronous message brokers (RabbitMQ/Kafka) or robust ETL orchestration.

▸Related Error Guides & Hub Links

•SQL Server Transport-Level Error 233 (H-33) — Network dropped sockets
•SQL Server Foreign Key Constraint 547 (H-23) — Referential integrity violations
•SQL Server Hub — High availability and enterprise linked server architecture

Other Database Error Triage Playbooks

Other battle-tested diagnostic guides for high-severity database errors.

All Errors (50)

SQLSERVER5 min