Partager via

Résoudre les problèmes intermittents ou périodiques liés à la connexion à SQL Server

  • Article

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. Pour plus d’informations, consultez les articles d’aide autonome.

La stabilité du réseau est essentielle pour le bon fonctionnement de différents services et applications. Toutefois, il existe des moments où les problèmes réseau perturbent cette stabilité. Cet article vous aide à comprendre et à résoudre les problèmes réseau intermittents ou périodiques et leurs messages d’erreur classiques. Ces problèmes peuvent être frustrants, mais vous pouvez les résoudre plus efficacement avec une meilleure compréhension et des techniques de dépannage appropriées.

Messages d’erreur les plus courants

Les problèmes intermittents se produisent de manière irrégulière, tandis que les problèmes périodiques ont tendance à se produire à intervalles prévisibles. L’identification du type de problème est la première étape de la résolution des problèmes. Lorsque des problèmes réseau intermittents ou périodiques se produisent, vous pouvez rencontrer les messages d’erreur suivants :

  • Échec du lien de communication : cette erreur indique une interruption de la communication entre les composants réseau.
  • Délai d’expiration de la connexion : la connexion au serveur a expiré, ce qui suggère un délai ou une indisponibilité du serveur.
  • Erreur réseau générale : un message d’erreur réseau général indique souvent un problème non spécifié avec le réseau.
  • Erreur au niveau du transport : cette erreur se produit au niveau de la couche de transport, ce qui suggère des problèmes de transmission de données.
  • Le nom de réseau spécifié n’est plus disponible : ce message implique que la ressource réseau spécifiée ne peut pas être atteinte.
  • Délai d’expiration du sémaphore : cette erreur pointe vers une condition de délai d’expiration liée à l’utilisation de sémaphores dans le réseau.
  • L’opération d’attente a expiré : une opération d’attente a dépassé son temps autorisé, généralement en raison de retards réseau.
  • Une erreur irrécupérable s’est produite lors de la lecture du flux d’entrée à partir du réseau : ce message suggère une erreur critique lors de la lecture des données du réseau.
  • Erreur de protocole dans le flux TDS : le flux de données tabulaires (TDS) est un protocole utilisé par SQL Server. Cette erreur indique un problème avec le protocole.
  • Le serveur n’a pas été trouvé ou n’a pas été accessible : ce message d’erreur suggère que le serveur auquel vous essayez d’accéder n’est pas disponible ou qu’il est introuvable.
  • SQL Server n’existe pas ou n’a pas accès refusé : cette erreur peut indiquer l’absence de SQL Server ou une erreur d’authentification lors de la tentative d’accès à SQL Server.

Cause

Les problèmes les plus courants sont liés aux suppressions de paquets en raison de l’antivirus, de l’optimisation du réseau, des pilotes réseau plus anciens, des routeurs ou des commutateurs incorrects et des connexions non mises en pool dans l’application.

Certaines causes, telles que l’antivirus, peuvent être difficiles à prouver, mais sont toujours courantes. Vous devrez peut-être désinstaller et redémarrer l’ordinateur pour le prouver, sans preuve claire. La création d’une exception pour SQL Server peut également fonctionner. Toutefois, la désactivation de l’antivirus ne fonctionne généralement pas, car les pilotes de filtre réseau sont toujours chargés même s’ils ne sont pas surveillés.

Processus de résolution des problèmes

Note

Ce processus est conçu pour les connexions client et serveur SQL Server. D’autres communications, telles que la mise en miroir SQL Server, Always-On et le trafic de synchronisation Service Broker sur le port 5022, ne sont pas traitées.

En général, la résolution des problèmes doit être pilotée par les données, ce qui peut donner lieu à des tests empiriques dans un contexte plus ciblé. Si le problème est très intermittent et que les traces réseau sont difficiles à capturer, les méthodes empiriques peuvent être appliquées en premier.

