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

Résumé

Cet article explique comment résoudre les problèmes intermittents ou périodiques liés au réseau qui entraînent l’échec, l’expiration ou la réinitialisation inattendue des connexions SQL Server. Il décrit les messages d’erreur les plus courants, les causes sous-jacentes (telles que les paquets supprimés, les filtres antivirus ou les ports éphémères épuisés) et un processus de résolution des problèmes piloté par les données basé sur SQLCHECK, SQLTRACE et l’analyse de trace réseau avec SQL Network Analyzer (SQLNA). Utilisez-le pour déterminer si le problème se trouve sur le client, sur le serveur ou dans le chemin réseau entre eux.

Note

Avant de commencer la résolution des problèmes, vérifiez les prérequis et passez par la liste de contrôle. Pour plus d’informations, consultez les articles d’aide autonome.

Messages d’erreur courants pour les problèmes de connectivité intermittents SQL Server

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 de connectivité d’SQL Server 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 accès refusé : cette erreur peut indiquer l’indisponibilité de SQL Server ou une erreur d’authentification lors d’une tentative d’accès à SQL Server.

Causes courantes des problèmes de connectivité intermittents SQL Server

Les problèmes les plus courants sont les suppressions de paquets causées par les logiciels antivirus, l’optimisation du réseau, les pilotes réseau obsolètes, les routeurs ou les commutateurs incorrects et les connexions non mises en pool dans l’application.

Certaines causes, telles que les logiciels antivirus, peuvent être difficiles à prouver mais sont toujours courantes. Vous devrez peut-être désinstaller le logiciel 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 chargent toujours 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. Elle ne concerne pas d’autres communications, telles que la mise en miroir de SQL Server, Always On et le trafic de synchronisation de Service Broker sur le port 5022.

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, appliquez d’abord les méthodes empiriques .

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 traçage.

      .\SQLTrace.ps1 -stop

    Le processus crée un dossier de sortie dans le répertoire actif. Utilisez ce dossier 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 des traces chaînées, 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 rejetés

Affichez la fin des conversations correspondantes. Si l’un présente de nombreux paquets retransmis (ou 10 paquets Keep-Alive, espacés d’une seconde), suivis d’un ACK+RESET, et pas l’autre, ou si l’un signale une réponse en temps opportun tandis que l’autre la constate retardée et ferme ou réinitialise la conversation, cela indique un problème au niveau de l’équipement réseau et que des paquets sont perdus 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 défectueux ou à un routeur qui interrompt la connexion en cours, et ces équipements peuvent parfois être configurés pour le faire s’ils détectent que la connexion est restée inactive pendant un certain temps, en ignorant souvent 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 présente un long délai avant d’envoyer le paquet SYN, vous pouvez observer une séquence ne montrant que la poignée de main d’ouverture TCP en trois temps, suivie immédiatement, ou parfois après l’envoi du paquet PreLogin, d’un ACK+FIN émis par le 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 BIDProviderList en ajoutant # au début de la ligne, puis supprimez cet élément du début de la liste ODBC ou OLEDB. Cela inclura 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 traçage 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 surveillez.

    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 traçage.

    .\SQLTrace.ps1 -stop

Le processus crée un dossier de sortie dans le répertoire actif. Utilisez ce dossier pour une analyse plus approfondie.

Pour effectuer le traçage d’autres pilotes Microsoft SQL Server, consultez les articles suivants. Effectuez l’opération à l’aide 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, un maxDOP élevé, des requêtes parallèles volumineuses et un blocage. Ces conditions peuvent provoquer une pénurie de threads, ce qui empêche qu’une requête d’authentification soit traitée rapidement, en particulier si de nombreuses expirations de délai de connexion se produisent en même temps et que la colonne LoginAck affiche « Late ». Le fichier SQL Server ERRORLOG peut indiquer des opérations d’E/S prenant plus de 15 secondes, ce qui constitue un autre indicateur de problèmes de performances. Dans la trace réseau, vous pouvez également voir de nombreuses conversations dans le rapport Reset avec six trames ou moins, ce qui indique que le handshake TCP en trois étapes ne s’est peut-être pas terminé. Pour plus d’informations, consultez Collecter le tampon circulaire de connectivité.

