Délai d'expiration SQL Server lors de la première tentative

J'ai un problème étrange où j'essaie de me connecter à SQL Server 2008 exécuté sur un deuxième ordinateur (les deux machines exécutant Win7 64 bits), soit via les sources de données dans Visual Studio, soit via la console de gestion SQL elle-même.

Lors de la première tentative de connexion, le délai expire. La deuxième tentative fonctionne bien.

Je peux accéder aux partages sur le deuxième ordinateur sans aucune difficulté, il semble que ce soit la première fois que j'essaie de me connecter à SQL pour chaque instance d'application. Autrement dit, si j'ouvre deux instances de Visual Studio, les deux échoueront lors de leur première tentative de connexion, mais réussiront la seconde. Je dois me connecter deux fois pour chaque instance (quelle que soit la séquence d'échec / réussite dans toute autre application).

J'espère que cela à du sens.

Aucun conseil?

Je pense avoir trouvé la solution, du moins dans mon cas ça marche. J'utilise le nom d'instance et cela implique automatiquement un port dynamique pour le service du serveur SQL. J'ai changé les paramètres de dynamique en port fixe, puis j'ai ouvert le pare-feu sur ce port.

Gestionnaire de configuration SQL Server -> Configuration réseau SQL Server -> Protocoles pour 'InstanceName' -> TCP / IP -> Propriétés -> Adresses IP -> IP All ->

Ici, vous voyez deux options:

• Ports dynamiques TCP: 51250 (générés aléatoirement)
• Port TCP: vide - j'ai mis ici 1433 puis j'ai ouvert le pare-feu (au cas où il ne serait pas déjà ouvert). Vous pouvez mettre le port que vous voulez (je mets 1433 car c'était la seule instance. En cas de plusieurs instances, vous devez choisir pour chaque instance un port différent puis les ouvrir dans le pare-feu)

Le script utilisé pour faciliter votre tâche d'ouverture des ports que j'ai téléchargés depuis MS et je le reproduis ici (les commentaires sont en allemand mais ils devraient être évidents):

@echo =========  Ports des SQL-Servers  ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer" 
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung" 
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker  
netsh firewall set portopening TCP 4022 "SQL-Service Broker" 
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC 
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC" 
@echo =========  Ports für Analysedienste  ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste" 
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser" 
@echo =========  Verschiedene Anwendungen  ==============
@echo Aktivieren von Port 80 für HTTP 
netsh firewall set portopening TCP 80 "HTTP" 
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL" 
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser" 
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE

Ma meilleure supposition ici est que vous avez activé AUTO_CLOSE pour la base de données. Cela signifie que la base de données doit tourner lorsque vous vous connectez, ce qui est à l'origine du délai d'attente initial.

La deuxième supposition est qu'il peut être lié à la résolution du nom d'hôte. Il faut donc trop de temps pour résoudre le nom d'hôte la première fois (par diffusion peut-être?), Mais il est ensuite mis en cache lors des tentatives de connexion suivantes. Qu'utilisez-vous pour résoudre l'hôte? est-ce dans DNS? Essayez de changer la chaîne de connexion pour qu'elle soit dans un format de port IP. soit 192.168.100.100,1433

Vous pouvez également essayer de courir ipconfig /flushdnsaprès une tentative de connexion réussie et voir si vous obtenez alors le même comportement. La solution de contournement douteuse consiste à placer la recherche dans votre fichier HOSTS, mais vous devez la corriger correctement.

Sent comme un long coup dans l'obscurité avec un bandeau sur les yeux, mais cela pourrait aider. Il y a un fil conducteur sur les forums Microsoft SQL Developer décrivant ce qui semble être le même problème, ainsi qu'un correctif possible. Son serveur exécute Windows Server 2008, mais peut également être pertinent pour votre configuration Win7.

Le fil:

http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/58bd9c4d-0572-4567-8e32-82a7fd600022

Du fil:

Oui, j'ai résolu ce problème.

Mon serveur Windows 2008 a été configuré pour rejeter les liaisons SASL LDAP (voir l'avertissement 2886).

Puisque j'ai configuré mon serveur pour ne pas rejeter de telles liaisons, les connexions au serveur SQL 2008 fonctionnent correctement.

Vous pouvez consulter Microsoft KB 935834 pour plus d'informations sur la modification des paramètres de signature LDAP (impossible de créer un lien vers celui-ci car je suis un nouvel utilisateur).

J'espère que cela aide!

Désactivez le pare-feu. Test du réseau (ping). Reniflez le trafic réseau vers le serveur SQL (utilisez Wireshark )

Pouvez-vous essayer d'exécuter SQL Profiler avant de vous connecter pour la première fois avec VS ou SSMS et voir ce qui se passe sur SQL Server?

De plus, avez-vous vérifié les journaux des événements pour voir si quelque chose est enregistré?