Collecter un rapport à l’aide de SQLCHECK sur chaque ordinateur

Exécutez SQLCHECK sur chaque ordinateur pour produire un rapport. Il est utile de déterminer pourquoi une connexion peut échouer.

Collecter les traces réseau sur le client et le serveur

  • Sur les machines Windows, collectez les traces réseau à l’aide de SQLTRACE.

    Suivez ces étapes pour préparer et suivre la trace. Les étapes 2 et 3 doivent être effectuées une seule fois.

    1. Téléchargez la dernière version de SQLTRACE et décompressez-la dans un dossier, tel que C :\MSDATA.

    2. Ouvrez le fichier SQLTrace.ini et désactivez les paramètres suivants :

      BIDTrace=no, AuthTrace=no et EventViewer=no

    3. Enregistrez le fichier.

    4. Ouvrez PowerShell en tant qu’administrateur et remplacez le répertoire par le dossier contenant SQLTrace.ps1.

      CD C:\MSDATA

    5. Démarrez la collection de traces.

      .\SQLTrace.ps1 -start

    6. Reproduire le problème ou attendre que l’erreur se produise.

    7. Arrêtez le suivi.

      .\SQLTrace.ps1 -stop

    Un dossier de sortie est généré dans le répertoire actif et vous pouvez l’utiliser pour une analyse plus approfondie.

  • Sur les ordinateurs non-Windows, utilisez TCPDUMP ou WireShark pour collecter une capture de paquets.

Exécuter SQL Server Network Analyzer

L’interface utilisateur SQL Network Analyzer (SQLNAUI) fournit une interface graphique permettant de sélectionner des fichiers de trace pour l’analyse et les options de définition. Téléchargez-le à partir de SQL Network Analyzer (SQLNA).

Traitez les traces client et serveur séparément. Si vous avez chaîné des traces, traitez-les en même temps. La taille totale de ces fichiers ne doit pas dépasser 80 % de la mémoire de votre ordinateur. Vérifiez que vous disposez d’une mémoire suffisante pour traiter tous les fichiers de trace associés.

Cet outil génère un rapport sur les problèmes suspects et un fichier CSV que vous pouvez explorer dans Excel pour une autre recherche.

Essayez de localiser les conversations mises en correspondance dans la trace du client et la trace du serveur. En règle générale, les adresses IP et les numéros de port correspondent. Toutefois, si les connexions passent par n’importe quel type de traduction d’adresses réseau ou de mappage de port, cela peut être plus difficile, et vous devrez peut-être vous aligner à l’aide d’ID de paquetS IPV4 et comparer les charges utiles.

Modèles à rechercher dans l’analyse de trace réseau

Examinez la façon dont les conversations se terminent dans NETMON ou WireShark. Vérifiez si le client et le serveur sont d’accord sur la même chose, ou s’ils racontent une autre histoire.

Connexion fermée pendant l’établissement d’une liaison SSL

Dans le paquet ServerHello, si la suite de chiffrement utilisée est une suite Diffie-Hellman et que le trafic se trouve entre Windows 2012 ou version antérieure et Windows 2016 ou version ultérieure, cet algorithme change à partir des correctifs de sécurité Windows 2016. Vous devez désactiver ce groupe de suites de chiffrement. Pour plus d’informations, consultez l’article Les applications rencontrent des erreurs de connexion TLS fermées de force lors de la connexion de serveurs SQL dans Windows.

Si la connexion est fermée après clientHello, vérifiez s’il existe une incompatibilité TLS 1.0 ou TLS 1.2 entre le client et le serveur. S’ils sont identiques, vérifiez les suites de chiffrement activées et les hachages activés sur les deux ordinateurs.

Pour plus d’informations, consultez la capture de données Advanced Secure Sockets Layer.

Paquets supprimés

