Xưởng quản lý SQL Server kết nối chậm hoặc hết thời gian khi sử dụng Xác thực Windows

23

Tôi đang bị trì hoãn rất lâu (10 ~ 30 giây) trong SQL Server Management Studio 2014 khi cố gắng kết nối với phiên bản SQL Server 2012 qua TCP bằng Windows xác thực . Điều này xảy ra khi kết nối Object Explorer hoặc một cửa sổ truy vấn trống mới. Sau khi kết nối, chạy truy vấn nhanh. Sự cố không xảy ra khi tôi kết nối bằng xác thực Máy chủ SQL.

Môi trường:

Windows 7, đăng nhập như một người dùng tên miền
Kết nối TCP qua địa chỉ IP (không phải tên máy chủ)
Máy chủ ở một vị trí từ xa được kết nối qua VPN
Không mã hóa

Khi tôi đăng nhập vào máy tính Windows 7 của đồng nghiệp với tài khoản miền của mình và được kết nối với cùng một Máy chủ SQL thông qua cùng một VPN, không có sự chậm trễ. Khi cùng một đồng nghiệp đăng nhập vào PC của tôi bằng tài khoản miền của chính anh ta, anh ta đã gặp phải sự chậm trễ. Các thử nghiệm này cho thấy vấn đề là duy nhất đối với PC của tôi. Ngoài ra, sự cố chỉ xuất hiện khi kết nối với SQL Server và VPN cụ thể này; Tôi có thể kết nối với các Máy chủ SQL khác trên mạng cục bộ thông qua Xác thực Windows mà không có bất kỳ sự chậm trễ nào.

Những điều tôi đã cố gắng không thành công:

Vô hiệu hóa chống vi-rút và tường lửa
Đổi tên thư mục "12.0" trong "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" thành "_12.0" để buộc SSMS tạo lại cài đặt người dùng của tôi.
Buộc giao thức mạng thành TCP chứ không phải <default>. Tôi cũng đã thử Named Faucet nhưng máy chủ của tôi không thiết lập cho điều đó.
Đã cài đặt SSMS 2012 và đã thử thay vì 2014.
IPv6 bị vô hiệu hóa
Blackholed crl.microsoft.com đến 127.0.0.1 trong tập tin etc \ hosts của tôi.
Vô hiệu hóa Chương trình cải thiện trải nghiệm khách hàng trong SSMS, Visual Studio và Windows.
Gỡ cài đặt tất cả các ứng dụng liên quan đến SQL Server khỏi PC của tôi và cài đặt lại vào năm 2012.

Manh mối TCPView:

Khi sử dụng TCPView, tôi nhận thấy rằng khi tôi tạo một kết nối mới, trạng thái của nó sẽ được THIẾT LẬP ngay lập tức, nhưng sau đó một hoặc hai kết nối với Máy chủ SQL liên tục được thử và đóng bằng TIME_WAIT . Trên máy tính của đồng nghiệp của tôi, các kết nối này được THÀNH LẬP và chắc chắn. Vì vậy, tôi khá chắc chắn đây là nguồn gốc của thời gian chờ, nhưng các kết nối là gì và tại sao chúng thất bại? (Tôi không có bất kỳ addons nào trong SSMS của mình.)

Có ý kiến gì không?

Cập nhật: Intellisense / Autocomplete clue (?):

Tôi nhận thấy rằng một khi cuối cùng tôi đã kết nối, Intellisense / Autocomplete không hoạt động. Những người yêu cầu kết nối riêng biệt từ SSMS? Tôi đã thử vô hiệu hóa chúng và dường như nó không giải quyết được sự chậm trễ kết nối dài.

— Jordan Rieger
nguồn

Bạn đã thử chạy SSMS với / log chưa?

— Magoo

@MisterMagoo đang thử điều đó ngay bây giờ. Nó không thực sự ghi lại bất cứ điều gì về các nỗ lực kết nối của nó (tệp không phát triển khi tạo kết nối mới). Chủ yếu là về việc tải các gói nhất định trong giao diện người dùng, ví dụ: "Đã lắp ráp thành công thành phần từ bộ đệm". Tôi không thể tìm thấy bất kỳ lỗi hoặc ngoại lệ.

