Problèmes de connectivité réseau SQL Server cohérents

2025-02-12

Note

Avant de commencer à résoudre un problème, nous vous recommandons de consulter les prérequis et de parcourir la liste de vérification.

Cet article vous aide à résoudre les erreurs de connectivité réseau dans SQL Server. Ces erreurs sont cohérentes et reproductibles à chaque fois. Ils pointent vers certains problèmes de configuration, tels que SQL Server qui n’active pas le protocole TCP ou un pare-feu bloquant la connexion. La résolution des problèmes se concentre sur les connexions TCP distantes, car il s’agit du type de connexion le plus courant dans la plupart des centres de données, mais de nombreuses techniques peuvent également être appliquées aux canaux nommés.

Messages d’erreur typiques

Les messages d’erreur les plus courants sont les suivants :

Échec du lien de communication.
Erreur réseau générale.
Le nom de réseau spécifié est inaccessible.
SQL Server n’existe pas ou n’a pas accès refusé. (Il peut également s’agir d’une erreur d’authentification)
Une erreur liée au réseau ou propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
Erreur lors de la localisation du serveur/de l’instance spécifiée.
Impossible d’ouvrir une connexion à SQL Server Microsoft SQL Server, Erreur :53. Le chemin d’accès réseau est introuvable.
Aucune connexion n’a pu être établie, car l’ordinateur cible l’a activement refusé.

Limiter l’étendue du problème à un domaine ciblé

Les étapes suivantes permettent de limiter la résolution des problèmes à un domaine ciblé :

Client : application, chaîne de connexion, pilote (sans TLS (Transport Layer Security) 1.2), alias SQL (64/32 bits), fichier hôtes et suffixe DNS (Domain Name System) incorrect (nom complet se connecte ; nom court échoue).
SQL Server : moteur de base de données, protocoles activés et pare-feu.
Réseau : alias DNS, passerelle, routeur et pare-feu.

1. Pouvez-vous vous connecter à SQL Server localement à l’aide de SQL Server Management Studio (SSMS) et TCP ?

Par exemple, utilisez le chaîne de connexion dans ce format : tcp:<ServerName>.<DomainName>.COM,1433, par tcp:sqlprod01.contoso.com,1433exemple .

Note

tcp ajouté avant que le nom du serveur ne soit en minuscules.

Si oui, SQL Server fonctionne bien. Le problème est lié à votre pare-feu, à votre réseau ou à votre client.

Si ce n’est pas le cas, le problème est lié au service SQL Server.

2. Pouvez-vous vous connecter au port SQL Server à partir de l’ordinateur client à l’aide de telnet ?

Par exemple, la commande permettant d’établir une connexion telnet à l’instance SQL Server est telnet <ServerName>.<DomainName>.COM 1433.

Si c’est le cas, le problème est lié aux pilotes/fournisseurs, à la couche SSL (Security/Secure Sockets Layer), aux alias SQL ou aux applications.

Si ce n’est pas le cas, le problème est lié à votre fichier, réseau ou pare-feu hôtes lorsque l’étape 1 fonctionne.

Si telnet elle n’est pas disponible en tant que commande, ajoutez-la en tant que fonctionnalité Windows. Cela ne nécessite pas de redémarrage.
Les versions plus récentes de Windows ont la commande PowerShell Test-NetConnection .

Par exemple, utilisez la commande Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 pour tester la connexion réseau à une instance SQL Server.

3. Pouvez-vous vous connecter au serveur à l’aide d’un fichier UDL si l’étape 2 fonctionne ?

Si c’est le cas, le problème est lié aux applications, comme une chaîne de connexion incorrecte, ou le fournisseur utilisé par l’application s’il est différent du fournisseur utilisé dans le fichier UDL (Universal Data Link).

Si ce n’est pas le cas, le problème est lié aux clients.

4. D’autres clients peuvent-ils se connecter à SQL Server ?

Si oui, le problème est lié à votre pare-feu, votre réseau, TLS 1.2 ou votre client.

Si ce n’est pas le cas, le problème est lié à votre pare-feu ou à votre serveur.