Affichez la fin des conversations correspondantes. Si un certain nombre de paquets retransmis (ou 10 paquets Keep-Alive, 1 seconde à part) suivis d’une ACK+RESET et de l’autre ne signale pas une réponse en temps opportun et l’autre voit qu’il retarde et ferme ou réinitialise la conversation, cela indique un problème avec l’appareil réseau et les paquets sont supprimés ou retardés.

Vous pouvez également voir le rapport client indiquant que le serveur réinitialise la conversation, et le rapport du serveur indiquant que le client réinitialise la conversation. Cela est dû à un commutateur incorrect ou à un routeur fermant la connexion à partir du milieu, et ils peuvent parfois être configurés pour le faire s’ils détectent que la connexion a été inactive pendant un certain temps - souvent ignorer les paquets Keep-Alive.

Pour plus d’informations sur les connexions supprimées, consultez :

La trace du serveur et la trace du client conviennent que le problème se trouve sur le client

Si les deux traces affichent un délai ou aucune réponse sur le client, ou si le client émet une ACK+RESET après avoir accusé réception d’une réponse de serveur, ou sinon, ferme la connexion tôt pendant la séquence de connexion, vous devez effectuer une trace BID et une trace NETSH sur le client pour examiner à l’intérieur de la pile TCP/IP et ce que le pilote pense. Cela est courant si l’antivirus ou d’autres pilotes de filtre réseau retardent la réception du paquet ou l’envoi de la réponse. Les délais d’expiration de connexion peuvent également être dus à une réponse DNS lente ou à une API de sécurité lente appelée avant l’envoi du paquet SYN initial sur le câble.

Vérifiez le rapport des ports éphémères de SQL Network Analyzer et vérifiez que le client n’est pas en panne de ports sortants.

Si le client a un long délai avant d’envoyer le paquet SYN, vous pouvez voir un modèle montrant uniquement l’établissement d’une liaison d’ouverture tcp 3, suivi immédiatement, ou parfois après l’envoi du paquet PreLogin, par un ACK+FIN provenant du client.

Collecter une trace réseau et une trace BID pour isoler les problèmes du client sur Windows

  1. Ouvrez le fichier SQLTrace.ini et réactivez les paramètres suivants :

    BIDTrace=Yes, AuthTrace=Yes et EventViewer=Yes

  2. Configurez l’SQLTrace.ini BIDProviderList pour qu’elle corresponde au pilote que votre application utilise.

    .NET System.Data.SqlClient est activé par défaut. Si ce n’est pas le pilote que vous utilisez, désactivez-le BIDProviderList en ajoutant # à l’avant de la ligne et supprimez-le du début de la liste ODBC ou OLEDB. Cela permet de capturer tous les pilotes pris en charge de ce type. Pour plus d’informations, consultez CONFIGURATION INI.

  3. Enregistrez le fichier.

  4. Ouvrez PowerShell en tant qu’administrateur et remplacez le répertoire par le dossier contenant SQLTrace.ps1.

    CD C:\MSDATA

  5. Initialisez le registre de suivi BID, si vous collectez des traces BID.

    Note

    Le suivi BID est activé par défaut.

    .\SQLTrace.ps1 -setup

  6. Redémarrez le service ou l’application que vous effectuez le suivi.

    Pour certaines applications, telles que les packages SQL Server Integration Services (SSIS), une nouvelle instance de DTEXEC ou ISServerExec est lancée lors de l’exécution du package. Par conséquent, un redémarrage n’a pas de sens.

  7. Démarrez la collection de traces.

    .\SQLTrace.ps1 -start

  8. Reproduire le problème ou attendre que l’erreur se produise.

  9. Arrêtez le suivi.

    .\SQLTrace.ps1 -stop

Un dossier de sortie est généré dans le répertoire actif et vous pouvez l’utiliser pour une analyse plus approfondie.

Pour suivre d’autres pilotes Microsoft SQL Server, consultez les articles suivants. Effectuez l’utilisation d’une trace réseau.

Pour suivre les pilotes tiers, consultez la documentation du fournisseur.

