wake-up-neo.net

Eine verteilte Transaktion kann nicht gestartet werden

ich versuche, SQL gegen einen Verbindungsserver auszuführen, aber ich erhalte die Fehler.

BEGIN DISTRIBUTED TRANSACTION
SELECT TOP 1 * FROM Sessions


OLE DB provider "SQLNCLI" for linked server "ASILIVE" returned message "No transaction is active.".

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

Es gibt zwei vom Anbieter zurückgegebene Fehler:

Fehler Nr. 1:

Number: $80040E14
Source: Microsoft OLE DB Provider for SQL Server
Description: OLE DB provider "SQLNCLI" for linked server "ASILIVE" returned message "No transaction is active.".
HelpFile: 
HelpContext: $00000000
SQLState: 01000
NativeError: 7412

Fehler # 2

Number: $80040E14
Source: Microsoft OLE DB Provider for SQL Server
Description: The operation could not be performed because OLE DB provider "SQLNCLI" for linked server "ASILIVE" was unable to begin a distributed transaction.
HelpFile: 
HelpContext: $00000000
SQLState: 42000
NativeError: 7391

Wie bringe ich Microsoft dazu, die Funktionalität der Sicherheit vorzuziehen?

Oder zumindest, wie kann ich zwei SQL Server dazu bringen, miteinander zu sprechen?

Verwandte Fragen


Was ich getan habe ist irrelevant, aber ich werde es trotzdem posten.

  1. Stellen Sie sicher, dass der Dienst Distributed Transaction Coordinator auf beiden Maschinen ausgeführt wird:

    enter image description here

    enter image description here

  2. Deaktivieren Sie die gesamte MSDTC-Sicherheit auf beiden Computern:

    enter image description here

    enter image description here

  3. Aktivieren Sie zufällige Optionen auf dem Verbindungsserver:

enter image description here

  1. Verflucht und geschworen.

  2. Zertrümmerte Sachen.

  3. Überprüft, ob ein SELECT den Verbindungsserver verwenden kann:

       SELECT * FROM ASILive.CustomerManagementSystem.dbo.Users
       ....
    
       (763 row(s) affected)
    
  4. Überprüft, ob der Client-Server den Remoteserver ping kann :

        C:\Documents and Settings\avatar>ping asicmstest.contoso.com
    
        Pinging asicmstest.contoso.com [10.0.0.40] with 32 bytes of data:
    
        Reply from 10.0.0.40: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.40: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.40: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.40: bytes=32 time<1ms TTL=128
    
        Ping statistics for 10.0.0.40:
            Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
        Approximate round trip times in milli-seconds:
            Minimum = 0ms, Maximum = 0ms, Average = 0ms
    
  5. Überprüft, ob der Remote-Server namentlich zum initiierenden Server zurückkommunizieren kann:

        C:\Documents and Settings\avatar>ping asitestserver.contoso.com
    
        Pinging asitestserver.contoso.com [10.0.0.22] with 32 bytes of data:
    
        Reply from 10.0.0.22: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.22: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.22: bytes=32 time<1ms TTL=128
        Reply from 10.0.0.22: bytes=32 time<1ms TTL=128
    
        Ping statistics for 10.0.0.22:
            Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
        Approximate round trip times in milli-seconds:
            Minimum = 0ms, Maximum = 0ms, Average = 0ms
    
  6. Überprüft, ob @@SERVERNAME mit dem Servernamen auf beiden Servern übereinstimmt :

      SELECT @@SERVERNAME, SERVERPROPERTY('MachineName')
    
      -------------  -------------
      ASITESTSERVER  ASITESTSERVER
    

    und

      SELECT @@SERVERNAME, SERVERPROPERTY('MachineName')
    
      ----------  ----------
      ASIGROBTEST  ASIGROBTEST
    
  7. Schrie

  8. SET XACT_ABORT ON vor dem Absenden meiner Anfrage ausgegeben :

    SET XACT_ABORT ON
    GO
    BEGIN DISTRIBUTED TRANSACTION
    SELECT TOP 1 * FROM Sessions
    
  9. Gewährt EveryoneFull Control z :

    HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer
    

    auf beiden Servern.

87
Ian Boyd

Es wurde festgestellt, dass MSDTC auf dem Remote-Server ein Klon des lokalen Servers war. 

Aus dem Windows-Anwendungsereignisprotokoll:

Ereignistyp: Fehler
Ereignisquelle: MSDTC
Ereigniskategorie: CM
Ereignis-ID: 4101
Datum: 19.09.2011
Zeit: 1:32:59 Uhr
Benutzer: N/A
Computer: ASITESTSERVER
Beschreibung: 

