Compartir a través de

Solución de problemas intermitentes o periódicos con la conexión a SQL Server

  • Artículo

Nota:

Antes de empezar a solucionar problemas, se recomienda comprobar los requisitos previos y seguir la lista de comprobación. Para obtener más información, consulte Artículos de autoayuda.

La estabilidad de la red es esencial para el funcionamiento sin problemas de varios servicios y aplicaciones. Sin embargo, hay ocasiones en las que los problemas de red interrumpen esta estabilidad. Este artículo le ayuda a comprender y solucionar problemas de red intermitentes o periódicos y sus mensajes de error típicos. Estos problemas pueden ser frustrantes, pero puede resolverlos de forma más eficaz con una mejor comprensión y técnicas de solución de problemas adecuadas.

Los mensajes de error más comunes

Los problemas intermitentes se producen de forma irregular, mientras que los problemas periódicos tienden a producirse a intervalos predecibles. Identificar el tipo de problema es el primer paso para solucionar problemas. Cuando se producen problemas de red intermitentes o periódicos, es posible que encuentre los siguientes mensajes de error:

  • Error de vínculo de comunicación: este error indica una interrupción en la comunicación entre los componentes de red.
  • Tiempo de espera de conexión Expirado: la conexión al servidor agota el tiempo de espera, lo que sugiere un retraso o una falta de disponibilidad del servidor.
  • Error general de red: un mensaje de error de red general suele indicar un problema no especificado con la red.
  • Error de nivel de transporte: este error se produce en la capa de transporte, lo que sugiere problemas con la transmisión de datos.
  • El nombre de red especificado ya no está disponible: este mensaje implica que no se puede acceder al recurso de red especificado.
  • Tiempo de espera del semáforo: este error apunta a una condición de tiempo de espera relacionada con el uso de semáforos en la red.
  • La operación de espera agota el tiempo de espera: una operación de espera ha superado su tiempo permitido, normalmente debido a retrasos en la red.
  • Error irrecuperable al leer el flujo de entrada de la red: este mensaje sugiere un error crítico al leer datos de la red.
  • Error de protocolo en el flujo de TDS: el flujo de datos tabular (TDS) es un protocolo usado por SQL Server. Este error indica un problema con el protocolo.
  • No se encontró el servidor o no se pudo acceder a él: este mensaje de error sugiere que el servidor al que intenta acceder no está disponible o no se encuentra.
  • SQL Server no existe o el acceso denegado: este error puede indicar la ausencia de SQL Server o un error de autenticación al intentar acceder a SQL Server.

Causa

Los problemas más comunes están relacionados con las caídas de paquetes debido a antivirus, optimización de red, controladores de red más antiguos, enrutadores o conmutadores incorrectos y conexiones no agrupadas en la aplicación.

Algunas causas, como antivirus, pueden ser difíciles de probar, pero siguen siendo comunes. Es posible que tenga que desinstalar y reiniciar el equipo para demostrarlo, sin evidencia clara. La creación de una excepción para SQL Server también puede funcionar. Pero desactivar el antivirus normalmente no funciona porque los controladores de filtro de red se siguen cargando incluso si no se supervisan.

Proceso de solución de problemas

Nota:

Este proceso está diseñado para las conexiones de cliente y servidor de SQL Server. No se tratan otras comunicaciones, como la creación de reflejo de SQL Server, Always-On y el tráfico de sincronización de Service Broker a través del puerto 5022.

En general, la solución de problemas debe ser controlada por datos, lo que puede dar forma a las pruebas empíricas en un contexto más centrado. Si el problema es muy intermitente y los seguimientos de red serán difíciles de capturar, los métodos empíricos se pueden aplicar primero.

Recopilación de un informe mediante SQLCHECK en cada máquina

Ejecute SQLCHECK en cada máquina para generar un informe. Resulta útil determinar por qué puede producirse un error en una conexión.

Recopilación de seguimientos de red en el cliente y el servidor

  • En las máquinas Windows, recopile seguimientos de red mediante SQLTRACE.

    Siga estos pasos para preparar y realizar el seguimiento. Los pasos 2 y 3 solo deben realizarse una vez.

    1. Descargue la versión más reciente de SQLTRACE y descomprima en una carpeta, como C:\MSDATA.

    2. Abra el archivo SQLTrace.ini y desactive la siguiente configuración:

      BIDTrace=no, AuthTrace=no y EventViewer=no

    3. Guarde el archivo.

    4. Abra PowerShell como administrador y cambie el directorio a la carpeta que contiene SQLTrace.ps1.

      CD C:\MSDATA

    5. Inicie la colección de seguimiento.

      .\SQLTrace.ps1 -start

    6. Reproduzca el problema o espere a que se produzca el error.

    7. Detenga el seguimiento.

      .\SQLTrace.ps1 -stop

    Se genera una carpeta de salida en el directorio actual y se puede usar para su posterior análisis.

  • En equipos que no son Windows, use TCPDUMP o WireShark para recopilar una captura de paquetes.

