Windows Kimlik Doğrulaması kullanılırken SQL Server Management studio yavaş bağlantı veya zaman aşımı

23

Windows Kimlik Doğrulaması'nı kullanarak TCP üzerinden bir SQL Server 2012 örneğine bağlanmaya çalışırken SQL Server Management Studio 2014'te çok uzun gecikmeler (10 ~ 30 saniye) alıyorum . Bu, Nesne Gezgini'ne veya yeni bir boş sorgu penceresi bağlanırken olur. Bağlandıktan sonra çalışan sorgulamalar hızlıdır. SQL Server kimlik doğrulaması kullanarak bağlandığımda sorun oluşmuyor.

Çevre:

Etki alanı kullanıcısı olarak oturum açan Windows 7
IP adresi üzerinden TCP bağlantısı (ana bilgisayar adı değil)
Sunucu VPN ile bağlı uzak bir yerde
Şifreleme yok

Bir iş arkadaşının Windows 7 bilgisayarına etki alanı hesabımla giriş yaptığımda ve aynı SQL Server'a aynı VPN üzerinden bağlandığımda hiçbir gecikme olmadı. Aynı iş arkadaşı bilgisayarıma kendi etki alanı hesabıyla giriş yaptığında gecikmeyi yaşadı. Bu testler problemin bilgisayarıma özgü olduğunu gösteriyor . Ayrıca, sorun yalnızca bu belirli SQL Server ve VPN'e bağlanırken görünür; Yerel ağdaki diğer SQL Sunucularına herhangi bir gecikme olmadan Windows Kimlik Doğrulama yoluyla bağlanabiliyorum.

Başarısızlıkla denediğim şeyler:

Engelli antivirüs ve güvenlik duvarı
SSMS'yi kullanıcı ayarlarımı yeniden oluşturmaya zorlamak için "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" altındaki "12.0" klasörünü "_12.0" olarak yeniden adlandırdım.
Ağ protokolünü yerine TCP'ye zorlayın <default>. Adlandırılmış Borular da denedim, ancak sunucum bunun için ayarlanmadı.
SSMS 2012'yi yükleyip 2014 yerine denedim.
Engelli IPv6
Blackholed crl.microsoft.com, benim \ \ hosts dosyamda 127.0.0.1.
SSMS, Visual Studio ve Windows'ta Müşteri Deneyimi Geliştirme Programını devre dışı bırakın.
Tüm SQL Server ile ilgili uygulamaları PC'mden kaldırdım ve yeniden 2012'ye yükledi.

TCPView ipuçları:

TCPView kullanarak, yeni bir bağlantı kurduğumda, durumunun hemen KURULDU haline geldiğini, ancak daha sonra SQL Server ile bir veya iki bağlantının sürekli denenip TIME_WAIT ile kapatıldığını fark ettim . İş arkadaşımın bilgisayarında bu bağlantılar KURULAN ve sağlam. Öyleyse bunun zaman aşımının kaynağı olduğuna eminim, ancak bunun için bağlantılar ve neden başarısız oluyorlar? (SSMS’mde herhangi bir eklenti yok.)

Herhangi bir fikir?

Güncelleme: Intellisense / Otomatik Tamamlama ipucu (?):

Sonunda bağlantı kurduğumda, Intellisense / Autocomplete'nin çalışmadığını fark ettim. Bunlar SSMS'den ayrı bağlantılar gerektiriyor mu? Onları devre dışı bırakmayı denedim ve uzun bağlantı gecikmesini çözmedi.

— Jordan Rieger
kaynak

/ Log anahtarıyla SSMS çalıştırmayı denediniz mi?

— Bay Magoo

@MisterMagoo şimdi çalışıyor. Aslında bağlantı girişimleriyle ilgili hiçbir şey kaydetmiyor (yeni bir bağlantı yaparken dosya büyümiyor). Çoğunlukla UI'ye belirli paketleri yüklemekle ilgili bir şeydir, örneğin "Önbellekten başarıyla yüklenen bileşen montajı". Herhangi bir hata veya istisna bulamadım.