La trace du serveur et la trace du client conviennent que le problème se trouve sur le serveur

Si les deux traces affichent un délai ou aucune réponse sur le serveur, ou si le serveur ferme la connexion à un point inattendu dans la séquence de connexion, ou si le serveur ferme de nombreuses connexions en même temps, cela indique qu’il existe des problèmes sur le serveur.

Les causes les plus probables sont des performances de serveur médiocres, des requêtes maxDOP élevées et des requêtes parallèles volumineuses et des blocages. Celles-ci peuvent entraîner une insuffisance de thread, empêchant la gestion rapide d’une demande de connexion, en particulier si de nombreux délais d’expiration de connexion se terminent en même temps et que la colonne LoginAck affiche « Late ». Le fichier SQL Server ERRORLOG peut afficher les opérations d’E/S prenant plus de 15 secondes, ce qui est un autre indicateur des problèmes de performances. Dans la trace réseau, vous pouvez également voir de nombreuses conversations dans le rapport de réinitialisation avec six images ou moins, indiquant que la négociation TCP 3 way n’a peut-être pas été terminée. Pour plus d’informations, consultez Collecter la mémoire tampon en anneau de connectivité.

Exécutez la RingBufferConnectivity requête et collez les résultats dans Excel. Étant donné qu’il s’agit d’une liste historique, elle peut être exécutée après le problème. Mais pour un serveur occupé, il peut se terminer rapidement. Pour un serveur lent, il peut avoir des données pendant quelques jours.

Si votre application utilise plusieurs jeux de résultats actifs (MARS), elle se termine par une RÉINITIALISATION dans le cadre de la séquence de fermeture. Cela est bénin si les paquets SMP :FIN et ACK+FIN ont déjà été envoyés à partir du client. Le paquet SMP :FIN du serveur arrive après ACK+FIN à partir du client, et Windows émet une ACK+RESET, puis une RÉINITIALISATION pour toutes les autres réponses du serveur dans le cadre de la séquence de fermeture de connexion.

Regroupement de connexions

Pour plus d’informations, consultez Regroupement de connexions.

Si le regroupement de connexions est utilisé, les conversations dans la trace réseau sont généralement assez longues. Vous pouvez utiliser le fichier CSV généré par SQL Server Network Analyzer pour trier et filtrer par protocoles et images. Vous ne verrez probablement pas les images de début ou de fin si la capture réseau est inférieure à une demi-heure. Si de nombreuses conversations sont inférieures à 30 images du paquet SYN au paquet ACK+FIN, cela indique des connexions non mises en pool. S’ils sont mélangés à quelques conversations plus longues, suspectez les connexions non mises en pool en arrière-plan provoquées par l’exécution de commandes sur une connexion non-MARS lors de la lecture d’un jeu de résultats.

Le rapport de port éphémère affiche le nombre de nouvelles connexions au cours de la durée de vie de la trace. Vous pouvez juger le taux de connexion en fonction du nombre de connexions par seconde.

RESET et ACK+RESET

ACK+RESET est généralement vu lorsque l’application ou Windows abandonne une connexion. Cela est généralement dû à une erreur TCP de bas niveau. Le paquet informe l’autre ordinateur d’arrêter d’envoyer immédiatement. Toutefois, si le serveur est au milieu de la transmission, un ou deux paquets peuvent arriver au client après l’envoi de l’ACK+RESET. Étant donné que le port est fermé, le système d’exploitation envoie un paquet RESET. Cela se produit également si les paquets arrivent après le paquet ACK+FIN qui ne fait pas partie de la négociation fermante normale.

Certains pilotes tiers envoient également un paquet ACK+RESET pour fermer la connexion au lieu d’un ACK+FIN. Certaines connexions de sonde peuvent également effectuer cette opération. Si le paquet ACK+RESET n’est pas précédé de paquets Keep-Alive, de paquets retransmis ou de paquets Windows zéro, et qu’il provient du client lorsqu’une fermeture normale d’ACK+FIN est attendue, elle peut être bénigne.

