Connessione lenta o timeout di SQL Server Management studio quando si utilizza l'autenticazione di Windows

23

Ricevo ritardi estremamente lunghi (10 ~ 30 secondi) in SQL Server Management Studio 2014 quando tento di connettermi a un'istanza di SQL Server 2012 su TCP utilizzando l' autenticazione di Windows . Ciò accade quando si collega Esplora oggetti o una nuova finestra di query vuota. Una volta connesso, l'esecuzione delle query è rapida. Il problema non si verifica quando mi connetto utilizzando l'autenticazione di SQL Server.

Ambiente:

Windows 7, eseguito l'accesso come utente di dominio
Connessione TCP tramite indirizzo IP (non nome host)
Il server si trova in una posizione remota connessa tramite VPN
Nessuna crittografia

Quando ho effettuato l'accesso al computer Windows 7 di un collega di lavoro con il mio account di dominio e mi sono connesso allo stesso SQL Server tramite la stessa VPN, non c'è stato alcun ritardo. Quando lo stesso collega ha effettuato l'accesso al mio PC con il proprio account di dominio, ha riscontrato un ritardo. Questi test mostrano che il problema è unico per il mio PC. Inoltre, il problema appare solo quando ci si collega a questo specifico SQL Server e VPN; Posso connettermi ad altri server SQL sulla rete locale tramite l'autenticazione di Windows senza alcun ritardo.

Cose che ho provato senza successo:

Anti-virus e firewall disabilitati
Rinominata la cartella "12.0" in "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" in "_12.0" per forzare SSMS a ricreare le mie impostazioni utente.
Forza il protocollo di rete su TCP anziché <default>. Ho anche provato Named Pipes ma il mio server non è configurato per quello.
Ho installato SSMS 2012 e l'ho provato invece del 2014.
IPv6 disabilitato
Blackled crl.microsoft.com a 127.0.0.1 nel mio file etc \ hosts.
Disabilitato il Programma di miglioramento dell'esperienza del cliente in SSMS, Visual Studio e Windows.
Ho disinstallato tutte le app relative a SQL Server dal mio PC e reinstallate solo nel 2012.

Indizi TCPView:

Usando TCPView, ho notato che quando faccio una nuova connessione, il suo stato diventa subito STABILITO, ma poi una o due altre connessioni con SQL Server vengono continuamente tentate e chiuse con TIME_WAIT . Sul computer del mio collega, queste connessioni sono STABILITE e solide. Quindi sono abbastanza sicuro che questa sia la fonte dei timeout, ma a cosa servono le connessioni e perché falliscono? (Non ho nessun componente aggiuntivo nel mio SSMS.)

Qualche idea?

Aggiornamento: Intellisense / Indizio di completamento automatico (?):

Ho notato che una volta finalmente connesso, Intellisense / Completamento automatico non funziona. Questi richiedono connessioni separate da SSMS? Ho provato a disabilitarli e non sembrava risolvere il lungo ritardo della connessione.

— Jordan Rieger
fonte

Hai provato a eseguire SSMS con l'opzione / log?

— Mago Magoo,

@MisterMagoo che ci prova adesso. In realtà non registra nulla dei suoi tentativi di connessione (il file non cresce quando si effettua una nuova connessione). Si tratta principalmente di caricare determinati pacchetti nell'interfaccia utente, ad esempio "Assemblaggio componente caricato correttamente dalla cache". Non sono riuscito a trovare errori o eccezioni.

— Jordan Rieger,

Ok, non ero sicuro che sarebbe successo, ma ho pensato che valesse la pena provare. Se sei veramente interessato a ciò che sta succedendo, potresti dover interrompere Sysinternals Process Monitor e vedere se riesci a identificare cosa sta succedendo. technet.microsoft.com/en-us/library/bb896645.aspx

— Mister Magoo,

Ho analizzato i dump ProcMon per circa un'ora, ma ci sono così tanti eventi (anche filtrati fino a Ssms.exe) che non riesco a farne gran parte.

— Jordan Rieger,

@MisterMagoo Tutto quello che posso vedere è che i tentativi di connessione che ho visto con TcpView stanno effettivamente impiegando molto tempo (oltre 5 secondi ciascuno). Lo sto basando sul vedere l'evento "TCP Connect" su una determinata porta locale, e poi la prossima volta che vedo qualcosa inviato o ricevuto su quella porta locale è sempre dopo almeno 5 secondi.

— Jordan Rieger,

19

Prova a eseguire una traccia con SQL Profiler mentre tu e il tuo collega vi connettete al server.
Seleziona RPC, Dichiarazione SQL e PreConnect - Avvio / Completato.
Selezionare l'opzione Salva risultati nella tabella, quindi confrontare le 2 tabelle per trovare il collo di bottiglia.

Oppure, poiché ti stai connettendo tramite IP, potrebbe essere una ricerca DNS inversa. In tal caso, aggiungi una voce nel file hosts.

— d -_- b
fonte

2