Ejecución del Analizador de red de SQL Server

La interfaz de usuario de SQL Network Analyzer (SQLNAUI) proporciona una interfaz gráfica para seleccionar archivos de seguimiento para analizar y establecer opciones. Descárguelo de SQL Network Analyzer (SQLNA).

Procesa los seguimientos de cliente y servidor por separado. Si ha encadenado seguimientos, procesándolos al mismo tiempo. El tamaño total de estos archivos no debe superar el 80 % de la memoria del equipo. Asegúrese de que tiene suficiente memoria para procesar todos los archivos de seguimiento relacionados.

Esta herramienta generará un informe de problemas sospechosos y un archivo CSV que puede explorar en Excel para una investigación alternativa.

Intente buscar conversaciones coincidentes en el seguimiento del cliente y el seguimiento del servidor. Por lo general, las direcciones IP y los números de puerto coinciden. Sin embargo, si las conexiones pasan por cualquier tipo de traducción de direcciones de red o asignación de puertos, puede ser más difícil, y es posible que tenga que alinearse con los identificadores de paquete IPV4 y comparar las cargas.

Patrones que se van a buscar en el análisis de seguimiento de red

Examine cómo terminan las conversaciones en NETMON o WireShark. Compruebe si el cliente y el servidor están de acuerdo con lo mismo o si cuentan otra historia.

Conexión cerrada durante el protocolo de enlace SSL

En el paquete ServerHello, si el conjunto de cifrado usado es un conjunto diffie-Hellman y el tráfico está entre Windows 2012 o versiones anteriores y Windows 2016 o posterior, este algoritmo cambia a partir de las revisiones de seguridad de Windows 2016. Debe deshabilitar este grupo de conjuntos de cifrado. Para obtener más información, consulte Las aplicaciones experimentan errores de conexión TLS de cierre forzoso al conectarse a servidores SQL en Windows.

Si la conexión se cierra después de ClientHello, compruebe si hay un error de coincidencia de TLS 1.0 o TLS 1.2 entre el cliente y el servidor. Si son iguales, compruebe los conjuntos de cifrado habilitados y los hash habilitados en ambas máquinas.

Para obtener más información, consulte Captura avanzada de datos de capa de sockets seguros.

Paquetes eliminados

Vea el final de las conversaciones coincidentes. Si uno tiene muchos paquetes retransmitidos (o 10 paquetes Keep-Alive, separados por 1 segundo) seguidos de ACK+RESET y el otro no, o uno notifica una respuesta oportuna y la otra ve retrasada y cierra o restablece la conversación, esto indica un problema con el dispositivo de red y los paquetes se quitan o retrasan.

También puede ver el informe de cliente que indica que el servidor restablece la conversación y el informe de servidor que indica que el cliente restablece la conversación. Esto se debe a un conmutador incorrecto o enrutador que cierra la conexión desde el centro, y a veces se pueden configurar para hacerlo si detectan que la conexión ha estado inactiva durante un tiempo, a menudo ignorando los paquetes Keep-Alive.

Para obtener más información sobre las conexiones eliminadas, consulte:

Tanto el seguimiento del servidor como el seguimiento del cliente están de acuerdo en que el problema está en el cliente.

Si ambos seguimientos muestran un retraso o ninguna respuesta en el cliente, o si el cliente emite un ACK+RESET después de reconocer una respuesta del servidor o, de lo contrario, cierra la conexión al principio durante la secuencia de inicio de sesión, debe tomar un seguimiento bid y un seguimiento NETSH en el cliente para buscar dentro de la pila TCP/IP y lo que el controlador está pensando. Esto es común si el antivirus u otros controladores de filtro de red retrasan la recepción del paquete o el envío de la respuesta. Los tiempos de espera de conexión también podrían deberse a una respuesta DNS lenta o a una API de seguridad lenta a la que se llamó antes de enviar el paquete SYN inicial a través de la conexión.

Compruebe el informe de puertos efímeros de SQL Network Analyzer y asegúrese de que el cliente no se está quedando sin puertos salientes.

