Comment résoudre les problèmes de connexions orphelines dans SQL Server


Résumé


Lorsqu’un client Microsoft SQL Server se déconnecte d’un serveur SQL Server, le processus de connexion doit être nettoyé du côté serveur. Si les processus de connexion n’ont pas été résolus pour une raison quelconque, il s’agit de processus « orphelins » ou « fantômes ». Ces processus pourraient utiliser des ressources utiles telles que des verrous et des connexions utilisateur. Les processus orphelins sont généralement causés par une fermeture incorrecte des applications clientes et des problèmes liés au réseau, et les solutions de déploiement nécessitent généralement des applications clientes et des configurations réseau ajustées.

Informations supplémentaires


Pour résoudre ce problème, gardez les points suivants à l’esprit :
  • SQL Server en tant qu’application n’est pas à tester de manière proactive sur la connexion du client pour déterminer son état actuel. Les communications entre processus de niveau inférieur (IPCs), telles que les canaux nommés, les sockets IPX/SPX ou TCP/IP, sont responsables de la gestion des connexions client.
  • Un IPC possède généralement son propre mécanisme pour gérer les connexions client. Lorsque les connexions clientes ne répondent pas pendant un certain temps, il est généralement préférable de détecter le problème en envoyant les sondes « Keep Alive » ou en effacant la connexion une fois qu’il est inactif pendant une durée configurée. Toutefois, les paquets « Keep-Alive » ne sont pas envoyés par défaut par une application. L’application doit activer cette fonctionnalité sur ses connexions.
  • Dans certains cas, par exemple, le problème de protection générale du client, il est possible que le client réponde aux sondes du serveur même si l’application est déjà endommagée. Dans ce cas, l’ordinateur Windows NT Server peut conserver cette connexion cliente indéfiniment, à condition que le client ne soit pas arrêté.
  • S’il n’est pas possible de fermer une connexion morte pour une raison quelconque, SQL Server suppose que cette connexion est toujours active et ne la désactive pas.
  • Si l’ordinateur Windows NT Server a fermé la connexion alors que le processus client existe toujours sur le serveur SQL, comme indiqué par sp_who, il est possible qu’il indique un problème avec la gestion de la connexion SQL Server. Dans ce cas, vous devez utiliser votre fournisseur de support principal pour résoudre ce problème.
