La connexion initiale à SQL Server Connection est lente. Pourquoi?

J’ai rencontré une situation avec une application C # installée sur deux sites où la connexion initiale à SQL Server est extrêmement lente. J’ai écrit une application de test pour vérifier si le ralentissement se produit et qu’il se trouve dans la première instruction SQLConnection.Open. Il fallait environ 41 secondes pour établir une connexion au serveur via des canaux nommés. Nous pensions qu’il pourrait s’agir d’un problème de DNS, mais il est tout aussi lent lorsque vous utilisez une connexion TCP / IP. Une fois la connexion initiale établie, la connexion est mise en pool et l’application répond normalement. Le poste de travail et le serveur sont des machines correctes sous Windows 7 Pro, Core 2 Duo à 3.16 Ghz avec 4 Go de RAM. J’ai trouvé l’article suivant sur un forum Microsoft:

http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/f295994c-5812-4e46-8ac9-f05471d4dd54

La désactivation du protocole LLMNR a permis de réduire le temps de connexion initial d’environ 21 secondes à environ moitié. Cependant, la connexion initiale à SQL Server est encore longue. La seule chose qui diffère légèrement de notre norme est que le DNS est dans ce cas utilisé via un routeur et non sur un serveur réel. Cela n’a eu lieu jusqu’à présent à deux endroits, d’autres sans problème. Toute aide serait appréciée.

Merci, Dennis

Devant le serveur sur la chaîne de connexion, ajoutez np:

Cela devient Server=np:server\instance et force le canal nommé à la place du TCP par défaut.

J’aurais probablement pu changer la priorité d’utiliser Named Pipes avant TCP … mais je ne voulais pas gâcher cela sur le serveur.

J’ai vu le même problème, mais je ne suis pas sûr que ce soit le même que le vôtre. Dans mon cas, le programme C # n’est pas le seul à être lent à établir la connexion SQL. Ce sont tous les outils se connectant au serveur SQL qui connaissent également la lenteur. En outre, une fois la connexion initiale établie avec le serveur SQL, les connexions suivantes sont correctes pour une période donnée.

La raison en était que SQL Server utilisait un certain nombre d’assemblys gérés. Il essaie de vérifier les certificates atsortingbués aux assemblées. Il connecte le crl.microsoft.com. Mon serveur SQL n’avait pas de connexion Internet. Donc, il attend le délai d’attente.

La solution consistait à faire en sorte que mon serveur SQL ait un access Internet ou à désactiver la vérification des listes de révocation de certificates. Vous pouvez aller sur la machine serveur SQL. Sélectionnez Outils> Options Internet> Avancé. Vérifiez si la révocation de certificate de l’éditeur sous le nœud de sécurité est vérifiée ou non. Si c’est coché, décochez-le.

J’ai essayé de spécifier la chaîne de connexion avec security = false intégré (ce qui signifie que l’ID utilisateur et le mot de passe sont dans la chaîne de connexion) et encrypt = false (soyez simplement sûr à 100% que le cryptage SSL n’est pas utilisé). Ces spécifications n’ont pas semblé aider et je ne pouvais pas établir de connexion de manière explicite à l’aide de la bibliothèque réseau TCP / IP (NetworkLibrary = “dbmssocn”). Cela pourrait avoir à voir avec le pare-feu du serveur et le port non ouvert. Je suis revenu sur les canaux nommés et ai mis la spécification de la bibliothèque de réseau de canaux nommés dans la chaîne de connexion cette fois-ci (NetworkLibrary = “dbnmpntw”). Après ce changement, la connexion a été établie instantanément.

Oui, lorsque vous utilisez la sécurité intégrée, c’est Active Directory qui peut être blâmé, de même que l’ensemble du réseau car tout dépend de cela. Une autre chose à laquelle je pourrais penser est l’édition de SQL Server que vous utilisez.

De même, lorsque SQL Server n’est pas utilisé pendant une longue période, il se comporte de la même manière qu’IIS, mettant le processus de travail en veille, donc lorsque vous appelez à nouveau le serveur, en fonction de la machine (nous pouvons voir que ces derniers ont des configurations de machines de bureau). ), il faudra un certain temps pour que le processus de travail reprenne vie et soit prêt à fonctionner.

Vous avez vérifié l’évidence je le prends? Le port UDP 1434 est ouvert sur le pare-feu et le service de navigateur est en cours d’exécution …. il faudrait environ 40 secondes pour s’authentifier.

il existe d’autres méthodes pour créer des connexions aux bases de données SQL. Essayez de trouver un tutoriel qui utilise le

sqlconnection myCon = new sqlconnection(details);

 myCon.Open() 

au lieu de créer un object pour illustrer la connexion.

Je n’ai pas de réponse concrète, mais avez-vous essayé d’exécuter SQL Profiler pour voir ce qui se passe du sharepoint vue de SQL?

Aussi, avez-vous essayé de vous connecter à SQL en utilisant les mêmes informations d’identification que votre connexion?

D’un autre côté, le niveau peut être beaucoup plus bas, mais je vérifie toujours les choses facilement en premier.

Bonne chance.

On dirait que la résolution de nom prend un certain temps ou que l’authentification prend un certain temps. Une fois la résolution initiale ou l’authentification effectuée, les détails des noeuds finaux sont mis en cache par le serveur. Il n’est donc pas nécessaire d’effectuer de nouvelles recherches jusqu’à l’expiration des caches.

