Wenn mehrere Systeme beteiligt sind, wird’s schnell heikel

Verteilst Du Transaktionen über mehrere SQL Server, oder über SQL + andere Systeme (z. B. MSMQ, Oracle, Dateiaktionen), brauchst Du einen Koordinator.
Dafür gibt’s den Microsoft Distributed Transaction Coordinator (MSDTC).

Früher war das oft fehleranfällig, langsam und schwer zu debuggen.
Seit SQL Server 2016 und besonders ab 2019 hat sich das spürbar verbessert.

Was ist neu?

• Verbesserte Performance beim Two-Phase-Commit
• Mehr Stabilität bei Server-Restarts und Timeouts
• Native Unterstützung für DTC über Always On (ab 2016)
• Mehr Transparenz in System Views und DMVs
• Verbesserte Isolationsbehandlung über Servergrenzen hinweg

Damit werden verteilte Transaktionen endlich praxistauglich. Auch im KMU-Umfeld.

Wofür ich Distributed Transactions einsetze

• gleichzeitiges Schreiben in zwei SQL Server (z. B. ERP + BI-Datenbank)
• kombinierte Transaktionen SQL + MSMQ
• Synchronisierung von Access + SQL + Web-API

Du willst konsistente Daten – auch wenn’s ausfällt?
Dann brauchst Du DTC. Und musst ihn richtig aufsetzen.

Vorbereitung: DTC aktivieren und konfigurieren

Auf beiden Servern:

• Dienst „Distributed Transaction Coordinator“ starten
• Netzwerkzugriff in DTC-Einstellungen aktivieren
• Firewall-Ausnahmen für Port 135 + RPC aktivieren
• NT AUTHORITY\NetworkService Zugriff auf MSDTC geben

Abfrage zur Prüfung:

SELECT * 
FROM sys.dm_tran_active_transactions 
WHERE transaction_type = 3; -- 3 = DTC

Beispiel: DTC mit zwei SQL Servern

BEGIN DISTRIBUTED TRANSACTION;

-- Lokaler Server
INSERT INTO dbo.Buchungen (Buchungstext, Betrag)
VALUES ('Server A', 100);

-- Entferntes System (verknüpfter Server)
EXEC [ServerB].Datenbank.dbo.Proc_BuchungAnlegen 'Server B', 100;

COMMIT TRANSACTION;

Früher war das wacklig.
Heute: deutlich stabiler, mit sauberer Fehlererkennung.

Neuerung: Automatisierte Promotion vermeiden

Früher wurde jede Verbindung zu einem zweiten Server automatisch promoted → DTC.
Ab SQL Server 2016 kannst Du das verzögern (Lazy Transaction Promotion).

-- Erst wenn nötig, wird distributed
BEGIN TRANSACTION;

-- Lokale Operationen
UPDATE Kunden SET Status = 'aktiv' WHERE KundenID = 123;

-- Erst jetzt: remote Operation, DTC wird aktiv
EXEC [RemoteServer].DB.dbo.RemoteProc;

COMMIT;

Das reduziert DTC-Overhead.
Und ist deutlich performanter.

Monitoring: Wer macht gerade was?

SELECT 
    at.transaction_id,
    at.transaction_type,
    at.transaction_state,
    at.transaction_begin_time,
    dtc.state_desc,
    dtc.name
FROM sys.dm_tran_active_transactions at
JOIN sys.dm_tran_current_transaction ct ON at.transaction_id = ct.transaction_id
LEFT JOIN sys.dm_dtc_transactions dtc ON at.transaction_id = dtc.transaction_id;

Damit findest Du hängende oder offene Transaktionen.
Hilfreich bei Deadlocks oder Abbrüchen.

Tabelle: Vorteile der neuen DTC-Implementierung

Mein Setup für stabile DTC-Transaktionen

Beispiel: TRY…CATCH für DTC-Transaktion

BEGIN TRY
    BEGIN DISTRIBUTED TRANSACTION;

    INSERT INTO dbo.Log (Nachricht) VALUES ('Start');

    EXEC [ServerB].DB.dbo.Proc_Eintrag 'remote';

    COMMIT;
END TRY
BEGIN CATCH
    ROLLBACK;
    INSERT INTO dbo.Log (Nachricht) VALUES ('Fehler: ' + ERROR_MESSAGE());
END CATCH

So verhinderst Du hängende Transaktionen und bekommst im Fehlerfall gleich Feedback.

Verteilte Transaktionen sind kein Hexenwerk mehr.

Aber Du musst wissen, was Du tust.

Mit den neuen DTC-Features bist Du nicht mehr der Prügelknabe,
wenn zwei Systeme gleichzeitig schreiben sollen.
Nur sauber konfigurieren –
und nicht vergessen: Rollback muss immer mitgedacht werden.