Si vous soupçonnez qu’un processus orphelin existe sur votre serveur SQL Server, suivez les étapes ci-dessous pour résoudre le problème :
  1. Identifiez les processus orphelins à l’aide d’sp_who, qui vous indiquent les applications qui ont été associées à ces processus par le biais des noms d’hôtes.
  2. Une fois que vous avez identifié ces processus orphelins, vous pouvez les ignorer s’ils ne possèdent pas de verrous ou utiliser de nombreuses connexions ou les supprimer à l’aide de la commande SQL Server KILL.
  3. Contactez les utilisateurs de l’application pour savoir s’il n’existe pas de procédures incorrectes de fermeture des applications, telles que le redémarrage à chaud ou à froid des stations de travail, sans quitter d’abord les applications. Vérifiez si un historique de votre station de travail devient instable, par exemple une erreur de protection générale, etc. Corrigez ces procédures incorrectes ou problèmes de stabilité s’ils existent.
  4. Vérifiez si la session IPC est toujours active sur l’ordinateur Windows NT Server sur lequel SQL Server est en cours d’exécution. Les commandes sont différentes en fonction de l’IPCs que vous utilisez. Par exemple, si vous utilisez des canaux nommés, la commande est « NET SESSION » ou « NET FILES »; s’il s’agit d’une connexion de sockets TCP/IP, vous pouvez utiliser « netstat » pour afficher des sessions TCP actives ; dans le cas d’une connexion IPX/SPX, il est possible que vous deviez utiliser l’outil de suivi des performances pour contrôler « connexions ouvertes » pour « NWLink SPX ».
  5. S’il est toujours actif sur l’ordinateur Windows NT Server, il est normal que SQL Server conserve ces processus de connexion. Lorsque Windows NT efface les sessions IPC, SQL Server en sera averti et effacera les processus de connexion en conséquence. Vous pourrez peut-être ajuster certains paramètres du réseau Windows NT afin de réduire la durée de la période avant la fin de la période de validité. Là encore, en fonction de l’IPCs que vous utilisez, les paramètres concernés sont très différents.Pour plus d’informations, cliquez sur le numéro ci-dessous pour modifier les paramètres de Registre correspondant aux éléments mentionnés ci-dessous pour voir l’article comment modifier les paramètres de Registre correspondant aux éléments mentionnés dans la base de connaissances Microsoft :
    120642 Paramètres de configuration de TCP/IP et de NetBT pour Windows 2000 ou Windows NT
    99745 Réglage des paramètres de Registre NWLINK
    • Canaux nommés : les canaux nommés sont implémentés dans la couche SMB (Server Message Block) par-dessus d’autres protocoles de transport tels que TCP/IP, NetBEUI ou NWLink IPX/SPX. Une couche fine appelée NetBIOS est généralement mise en œuvre entre le SMB et la couche de transport. Par conséquent, un moyen pratique d’ajuster la durée d’attente d’une session de canaux nommée sans réponse avant d’être fermé consiste à ajuster les paramètres KeepAlive de la couche NetBIOS correspondante. Pour TCP/IP, la couche NetBIOS impliquée est NBT (NetBIOS sur TCP) et le paramètre impliqué est SessionKeepAlive dans la clé de Registre suivante :
               KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters      
      Si le protocole utilisé est NWlink IPX/SPX, les paramètres concernés sont KeepAliveCount et KeepAliveTimeout dans la clé de Registre suivante :
               HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWNBLink\Parameters      
      Notez que certaines implémentations de canaux nommés sur NWLink risquent d’ignorer la couche NetBIOS (DirectHosting), ce qui signifie que les paramètres de NWNBlink NetBIOS mentionnés ci-dessus ne s’appliquent pas.
    • Sockets TCP/IP : Windows NT Server envoie périodiquement des paquets « Keep Alive aux clients » et les clients sont censés répondre. Si, pour une raison quelconque, le client ne répond pas à ces paquets, Windows NT efface la session TCP après un certain nombre de fois. Les paramètres concernés sont KeepAliveInterval, KeepAliveTime et TcpMaxDataRetransmissions dans la clé de Registre suivante :
               HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters      
    • IPX/SPX : similaire au protocole TCP/IP, Windows NT Server envoie périodiquement les paquets « Keep Alive » et les clients répondent. Windows NT efface les connexions SPX s’il ne peut pas recevoir de réponses après avoir envoyé un nombre configuré de paquets « Keep Alive ». Les paramètres concernés sont KeepAliveCount et KeepAliveTimeout dans la clé de Registre suivante :
               HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWLnkSPX\Parametes      
    Notez que si les paramètres « Keep Alive » de votre IPCs sont configurés pour n’être jamais en délai d’expiration, Windows NT garde les sessions IPC indéfinies, même si les clients sont complètement arrêtés. Le cas échéant, SQL Server conservera ces processus de client indéfiniment. Pour plus d’informations sur les paramètres, consultez la documentation de Windows NT ou le kit de ressources Windows NT. Si vous soupçonnez que votre ordinateur Windows NT Server ne supprime pas ces sessions en fonction des paramètres de configuration, vous pouvez contacter votre fournisseur de support Windows NT principal pour obtenir de l’aide.
  6. Si la session IPC n’existe plus sur l’ordinateur Windows NT Server, mais que SQL Server continue de conserver le processus client tel qu’indiqué par sp_who, vous pouvez utiliser la commande KILL pour effacer le processus en tant que solution temporaire et contacter votre fournisseur de support SQL Server principal pour obtenir une assistance supplémentaire.
Pour plus d’informations sur cet objet lié à SQL Server 2000, voir la rubrique « sessions orphelines » dans la documentation en ligne de SQL Server.