Blog gratis
Reportar
Editar
¡Crea tu blog!
Compartir
¡Sorpréndeme!
img
img

 

 

SQL Server
Blog. (Apuntes y Recopilaciones) por Norman M. Pardell

img
img
22 de Febrero, 2011 · generalnetworkerror

Como solucionar problemas en SQL Server de: "General Network error", "Communication link failure", or "A transport-level error"

 Voy a comentar los pasos a seguir, para abordar los problemas relacionados con: "General Network error", "Communication link failure", or "A transport-level error", “Time-out”. Hablaremos del TCP Chimney, WinsockListenBacklog, SynAttackProtect, configuración de antivirus, Network Monitor (NetMon), etc.

 

Paso 1:

 

Para empezar debemos revisar la Versiónn de los drivers de las tarjetas de red, y verificar si hay actualizaciones aconsejables.  Deberemos revisar de nuevo la configuración de TCP Chimney ya que en algunos casos la instalación de un nuevo driver modifica los parámetros. Puedes utilizar el siguiente enlace web para realizar esta configuración:

 

"General Network error," "Communication link failure," or "A transport-level error"

 

http://support.microsoft.com/kb/942861  este link nos dice para un windows 2003 que hagamos:

Para evitar este problema, deshabilite la característica de descarga TCP Chimney. Para ello, siga estos pasos:

1.       Haga clic en Inicio , haga clic en Ejecutar , escriba cmd y, a continuación, presione ENTRAR.

2.       En el símbolo del sistema, escriba el comando siguiente y presione ENTRAR:

netsh int ip establece chimney DISABLED

Nota No es necesario reiniciar el servidor después de ejecutar este comando.

Si se disminuye el rendimiento de Windows Server 2003 después de deshabilitar la característica de descarga TCP Chimney, siga estos pasos adicionales:

1.       Haga clic en Inicio , haga clic en Ejecutar , escriba Regedit y, a continuación, haga clic en Aceptar .

2.       Busque la siguiente subclave del Registro:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

3.       Haga doble clic en la entrada de registro EnableTCPChimney .

4.       En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .

5.       Haga doble clic en la entrada de registro EnableRSS .

6.       En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .

7.       Haga doble clic en la entrada de registro EnableTCPA .

8.       En el cuadro de diálogo Editar valor DWORD , escriba 0 en el cuadro de datos de valor y, a continuación, haga clic en Aceptar .

9.       Reinicie el servidor.

Paso 2:

 

 Por otro lado, comprueba que el servicio de Antivirus se encuentra configurado excluyendo los directorios de datos de SQL Server y Reporting Services.

 

 

 

Paso 3:

 

 Vamos a pasar a la tercera parte del plan y capturar trazas de red en el servidor de SQL Server. Para ello:

 

1.       Nos vamos al nodo activo del clúster e instalamos la última versión de Network Monitor (NetMon) que podrás encontrar en el siguiente enlace web:

 

Microsoft Network Monitor 3.3,

http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

 

2.       Si disponemos de algún servidor o PC cliente en el que podamos reproducir el problema, o en el que frecuentemente se produzca el problema, instalaremos también ahí la última versión de NetMon

 

3.       Abrimos Netmon y lo configuramos con un buffer de 150 MB en a través de la opción Tools > Options > Capture como se muestra:

 

 

4.       Hacemos clic en el botón "Start" para comenzar la traza. Si tenemos Netmon instalado también en una máquina cliente configurarnos los mismos parámetros de buffer de traza y lanzamos también el proceso de captura

 

5.       Esperamos a que se reproduzca el error y paramos la capturar haciendo clic en el botón "Stop" en el servidor de SQL Server y, si disponemos de un cliente, también en el cliente

 

6.       Guardamos la traza de Network Monitor con la opción "Save as", usaremos el nombre del servidor de SQL Server como nombre del fichero y nos aseguraremos de que la opción "All captured frames" está seleccionada

 

7.       Guardaremos en un bloc de notas la salida del comando ipconfig.exe /all en el nodo del clúster en el que hemos ejecutado NetMon

 

En este punto, es interesante estudiar lo resultados y ver que nos dice la información:

 

-          Traza de NetMon capturada en el servidor de SQL Server

-          Traza de NetMon capturada en el cliente donde se produce el error, si existe

-          Fichero de texto con la salida del comando ipconfig.exe /all en el servidor de SQL Server

-          Fichero de texto con la salida del comando ipconfig.exe /All en el cliente, si existe

-          Fichero ERRORLOG de SQL Server (el último, que no tiene ninguna extensión)

-          Visor de Eventos de Aplicaciones y de Sistema en modo TXT del Servidor de SQL Server. Puedes exportar esta información desde el propio Visor de Eventos de Windows

-          Visor de Eventos de Aplicaciones y de Sistema en modo TXT del cliente donde se produce el error, si existe

 

 

 Cabe la posibilidad de que en estas trazas no encontremos ningún error, con lo que descartaríamos que el error se encuentra en el servidor de SQL Server y tendríamos que centrarnos en algún elemento de red o alguna propiedad común a todos los clientes.

 

 

 

Paso 4:

 

 Es posible que el problema no esté relacionado con SQL Server sino con el propio servidor Windows.

 

La primera posibilidad es que nos encontremos con un problema referido al valor de configuración del parámetro de red WinsockListenBacklog que es un parámetro de configuración específico para SQL Server 2000 que determina el periodo de espera de cada puerto TCP/IP, esto se encuentra mejor explicado en el siguiente enlace web:

 

Description of TCP/IP settings that you may have to adjust when SQL Server connection pooling is disabled,

http://support.microsoft.com/default.aspx?scid=kb;EN-US;328476

 

