SQL Server Management Studio conexión lenta o tiempo de espera al usar la autenticación de Windows

23

Recibo demoras extremadamente largas (10 ~ 30 segundos) en SQL Server Management Studio 2014 cuando intento conectarme a una instancia de SQL Server 2012 a través de TCP utilizando la autenticación de Windows . Esto sucede al conectar Object Explorer o una nueva ventana de consulta en blanco. Una vez conectado, ejecutar consultas es rápido. El problema no ocurre cuando me conecto usando la autenticación de SQL Server.

Medio ambiente:

Windows 7, conectado como usuario de dominio
Conexión TCP a través de la dirección IP (no el nombre de host)
El servidor está en una ubicación remota conectada a través de VPN
Sin cifrado

Cuando inicié sesión en la computadora Windows 7 de un compañero de trabajo con mi cuenta de dominio y me conecté al mismo SQL Server a través de la misma VPN, no hubo demora. Cuando el mismo compañero de trabajo inició sesión en mi PC con su propia cuenta de dominio, experimentó el retraso. Estas pruebas muestran que el problema es exclusivo de mi PC. Además, el problema solo aparece cuando se conecta a este SQL Server y VPN específicos; Puedo conectarme a otros servidores SQL en la red local a través de la autenticación de Windows sin demora.

Cosas que he intentado sin éxito:

Antivirus y firewall deshabilitados
Cambié el nombre de la carpeta "12.0" en "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" a "_12.0" para obligar a SSMS a recrear mi configuración de usuario.
Forzar el protocolo de red a TCP en lugar de <default>. También probé Canalizaciones con nombre, pero mi servidor no está configurado para eso.
Instalé SSMS 2012 y probé eso en lugar de 2014.
IPv6 deshabilitado
Blackholed crl.microsoft.com a 127.0.0.1 en mi archivo etc \ hosts.
Deshabilitó el Programa de mejora de la experiencia del cliente en SSMS, Visual Studio y Windows.
Desinstalé todas las aplicaciones relacionadas con SQL Server de mi PC y reinstalé solo 2012.

Pistas de TCPView:

Usando TCPView, noté que cuando hago una nueva conexión, su estado se ESTABLECE de inmediato, pero luego una o dos conexiones más con el Servidor SQL se intentan continuamente y se cierran con TIME_WAIT . En la computadora de mi compañero de trabajo, estas conexiones están ESTABLECIDAS y son sólidas. Así que estoy bastante seguro de que esta es la fuente de los tiempos de espera, pero ¿para qué sirven las conexiones y por qué fallan? (No tengo complementos en mi SSMS).

¿Algunas ideas?

Actualización: Pista Intellisense / Autocompletar (?):

Noté que una vez que finalmente me conecto, Intellisense / Autocomplete no funciona. ¿Esos requieren conexiones separadas de SSMS? Traté de deshabilitarlos, y no pareció resolver el largo retraso de la conexión.

— Jordan Rieger
fuente

¿Has intentado ejecutar SSMS con el modificador / log?

— Señor Magoo

@MisterMagoo intentando eso ahora. En realidad, no registra nada sobre sus intentos de conexión (el archivo no crece al hacer una nueva conexión). Se trata principalmente de cargar ciertos paquetes en la interfaz de usuario, por ejemplo, "Ensamblado de componentes cargado con éxito desde la memoria caché". No pude encontrar ningún error o excepción.

— Jordan Rieger

Ok, no estaba seguro de si lo haría, pero pensé que valía la pena intentarlo rápidamente. Si está realmente interesado en lo que está sucediendo, es posible que necesite dividir el Monitor de proceso Sysinternals y ver si puede identificar lo que está sucediendo. technet.microsoft.com/en-us/library/bb896645.aspx

— Mister Magoo

He estado estudiando los volcados de ProcMon durante aproximadamente una hora, pero hay tantos eventos (incluso filtrados a Ssms.exe) que no puedo aprovecharlo.

— Jordan Rieger

@MisterMagoo Todo lo que puedo ver es que los intentos de conexión que vi con TcpView realmente están tomando mucho tiempo (más de 5 segundos cada uno). Estoy basando eso en ver el evento "TCP Connect" en un puerto local en particular, y luego la próxima vez que vea algo enviado o recibido en ese puerto local siempre es después de al menos 5 segundos.

— Jordan Rieger

19

Intente ejecutar un seguimiento con SQL Profiler mientras usted y su compañero de trabajo se conectan al servidor.
Seleccione RPC, SQL Statement & PreConnect - Iniciando / Completado.
Seleccione la opción Guardar resultados en la tabla, luego compare las 2 tablas para encontrar el cuello de botella.

O, dado que se está conectando por IP, podría estar haciendo una búsqueda inversa de DNS. Si es así, agregue una entrada en su archivo de hosts.

— d -_- b
fuente

2

