Timeout di SQL Server al primo tentativo

Sto riscontrando uno strano problema in cui provo a collegarmi a SQL Server 2008 in esecuzione su un secondo computer (entrambe le macchine che eseguono Win7 a 64 bit), tramite l'origine dati in Visual Studio o tramite la console di gestione SQL stessa.

Al primo tentativo di connessione, si verifica un timeout. Il secondo tentativo funziona bene.

Posso accedere alle condivisioni sul secondo computer senza alcuna difficoltà, sembra solo essere la prima volta che provo a connettermi a SQL per ogni istanza dell'applicazione. Cioè, se apro due istanze di Visual Studio, entrambe falliranno al primo tentativo di connessione, ma riusciranno nel secondo. Devo collegarmi due volte per ogni istanza (indipendentemente dalla sequenza di errori / successi in qualsiasi altra applicazione).

Spero che abbia un senso.

Qualche consiglio?

Penso di aver trovato la soluzione, almeno nel mio caso funziona. Sto usando il nome dell'istanza e questo implica automaticamente una porta dinamica per il servizio SQL Server. Ho modificato le impostazioni da dinamica a porta fissa e quindi ho aperto il firewall su quella porta.

Gestione configurazione SQL Server -> Configurazione rete SQL Server -> Protocolli per 'Nomeistanza' -> TCP / IP -> Proprietà -> Indirizzi IP -> IP tutto ->

Qui vedi due opzioni:

• Porte dinamiche TCP: 51250 (generate casualmente)
• Porta TCP: vuota - Ho inserito qui il 1433 e quindi ho aperto il firewall (nel caso in cui non fosse già stato aperto). Puoi mettere qualunque porta desideri (ho inserito 1433 perché era l'unica istanza. In caso di più istanze dovresti scegliere per ogni istanza una porta diversa e quindi aprirle nel firewall)

Lo script utilizzato per facilitare il tuo compito di aprire le porte che ho scaricato da MS e lo sto riproducendo qui (i commenti sono in tedesco ma dovrebbero essere ovvi):

@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

La mia ipotesi migliore è che AUTO_CLOSE sia attivato per il database. Ciò significa che il database deve essere sottoposto a spin-up quando ci si connette, che è la causa del timeout iniziale.

La seconda ipotesi è che potrebbe essere correlato alla risoluzione del nome host. Quindi ci vuole troppo tempo per risolvere il nome host la prima volta (forse per trasmissione?), Ma poi viene memorizzato nella cache per i successivi tentativi di connessione. Cosa stai usando per risolvere l'host? è in DNS? Prova a cambiare la stringa di connessione in un formato IP, porta. cioè 192.168.100.100,1433

Puoi anche provare a correre ipconfig /flushdnsdopo un tentativo di connessione riuscito e vedere se ottieni lo stesso comportamento. La soluzione complicata consiste nel mettere la ricerca nel file HOSTS, ma è necessario risolverlo correttamente.

Sembra un lungo tiro nel buio con una benda sugli occhi, ma potrebbe essere d'aiuto. C'è un vecchio thread nei forum degli sviluppatori di Microsoft SQL che descrive quello che sembra essere lo stesso problema, insieme a una possibile soluzione. Il suo server esegue Windows Server 2008, ma potrebbe essere rilevante anche per la tua configurazione di Win7.

Il filo:

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

Dal thread:

Sì, ho risolto questo problema.

Il mio server Windows 2008 è stato configurato per rifiutare i binding LDAP SASL (vedi avviso 2886).

Dal momento che ho configurato il mio server per non rifiutare tali collegamenti, le connessioni SQL Server 2008 funzionano correttamente.

Puoi consultare Microsoft KB 935834 per informazioni sulla modifica delle impostazioni di firma LDAP (non riesco a collegarmi perché sono un nuovo utente).

Spero che sia d'aiuto!

Disabilita il firewall. Rete di prova (ping). Sniffare il traffico di rete al server sql (utilizzare WireShark )

Puoi provare a eseguire SQL Profiler prima di connetterti per la prima volta con VS o SSMS e vedere cosa sta succedendo su SQL Server?

Inoltre, hai controllato i registri degli eventi per vedere se qualcosa viene registrato?