Impossible de commencer une transaction distribuée

Question

J'essaie d'exécuter SQL sur un serveur lié, mais j'obtiens les erreurs suivantes :

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.

Il y a deux erreurs retournées par le fournisseur :

Erreur n° 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

Erreur n°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

Comment faire pour que Microsoft privilégie la fonctionnalité à la sécurité ?

Ou, au moins, comment puis-je faire en sorte que deux SQL Severs se parlent ?

Questions connexes

• L'opération n'a pas pu être effectuée car le fournisseur OLE DB "SQLNCLI10"... (*Le nom du serveur lié est (null) )
• Erreur de transaction distribuée ? ( en utilisant le fournisseur Oracle )
• Impossible de s'inscrire dans une transaction distribuée avec NHibernate ( en utilisant Hibernate )
• Erreur lors de l'utilisation de la transaction distribuée dans SQL Server 2008 R2 ( SQL Server 2008 R2, pas de réponse )
• Erreur de transaction distribuée uniquement par le code ( causés par la mise en commun des connexions )
• Erreur lors de l'exécution du coordinateur de transactions distribuées dans un serveur lié ( SQL Server 2008, pas de réponse )
• Erreur de transaction distribuée ? ( aucune réponse acceptée ; la seule réponse n'aide pas )
• Comment insérer dans une table distante en utilisant Linked Server sans transaction ? ( La réponse acceptée ne résout pas )

---

Ce que je ont fait n'est pas pertinent, mais je vais quand même le poster.

1. Assurer Distributed Transaction Coordinator Le service fonctionne sur les deux machines :

   

   

2. Désactiver toute la sécurité MSDTC sur les deux machines :

   

   

3. Activez les options aléatoires sur le serveur lié :

4. Maudits et jurés.

5. Des choses cassées.

6. Vérifié qu'un SELECT peut utiliser le serveur lié :

       SELECT * FROM ASILive.CustomerManagementSystem.dbo.Users
       ....
   
       (763 row(s) affected)

7. Vérifié que le serveur client peut ping le serveur distant :

        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

8. Vérifié que le serveur distant peut communiquer en retour, par son nom, avec le serveur initiateur :

        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

9. Vérifié que @@SERVERNAME correspond au nom du serveur sur les deux serveurs :

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

   et

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

10. Screamed

11. Délivré SET XACT_ABORT ON avant d'émettre ma requête :

    SET XACT_ABORT ON
    GO
    BEGIN DISTRIBUTED TRANSACTION
    SELECT TOP 1 * FROM Sessions

12. Accordé Everyone Full Control à :

    HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer

    sur les deux serveurs.

Answer 1

Je l'ai trouvé, MSDTC sur le serveur distant était un clone du serveur local.

À partir du journal des événements de l'application Windows :

Type d'événement : Erreur
Source de l'événement : MSDTC
Catégorie d'événement : CM
ID de l'événement : 4101
Date : 9/19/2011
Heure : 1:32:59 PM
Utilisateur : N/A
Ordinateur : ASITESTSERVER
Description :

Le MS DTC local a détecté que le MS DTC sur ASICMSTEST a la même identité unique que le MS DTC local. DTC LOCAL. Cela signifie que les deux MS DTC ne seront pas en mesure de communiquer entre eux. entre eux. Ce problème se produit généralement si l'un des systèmes a été cloné à l'aide d'outils de clonage non pris en charge. MS DTC exige que les systèmes soient clonés à l'aide d'outils de clonage pris en charge, tels que SYSPREP. L'exécution de 'msdtc -uninstall' puis de 'msdtc -install' à partir de l'invite de commande résoudra le problème. de commande résoudra le problème. Note : L'exécution de 'msdtc -uninstall' aura pour effet de le système perdra toutes les informations de configuration de MS DTC.

Pour plus d'informations, voir le Centre d'aide et de support à l'adresse suivante http://go.microsoft.com/fwlink/events.asp .

Running

msdtc -uninstall
msdtc -install

puis l'arrêt et le redémarrage du service SQL Server l'ont réparé.

Answer 2

J'ai pu résoudre ce problème (comme d'autres l'ont mentionné dans les commentaires) en désactivant "Enable Promotion of Distributed Transactions for RPC" (c'est-à-dire en le réglant sur False ) :

Comme demandé par @WonderWorker, vous pouvez le faire via SQL script :

EXEC master.dbo.sp_serveroption
     @server = N'[mylinkedserver]',
     @optname = N'remote proc transaction promotion',
     @optvalue = N'false'

Answer 3

OK, donc les services sont démarrés, il y a un chemin Ethernet entre eux, la résolution de nom fonctionne, les serveurs liés fonctionnent, et vous avez désactivé l'authentification des transactions.

Mon instinct me dit que c'est un problème de pare-feu, mais plusieurs choses me viennent à l'esprit...

1. Les machines sont-elles dans le même domaine ? (oui, cela ne devrait pas poser de problème avec une authentification désactivée)
2. Les pare-feu fonctionnent-ils sur les machines ? DTC peut être un peu difficile à gérer pour les pare-feu car il utilise une série de ports. http://support.microsoft.com/kb/306843 Pour l'instant, je désactiverais les pare-feu afin d'identifier le problème.
3. Que dit le ping DTC ? http://www.microsoft.com/download/en/details.aspx?id=2868
4. Sous quel compte le service SQL est-il exécuté ?

Answer 4

Pour moi, c'est lié aux paramètres du pare-feu. Allez dans les paramètres de votre pare-feu, autorisez le service DTC et ça a marché.

Answer 5

Si les serveurs sont en grappe et qu'il existe un CPT en grappe, vous devez désactiver la sécurité sur le CPT en grappe et non sur le CPT local.