DetailPage-MSS-KB

Base de connaissances

Numéro d'article: 328476 - Dernière mise à jour: dimanche 10 mars 2013 - Version: 13.0

 

Sommaire

Résumé

Lorsque vous utilisez le pilote ODBC de SQL Server, le fournisseur OLE DB pour SQL Server ou le fournisseur managé System.Data.SqlClient, vous pouvez désactiver en utilisant les interfaces de programmation d'application respectif (API) du pool de connexions. Lorsque vous désactivez le regroupement, la contrainte sur la bibliothèque réseau SQL Server sous-jacente peut être augmentée si votre application ouvre et ferme les connexions fréquemment. Cet article décrit certains paramètres TCP/IP que vous devrez peut-être ajuster dans ces conditions.

Plus d'informations

Si vous désactivez le regroupement peut provoquer le pilote de réseau SQL Server sous-jacente pour rapidement ouvrir et fermer les nouvelles connexions de socket à l'ordinateur qui exécute SQL Server. Vous devrez peut-être modifier les paramètres de socket TCP/IP par défaut pour le système d'exploitation et l'ordinateur qui exécute SQL Server pour traiter les plus hauts niveaux de stress.

Notez que cet article traite uniquement des paramètres qui affectent la bibliothèque réseau SQL Server lorsque vous utilisez le protocole TCP/IP. Si vous désactivez le regroupement peut également entraîner des problèmes liés au stress avec d'autres protocoles de SQL Server, tels que les canaux nommés, mais cet article ne traite pas de cette rubrique. Cet article est destiné aux utilisateurs expérimentés. Si vous ne comprenez pas les rubriques de cet article, Microsoft recommande que vous consultez un ouvrage sur les sockets TCP/IP.

Notez que Microsoft recommande vivement de toujours utiliser le regroupement avec les pilotes de SQL Server. Améliore les performances globales du côté client et côté SQL Server à l'aide de la mise en pool considérablement lorsque vous utilisez les pilotes de SQL Server. À l'aide de la mise en pool également considérablement réduit le trafic réseau à l'ordinateur qui exécute SQL Server. Par exemple, un test d'échantillons utilisés 20 000 de SQL Server connexion s'ouvre et se ferme avec le regroupement activé utilisé environ 160 paquets de réseau TCP/IP, pour un total de 23,520 octets de l'activité réseau. Regroupement de désactivé, le même test généré 225,129 paquets de réseau TCP/IP, pour un total de 27,209,622 octets de l'activité réseau.

Notez que lorsque vous voyez ces problèmes liées au stress de socket TCP/IP avec les bibliothèques réseau SQL Server, vous pouvez recevoir un ou plusieurs des messages d'erreur suivants lorsque vous essayez de vous connecter à un ordinateur qui exécute SQL Server :
SQL Server n'existe pas ou accès refusé
Délai d'attente expiré
Erreur de réseau générale
Fournisseur TCP : Une seule utilisation de chaque adresse de socket (protocole/adresse réseau/port) est normalement autorisée.
Notez que vous pouvez également recevoir ces messages d'erreur spécifiques, lorsque d'autres problèmes sont produisent avec SQL Server ; par exemple, vous pouvez recevoir ces messages d'erreur si l'ordinateur distant qui exécute SQL Server est arrêté, si l'ordinateur distant qui exécute SQL Server n'écoute pas sur les sockets TCP/IP, si la connectivité réseau à l'ordinateur qui exécute SQL Server est interrompue car le câble réseau est retiré, ou si vous rencontrez des problèmes de résolution DNS. En fait tout ce qui peut provoquer le client afin de ne pas ouvrir un socket TCP/IP à l'ordinateur qui exécute SQL Server peut également provoquer les messages d'erreur. Toutefois, pour un problème de socket liées au stress, le problème se produit par intermittence comme la contrainte s'accroît et tombe. L'ordinateur peut exécuter des heures sans erreurs, puis l'erreur produit une ou deux fois et l'ordinateur, puis s'exécute pour plusieurs heures sans erreur. En outre, lorsque vous rencontrez ce problème, générale connectivité à SQL Server fonctionne un instant, échoue la suivante, puis fonctionne à nouveau la prochaine instantanée. En d'autres termes, problèmes liées au stress de socket se produisent généralement par intermittence, mais des problèmes de connectivité réseau réel avec SQL Server en général ne se produisent pas par intermittence.