— Jordan Rieger

Tamam, olacağından emin değildim ama hızlıca denemeye değer olduğunu anladım. Neler olup bittiğiyle gerçekten ilgileniyorsanız, Sysinternals Process Monitor'ü dağıtmanız ve neler olup bittiğini tespit edip edemediğinizi görmeniz gerekebilir. technet.microsoft.com/en-us/library/bb896645.aspx

— Bay Magoo

ProcMon dökümlerini yaklaşık bir saattir gözetliyordum, fakat fazlaca yapamayacağım çok fazla olay var (hatta Ssms.exe'ye kadar filtrelendi).

— Jordan Rieger

@MisterMagoo Tüm görebildiğim, TcpView ile gördüğüm bağlantı girişimlerinin gerçekten de uzun zaman alıyor olması (her biri 5 saniyeden fazla). Belirli bir yerel bağlantı noktasında "TCP Connect" olayını görmeye dayanıyor ve bir dahaki sefere bu yerel bağlantı noktasında gönderilen veya alınan bir şey gördüğümde her zaman en az 5 saniye sonra oluyor.

— Jordan Rieger

19

Siz ve sonra iş arkadaşınız sunucuya bağlanırken SQL Profiler ile bir izleme çalıştırmayı deneyin.
RPC, SQL Beyanı ve PreConnect - Başla / Tamamlandı'yı seçin.
Sonuçları Tabloya Kaydet seçeneğini seçin, ardından tıkanıklığı bulmak için 2 tabloyu karşılaştırın.

Veya, IP ile bağladığınız için, bir DNS Ters Arama işlemi yapıyor olabilir. Öyleyse, hosts dosyasına bir giriş ekle.

— d -_- b
kaynak

2

Sunucumun IP adresi için yerel bir etc / hosts girişi ekledim, sonra SSMS'yi tekrar denedim. Bingo! Çok hızlı. Teşekkür ederim! (SSMS'yi IP adresi üzerinden ana bilgisayar adı yerine bağlanarak bıraktım.) Bu geçici çözüme neden ihtiyaç duyduğumu merak ediyorum ancak iş arkadaşlarım ihtiyaç duymuyor. DNS ile ilgili gibi görünüyor. Her durumda, bu benim için oldukça iyi bir çözüm, bu yüzden cevabınızı güncelledikten sonra size ödül vereceğim.

— Jordan Rieger

Ben ters arama olduğunu düşünüyorum çünkü hosts girişini kaldırdığımda, ping - a ###. ###. ###. ### ilk ping işleminden önce çok yavaştı (ters arama için 5 saniye duraklatıldı.) Ana bilgisayar girişini geri eklediğinizde, ping -a hızlıydı. Yine de izlemede veya bakış açısında bir fark yoktu. Bilgisayarımda, iş arkadaşlarım olmadığı zamanlarda (ya da kendi başlarına çok daha hızlı olduğu zaman) geriye doğru arama yapmamı sağlayan bir şeylerin farklı olması gerektiğini düşünüyorum. BTW, Intellisense, bağlantı hızının hızlı olması için tekrar çalışıyor.

— Jordan Rieger

Ana bilgisayar dosyasında IP için sahte bir DNS girişi bile bu işlemi daha hızlı yapar! Teşekkür ederim!

— Felickz

Cevabınızı okuyana kadar SSMS'yi bir VPN üzerinden bağlamaya çalışırken zaman aşımına uğradım, evet, sunucuya IP üzerinden bağlanıyordum ve ad çözümlemesi işe yaramıyordu. Ana bilgisayar dosyasına bir giriş eklemek sonunda bu çalışmayı denemek için birkaç saat sonra çalışmasını sağladı. Teşekkürler! Dipnot olarak, Windows kimlik doğrulamasını farklı alanlardan runas / netonly ile kullandığımı ve bu çözümle iyi çalıştığımı söylemek istiyorum.

— RobbZ

5