— Jordan Rieger

Ok, tôi không chắc là nó có, nhưng hình dung nó đáng để thử nhanh. Nếu bạn thực sự quan tâm đến những gì đang diễn ra, bạn có thể cần phải phá vỡ Trình theo dõi quy trình Sysiternals và xem liệu bạn có thể xác định những gì đang xảy ra không. technet.microsoft.com/en-us/l Library / bb896645.aspx

— Mister Magoo

Tôi đã miệt mài với bãi rác ProcMon trong khoảng một giờ, nhưng có quá nhiều sự kiện (thậm chí được lọc xuống Ssms.exe) mà tôi không thể thực hiện được nhiều.

— Jordan Rieger

@MisterMagoo Tất cả những gì tôi có thể thấy là các nỗ lực kết nối mà tôi đã thấy với TcpView thực sự mất nhiều thời gian (mỗi lần hơn 5 giây). Tôi dựa trên cơ sở khi thấy sự kiện "Kết nối TCP" trên một cổng cục bộ cụ thể, và lần sau tôi thấy bất kỳ thứ gì được gửi hoặc nhận trên cổng cục bộ đó luôn luôn sau ít nhất 5 giây.

— Jordan Rieger

19

Hãy thử chạy một dấu vết với SQL Profiler trong khi bạn và sau đó đồng nghiệp của bạn kết nối với máy chủ.
Chọn RPC, SQL Statement & PreConnect - Bắt đầu / Hoàn thành.
Chọn tùy chọn Lưu kết quả vào bảng, sau đó so sánh 2 bảng để tìm nút cổ chai.

Hoặc, vì bạn đang kết nối bằng IP, nên có thể thực hiện tra cứu DNS ngược. Nếu vậy, thêm một mục trong tập tin máy chủ của bạn.

— d -_- b
nguồn

2

Tôi đã thêm một mục nhập cục bộ / máy chủ cho địa chỉ IP của máy chủ của mình, sau đó thử lại SSMS. Chơi lô tô! Siêu nhanh. Cảm ơn bạn! (Tôi đã rời SSMS kết nối qua địa chỉ IP như trước đây, không phải tên máy chủ.) Tôi chỉ tự hỏi tại sao tôi cần giải pháp này nhưng đồng nghiệp của tôi thì không. Nó dường như có liên quan đến DNS. Trong mọi trường hợp, đây là một giải pháp khá tốt cho tôi, vì vậy tôi sẽ trao thưởng cho bạn tiền thưởng sau khi bạn cập nhật câu trả lời của mình.

— Jordan Rieger

Tôi nghĩ rằng đó là tra cứu ngược vì khi tôi xóa mục nhập máy chủ, ping - một ###. ###. ###. ### rất chậm trước khi ping đầu tiên (tạm dừng 5 giây để tra cứu ngược lại.) Khi được thêm lại mục nhập máy chủ, ping -a rất nhanh. Không có sự khác biệt trong tracert hoặc nslookup. Tôi nghĩ rằng một cái gì đó phải khác trên PC của tôi khiến tôi phải tìm kiếm ngược lại khi đồng nghiệp của tôi không (hoặc nó nhanh hơn nhiều so với máy tính của họ.) BTW, Intellisense của tôi hoạt động trở lại khi tốc độ kết nối nhanh.

— Jordan Rieger

Ngay cả một mục DNS giả cho IP trong tệp máy chủ cũng giúp công việc này nhanh hơn nhiều! Cảm ơn bạn!

— felickz

Tôi đã hết thời gian cố gắng kết nối SSMS qua VPN cho đến khi tôi đọc câu trả lời của bạn, vâng, điều đó có ý nghĩa vì tôi đang kết nối với máy chủ thông qua IP và độ phân giải tên không hoạt động. Thêm một mục trong tệp máy chủ cuối cùng đã làm cho nó hoạt động sau nhiều giờ cố gắng để làm việc này. Cảm ơn! Như một chú thích tôi muốn nói rằng tôi đang sử dụng xác thực Windows từ các miền khác nhau với runas / netonly và nó hoạt động tốt với giải pháp này.

— RobbZ