"The backlog setting works as follows: Suppose an arbitrary service is listening for incoming TCP/IP socket requests. If you set the backlog setting to 5 and many socket connection requests are continually streaming in, the service may not be able to respond to the incoming requests as fast as they come in […] After the queue fills up, the TCP/IP socket layer immediately rejects any additional socket requests that come in by sending an ACK+RESET packet back to the client. Increasing the backlog queue size increases the number of pending socket connection requests that the TCP/IP socket layer queues before requests are rejected."

 

 Cuando la carga de red en el servidor es muy alta el valor por defecto de WinsockListenBacklog puede ser insuficiente para dar soporte a la misma.

 

 Otra posibilidad es la relacionada con el valor SynAttackProtect que es una funcionalidad existente en Windows 2000 y que fue implementada por defecto en Windows Server 2003 para prevenir ataques de denegación de servicio (DoS) pero que puede originar problemas cuando el servidor se encuentra con mucha carga y gestionando un alto número de conexiones cliente. Puedes encontrar más información sobre este parámetro en el siguiente enlace web:

 

How to harden the TCP/IP stack against denial of service attacks in Windows 2000,

http://support.microsoft.com/kb/315669

 

 Una tercera posibilidad tendría que ver con el cliente y no con el servidor. Cabe la posibilidad de que el cliente haya sido configurado para no usar 'connection pooling', lo que puede tener un efecto nocivo en SQL Server ya que de este modo no se reúsan conexiones existentes sino que cada conexión al servidor abre su conexión de forma independiente. Puedes encontrar más información sobre esto en el siguiente enlace web:

 

Pooling,

http://en.wikipedia.org/wiki/Database_connection#Pooling

 

El no usar 'connection pooling' en la aplicación cliente origina una carga extra en el servidor de SQL Server que puede provocar errores del tipo "General Network Error".

 

El plan de acción sería:

 

1.       Necesitamos identificar si las aplicaciones que provocan estos errores son siempre las mismas.

 

2.       Debemos confirmar que la aplicación está haciendo uso de 'connection pooling'. En este punto necesitaremos implicar a vuestro grupo de desarrollo. Este artículo os puede servir de referencia para esta comprobación:

 

Connection Pooling (ADO.NET),

http://msdn.microsoft.com/en-us/library/bb399543.aspx

 

Este paso es muy importante ya que el problema puede no tener su causa raíz en el servidor, sino en la aplicación. El problema de "General Network Error" aparece asociado en muchas ocasiones a aplicaciones cliente de SQL Server que no hacen uso de 'connection pooling'.

 

3.       Una vez revisados los pasos anteriores, vamos a configurar el valor de WinsockListenBacklog en el servidor de SQL Server utilizando el registro. Este valor debe de ser configurado en ambos nodos, si tu entrono esta en un cluster, y  requiere un reinicio del servidor Windows. Para ello realizarnos el siguiente paso:

 

Nos vamos a la siguiente clave del registro:

 

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerInstance NameMSSQLServerSuperSocketNetLib

 

y añadimos la siguiente entrada:

 

Value Name: WinsockListenBacklog

Data Type: REG_DWORD

Data: 10

 

El valor por defecto de WinsockListenBacklog cuando esta clave no existe es '5'. Vamos a ir aumentado su valor de 5 en 5 para comprobar si el número de errores en la aplicación cliente se sigue produciendo con la misma intensidad

 

4.       Si las acciones realizadas antes no dan ningún resultado seguiremos las indicaciones en la sección "Resolution" del siguiente KB:

 

A BizTalk Server Host instance fails, and a "General Network" error is written to the Application log when the BizTalk Server-based server processes a high volume of documents,

http://support.microsoft.com/kb/899599/en-us

 

 Es necesario que el cambio en el registro se realice en abrimos nodos y que los servidores Windows sean reiniciados para que el cambio tenga efecto.

 

 Si con esto no se aprecia ningún cambio pasaremos a desactivar lo servicios no esenciales del servidor para comprobar si alguno de ellos no está causando el problema. Por ejemplo, los servicios de Antivirus instalan un Filter Driver de red que puede dar lugar a problemas.

 

 

Apunte realilzado por Norman M. Pardell

 

Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.

publicado por normanmpardell a las 08:08 · Sin comentarios  ·  Recomendar
Comentarios (0) ·  Enviar comentario
Esta entrada no admite comentarios.
img
.Sobre mí
FOTO

Norman M. Pardell

MCITP: Database Administrator & Database Developer, SQL Server 2008. MCC Award Certificate. Consultor Senior de bases de datos en Capgemini España, S.L. Asesoramiento en implementación, desarrollo y gestión de bases de datos en grandes compañías. Actualmente, asignado a proyecto en compañía líder en el sector energético global. Más de 10 años trabajando con SQL Server (y otros gestores de BBDD)

» Ver perfil

img
.Secciones
» Inicio
img
.Enlaces
» Microsoft MSDN Foros
» Windows Server 2012
img
.Más leídos
» Asignar la cantidad correcta de Memoria para SQL Server
» Base de Datos Sospechosa (Suspect)
» Como modificar la Intercalación (Collation) en SQL Server
» Detectar bloqueos. SQL Server V.2005 y superiores
» Funciones SQL Server. Funciones escalares y funciones con valores de tabla.
» Integridad y corrupción en las bases de datos: DBCC CHECKDB
» Log de transacciones ( .ldf ). SQL Server.
» Migrando SQL Server 2005, 2008, 2008 R2 a SQL Server 2012
» Tomo I. Memoria RAM. Optimización de sistemas de 32 y 64 bits. SQL Server 2008.
» Transacciones activas. SQL server 2008
img
.Nube de tags [?]
                                                           
img img
FULLServices Network | Crear blog | Privacidad