Si el cliente tiene un retraso largo antes de enviar el paquete SYN, puede ver un patrón que muestra solo el protocolo de enlace de apertura TCP 3, seguido inmediatamente o, a veces, después de enviar el paquete PreLogin, por un ACK+FIN que se origina en el cliente.

Recopilación de un seguimiento de red y un seguimiento de BID para aislar problemas de cliente en Windows

  1. Abra el archivo SQLTrace.ini y vuelva a activar la siguiente configuración:

    BIDTrace=Yes, AuthTrace=Yes y EventViewer=Yes

  2. Configure en BIDProviderList SQLTrace.ini para que coincida con el controlador que usa la aplicación.

    .NET System.Data.SqlClient se habilita de forma predeterminada. Si no es el controlador que está usando, deshabilite BIDProviderList agregando # al principio de la línea y quítelo desde el principio de la lista ODBC o OLEDB. Esto capturará todos los controladores admitidos de ese tipo. Para obtener más información, consulte Configuración de INI.

  3. Guarde el archivo.

  4. Abra PowerShell como administrador y cambie el directorio a la carpeta que contiene SQLTrace.ps1.

    CD C:\MSDATA

  5. Inicialice el Registro de seguimiento de BID, si recopila seguimientos de BID.

    Nota:

    El seguimiento de BID está habilitado de forma predeterminada.

    .\SQLTrace.ps1 -setup

  6. Reinicie el servicio o la aplicación que está trazando.

    Para algunas aplicaciones, como paquetes de SQL Server Integration Services (SSIS), se inicia una nueva instancia de DTEXEC o ISServerExec cuando se ejecuta el paquete, por lo que no tiene sentido reiniciar.

  7. Inicie la colección de seguimiento.

    .\SQLTrace.ps1 -start

  8. Reproduzca el problema o espere a que se produzca el error.

  9. Detenga el seguimiento.

    .\SQLTrace.ps1 -stop

Se genera una carpeta de salida en el directorio actual y se puede usar para su posterior análisis.

Para realizar un seguimiento de otros controladores de Microsoft SQL Server, consulte los siguientes artículos. Realice el uso de un seguimiento de red.

Para realizar un seguimiento de los controladores de terceros, consulte la documentación del proveedor.

Tanto el seguimiento del servidor como el seguimiento del cliente están de acuerdo en que el problema está en el servidor.

Si ambos seguimientos muestran un retraso o ninguna respuesta en el servidor, o si el servidor cierra la conexión en un punto inesperado de la secuencia de inicio de sesión, o si el servidor cierra muchas conexiones al mismo tiempo, esto indica que hay algunos problemas en el servidor.

Las causas más probables son un rendimiento deficiente del servidor, maxDOP elevado y consultas paralelas grandes y bloqueos. Estos pueden provocar un colapso de subprocesos, lo que impide que se controle rápidamente una solicitud de inicio de sesión, especialmente si muchos tiempos de espera de conexión terminan al mismo tiempo y la columna LoginAck muestra "Late". El archivo ERRORLOG de SQL Server puede mostrar que las operaciones de E/S tardan más de 15 segundos, que es otro indicador de problemas de rendimiento. En el seguimiento de red, es posible que también vea muchas conversaciones en el informe de restablecimiento con seis fotogramas o menos, lo que indica que es posible que el protocolo de enlace TCP 3 vías no se haya completado. Para obtener más información, consulte Recopilación del búfer de anillo de conectividad.

Ejecute la RingBufferConnectivity consulta y pegue los resultados en Excel. Dado que se trata de una lista histórica, se puede ejecutar después de que se produzca el problema. Pero para un servidor ocupado, podría terminar rápidamente. En el caso de un servidor lento, es posible que tenga datos durante un par de días.

Si la aplicación usa varios conjuntos de resultados activos (MARS), finaliza con un RESET como parte de la secuencia de cierre. Esto es benigno si los paquetes SMP:FIN y ACK+FIN ya se han enviado desde el cliente. El paquete SMP:FIN del servidor llegará después de ACK+FIN del cliente y Windows emitirá un ACK+RESET y, a continuación, un RESET para cualquier otra respuesta del servidor como parte de la secuencia de cierre de la conexión.

Agrupación de conexiones

Para más información, consulte Agrupación de conexiones.