5

Điều bạn nên kiểm tra đầu tiên là cài đặt DNS máy chủ hoặc máy khách của bạn

Không phải là hiếm khi SQL Server của bạn gặp sự cố khi kết nối với Active Directory. Nếu bạn thử với tài khoản Windows cục bộ, tôi chắc chắn rằng bạn sẽ không gặp vấn đề gì. Không có gì lạ khi máy chủ được cấu hình với DNS internet công cộng và khi SQL Server kết nối với DC để kiểm tra thông tin đăng nhập và xác minh nó, nó sẽ thử liên hệ hàng đầu với DNS công cộng thay vì máy chủ DNS của AD. Vì thông tin này không được lưu trữ trên DNS công cộng nên sẽ không thể xác minh và điều này sẽ gây ra sự chậm trễ cho đến khi nó quản lý để liên hệ với máy chủ DNS hoặc DC thích hợp thông qua NTLM

Vì bạn không gặp vấn đề với các Máy chủ SQL khác, nên gần như chắc chắn vấn đề không liên quan đến cấu hình AD hoặc DC

Bắn IPConfig.exe / all lệnh từ cmd để kiểm tra các máy chủ DNS được cấu hình. Bạn chỉ nên cấu hình máy chủ DNS của AD. Xóa tất cả các máy chủ DNS công cộng và chỉ để lại các máy chủ DNS của AD.

— NikolaD
nguồn

Bạn có gợi ý rằng Máy chủ SQL đang liên hệ với DNS công cộng để tra cứu địa chỉ IP của Bộ điều khiển miền và điều đó gây ra sự chậm trễ khi nó cố xác thực Windows xác thực của tôi không? Nếu đó là lý do, tại sao nó hoạt động tốt từ PC của đồng nghiệp của tôi trên cùng một mạng cục bộ, trên cùng một VPN? Tôi đã kiểm tra cài đặt DNS trên máy tính của mình và có thêm một máy chủ DNS thứ ba mà bộ phận IP của tôi đã yêu cầu tôi thêm, không có trên PC của đồng nghiệp của tôi. Nhưng khi tôi gỡ bỏ máy chủ đó, thực hiện ipconfig / flushdns và thử lại, nó vẫn chậm.

— Jordan Rieger

Việc sử dụng địa chỉ IP hoặc FQDN của máy chủ (không chỉ tên máy chủ) đã tạo ra sự khác biệt rất lớn đối với tôi. Chắc chắn là một vấn đề DNS chậm trong trường hợp của tôi.

— userSteve

0

Tôi mở rộng C:\Windows\System32\drivers\etc\hoststập tin bằng cách thêm dòng như thế này:

201.202.203.204     mysqlserver

201.202.203.204 là địa chỉ IP của SQL Server của bạn.

mysqlserver - bất kỳ tên nào bạn thích (bạn không phải sử dụng nó ở bất cứ đâu).

Điều này làm cho máy chủ của tôi nhanh hơn.

Cảm ơn: d -_- b, Jordan, Rieger, felickz, RobbZ

— Dennis Gorelik
nguồn

0

Tắt Windows Firewall trên máy chủ SQL của bạn cho cấu hình mạng Miền.

Bắt đầu Powershell
Chạy Get-NetFirewallProfile -Profile Domainđể kiểm tra trạng thái hiện tại của nó
Nếu nó được kích hoạt, hãy chạy: Set-NetFirewallProfile -Profile Domain -Enabled Falsetắt nó đi.

Nếu đây là nó, bạn có thể bật lại sau và tinh chỉnh cài đặt của bạn. Hoặc, nếu bạn đang ở trong một môi trường an toàn, bạn có thể bỏ nó đi.

Điều kỳ lạ là ngay cả khi Windows Firewall chặn giao tiếp, bạn vẫn có thể kết nối nhưng cả bắt tay ban đầu và các yêu cầu tiếp theo sẽ rất chậm. Lý thuyết của tôi (dựa trên không có bằng chứng thực tế) là trong những trường hợp này, giao tiếp rơi vào Named Faucet, tốc độ chậm hơn rất nhiều giữa các PC từ xa.

— Laszlo Mako
nguồn