Deux principaux problèmes liés au stress se produisent généralement lorsque vous désactivez le regroupement lorsque vous utilisez le protocole TCP/IP de SQL Server : vous pouvez manquer ports anonymes sur l'ordinateur client, ou vous risquez de dépasser le paramètre WinsockListenBacklog par défaut sur l'ordinateur qui exécute SQL Server.

Pour plus d'informations sur les ports anonymes, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
319502  (http://support.microsoft.com/kb/319502/EN-US/ ) PRB : Message d'erreur « WSAEADDRESSINUSE » lorsque vous essayez de vous connecter via un Port anonyme après avoir augmenté la limite de connexion IMAP

Ajustez les paramètres MaxUserPort et TcpTimedWaitDelay

Notez que les paramètres MaxUserPort et TcpTimedWaitDelay sont uniquement applicables pour un ordinateur client qui est rapidement l'ouverture et fermeture des connexions à un ordinateur distant qui exécute SQL Server et qui n'utilise pas le regroupement de connexion. Par exemple, ces paramètres s'appliquent sur un serveur Internet Information Services (IIS) qui prend en charge un grand nombre de demandes HTTP entrantes et qui est l'ouverture et fermeture des connexions à un ordinateur distant qui exécute SQL Server et qui utilise le protocole TCP/IP avec regroupement désactivé. Si le regroupement est activé, vous n'êtes pas obligé de régler les paramètres MaxUserPort et TcpTimedWaitDelay .

Lorsque vous utilisez le protocole TCP/IP pour ouvrir une connexion à un ordinateur qui exécute SQL Server, la bibliothèque réseau SQL Server sous-jacente ouvre un socket TCP/IP à l'ordinateur qui exécute SQL Server. Lorsqu'il ouvre ce socket, la bibliothèque réseau SQL Server n'active pas l'option de socket TCP/IP SO_REUSEADDR . Pour plus d'informations sur le paramètre de socket SO_REUSEADDR , consultez la rubrique « Setsockopt » dans la MSDN Microsoft Developer Network ().

Notez que la bibliothèque de réseau SQL Server ne permet plus précisément pas l'option de socket TCP/IP SO_REUSEADDR pour des raisons de sécurité. Lorsque SO_REUSEADDR est activé, un utilisateur malveillant peut détourner un port client à SQL Server et utiliser les informations d'identification que le client fournit pour accéder à l'ordinateur qui exécute SQL Server. Par défaut, car la bibliothèque réseau SQL Server ne permet pas l'option de socket SO_REUSEADDR , chaque fois que vous ouvrez et fermez un socket via la bibliothèque de réseau SQL Server sur le côté client, le socket affiche l'état TIME_WAIT pendant quatre minutes. Si vous êtes rapidement d'ouverture et fermeture des connexions de SQL Server via TCP/IP avec regroupement désactivé, vous êtes rapidement ouverture et fermeture des sockets TCP/IP. En d'autres termes, chaque connexion SQL Server a un socket TCP/IP. Si vous ouvrez et fermez rapidement 4000 sockets en moins de quatre minutes de, vous allez atteindre le paramètre maximal par défaut pour les ports clients anonymes et les nouvelles tentatives de connexion de socket échouent jusqu'à ce que l'ensemble existant de sockets TIME_WAIT arrive à expiration.

Sur le côté client, vous devrez augmenter les paramètres MaxUserPort et TcpTimedWaitDelay sont décrits dans Q319502 lorsque vous avez le regroupement désactivé. Les paramètres de ces valeurs sont déterminées par le nombre de connexion de SQL Server s'ouvre et ferme se produire sur le côté client. Vous pouvez examiner le nombre de ports client est dans un état TIME_WAIT en utilisant l'outil Netstat sur l'ordinateur client. Exécutez l'outil Netstat avec l'indicateur -n comme suit et le nombre de sockets client à votre adresse IP de SQL Server qui se trouvent dans un état TIME_WAIT. Dans cet exemple, l'adresse IP de l'ordinateur distant qui exécute SQL Server est 10.10.10.20, l'adresse IP de l'ordinateur client est 10.10.10.10 et trois établissement, les connexions et deux connexions sont dans un état TIME_WAIT :
C:\>netstat -n

Active Connections

  Proto  Local Address         Foreign Address       State
  TCP    10.10.10.10:2000      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2001      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2002      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2003      10.10.10.20:1433      TIME_WAIT
  TCP    10.10.10.10:2004      10.10.10.20:1433      TIME_WAIT
				
Si vous exécutez netstat-n et vous constatez que près de 4000 connexions vers l'adresse IP, adresse de l'ordinateur cible qui exécute SQL Server sont dans un état TIME_WAIT, vous pouvez augmenter le paramètre MaxUserPort par défaut et réduire le paramètre TcpTimedWaitDelay afin que vous n'exécutez pas de ports du client anonyme. Par exemple, vous pouvez définir le paramètre MaxUserPort à 20000 et définir le paramètre TcpTimedWaitDelay à 30. Un paramètre TcpTimedWaitDelay inférieur signifie que les sockets attendent dans l'état TIME_WAIT moins de temps. Un paramètre MaxUserPort supérieur signifie que vous pouvez avoir plusieurs sockets dans l'état TIME_WAIT.

Notez que si vous ajustez le paramètre MaxUserPort ou TcpTimedWaitDelay , vous devez redémarrer Microsoft Windows pour le nouveau paramètre prenne effet. Les paramètres MaxUserPort et TcpTimedWaitDelay sont pour n'importe quel ordinateur client qui communique avec un ordinateur qui exécute SQL Server sur des sockets TCP/IP. Ces paramètres n'ont aucun effet si elles sont définies sur l'ordinateur qui exécute SQL Server, sauf si vous effectuez des connexions de socket TCP/IP locales sur l'ordinateur local qui exécute SQL Server.

Remarque : Si vous ajustez le paramètre MaxUserPort , nous vous recommandons de réserver le port 1434 pour une utilisation par le service de navigateur de SQL Server (sqlbrowser.exe). Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
812873  (http://support.microsoft.com/kb/812873/ ) Procédure de réservation d'une plage de ports éphémères sur un ordinateur qui exécute Windows Server 2003 ou Windows 2000 Server

Réglez le paramètre WinsockListenBacklog

Pour plus d'informations sur ce paramètre de Registre spécifiques à SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
154628  (http://support.microsoft.com/kb/154628/EN-US/ ) INF: SQL journaux 17832 avec plusieurs demandes TCP\IP de connexion
Lorsque la bibliothèque réseau SQL Server écoute sur les sockets TCP/IP, la bibliothèque réseau SQL Server utilise écoute API Winsock. Le deuxième paramètre pour l' écouter API est la file d'attente qui est autorisé pour le socket. Ce retard représente la longueur maximale de la file d'attente de connexions pour l'écouteur en attente. Lorsque la longueur de la file d'attente dépasse cette longueur maximale, la bibliothèque réseau SQL Server rejette immédiatement les autres tentatives de connexion de socket TCP/IP. En outre, la bibliothèque réseau SQL Server envoie un paquet d'accusé de réception + RESET.

Paramètre de file d'attente de 5 à l'écoute SQL Server 2000 utilise par défaut. Cela signifie que l'ordinateur qui exécute SQL Server transmet la valeur 5 au paramètre de file d'attente de l' écouter API Winsock lorsque l'API écouter configure les threads à l'écoute du protocole TCP/IP sur l'ordinateur qui exécute SQL Server. Vous pouvez régler la clé de Registre WinsockListenBacklog pour spécifier une valeur différente à passer pour ce paramètre. À partir de SQL Server 2005, la bibliothèque réseau passe une valeur de SOMAXCONN comme paramètre de la file d'attente pour l' écouter API. SOMAXCONN permet au fournisseur Winsock de valeur maximale raisonnable pour ce paramètre. Par conséquent, la clé de Registre WinsockListenBacklog n'est plus utilisée ni nécessaire dans SQL Server 2005.

La file d'attente définition fonctionne comme suit : supposons qu'un service arbitraire est à l'écoute des demandes de socket TCP/IP entrantes. Si vous définissez le paramètre de file d'attente à 5 et de demandes de connexion de socket sont en permanence en flux continu dans, le service ne peut pas être capable de répondre aux demandes entrantes aussi rapides qu'ils se présentent sous. À ce stade, la couche de socket TCP/IP files d'attente de ces requêtes entrantes dans la file d'attente de la file d'attente et le service peut ultérieurement extraient les requêtes de cette file d'attente et gérer la demande de connexion de socket entrante. Une fois que la file d'attente est pleine, la couche de socket TCP/IP rejette immédiatement toutes les demandes de socket supplémentaires arrivent en envoyant un paquet d'accusé de réception + RESET au client. L'augmentation de l'augmentation de taille de file d'attente en retard que le nombre de connexions de socket en attente demande que la couche de socket TCP/IP files d'attente avant que les demandes sont rejetées.

Notez que le paramètre WinsockListenBacklog est spécifique à SQL Server. SQL Server essaie de lire ce paramètre de Registre lorsque le service SQL Server démarre en premier. Si le paramètre n'existe pas, la valeur 5 par défaut est utilisé. Si le paramètre de Registre existe, SQL Server lit le paramètre et utilise la valeur fournie comme les paramètres du journal lorsque l'API WinSock écoutez est appelée, comme les threads à l'écoute de socket TCP/IP sont configurés à l'intérieur de SQL Server.

Pour déterminer si vous exécutez ce problème, vous pouvez exécuter une trace du Moniteur réseau sur le client ou l'ordinateur qui exécute SQL Server et recherchez les demandes de connexion de socket qui sont immédiatement rejetés avec un accusé de réception + RESET. Si vous examinez les paquets TCP/IP dans le Moniteur réseau, vous voyez un paquet semblable à celui-ci lorsque ce problème se produit :
Frame: Base frame properties
ETHERNET:  EType = Internet IP (IPv4) 
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len:    0, seq:         0-0, ack:3409265780, win:    0, src: 1433  dst: 4364 
  TCP: Source Port = 0x0599	
  TCP: Destination Port = 0x110C
  TCP: Sequence Number = 0 (0x0)
  TCP: Acknowledgement Number = 3409265780 (0xCB354474)
  TCP: Data Offset = 20 bytes
  TCP: Flags = 0x14 : .A.R..
    TCP: ..0..... = No urgent data
    TCP: ...1.... = Acknowledgement field significant
    TCP: ....0... = No Push function
    TCP: .....1.. = Reset the connection
    TCP: ......0. = No Synchronize
    TCP: .......0 = Not the end of the data
  TCP: Window = 0 (0x0)
  TCP: Checksum = 0xF1E7
  TCP: Urgent Pointer = 0 (0x0)
				
Notez que le port source est 0x599 ou 1433 au format décimal. Cela signifie que le paquet provient d'un ordinateur typique qui exécute SQL Server et qui s'exécute sur le port par défaut 1433. Notez également que le champ accusé de réception significatif et les indicateurs de Réinitialiser la connexion sont définies. Si vous êtes familiarisé avec le filtrage d'une trace du Moniteur réseau, vous pouvez filtrer la valeur des indicateurs TCP par 0 x 14 hexadécimal pour afficher uniquement les paquets d'accusé de réception + RESET dans la trace de moniteur réseau.

Notez que vous pouvez également voir des paquets d'accusé de réception + RESET similaires si l'ordinateur qui exécute SQL Server ne fonctionne pas du tout ou si l'ordinateur qui exécute SQL Server n'écoute pas au protocole TCP/IP, voir les paquets d'accusé de réception + RESET n'est pas confirmation définitive que vous rencontrez ce problème. Si le WinsockListenBacklog est trop faible, certaines tentatives de réception de connexion accepte les paquets et certaines connexions reçoivent immédiatement les paquets d'accusé de réception + RESET dans la même période.

Notez que dans de très rares cas, vous devrez ajuster ce paramètre, même si le regroupement est activé sur les ordinateurs clients. Par exemple, si de nombreux ordinateurs clients communiquent avec un seul ordinateur qui exécute SQL Server, un grand nombre de tentatives de connexion entrantes simultanées peut se produire à tout moment particulier même si le regroupement est activé.

Remarque Si vous ajustez le paramètre WinsockListenBacklog , vous n'êtes pas obligé de redémarrer Windows pour que ce paramètre prenne effet. Il vous suffit, arrêtez et redémarrez le service SQL Server pour le paramètre prenne effet. Le paramètre de Registre WinsockListenBacklog est uniquement pour l'ordinateur qui exécute SQL Server. Il n'a pas d'effet sur n'importe quel ordinateur client qui communique avec SQL Server.

Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 2000 Standard
  • Microsoft ADO.NET 1.1
  • Microsoft SQL Server 7.0 Standard
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Mots-clés : 
kbsqlsetup kbinfo kbmt KB328476 KbMtfr
Traduction automatiqueTraduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 328476  (http://support.microsoft.com/kb/328476/en-us/ )
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Partager
Options de support supplémentaire
Forums du support Microsoft Community
Nous contacter directement
Trouver un partenaire Microsoft Certified Partner
Microsoft Store