SQL Server-Zeitlimit beim ersten Versuch

Ich habe ein seltsames Problem, bei dem ich versuche, eine Verbindung zu SQL Server 2008 herzustellen, das auf einem zweiten Computer ausgeführt wird (beide Computer führen Win7 64-Bit aus), entweder über die Datenquellen in Visual Studio oder über die SQL Management-Konsole selbst.

Beim ersten Verbindungsversuch tritt eine Zeitüberschreitung auf. Der zweite Versuch funktioniert gut.

Ich kann problemlos auf Freigaben auf dem zweiten Computer zugreifen. Es scheint nur das erste Mal zu sein, dass ich versuche, für jede Anwendungsinstanz eine Verbindung zu SQL herzustellen. Das heißt, wenn ich zwei Visual Studio-Instanzen öffne, schlagen beide beim ersten Verbindungsversuch fehl, beim zweiten jedoch erfolgreich. Ich muss für jede Instanz zweimal eine Verbindung herstellen (unabhängig von der Fehler- / Erfolgssequenz in einer anderen Anwendung).

Ich hoffe das ergibt Sinn.

Irgendein Rat?

Ich denke, ich habe die Lösung gefunden, zumindest in meinem Fall funktioniert sie. Ich verwende den Instanznamen und dies impliziert automatisch einen dynamischen Port für den SQL Server-Dienst. Ich habe die Einstellungen von dynamisch auf einen festen Port geändert und dann die Firewall an diesem Port geöffnet.

SQL Server Configuration Manager -> SQL Server-Netzwerkkonfiguration -> Protokolle für 'Instanzname' -> TCP / IP -> Eigenschaften -> IP-Adressen -> IP Alle ->

Hier sehen Sie zwei Möglichkeiten:

• Dynamische TCP-Ports: 51250 (zufällig generiert)
• TCP-Port: leer - Ich habe hier 1433 eingefügt und dann die Firewall geöffnet (falls sie noch nicht geöffnet war). Sie können einen beliebigen Port festlegen (ich habe 1433 angegeben, da dies die einzige Instanz war. Bei mehreren Instanzen sollten Sie für jede Instanz einen anderen Port auswählen und diese dann in der Firewall öffnen.)

Das Skript erleichtert Ihnen das Öffnen der von MS heruntergeladenen Ports und ich reproduziere es hier (Kommentare sind in deutscher Sprache, sollten aber offensichtlich sein):

@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

Ich vermute hier, dass Sie AUTO_CLOSE für die Datenbank aktiviert haben . Dies bedeutet, dass die Datenbank beim Herstellen einer Verbindung hochgefahren werden muss, was zu dem anfänglichen Timeout führt.

Die zweite Vermutung ist, dass es sich möglicherweise um eine Auflösung des Hostnamens handelt. Es dauert also zu lange, um den Hostnamen beim ersten Mal aufzulösen (möglicherweise per Broadcast?), Wird dann aber bei nachfolgenden Verbindungsversuchen zwischengespeichert. Womit lösen Sie den Host auf? ist es in DNS? Versuchen Sie, die Verbindungszeichenfolge in ein IP-Port-Format zu ändern. dh 192.168.100.100,1433

Sie können auch versuchen, ipconfig /flushdnsnach einem erfolgreichen Verbindungsversuch ausgeführt zu werden und festzustellen, ob Sie dann dasselbe Verhalten erhalten. Die zweifelhafte Problemumgehung besteht darin, die Suche in Ihre HOSTS-Datei einzufügen, aber Sie sollten sie ordnungsgemäß beheben.

Fühlt sich an wie ein langer Schuss im Dunkeln mit einer Augenbinde, aber es könnte helfen. In den Microsoft SQL Developer-Foren gibt es einen alten Thread, der beschreibt, was das gleiche Problem zu sein scheint, zusammen mit einer möglichen Lösung. Auf seinem Server wird Windows Server 2008 ausgeführt, dies kann jedoch auch für die Einrichtung von Win7 relevant sein.

Der Faden:

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

Aus dem Thread:

Ja, ich habe dieses Problem behoben.

Mein Windows Server 2008 wurde so konfiguriert, dass SASL-LDAP-Bindungen abgelehnt werden (siehe Warnung 2886).

Da ich meinen Server so konfiguriert habe, dass solche Bindungen nicht abgelehnt werden, funktionieren SQL Server 2008-Verbindungen ordnungsgemäß.

Informationen zum Ändern der LDAP-Signatureinstellungen finden Sie in Microsoft KB 935834 (ich kann keine Verknüpfung herstellen, da ich ein neuer Benutzer bin).

Ich hoffe es hilft!

Deaktivieren Sie die Firewall. Testnetzwerk (Ping). Sniff-Netzwerkverkehr zum SQL-Server (verwenden Sie Wireshark )

Können Sie versuchen, SQL Profiler auszuführen, bevor Sie zum ersten Mal eine Verbindung mit VS oder SSMS herstellen, und sehen, was auf dem SQL Server passiert?

Haben Sie auch die Ereignisprotokolle überprüft, um festzustellen, ob etwas protokolliert wird?