Ho aggiunto una voce locale etc / hosts per l'indirizzo IP del mio server, quindi ho provato di nuovo SSMS. Bingo! Super veloce. Grazie! (Ho lasciato la connessione SSMS tramite l'indirizzo IP come prima, non il nome host.) Mi chiedo solo perché ho bisogno di questa soluzione alternativa, ma i miei colleghi no. Sembra essere correlato al DNS. In ogni caso, questa è una soluzione abbastanza buona per me, quindi ti assegnerò la generosità una volta aggiornata la tua risposta.

— Jordan Rieger,

Penso che sia stata la ricerca inversa perché quando ho rimosso la voce hosts, il ping - a ###. ###. ###. ### era molto lento prima del primo ping (in pausa 5 secondi per la ricerca inversa). Quando è stata aggiunta nuovamente la voce hosts, il ping -a è stato veloce. Tuttavia, non vi era alcuna differenza nel tracert o nslookup. Penso che qualcosa sul mio PC debba essere diverso e che mi sta facendo fare la ricerca inversa quando i miei colleghi non lo sono (o è solo molto più veloce sul loro.) A proposito, il mio Intellisense funziona di nuovo ora che la velocità di connessione è alta.

— Jordan Rieger,

Anche una voce DNS falsa per l'IP nel file hosts rende questo lavoro molto più veloce! Grazie!

— Felickz,

Stavo ottenendo timeout cercando di connettere SSMS attraverso una VPN fino a quando non ho letto la tua risposta, sì, ha senso perché mi stavo collegando al server tramite IP e la risoluzione dei nomi non funzionava. L'aggiunta di una voce nel file host alla fine ha funzionato dopo molte ore cercando di farlo funzionare. Grazie! Come nota a piè di pagina voglio dire che sto usando l'autenticazione di Windows da domini diversi con runas / netonly e funziona bene con questa soluzione.

— RobbZ,

5

Quello che dovresti controllare prima sono le impostazioni DNS del tuo server o client

Non è raro che SQL Server abbia il problema di connettersi ad Active Directory. Se provi con un account Windows locale sono sicuro che non avrai il problema in questione. Non è insolito che il server sia configurato con DNS Internet pubblico e quando SQL Server si connette a DC per controllare le credenziali e verificarlo, proverà a contattare il DNS pubblico anziché il server DNS di Active Directory. Poiché queste informazioni non sono archiviate sul DNS pubblico, non verrà verificata e ciò causerà il ritardo fino a quando non riuscirà a contattare il server DNS o il controller di dominio corretto tramite NTLM

Poiché non si verifica il problema con altri server SQL, quasi sicuramente il problema non è correlato alle configurazioni AD o DC

Fuoco l'ipconfig.exe / all comando dal cmd per controllare i server DNS configurati. Dovresti avere configurato solo i server DNS di AD. Rimuovi tutti i server DNS pubblici e lascia solo i server DNS di AD.

— NikolaD
fonte

Stai suggerendo che SQL Server sta contattando un DNS pubblico per cercare l'indirizzo IP del controller di dominio e che sta causando il ritardo quando tenta di convalidare la mia autenticazione di Windows? In tal caso, perché dovrebbe funzionare correttamente dal PC del mio collega di lavoro sulla stessa rete locale, sulla stessa VPN? Ho controllato le impostazioni DNS sul mio computer e c'era un terzo server DNS aggiuntivo che il mio dipartimento IP mi aveva chiesto di aggiungere, che non era presente sul PC del mio collega. Ma quando ho rimosso quel server, ho eseguito un ipconfig / flushdns e riprovato, era ancora lento.

— Jordan Rieger,

L'uso dell'indirizzo IP o del nome FQDN del server (non solo del nome host) ha fatto una grande differenza per me. Nel mio caso è stato sicuramente un lento problema DNS.

— userSteve

0

Ho esteso il C:\Windows\System32\drivers\etc\hostsfile aggiungendo una linea come questa:

201.202.203.204     mysqlserver

201.202.203.204 è l'indirizzo IP del tuo SQL Server.

mysqlserver - qualsiasi nome che ti piace (non devi usarlo da nessuna parte).

Questo ha reso il mio server più veloce.

Grazie a: d -_- b, Jordan, Rieger, felickz, RobbZ

— Dennis Gorelik
fonte

0

Disattiva Windows Firewall sul tuo server SQL per il profilo di rete del dominio.

Avvia Powershell
Esegui Get-NetFirewallProfile -Profile Domainper controllare il suo stato attuale
Se è abilitato, esegui: Set-NetFirewallProfile -Profile Domain -Enabled Falseper disattivarlo.

In questo caso, è possibile riattivarlo in seguito e ottimizzare le impostazioni. Oppure, se ti trovi in un ambiente sicuro, puoi lasciarlo spento.

La cosa strana è che anche se Windows Firewall blocca la comunicazione, sarai comunque in grado di connetterti, ma sia la stretta di mano iniziale che le richieste successive saranno incredibilmente lente. La mia teoria (basata su nessuna prova reale) è che in questi casi la comunicazione ricade su Named Pipes che è molto più lento tra i PC remoti.

— Laszlo Mako
fonte