Utiliser NETSTAT pour analyser les problèmes réseau

NETSTAT est automatiquement collecté lors de l’exécution de SQLTrace.ps1 pour la collecte de données.

Vous pouvez également exécuter NETSTAT -abon > c:\ports.txt dans l’invite de commandes en tant qu’administrateur pour collecter des informations relatives aux problèmes réseau.

Le fichier ports.txt contient une liste de tous les ports entrants et sortants, numéros de port, ID de processus et noms des applications propriétaires des ports. Vous pouvez l’utiliser pour voir les pires délinquants et si la limite de port a été atteinte. Activez la barre d’état dans le Bloc-notes et désactivez word wrap. La barre d’état donne un nombre de lignes. Vous pouvez diviser par deux pour obtenir une utilisation approximative des ports.

Ajuster TcpTimedWaitDelay et MaxUserPort

Si une application épuise les ports sortants sur l’ordinateur hôte et que vous ne pouvez pas apporter de modifications immédiates à l’application, vous pouvez diminuer TcpTimedWaitDelay de 240 à 30 secondes, ce qui permet aux ports sortants d’être recyclés plus rapidement.

Pour windows 2003 et versions ultérieures, vous pouvez également augmenter le MaxUserPort. Pour Windows Vista et versions ultérieures, vous définissez cette option via la NETSH commande. Ce cours d’action n’élimine pas les inefficacités des connexions non mises en pool ou des connexions en arrière-plan non mises en pool, et le développeur doit être fortement encouragé à modifier ses applications pour utiliser le regroupement de connexions.

Pour Windows 2008 et versions ultérieures, la plage a été augmentée d’environ 4 000 ports éphémères à 16 000 ports, par défaut.

Pour plus d’informations, consultez Ajuster les paramètres MaxUserPort et TcpTimedWaitDelay.

Presque tous les paquets envoyés du client au serveur ou au serveur au client sont répondus avec un paquet ACK qui se trouve dans la direction opposée. La couche TCP.SYS génère l’ACK. Si un paquet est reçu sur le client et que la trace du client l’affiche, mais qu’aucun ACK n’est retourné au serveur, il s’agit d’une bonne indication que l’antivirus ou un autre pilote de filtre réseau a perdu ou supprimé le paquet ou l’a conservé pendant une longue période (après la fin de la collection de traces réseau). De même, si la trace du serveur affiche un paquet provenant d’un client, mais qu’aucun ACK n’est renvoyé au client, cela indique que l’antivirus serveur sur le serveur peut rencontrer un problème.

Toutefois, lors du chargement ou du téléchargement d’une grande quantité de données, les paquets ACK peuvent venir après une série de paquets de données pour faciliter le contrôle de flux.

L’antivirus et les pilotes de filtre sont très difficiles à prouver en tant que coupable. Un test empirique est presque toujours nécessaire. Créez une exception pour l’application ou SQL Server dans l’antivirus, puis surveillez-la pendant 48 heures pour voir si le comportement s’améliore. Si aucune exception ne peut être définie, désinstallez le programme antivirus et redémarrez. La désactivation ne permet généralement pas de charger le pilote de filtre antivirus. Faites cela uniquement en dernier recours si votre protection de périphérie est en place.

Consultez vos administrateurs de sécurité réseau. Si la situation s’améliore, vous devrez peut-être travailler avec le fournisseur antivirus pour atténuer le problème. Si ce n’est pas le cas, d’autres pilotes de filtre réseau peuvent être le coupable.

Activer l’audit du Pare-feu Windows

Pour déterminer si le pare-feu a supprimé les paquets, activez l’audit du pare-feu dans Windows.