Exécutez la RingBufferConnectivity requête et collez les résultats dans Excel. Étant donné que cette liste est historique, vous pouvez l’exécuter 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 arrivera après l’ACK+FIN du client, et Windows enverra un ACK+RESET puis un RESET pour toute autre réponse du serveur dans le cadre de la séquence de fermeture de la connexion.

Regroupement de connexions

Pour plus d’informations, consultez Regroupement de connexions.

Si vous utilisez le regroupement de connexions, 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 voyez 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 comportent moins de 30 trames entre le paquet SYN et le paquet ACK+FIN, cette condition indique des connexions non mutualisées. Si ces connexions non mises en pool sont mélangées à 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 contre ACK+RESET

En règle générale, ACK+RESET s’affiche lorsque l’application ou Windows abandonne une connexion. Cette condition est généralement due à 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. Cette condition se produit également si les paquets arrivent après le paquet ACK+FIN ne faisant pas partie de la procédure normale de fermeture.

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 action. 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é lorsque vous exécutez 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. Utilisez cette liste pour voir les pires délinquants et déterminer si la limite de port est 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.

Vous pouvez également élargir la plage de ports client dynamique sur l’ordinateur hôte à l’aide de la netsh int ipv4 set dynamicport tcp commande (ou ipv6) . Cette action n’élimine pas les inefficacités des connexions non mises en pool ou des connexions en arrière-plan non mises en pool. Dans l’idéal, l’application doit être modifiée pour utiliser le regroupement de connexions.

Les versions actuelles prises en charge de Windows utilisent déjà la plage de ports client dynamiques compatible IANA de 49152 à 65535, qui fournit environ 16 384 ports éphémères.

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, cette condition est 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, cette condition 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.

Il est très difficile de prouver que l’antivirus et les pilotes de filtre sont responsables. Vous avez presque toujours besoin d’exécuter un test empirique. 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 vous ne pouvez pas définir d’exception, désinstallez le programme antivirus et redémarrez. Le désactiver n’aide généralement pas, car le pilote de filtre antivirus se chargera quand même. 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 supprime des 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 retransmis, ne recevoir à nouveau aucune réponse, et finalement, la connexion est réinitialisée.

Actions 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 gérer jusqu’à 64 000 connexions entrantes par adresse IP cliente et sont généralement illimités à tous les fins pratiques.

Pour les connexions sortantes, le nombre de ports est limité et partagé entre toutes les connexions serveur. Sur les versions actuelles prises en charge de Windows, la plage de ports client dynamique par défaut est 49152 à 65535, qui fournit environ 16 384 ports éphémères.

Normalement, le système d’exploitation conserve les ports pendant quatre minutes (240 secondes) avant de les recycler et de permettre aux applications de les réutiliser. Ce délai empêche l’usurpation de port par des logiciels malveillants ou une redirection accidentelle d’une nouvelle connexion au titulaire précédent de ce port. En raison de ce délai, une application cliente qui utilise la plage de ports dynamiques par défaut et la valeur par défaut TcpTimedWaitDelay de 240 secondes ne peut ouvrir qu’environ 68 nouvelles connexions sortantes par seconde pour SQL Server avant d’épuiser environ 16 384 ports éphémères. Abaisser TcpTimedWaitDelay ou élargir la plage de ports dynamiques à l’aide de netsh int ipv4 set dynamicport tcp augmente cette limite.

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 certaines fonctions de déchargement depuis une invite de commandes ouverte avec des droits d’administrateur :

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. Ils sont activés par défaut sur les versions actuelles prises en charge de Windows.

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

Vérifiez si des instantanés VMware se produisent au moment où l’erreur se produit 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) .

Contenu connexe

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.

  • Last updated on