5. Le client peut-il se connecter à d’autres serveurs ?

Si c’est le cas, le problème est lié à votre pare-feu, réseau, TLS 1.2 ou serveur.

Si ce n’est pas le cas, le problème lié à votre pare-feu, à votre réseau ou à TLS 1.2.

Service SQL Server

Si le problème est lié au service SQL Server, procédez comme suit :

Vérifiez que le processus de service (sqlserver.exe) est en cours d’exécution dans le Gestionnaire des tâches. (Ou vérifiez via Gestionnaire de configuration SQL Server ou services.msc si plusieurs instances sont installées.)

S’il n’est pas en cours d’exécution, essayez de démarrer l’instance. S’il s’agit d’une configuration mise en miroir ou en cluster, vérifiez que vous êtes sur le nœud principal ou actif. Utilisez le gestionnaire de cluster pour le basculement ou toujours sur les clusters pour vous assurer que les ressources sont en ligne.
Vérifiez si le journal des événements de l’application, les journaux de cluster ou le fichier SQL Server ERRORLOG indique une erreur irrécupérable actionnable.

Vérifiez que les protocoles attendus sont activés dans Gestionnaire de configuration SQL Server et dans le fichier SQL Server ERRORLOG (consultez l’exemple suivant).

Si ce n’est pas le cas, activez-les et redémarrez SQL Server. TCP doit toujours être activé si les connexions distantes sont autorisées.

2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433].
2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433].
2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ].
2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].

Dans une connexion administrateur de source de données SSMS, UDL ou ODBC, ignorez le navigateur SQL Server en spécifiant le nom du serveur au format : tcp:<ServerName>.<DomainName>.com,1433.

Note

L’utilisation du nom de domaine complet (FQDN), tcp:et le numéro de port pour créer une connexion est la méthode la plus fiable et résiliente. tcp: doit être en minuscules.
- Si la connexion réussit :
  - Vérifiez que SQL Server Browser est en cours d’exécution. Si SQL Server est une instance par défaut qui écoute sur le port 1433, il n’est pas obligé d’être en cours d’exécution. Vous pouvez supprimer le numéro de port et le faire fonctionner.
  - Si vous supprimez le tcp: préfixe, vous pouvez vous connecter par défaut via des canaux nommés. Vous pouvez valider en utilisant np:hostname\<ServerName> le nom du serveur.
  - Si l’utilisation du nom NetBIOS échoue, vous pouvez avoir un alias SQL qui remplace le nom NetBIOS ou un suffixe DNS incorrect dans la configuration réseau. Vérifiez également les alias 32 bits.
- Si SSMS ne parvient pas à se connecter, essayez de vous connecter avec un fichier UDL ou via l’administrateur de source de données ODBC.
  - Essayez d’utiliser l’adresse IP du serveur au lieu du nom d’hôte. Vous pouvez même essayer d’utiliser la version 127.0.0.1 si le serveur n’est pas cluster et écoute sur « any ».
  - Essayez différents pilotes. Les pilotes plus récents prennent en charge TLS 1.2 et donnent de meilleurs messages d’erreur.
  - Essayez différents protocoles : tcp:<ServerName>.<DomainName>.com,1433, np:<ServerName>.<DomainName>.com\<InstanceName>ou lpc:<ServerName>.<DomainName>.com\<InstanceName>. Utilisez le Gestionnaire de configuration SQL Server pour apporter des modifications. Ensuite, redémarrez SQL Server et utilisez le fichier ERORLOG pour confirmer les modifications.
  - SQL Server (2014 ou version antérieure) a-t-il été mis à niveau pour prendre en charge TLS 1.2 ? Le client a-t-il été mis à niveau pour prendre en charge TLS 1.2 ? Ces protocoles sont-ils activés ?
  - Recherchez un alias SQL dans Gestionnaire de configuration SQL Server ou cliconfg.exe sur toutes les machines Windows. Vérifiez les alias 64 bits et 32 bits.
  - Vérifiez le fichier ERRORLOG pour connaître les messages d’échec, tels que la base de données indisponible ou en récupération.
  - Vérifiez la NETSTAT sortie pour vérifier si SQL Server possède le port attendu. Par exemple, exécutez à NETSTAT -abon > c:\temp\ports.txt partir d’une invite de commandes avec des autorisations d’administrateur.