Öncelikle kontrol etmeniz gereken şey sunucu veya müşteri DNS ayarlarınızdır

SQL Server'ınızın Active Directory'ye bağlanma sorunu olmadığı nadir değildir. Yerel Windows hesabıyla çalışırsanız, sorun olmayacağına eminim. Sunucunun genel İnternet DNS ile yapılandırılması alışılmadık bir durum değildir ve SQL Server, kimlik bilgilerini kontrol etmek ve doğrulamak için DC'ye bağlandığında, AD'nin DNS sunucusu yerine genel DNS ile en iyi iletişim kurmaya çalışır. Bu bilgi genel DNS’de depolanmadığından doğrulanamayacak ve bu durum NTLM üzerinden uygun DNS sunucusuyla veya DC’yle bağlantı kurmayı başarana kadar gecikmeye neden olacaktır.

Sorunu diğer SQL Sunucuları ile yaşamadığınızdan, neredeyse kesin olarak sorun AD ya da DC yapılandırmalarıyla ilgili değil.

Yapılandırılmış DNS sunucularını kontrol etmek için IPConfig.exe / all komutunu cmd'den kapatın . Sadece AD’nin DNS sunucularını yapılandırmış olmalısınız. Tüm genel DNS sunucularını kaldırın ve yalnızca AD'nin DNS sunucularını bırakın.

— NikolaD
kaynak

SQL Server'ın Etki Alanı Denetleyicisinin IP adresini aramak için ortak bir DNS ile iletişim kurmasını ve Windows Kimlik Doğrulamamı doğrulamaya çalışırken gecikmeye neden olduğunu mu söylüyorsunuz? Öyleyse, neden aynı yerel ağdaki iş arkadaşımın bilgisayarından aynı VPN üzerinden iyi çalışıyor? Bilgisayarımdaki DNS ayarlarını kontrol ettim ve iş arkadaşımın bilgisayarında bulunmayan IP bölümümün eklememi istediği üçüncü bir DNS sunucusu daha vardı. Ama o sunucuyu kaldırdığımda, bir ipconfig / flushdns yaptım ve tekrar denediğimde, hala yavaştı.

— Jordan Rieger

Sunucunun IP adresini veya FQDN'sini kullanmak (sadece ana bilgisayar adını değil) benim için büyük bir fark yarattı. Benim durumumda kesinlikle yavaş bir DNS sorunuydu.

— userSteve

0

C:\Windows\System32\drivers\etc\hostsBöyle bir çizgi ekleyerek dosyayı genişlettim :

201.202.203.204     mysqlserver

201.202.203.204 SQL Server'ınızın IP adresidir.

mysqlserver - İstediğiniz herhangi bir ad (herhangi bir yerde kullanmak zorunda değilsiniz).

Bu sunucumu daha hızlı yaptı.

Teşekkürler: d-_- b, Ürdün, Rieger, felickz, RobbZ

— Dennis Gorelik
kaynak

0

Etki alanı ağ profili için SQL sunucunuzdaki Windows Güvenlik Duvarı'nı kapatın.

Powershell'i Başlat
Koşmak Get-NetFirewallProfile -Profile DomainMevcut durumunu kontrol etmek için
Etkinleştirilmişse, çalıştırmak için: Set-NetFirewallProfile -Profile Domain -Enabled Falsekapatın.

Eğer öyleyse, daha sonra tekrar açabilir ve ayarlarınızı hassas şekilde yapabilirsiniz. Veya, güvenli bir ortamdaysanız, kapalı bırakabilirsiniz.

Tuhaf olan şey, Windows Güvenlik Duvarı iletişimi engellese bile, yine de bağlanabileceksiniz, ancak hem ilk el sıkışma hem de sonraki isteklerin inanılmaz derecede yavaş olması. Teorim (gerçek kanıtlara dayanarak değil), bu durumlarda iletişimin uzak PC'ler arasında çok daha yavaş olan Adlı Borulara geri döndüğüdür.

— Laszlo Mako
kaynak