Si se usa la agrupación de conexiones, las conversaciones del seguimiento de red suelen ser bastante largas. Puede usar el archivo CSV generado por el Analizador de red de SQL Server para ordenar y filtrar por protocolos y marcos. Probablemente no verá los fotogramas iniciales o finales si la captura de red es inferior a media hora. Si muchas conversaciones tienen menos de 30 fotogramas del paquete SYN al paquete ACK+FIN, esto indica conexiones no agrupadas. Si se mezclan con algunas conversaciones más largas, sospecha que las conexiones no agrupadas en segundo plano se deben ejecutar comandos en una conexión que no sea de MARS mientras lee un conjunto de resultados.

El informe de puertos efímeros mostrará el número de nuevas conexiones durante la vigencia del seguimiento. Puede juzgar la tasa de conexión por el número de conexiones por segundo.

RESET frente a ACK+RESET

ACK+RESET se suele ver cuando la aplicación o Windows anula una conexión. Esto suele deberse a un error TCP de bajo nivel. El paquete informa al otro equipo para dejar de enviar inmediatamente. Sin embargo, si el servidor está en medio de la transmisión, uno o dos paquetes pueden llegar al cliente después de enviar el ACK+RESET. Dado que el puerto está cerrado, el sistema operativo envía un paquete RESET. Esto también sucede si los paquetes llegan después del paquete ACK+FIN que no forma parte del protocolo de enlace de cierre normal.

Algunos controladores de terceros también envían un paquete ACK+RESET para cerrar la conexión en lugar de un ACK+FIN. Algunas conexiones de sondeo también pueden hacerlo. Si el paquete ACK+RESET no va precedido de paquetes Keep-Alive, paquetes retransmitidos o paquetes de Windows cero, y procede del cliente cuando se espera un cierre normal de ACK+FIN, podría ser benigno.

Uso de NETSTAT para analizar problemas de red

NETSTAT se recopila automáticamente al ejecutar SQLTrace.ps1 para la recopilación de datos.

O bien, puede ejecutarse NETSTAT -abon > c:\ports.txt en el símbolo del sistema como administrador para recopilar información relacionada con problemas de red.

El archivo ports.txt contendrá una lista de todos los puertos entrantes y salientes, los números de puerto, los identificadores de proceso y los nombres de las aplicaciones que poseen los puertos. Puede usarlo para ver los peores delincuentes y si se ha alcanzado el límite del puerto. Active la barra de estado en el Bloc de notas y desactive el ajuste de Word. La barra de estado proporcionará un recuento de líneas. Puede dividir entre dos para obtener un uso aproximado del puerto.

Ajustar TcpTimedWaitDelay y MaxUserPort

Si una aplicación agota los puertos salientes en el equipo host y no puede realizar cambios inmediatos en la aplicación, puede disminuir TcpTimedWaitDelay de 240 a tan solo 30 segundos, lo que permite reciclar los puertos salientes más rápido.

Para windows 2003 y versiones posteriores, también puede aumentar .MaxUserPort Para Windows Vista y versiones posteriores, establézcalo mediante el NETSH comando . Este curso de acción no elimina las ineficacias de conexiones no agrupadas o conexiones en segundo plano no agrupadas, y se recomienda encarecidamente al desarrollador que cambie sus aplicaciones para usar la agrupación de conexiones.

Para Windows 2008 y versiones posteriores, el intervalo se ha aumentado de aproximadamente 4000 puertos efímeros a 16 000 puertos, de forma predeterminada.

Para obtener más información, vea Ajustar la configuración de MaxUserPort y TcpTimedWaitDelay.

Casi todos los paquetes enviados desde el cliente al servidor o al servidor al cliente se responden con un paquete ACK que va en la dirección opuesta. La capa de TCP.SYS genera la ACK. Si se recibe un paquete en el cliente y el seguimiento del cliente muestra que viene pero no se devuelve ACK al servidor, se trata de una buena indicación de que el antivirus o algún otro controlador de filtro de red ha perdido o quitado el paquete o se mantiene en él durante mucho tiempo (pasado el final de la recopilación de seguimientos de red). Del mismo modo, si el seguimiento del servidor muestra un paquete procedente de un cliente, pero no se envía ACK de vuelta al cliente, esto indica que el antivirus del servidor en el servidor puede tener un problema.

Sin embargo, al cargar o descargar una gran cantidad de datos, los paquetes ACK pueden aparecer después de una serie de paquetes de datos para ayudar con el control de flujo.