- Si SQL Server utilise un port autre que 1433 :
  - Si vous pouvez vous connecter en spécifiant le numéro de port, mais pas lorsque vous omettez le numéro de port, il s’agit d’un problème SQL Server Browser. Cela signifie que le service SQL Browser n’est pas en mesure de fournir le numéro de port approprié pour l’instance SQL Server à laquelle vous souhaitez vous connecter. Vous devrez peut-être également redémarrer le service SQL Browser pour actualiser ses informations.
  - Si vous ne pouvez pas vous connecter même lorsque vous spécifiez le numéro de port et que cela se produit uniquement lorsque vous vous connectez à distance, il s’agit d’un problème de pare-feu. Vous devez vérifier les paramètres du pare-feu et vérifier que le port est autorisé pour les connexions entrantes et sortantes. Vous devrez peut-être également créer une règle de pare-feu pour permettre à l’application ou au service SQL Server de communiquer via le pare-feu.
  - Si vous utilisez Always On, la connexion à l’écouteur n’utilise pas SQL Server Browser. Vous devez donc spécifier le numéro de port dans le chaîne de connexion. Si cela ne fonctionne pas, essayez de vous connecter directement au nœud principal sur son port SQL standard. Si cela fonctionne, le problème est lié à l’écouteur.

Si aucune des méthodes ci-dessus ne fonctionne, redémarrez l’ordinateur SQL Server.

Le pire des scénarios consiste à arrêter le service SQL Server, à installer une nouvelle instance ou à reconstruire potentiellement la machine, puis à détacher la base de données ou la restauration à partir de la sauvegarde. Si vous utilisez le chiffrement transparent des données (TDE), tel que la base de données SSISDB , vérifiez que les clés de chiffrement sont enregistrées avant d’effectuer cette étape. Il est proposé comme option de reconstruction peut parfois être plus rapide qu’une analyse racine des problèmes inductibles. Pour les installations en cluster, l’impact peut être moindre que vous pouvez reconstruire un nœud pendant son exécution sur le nœud de remplacement.

Pare-feu

En général, le comportement par défaut du pare-feu consiste à bloquer les ports SQL Server et SQL Server Browser. Dans ce cas, les connexions distantes échouent, tandis que les connexions locales réussissent. Testez-le à l’aide de Test-NetConnection. Il est disponible sur toutes les versions prises en charge de Windows.

Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433

Veillez à vérifier le port sur lequel SQL Server écoute dans le fichier ERRORLOG . Vous devrez peut-être l’activer telnet en l’ajoutant en tant que fonctionnalité Windows. Cela ne nécessite pas de redémarrage. SQL Server doit également être à l’écoute sur TCP. PortQry peut être téléchargé à partir du site de téléchargement Microsoft. Si vous utilisez SQL Server Browser, vérifiez que le port UDP 1434 est ouvert dans le pare-feu et le port TCP SQL Server.

Network (Réseau)

Le client ou le serveur d’applications peut se connecter à SQL Server sur un autre ordinateur. Peut-être que plusieurs clients sur un réseau ou un sous-réseau particulier rencontrent des difficultés à se connecter à un serveur en dehors du sous-réseau ou dans un autre sous-réseau spécifique. Un pare-feu réseau peut empêcher un client spécifique de se connecter à un serveur SQL Server spécifique. Par exemple, le client peut se connecter à d’autres serveurs SQL, et d’autres clients peuvent se connecter au problème SQL Server.

VPN

Si le problème se produit uniquement sur un réseau privé virtuel (VPN) et non lorsque l’ordinateur portable est mis en interne, le fournisseur VPN doit résoudre le problème. Vous pouvez obtenir une trace réseau de client et de serveur, ce qui peut vous aider à montrer le type de problèmes que pose le VPN. Par exemple, les paquets supprimés sont les plus probables. Le VPN peut également modifier le routage interne entre le client et le serveur, l’exposant à un autre périphérique réseau qui bloque la connexion. La collecte des traces réseau sur les appareils intermédiaires permet d’isoler le problème en subdivisant le réseau. La commande tracet peut révéler le routage.