Das lokale MS DTC hat das erkannt Der MS-DTC auf ASICMSTEST hat dieselbe eindeutige Identität wie die lokale MS DTC. Dies bedeutet, dass die beiden MS DTC nicht kommunizieren können miteinander. Dieses Problem tritt normalerweise auf, wenn eines der Systeme wurden mit nicht unterstützten Klonwerkzeugen geklont. MS DTC erfordert, dass die Systeme werden mit unterstützten Klonwerkzeugen wie SYSPREP ..__ geklont. Führen Sie 'msdtc -uninstall' und dann 'msdtc -install' über den Befehl .__ aus. Prompt wird das Problem beheben. Hinweis: Wenn Sie 'msdtc -uninstall' ausführen, wird das System verliert alle MS DTC-Konfigurationsinformationen.

Weitere Informationen finden Sie im Hilfe- und Supportcenter unter http://go.Microsoft.com/fwlink/events.asp .

Laufen

msdtc -uninstall
msdtc -install

anschließend wurde der SQL Server-Dienst gestoppt und neu gestartet.

28
Ian Boyd

OK, also Dienste werden gestartet, es gibt einen Ethernet-Pfad zwischen ihnen, Namensauflösung funktioniert, Verbindungsserver funktionieren, und Sie haben die Transaktionsauthentifizierung deaktiviert. 

Mein Bauch sagt Firewall-Problem, aber ein paar Dinge fallen mir ein ...

  1. Befinden sich die Maschinen in derselben Domäne? (Ja, sollte bei deaktivierter Authentifizierung keine Rolle spielen)
  2. Laufen auf den Maschinen Firewalls? DTC kann für Firewalls ein wenig schmerzhaft sein, da sie eine Reihe von Ports verwendet, siehe http://support.Microsoft.com/kb/306843 Vorläufig würde ich Firewalls deaktivieren, um das zu identifizieren Problem
  3. Was sagt der DTC-Ping? http://www.Microsoft.com/download/de/details.aspx?id=2868
  4. Welches Konto läuft der SQL-Dienst als?
6
EBarr

Ich konnte dieses Problem beheben (wie in anderen Kommentaren erwähnt), indem ich "Förderung verteilter Transaktionen für RPC aktivieren" deaktivierte:

enter image description here

2
Steve Bauman

Wenn sich die Server in einem Cluster befinden und ein Cluster-DTC vorliegt, müssen Sie die Sicherheit für den Cluster-DTC und nicht für den lokalen DTC deaktivieren.

2
David Wolfinger

Wenn sich Ihr Zielserver in einer anderen Cloud oder einem anderen Rechenzentrum befindet, müssen Sie den Host-Eintrag des MSDTC-Diensts (Zielserver) in Ihrem Quellserver hinzufügen.

Versuchen Sie es mit diesem Problem, falls das Problem nicht behoben wurde. Aktivieren Sie anschließend die MSDTC-Einstellungen.

1
JERRY

Abgesehen von den Sicherheitseinstellungen musste ich auf beiden Servern einige Ports öffnen, damit die Transaktion ausgeführt werden konnte. Ich musste Port 59640 öffnen, aber gemäß dem folgenden Vorschlag muss Port 135 geöffnet sein . http://support.Microsoft.com/kb/839279

0
Trepach

Mein letztes Abenteuer mit MSDTC und dieser Fehler stellte sich heute als DNS-Problem heraus. Sie sind auf dem richtigen Weg und fragen, ob sich die Maschinen in derselben Domäne befinden, EBarr. Tolle Liste für diese Ausgabe übrigens! 

Meine Situation: Ich brauchte einen Server in einer untergeordneten Domäne, um verteilte Transaktionen mit einem Server in der übergeordneten Domäne über eine Firewall ausführen zu können. Ich habe im Laufe der Jahre ziemlich oft Verbindungsserver verwendet, also hatte ich alle üblichen Einstellungen in SQL für einen Verbindungsserver und in MSDTC, die Ian so schön oben dokumentiert hat. Ich habe MSDTC mit einer Reihe von TCP - Ports (5000-5200) für die Verwendung auf beiden Servern eingerichtet und eine Firewall-Lücke zwischen den Boxen für die Ports 1433 und 5000-5200 eingerichtet. Das hätte funktionieren sollen. Der Verbindungsserver hat OK getestet und ich konnte den Remote-SQL-Server über den Verbindungsserver gut abfragen, aber ich konnte keine verteilte Transaktion zulassen. Ich konnte sogar eine Verbindung auf dem QA-Server vom DEV-Server sehen, aber irgendetwas machte nicht die Rückreise. 

Ich könnte den DEV-Server über QA mit einem FQDN wie PING anrufen (PING DEVSQL.dev.domain.com)

Ich konnte den DEV-Server nicht nur mit dem Computernamen anpingen: PING DEVSQL

Der DEVSQL-Server sollte Mitglied beider Domänen sein, der Name wurde jedoch nicht in der DNS der übergeordneten Domäne aufgelöst. In der übergeordneten Domäne war dem Computerkonto für DEVSQL ein Fehler aufgetreten. Nachdem wir DEVSQL für die übergeordnete Domäne zum DNS hinzugefügt hatten und "PING DEVSQL" vom Remote-QA-Server aus funktionierte, wurde dieses Problem für uns gelöst. 

Ich hoffe das hilft!

0
Marck