Agregué una entrada local de etc / hosts para la dirección IP de mi servidor, luego intenté SSMS nuevamente. ¡Bingo! Súper rápido. ¡Gracias! (Dejé SSMS conectando a través de la dirección IP como antes, no el nombre de host). Me pregunto por qué necesito esta solución, pero mis compañeros de trabajo no. Parece estar relacionado con DNS. En cualquier caso, esta es una solución bastante buena para mí, por lo que le otorgaré la recompensa una vez que actualice su respuesta.

— Jordan Rieger

Creo que fue la búsqueda inversa porque cuando eliminé la entrada de hosts, el ping - a ###. ###. ###. ### era muy lento antes del primer ping (se detuvo 5 segundos para la búsqueda inversa). Cuando se volvió a agregar la entrada de hosts, ping -a fue rápido. Sin embargo, no hubo diferencia en el tracert o nslookup. Creo que algo debe ser diferente en mi PC que me está haciendo hacer la búsqueda inversa cuando mis compañeros de trabajo no lo están (o es mucho más rápido en ellos). Por cierto, mi Intellisense funciona nuevamente ahora que la velocidad de conexión es rápida.

— Jordan Rieger

¡Incluso una entrada DNS falsa para la IP en el archivo de hosts hace que esto funcione mucho más rápido! ¡Gracias!

— felickz

Estaba obteniendo tiempos de espera tratando de conectar SSMS a través de una VPN hasta que leí su respuesta, sí, tiene sentido porque me estaba conectando al servidor a través de IP y la resolución de nombre no funcionaba. Agregar una entrada en el archivo host finalmente lo hizo funcionar después de muchas horas tratando de hacer que esto funcionara. ¡Gracias! Como nota al pie de página, quiero decir que estoy usando la autenticación de Windows de diferentes dominios con runas / netonly y funciona bien con esta solución.

— RobbZ

5

Lo que debe verificar primero es la configuración de DNS de su servidor o cliente

No es raro que su servidor SQL tenga el problema de conectarse a Active Directory. Si intenta con una cuenta local de Windows, estoy seguro de que no tendrá el problema. No es inusual que el servidor esté configurado con DNS público de Internet y cuando SQL Server se conecta a DC para verificar las credenciales y verificarlo, intentará ponerse en contacto con el DNS público en lugar del servidor DNS del AD. Dado que esta información no se almacena en el DNS público, no se podrá verificar y esto causará la demora hasta que logre contactar al servidor DNS o DC adecuado a través del NTLM

Como no está experimentando el problema con otros servidores SQL, es casi seguro que el problema no está relacionado con las configuraciones de AD o DC

Disparar el IPConfig.exe / todos los comandos del cmd para comprobar los servidores DNS configurados. Solo debe tener configurados los servidores DNS de AD. Elimine todos los servidores DNS públicos y deje solo los servidores DNS de AD.

— NikolaD
fuente

¿Está sugiriendo que SQL Server se está contactando con un DNS público para buscar la dirección IP del controlador de dominio, y eso está causando la demora cuando intenta validar mi autenticación de Windows? Si ese es el caso, ¿por qué funcionaría bien desde la PC de mi compañero de trabajo en la misma red local, a través de la misma VPN? Verifiqué la configuración de DNS en mi computadora, y había un tercer servidor DNS adicional que mi departamento de IP me había pedido que agregara, que no estaba presente en la PC de mi compañero de trabajo. Pero cuando eliminé ese servidor, hice un ipconfig / flushdns e intenté nuevamente, todavía era lento.

— Jordan Rieger

Usar la dirección IP o el FQDN del servidor (no solo el nombre de host) marcó una gran diferencia para mí. Definitivamente fue un problema de DNS lento en mi caso.

— userSteve

0

Extendí el C:\Windows\System32\drivers\etc\hostsarchivo agregando una línea como esta:

201.202.203.204     mysqlserver

201.202.203.204 es la dirección IP de su servidor SQL.

mysqlserver - cualquier nombre que le guste (no tiene que usarlo en ningún lado).

Esto hizo que mi servidor fuera más rápido.

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

— Dennis Gorelik
fuente

0

Desactive el Firewall de Windows en su servidor SQL para el perfil de red de dominio.

Iniciar Powershell
Ejecutar Get-NetFirewallProfile -Profile Domainpara verificar su estado actual
Si está habilitado, ejecute: Set-NetFirewallProfile -Profile Domain -Enabled Falsepara apagarlo.

Si fuera así, puede volver a encenderlo más tarde y ajustar su configuración. O, si se encuentra en un entorno seguro, puede dejarlo.

Lo extraño es que incluso si Firewall de Windows bloquea la comunicación, aún podrá conectarse, pero tanto el apretón de manos inicial como las solicitudes posteriores serán increíblemente lentas. Mi teoría (basada en ninguna evidencia real) es que en estos casos la comunicación recae en Canalizaciones con nombre, que es mucho más lenta entre las PC remotas.

— Laszlo Mako
fuente