MSSQLSERVER_7391

S’applique à :SQL Server

Explication

Cette erreur se produit car le service Microsoft Distributed Transaction Coordinator (MSDTC) n’est pas en cours d’exécution ou a désactivé l’accès réseau.

Dans certains cas, vous pouvez également recevoir l’erreur 8522 :

Microsoft Distributed Transaction Coordinator (MS DTC) has stopped this transaction.

Les numéros d’erreur compris entre 7300 et 7399 indiquent un problème qui affecte le fournisseur. Étant donné que chaque fournisseur peut avoir des fonctionnalités différentes et afficher des détails différents, il se peut que vous ne receviez pas de message d’erreur complet. Pour récupérer le message d’erreur complet des fournisseurs, exécutez la commande suivante avant d’exécuter la requête qui génère l’erreur :

DBCC TRACEON (3604, 7300)

Si vous recevez l’erreur 7391 à partir d’un processus tel que la réplication SQL Server ou SQL Server Integration Services (SSIS), vous pouvez également recevoir le message d’erreur si le code contient une BEGIN DISTRIBUTED TRAN instruction.

Action requise

Prise en charge

• Pour vérifier si le pilote prend en charge les transactions distribuées, contactez le fournisseur du pilote que vous utilisez dans votre requête de serveur lié.

• Vérifiez si l’objet sur le serveur de destination pointe vers le premier serveur. C’est ce qu’on appelle une situation de bouclage. Les serveurs liés de bouclage sont destinés à des tests et ne sont pas pris en charge pour de nombreuses opérations, telles que les transactions distribuées.

Communication du serveur

Pour vous assurer que la communication entre les serveurs réussit, procédez comme suit :

1. Vérifiez si votre résolution de noms réseau fonctionne. Assurez-vous que les serveurs peuvent communiquer entre eux par nom et non seulement par adresse IP. Vérifiez les deux directions (par exemple, du serveur A au serveur B et du serveur B au serveur A). Résolvez tous les problèmes de résolution de noms sur le réseau avant d’exécuter votre requête distribuée. Cela peut impliquer la mise à jour des fichiers WINS, DNS ou LMHost.

2. Si vous disposez d’un pare-feu, assurez-vous que vos ports d’appel de procédure distante (RPC) sont ouverts correctement. Pour plus d’informations, consultez les articles suivants :

   • Comment configurer l’allocation de ports dynamiques RPC pour qu’elle fonctionne avec des pare-feu - Windows Server

   • Configurer le pare-feu pour le domaine et les approbations AD - Windows Server

   • Configurer le Pare-feu Windows pour autoriser l’accès à SQL Server - SQL Server

3. Vérifiez l’objet vers lequel vous pointez sur le serveur de destination. Si l’objet est une vue ou une procédure stockée, ou s’il provoque l’exécution d’un déclencheur, vérifiez s’il pointe implicitement vers un autre serveur. Si c’est le cas, le troisième serveur est la source du problème. Exécutez la requête directement sur le troisième serveur. Si vous ne pouvez pas le faire, la requête de serveur lié n’est pas le problème. Résolvez d’abord le problème sous-jacent.

4. Vérifiez si vous utilisez le serveur d’accès à distance (RAS) pour accéder aux serveurs distants. Si c’est le cas, vérifiez que vous avez implémenté le RRAS (Routing RAS). Les serveurs liés ne fonctionnent pas sur ras, car RAS autorise uniquement la communication unidirectionnelle.

Configurer le serveur

Procédez comme suit pour configurer les serveurs :

1. Démarrez le coordinateur de transactions distribuées (DTC ou MS DTC) sur tous les serveurs impliqués dans la transaction distribuée. Pour plus d’informations sur l’activation de l’accès DTC réseau, consultez Message d’erreur du fournisseur OLE DB - SQL Server.

2. Définissez l’option XACT_ABORT sur ON pour les instructions de modification de données dans une transaction implicite ou explicite sur la plupart des fournisseurs OLE DB, y compris SQL Server. Pour ce faire, exécutez la commande suivante avant d’exécuter votre requête.

   SET XACT_ABORT ON
   

   Notes

   Cette option n’est pas nécessaire si le fournisseur prend en charge les transactions imbriquées.

3. Vérifiez si l’un des serveurs se trouve sur un cluster de basculement Windows Server. Le service MSDTC sur le cluster doit avoir sa propre adresse IP. Assurez-vous que la résolution de noms correcte du service DTC se produit sur chaque serveur. L’adresse IP du DTC doit être définie dans votre système de résolution de noms (par exemple WINS, DNS ou LMHosts). Vérifiez que chaque serveur peut communiquer avec MSDTC sur les autres serveurs par nom et non seulement par adresse IP. Vérifiez les deux directions. Par exemple, vérifiez le service MSDTC du serveur A vers le service MSDTC du serveur B, puis vérifiez le serveur B vers le MSDTC du serveur A. Vous devez résoudre tous les problèmes de résolution de noms sur le réseau avant d’exécuter votre requête distribuée. Pour configurer MSDTC sur un cluster, consultez les recommandations MSDTC sur le cluster de basculement SQL - Microsoft Community Hub.

4. Si vous utilisez l’ancienne technologie des serveurs distants au lieu des serveurs liés recommandés, définissez l’option OFF de configuration de trans de processus distant sur le serveur ou exécutez une SET REMOTE_PROC_TRANSACTIONS OFF instruction avant d’exécuter une requête distribuée. Si ce paramètre est défini ONsur , les appels de procédure distante sont effectués dans une transaction locale. Pour plus d’informations, consultez Configurer le processus distant trans (option de configuration du serveur) - SQL Server.

5. Vérifiez la valeur de retour de la fonction @@SERVERNAME système sur les deux serveurs. Vérifiez si la valeur de retour correspond au nom de l’ordinateur de chaque serveur. S’il ne correspond pas, renommez le serveur.

6. Vérifiez que le compte de démarrage SQL Server dispose d’autorisations de contrôle total sur la clé de Registre suivante :

   HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer

Étapes suivantes

• Configurer et résoudre les problèmes d’un serveur lié à une base de données Oracle
• Serveurs liés (Moteur de base de données)