Client

Si le problème est lié aux clients, vous pouvez voir les indicateurs suivants :

D’autres clients peuvent se connecter au serveur normalement.
Aucune application ne peut se connecter à partir de cet ordinateur.
Vous ne pouvez pas vous connecter à l’aide d’un administrateur de source de données UDL ou ODBC.

Cela peut être dû à une règle de pare-feu sortante ou à des suffixes DNS par défaut incorrects. Essayez de tester avec le nom complet du serveur, par exemple :
```
Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
```
Il peut s’agir d’un problème TLS. Par exemple, le serveur utilise TLS 1.2 et les pilotes clients n’ont pas été mis à niveau pour lui.

Il peut y avoir une entrée de fichier hosts, un alias SQL ou un alias DNS qui dirige la connexion à un autre serveur. Utilisez ping et telnet. S’ils fonctionnent, mais que le pilote échoue, suspectez un alias SQL ou un problème TLS.

Pilote

Si le problème est lié aux pilotes, essayez différents pilotes.

Si certains pilotes fonctionnent et que d’autres échouent, suspectez un problème TLS. Téléchargez le pilote le plus récent, tel que Microsoft OLE DB Driver pour SQL Server ou ODBC Driver 17 pour SQL Server, puis essayez cela.
Si vous utilisez .NET, vérifiez que vous utilisez la dernière version du framework. En cas d’échec, il doit donner un meilleur message d’erreur. Vous pouvez également télécharger la dernière version de SQL Server Management Studio indépendante de SQL Server et l’installer sur n’importe quel client. Cela utilise la SqlClient .NET classe.

Utilisateur

Si le problème est lié aux utilisateurs, connectez-vous à cet ordinateur par un autre utilisateur.

Si la connexion réussit, voyez ce qui est différent de l’utilisateur défaillant. Par exemple, le profil utilisateur Windows est endommagé, ou peut-être que les utilisateurs appartiennent à une unité d’organisation ou à un domaine différent.
S’il existe des utilisateurs de plusieurs domaines, essayez d’utiliser un utilisateur du même domaine que le serveur. En règle générale, les problèmes utilisateur entraînent des erreurs d’authentification et ont un flux de travail de résolution des problèmes différent.
S’il ne s’agit pas d’un problème d’authentification, un journal Process Monitor peut aider à identifier les problèmes d’autorisation locaux affectant la connectivité. Par exemple, l’utilisateur a un nom de source de données (DSN) ou une redirection de registre vers un autre pilote, une restriction d’autorisation locale ou quelque chose qui peut expliquer l’échec de connectivité.

Application

Si seule une application particulière échoue et qu’un fichier UDL réussit, il peut s’agir d’un problème de pilote ou que l’application a une chaîne de connexion incorrecte. Disposez de l’équipe de développement d’applications ou du fournisseur tiers pour vérifier la chaîne de connexion. Vous pouvez utiliser l’Explorateur de www.sysinternals.com processus pour voir quel pilote est utilisé si le client n’est pas sûr.

Outils de suivi pour capturer

Capturez une trace réseau cliente et serveur. Exécutez la trace SQL sur le client et le serveur en même temps.

Installez WireShark avec le pilote NCAP pour effectuer le suivi lorsque le client et le serveur se trouvent sur le même ordinateur.

Votre organisation peut avoir sa propre équipe d’infrastructure réseau avec laquelle vous pouvez vous engager et peut avoir un outil de suivi préféré pour effectuer la capture. Ils peuvent utiliser n’importe quel outil tant qu’il est enregistré dans un format compatible avec Network Monitor (NetMon.exe) ou WireShark. Le format PCAP est le plus populaire.

Exécutez SQL Network Analyzer (SQLNA) et SQL Network Analyzer UI (SQLNAUI) sur la trace réseau pour obtenir un rapport facile à lire.

Plus d’informations

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Partager via