Pour SQL Server, ce problème peut être lié à l’ordinateur client ou serveur. La trace réseau indique que la machine a reçu un paquet, mais n’a pas répondu. Le paquet peut ensuite être retransmise, obtenir à nouveau aucune réponse, et éventuellement, la connexion est réinitialisée.

Empiriques et autres actions

Ports éphémères

L’épuisement des ports éphémères est une cause relativement courante des délais d’expiration de connexion intermittents, en particulier si vous ne voyez pas le paquet SYN sur le câble.

Pour les requêtes entrantes sur le serveur, les ports, tels que 80 ou 1433, peuvent prendre jusqu’à 64 000 connexions entrantes par adresse IP cliente et sont généralement « illimitées » à toutes fins pratiques.

En revanche, pour les connexions sortantes, le nombre de ports est limité et partagé entre toutes les connexions serveur. Pour Windows Vista, Windows 2008 et versions ultérieures, la plage par défaut est comprise entre le port 49152 et 65535 (2^16 = 16 384 ports).

Normalement, les ports sont conservés pendant quatre minutes (240 secondes) par le système d’exploitation avant qu’ils ne soient recyclés et autorisés à être réutilisés par les applications. Cela permet d’empêcher l’usurpation de port par un logiciel malveillant ou une redirection accidentelle d’une nouvelle connexion au titulaire précédent de ce port. En raison de ce délai, sur Windows 2003, une application cliente ne peut établir que 17 connexions par seconde à SQL Server et la plage de ports sortantes est épuisée en moins de quatre minutes. Pour Windows Vista, ce nombre atteint 68 connexions par seconde.

Pour les applications telles que IIS, chaque client HTTP peut avoir un port sortant vers SQL Server. Pour un serveur web occupé, l’épuisement des ports sortants est une possibilité réelle lorsque la charge est élevée. Une batterie de serveurs web peut atténuer cette situation.

Ajuster la mémoire maximale du serveur (Mo)

Pour résoudre les problèmes liés à la mémoire faible du noyau, ajustez la mémoire maximale du serveur (Mo) .

Désactiver le déchargement

À des fins de test, vous pouvez désactiver un déchargement via une invite de commandes d’administration :

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Ne conservez pas ces paramètres désactivés pendant longtemps, sauf s’ils réduisent un problème. Elles doivent être activées par défaut sur Windows 2008 et versions ultérieures.

Pour d’autres déchargements, vous devez accéder aux propriétés de la carte réseau pour les afficher et les désactiver.

Problèmes de mémoire tampon réseau VMware

L’hôte ESX qui contient la machine virtuelle a une petite mémoire tampon réseau qui peut provoquer des problèmes de fiabilité en cas de rafale de trafic. L’article VMware suivant explique comment augmenter la taille de la mémoire tampon. Aucun redémarrage n’est nécessaire. Cette opération doit être effectuée sur l’ordinateur hôte ESX, et non sur la machine virtuelle.

Perte de paquets importante dans le système d’exploitation invité à l’aide de VMXNET3 dans ESXi

En outre, essayez de déplacer les machines virtuelles vers un autre serveur hôte ESX ou de déplacer le client et le serveur vers le même serveur hôte ESX et de voir si le problème disparaît. Si c’est le cas, il s’agit d’un problème réseau de base.

Captures instantanées VMware

Recherchez les captures instantanées VMware qui se produisent pendant l’erreur et désactivez-les.

Mise à l’échelle côté réception (RSS) désactivée sur l’ordinateur hôte

Lorsque RSS est désactivé, l’hôte SQL Server utilise uniquement un seul processeur pour traiter toutes les requêtes réseau. Cela peut faire monter le processeur à 100 % et provoquer des problèmes, même si les autres processeurs (et le processeur global) sont faibles.

Pour plus d’informations, consultez Présentation de la mise à l’échelle côté réception et de la mise à l’échelle côté réception version 2 (RSSv2) .

Plus d’informations

Problèmes d’authentification intermittents ou périodiques dans SQL Server

Collecter une trace réseau

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.