Los controladores antivirus y de filtro son muy difíciles de probar como culpable. Casi siempre se requiere una prueba empírica. Cree una excepción para la aplicación o SQL Server en el antivirus y, a continuación, supervisela durante 48 horas para ver si el comportamiento mejora. Si no se puede establecer una excepción, desinstale el programa antivirus y reinicie. Deshabilitarlo normalmente no ayuda, ya que el controlador de filtro antivirus seguirá cargando. Haga esto solo como último recurso si la protección perimetral está en vigor.

Consulte a los administradores de seguridad de red. Si la situación mejora, es posible que tenga que trabajar con el proveedor del antivirus para mitigar el problema. Si no es así, otros controladores de filtro de red podrían ser el culpable.

Habilitación de la auditoría del Firewall de Windows

Para determinar si el firewall ha quitado los paquetes, habilite la auditoría de firewall en Windows.

Para SQL Server, este problema podría estar relacionado con el cliente o la máquina del servidor. El seguimiento de red mostrará que la máquina recibió un paquete, pero no respondió. Después, el paquete se puede retransmitir, volver a obtener ninguna respuesta y, finalmente, se restablece la conexión.

Acciones empíricas y otras

Puertos efímeros

La ejecución de puertos efímeros es una causa relativamente común de tiempos de espera de conexión intermitentes, especialmente si no ve el paquete SYN en la conexión.

En el caso de las solicitudes entrantes en el servidor, los puertos, como 80 o 1433, pueden tardar hasta 64 000 conexiones entrantes por dirección IP de cliente y, por lo general, son "ilimitados" para todos los fines prácticos.

Por otro lado, para las conexiones salientes, el número de puertos es limitado y compartido entre todas las conexiones de servidor. Para Windows Vista, Windows 2008 y versiones posteriores, el intervalo predeterminado es del puerto 49152 al 65535 (2^16 = 16 384 puertos).

Normalmente, los puertos se mantienen durante cuatro minutos (240 segundos) por el sistema operativo antes de que se reciclan y puedan reutilizarlos las aplicaciones. Esto es para evitar la suplantación de puerto por software malintencionado o redirección accidental de una nueva conexión al titular anterior de ese puerto. Debido a este retraso, en Windows 2003, una aplicación cliente solo puede realizar 17 conexiones por segundo a SQL Server y el intervalo de puertos salientes se agota en menos de cuatro minutos. Para Windows Vista, ese número aumenta a 68 conexiones por segundo.

En el caso de las aplicaciones como IIS, cada cliente HTTP puede tener un puerto saliente a SQL Server. En el caso de un servidor web ocupado, quedarse sin puertos salientes es una posibilidad real cuando la carga es alta. Una granja de servidores web puede mitigar esta situación.

Ajustar la memoria máxima del servidor (MB)

Para resolver problemas relacionados con la memoria de kernel baja, ajuste el número máximo de memoria del servidor (MB).

Deshabilitación de la descarga

Con fines de prueba, puede deshabilitar algunas descargas a través de un símbolo del sistema administrativo:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

No mantenga esta configuración deshabilitada durante mucho tiempo a menos que solucione un problema. Se deben habilitar de forma predeterminada en Windows 2008 y versiones posteriores.

Para otras descargas, debe ir a las propiedades del adaptador de red para verlas y deshabilitarlas.

Problemas de búfer de red de VMware

El host ESX que contiene la máquina virtual (VM) tiene un búfer de red pequeño que puede causar problemas de confiabilidad si hay una ráfaga en el tráfico. En el siguiente artículo de VMware se describe cómo aumentar el tamaño del búfer. No se requiere ningún reinicio. Esta operación debe realizarse en la máquina host ESX, no en la máquina virtual.

Pérdida de paquetes grandes en el sistema operativo invitado mediante VMXNET3 en ESXi

Además, intente mover las máquinas virtuales a un servidor host ESX diferente o mueva el cliente y el servidor al mismo servidor host ESX y compruebe si el problema desaparece. Si es así, se trata de un problema de red base.

Instantáneas de VMware

Compruebe si se producen instantáneas de VMware durante el error y deshabilitelas.

Escalado lateral de recepción (RSS) deshabilitado en el equipo host

Cuando RSS está deshabilitado, el host de SQL Server solo usa una sola CPU para procesar todas las solicitudes de red. Esto podría aumentar la CPU al 100 % y causar problemas, incluso si los demás niveles de CPU (y cpu general) son bajos.

Para obtener más información, vea Introduction to Receive Side Scaling and Receive Side Scaling Version 2 (RSSv2).

Más información

Problemas de autenticación intermitentes o periódicos en SQL Server

Recopilación de un seguimiento de red

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.