En guise d’expérience, essayez d’envoyer une requête ping au serveur à partir de la boîte client. Si la résolution du nom d’hôte prend beaucoup de temps, vous avez trouvé le coupable: la recherche de nom d’hôte (DNS ou NBNS). Une autre alternative consiste à utiliser l’adresse IP de l’hôte plutôt que son nom. Donc, si vous avez une instance nommée SQL Server de bob sur le serveur sql2005-01 et que ce serveur a une adresse IP de 192.168.200.12 , essayez de vous connecter à 192.168.200.12\bob au lieu de sql2005-01\bob .

L’authentification est plus difficile à résoudre, mais vous pourrez peut-être la tester avec des runas sur le serveur SQL (par exemple, runas /user:domain\user cmd pour voir si vous pouvez ouvrir une invite de commande en tant qu’utilisateur que vous essayez d’utiliser. s’authentifier comme.

Cela peut facilement être un problème de connexion ou d’authentification. Il est normal que la première connexion prenne plus de temps car ADO.NET dispose d’un pool de connexions afin d’éviter ce long temps de connexion.

Plusieurs facteurs peuvent influer sur la vitesse: – configuration TCP / IP – routeurs côté serveur – etc.

Nous avons eu le même problème et il s’est avéré que notre serveur Active Directory hébergé à distance était à blâmer.

Nous avons créé un serveur Active Directory local pour la réplication du maître AD hébergé à distance, puis tous nos problèmes de performances liés à l’authentification de sécurité intégrée à SQL Server ont disparu.

J’espère que ça aide.

Toujours si vous faites face au problème, s’il vous plaît voir la résolution de coup:

Cause première

Le problème que nous voyions sur les VDI Win7 pourrait être dû au périphérique matériel réseau connecté à la machine. Si la mise à l’échelle TCP / IP n’est pas prise en charge par le périphérique réseau, les performances seront lentes.

Solution

Désactiver le niveau de réglage automatique du TCP. Veuillez suivre les étapes ci-dessous: 1) Invite de commande ouverte avec droit d’administrateur (Exécuter en tant qu’administrateur) 2) Tapez “netsh interface tcp set global autotuninglevel = disabled” 3) Après avoir exécuté la commande ci-dessus, redémarrez la machine.

Pour plus d’informations sur cette commande, visitez le lien «http://support.microsoft.com/kb/935400».

J’ai eu le même problème. Après des recherches approfondies sur google et stackoverflow, j’ai modifié le fichier hosts de l’ordinateur client (dans Windows, situé dans C: \ Windows \ System32 \ drivers \ etc). J’ai saisi l’adresse IP de mon hôte et le nom du serveur dans ce fichier et Viola !. Les choses sont devenues super-rapides! Comme le dit tout le monde dans stackoverflow, c’est l’ordinateur qui cherche l’adresse du nom de serveur dans le service DNS et qui obtient un délai d’expiration. Voici les étapes que j’ai suivies. Essayez si rien d’autre ne fonctionne.

COMMENT AJOUTER UNE ENTRÉE DANS LE FICHIER D’HÔTES


1. Ouvrez l’invite de commande et envoyez une requête ping à votre serveur, où se trouve la firebase database distante. Pour ce faire, entrez la commande suivante:

 ping servername 

Ici, mon nom d’ordinateur distant était Juno. Donc, je devrais cingler comme ça.

 ping Juno 

Cette commande va cingler mon serveur et retourner l’adresse IP comme ceci.

 Pinging Juno [192.168.0.3] with 32 bytes of data: 

Comme vous pouvez voir l’adresse IP du serveur est entre les crochets. Copiez l’adresse IP.

2.Maintenant, ouvrez le fichier Hosts avec le Bloc-notes élevé (Exécuter en tant qu’administrateur).

À la fin du fichier hosts, il y aura quelques lignes comme celles-ci:

  #localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 

Tout en bas (ici, après l’hôte local), tapez # et entrez l’adresse IP du serveur que nous venons d’obtenir, précédée du nom du serveur. Ainsi, le fichier hosts devrait ressembler à ceci.

 # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost # 169.254.63.1 Juno 
  1. Enregistrez maintenant le fichier hosts et redémarrez le PC client. (Pour moi, cela a fonctionné instantanément sans redémarrage.)

Et voilà!

Pour plus d’informations sur la modification de votre fichier hosts, cliquez ici

Dans mon cas, la réponse était:

  • Essayez tout sans résultat.
  • Bureau à distance vers le serveur SQL (non-prod) pour vérifier les parameters.
  • Fermez Visual Studio que vous avez quitté en cours d’exécution après avoir effectué un travail SSIS rapide.
  • Va quelque part et tue-toi.

L’établissement d’une connexion de sécurité intégrée à SQL Server à l’aide de l’adresse IP (au lieu d’un nom d’hôte) empêchera l’utilisation de l’authentification Kerberos. Dans ce scénario, vérifiez la connexion entre SQL Server et le contrôleur de domaine.

Si vous vous connectez à l’aide du nom d’hôte (et non de l’adresse IP), Kerbos est en jeu. Dans ce cas, vous devez vérifier la connexion de l’ordinateur client au contrôleur de domaine.