Estás trabajando sin conexión, espera a que vuelva la conexión a Internet

Descripción de la configuración de TCP/IP que puede que deba ajustar cuando se deshabilita la agrupación de conexiones de SQL Server

Extended support for SQL Server 2005 ends on April 12, 2016

If you are still running SQL Server 2005 after April 12, 2016, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 328476
Resumen
Cuando se utiliza el controlador ODBC de SQL Server, el proveedor OLE DB de SQL Server o el proveedor administrado System.Data.SqlClient, puede deshabilitar la agrupación de conexiones utilizando las interfaces de programación de aplicación (API). Al deshabilitar la agrupación de la carga en la biblioteca de red de SQL Server subyacente puede aumentarse si la aplicación que con frecuencia se abre y cierra las conexiones. Este artículo describe algunas opciones de configuración de TCP/IP puede que deba ajustar en estas condiciones.
Más información
Si se desactiva la agrupación puede causar que el controlador de red de SQL Server subyacente rápidamente, abrir y cerrar nuevas conexiones de socket en el equipo que ejecuta SQL Server. Tendrá que cambiar la configuración de socket TCP/IP predeterminada para el sistema operativo y el equipo que está ejecutando SQL Server para tratar con los niveles más altos de estrés.

Tenga en cuenta que este artículo sólo trata de configuración que afectan a la biblioteca de red de SQL Server cuando se utiliza el protocolo TCP/IP. Si se desactiva la agrupación también puede causar problemas de estrés con otros protocolos de SQL Server como canalizaciones con nombrados, pero este artículo no describen en este tema. Este artículo es sólo para usuarios avanzados. Si no entiende los temas de este artículo, Microsoft recomienda que consulte con un buen libro acerca de sockets TCP/IP.

Tenga en cuenta que Microsoft recomienda utilizar siempre la agrupación con los controladores de SQL Server. Mediante la agrupación en gran medida mejora el rendimiento global en tanto el cliente y SQL Server cuando se utilizan los controladores de SQL Server. Mediante la agrupación de considerablemente también reduce el tráfico de red en el equipo que ejecuta SQL Server. Por ejemplo, una prueba de ejemplo que utiliza 20.000 de SQL Server de conexión se abre y se cierra con la agrupación habilitado utiliza aproximadamente 160 paquetes de red TCP/IP, para un total de 23.520 bytes de actividad de la red. Deshabilitada la agrupación, la misma prueba de ejemplo generado 225,129 paquetes de red TCP/IP, para un total de 27,209,622 bytes de actividad de la red.

Tenga en cuenta que cuando vea estos problemas relacionados con el estrés de un socket de TCP/IP con las bibliotecas de red de SQL Server, puede recibir uno o varios de los siguientes mensajes de error cuando intenta conectarse a un equipo que ejecuta SQL Server:
SQL Server no existe o acceso denegado
Tiempo de espera agotado
Error de red general
Proveedor de TCP: Normalmente se permite sólo un uso de cada dirección de socket (dirección de protocolo de red/puerto).
Tenga en cuenta que también puede recibir estos mensajes de error específicos cuando se producen otros problemas con SQL Server; Por ejemplo, puede recibir estos mensajes de error si se apaga el equipo remoto que ejecuta SQL Server, si el equipo remoto que ejecuta SQL Server no está escuchando a los sockets TCP/IP, si se interrumpe la conectividad de red con el equipo que está ejecutando SQL Server porque se extrae el cable de red, o si tiene problemas con la resolución DNS. Básicamente todo lo que puede ocasionar que el cliente no se pueda abrir un socket TCP/IP en el equipo que ejecuta SQL Server puede causar también los mensajes de error. Sin embargo, con un problema de estrés socket, el problema se produce intermitentemente cuando la carga aumenta o disminuye. El equipo puede ejecutar durante horas sin errores, y a continuación, el error produce una o dos veces y el equipo, a continuación, ejecuta para varias horas sin errores. Además, si tiene este problema, generales de conectividad de SQL Server funciona en un instante, se produce un error de la siguiente y vuelve a funcionar la siguiente instantánea. En otras palabras, los problemas relacionados con el estrés socket ocurren esporádicamente, pero problemas de conectividad de red real con SQL Server no ocurren esporádicamente.

Dos de los problemas principales relacionados con el estrés suelen producen cuando deshabilita la agrupación mientras se utiliza el protocolo TCP/IP de SQL Server: puede quedarse sin puertos anónimos en el equipo cliente o puede exceder el valor de WinsockListenBacklog predeterminado en el equipo que ejecuta SQL Server.

Para obtener información adicional acerca de los puertos anónimos, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
319502 PRB: 'WSAEADDRESSINUSE' mensaje de Error cuando intenta conectar a través de un puerto anónimo después de aumentar el límite de conexiones IMAP

Ajuste la configuración MaxUserPort y TcpTimedWaitDelay

Tenga en cuenta que la configuración MaxUserPort y TcpTimedWaitDelay es aplicable sólo para un equipo cliente que es rápidamente de apertura y cierre de las conexiones a un equipo remoto que ejecuta SQL Server y que no utiliza la agrupación de conexiones. Por ejemplo, estas opciones son aplicables en un servidor de servicios de Internet Information Server (IIS) que da servicio a un gran número de solicitudes HTTP entrantes y que abre y cierra las conexiones a un equipo remoto que ejecuta SQL Server y que utiliza el protocolo TCP/IP con la agrupación de deshabilitado. Si está habilitada la agrupación, no es necesario ajustar la configuración de MaxUserPort y TcpTimedWaitDelay .

Cuando se utiliza el protocolo TCP/IP para abrir una conexión a un equipo que ejecuta SQL Server, la biblioteca de red de SQL Server subyacente abre un socket TCP/IP en el equipo que ejecuta SQL Server. Cuando se abre este socket, la biblioteca de red de SQL Server no permite la opción de socket TCP/IP SO_REUSEADDR . Para obtener más información acerca de la opción de socket SO_REUSEADDR , vea el tema "Setsockopt" en Microsoft Developer Network (MSDN).

Tenga en cuenta que la biblioteca de red de SQL Server en concreto no habilitar la opción de socket TCP/IP de SO_REUSEADDR por razones de seguridad. Cuando está habilitada la SO_REUSEADDR , un usuario malintencionado puede apropiarse de un puerto de cliente de SQL Server y utilice las credenciales que proporciona el cliente para tener acceso al equipo que está ejecutando SQL Server. De manera predeterminada, porque la biblioteca de red de SQL Server no permite la opción de socket SO_REUSEADDR , cada vez que abre y cierra un socket a través de la biblioteca de red de SQL Server en el cliente, el socket entra en un estado TIME_WAIT durante cuatro minutos. Si estás rápidamente de apertura y cierre de las conexiones de SQL Server sobre TCP/IP con la agrupación deshabilitado, rápidamente se abre y cierre de sockets TCP/IP. En otras palabras, cada conexión de SQL Server tiene un socket TCP/IP. Si se abre y cierren los 4000 sockets en menos de cuatro minutos rápidamente, alcanzará el valor máximo predeterminado para los puertos de cliente anónimo, y nuevos intentos de conexión de socket hasta el conjunto existente de sockets TIME_WAIT se agote.

En el cliente, tendrá que aumentar la configuración de MaxUserPort y TcpTimedWaitDelay que se describe en Q319502 una vez deshabilitada la agrupación. La configuración de estos valores se determina cuántos conexión de SQL Server se abre y se cierra se produce en el cliente. Puede examinar cuántos puertos de cliente están en un estado TIME_WAIT mediante la herramienta Netstat en el equipo cliente. Ejecutar la herramienta Netstat con el indicador -n como sigue y contar el número de sockets de cliente a la dirección IP de SQL Server que se encuentran en un estado TIME_WAIT. En este ejemplo, la dirección IP del equipo remoto que ejecuta SQL Server es 10.10.10.20, la dirección IP del equipo cliente es 10.10.10.10 y tres establecieron conexiones y dos conexiones están en un estado TIME_WAIT:
C:\>netstat -nActive Connections  Proto  Local Address         Foreign Address       State  TCP    10.10.10.10:2000      10.10.10.20:1433      ESTABLISHED  TCP    10.10.10.10:2001      10.10.10.20:1433      ESTABLISHED  TCP    10.10.10.10:2002      10.10.10.20:1433      ESTABLISHED  TCP    10.10.10.10:2003      10.10.10.20:1433      TIME_WAIT  TCP    10.10.10.10:2004      10.10.10.20:1433      TIME_WAIT				
Si ejecuta netstat - n y verá que cerca de 4000 conexiones a la dirección IP del equipo de destino que ejecuta SQL Server son en el estado TIME_WAIT, puede aumentar el valor de MaxUserPort predeterminado y reducir el valor de TcpTimedWaitDelay para que no se ejecute fuera de los puertos de cliente anónimo. Por ejemplo, puede establecer la configuración de MaxUserPort a 20000 y establezca el valor de TcpTimedWaitDelay en 30. Un valor de TcpTimedWaitDelay inferior significa que los sockets de esperaren en el estado TIME_WAIT menos tiempo. Un valor de MaxUserPort superior significa que puede tener más de sockets en el estado TIME_WAIT.

Tenga en cuenta que si ajusta la configuración de MaxUserPort o TcpTimedWaitDelay , debe reiniciar Microsoft Windows para la nueva configuración surta efecto. La configuración de MaxUserPort y TcpTimedWaitDelay es para cualquier equipo cliente que se está conectando a un equipo que está ejecutando SQL Server a través de sockets TCP/IP. Esta configuración no tiene ningún efecto si se establecen en el equipo que ejecuta SQL Server a menos que se realicen conexiones de socket TCP/IP locales en el equipo local que ejecuta SQL Server.

Nota: Debido a que existen varias versiones de Microsoft Windows, los siguientes pasos pueden ser diferentes en su equipo. Si ajusta la configuración MaxUserPort , recomendamos reservar el puerto 1434 para utilizar el servicio Explorador de SQL Server (sqlbrowser.exe). Para obtener más información acerca de cómo hacerlo, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
812873 Cómo reservar un rango de puertos efímeros en un equipo que ejecuta Windows Server 2003 o Windows 2000 Server

Ajustar la configuración de WinsockListenBacklog

Para obtener información adicional acerca de esta configuración del Registro específica de SQL Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
154628 INF: SQL registros 17832 con varias solicitudes de conexión TCP/IP
Cuando la biblioteca de red de SQL Server escucha en sockets TCP/IP, la biblioteca de red de SQL Server utiliza la escucha API de Winsock. El segundo parámetro de la escucha API es el trabajo pendiente permitido para el socket. Este registro representa la longitud máxima de la cola de conexiones para el agente de escucha pendientes. Cuando la longitud de la cola supera este máximo, la biblioteca de red de SQL Server rechaza inmediatamente más intentos de conexión de socket TCP/IP. Además, la biblioteca de red de SQL Server envía un paquete ACK + RESET.

SQL Server 2000 utiliza una predeterminada escucha configuración de retraso de 5. Esto significa que el equipo que está ejecutando SQL Server pasa el valor 5 al parámetro de trabajo pendiente de la escucha API Winsock cuando la API escuchar configura los subprocesos de escucha de protocolo TCP/IP en el equipo que ejecuta SQL Server. Puede ajustar la clave del registro WinsockListenBacklog para especificar un valor diferente que se pasarán por este parámetro. A partir de SQL Server 2005, la biblioteca de red pasa un valor de SOMAXCONN como el valor de trabajo pendiente para la escucha API. SOMAXCONN permite al proveedor de Winsock establecer un valor máximo razonable para esta configuración. Por lo tanto, la clave de registro WinsockListenBacklog ya no se utilizan o necesarios en SQL Server 2005.

El trabajo pendiente del establecimiento funciona de la siguiente manera: supongamos que un servicio arbitrario está escuchando las solicitudes entrantes de socket TCP/IP. Si establece el valor del registro en 5 y continuamente transmite en muchas de las solicitudes de conexión de socket, el servicio no puede responder a las solicitudes entrantes tan rápidas como entran. En este punto, la capa de sockets TCP/IP colas de estas solicitudes de entrada en la cola de registro y el servicio más tarde puede extraen las peticiones de esta cola y controlar la solicitud de conexión entrante de socket. Después de que la cola se llena, la capa de sockets TCP/IP inmediatamente rechaza las solicitudes adicionales de socket que vienen en mediante el envío de un paquete ACK + RESET al cliente. Aumentar el aumentar el tamaño de cola trabajo pendiente que el número de pendientes de conexión de socket solicita que la capa de sockets TCP/IP pone en cola antes de que se rechazan las solicitudes.

Tenga en cuenta que el valor de WinsockListenBacklog es específico de SQL Server. SQL Server intenta leer este valor del registro cuando se inicie el servicio SQL Server. Si el valor no existe, se utiliza el valor predeterminado de 5. Si la configuración del registro no existe, SQL Server lee la configuración y utiliza el valor proporcionado como el valor de registro cuando escucha la API de WinSock se llama como los subprocesos de escucha de socket TCP/IP se establecen dentro de SQL Server.

Para determinar si se está ejecutando en este problema, puede ejecutar una traza de Monitor de red en el cliente o el equipo que ejecuta SQL Server y busque las solicitudes de conexión de socket son rechazadas inmediatamente con un ACK + RESET. Si examina los paquetes TCP/IP en Monitor de red, verá un paquete como el siguiente cuando se produzca este problema:
Frame: Base frame propertiesETHERNET:  EType = Internet IP (IPv4) IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No OptionsTCP: Control Bits: .A.R.., len:    0, seq:         0-0, ack:3409265780, win:    0, src: 1433  dst: 4364   TCP: Source Port = 0x0599	  TCP: Destination Port = 0x110C  TCP: Sequence Number = 0 (0x0)  TCP: Acknowledgement Number = 3409265780 (0xCB354474)  TCP: Data Offset = 20 bytes  TCP: Flags = 0x14 : .A.R..    TCP: ..0..... = No urgent data    TCP: ...1.... = Acknowledgement field significant    TCP: ....0... = No Push function    TCP: .....1.. = Reset the connection    TCP: ......0. = No Synchronize    TCP: .......0 = Not the end of the data  TCP: Window = 0 (0x0)  TCP: Checksum = 0xF1E7  TCP: Urgent Pointer = 0 (0x0)				
Tenga en cuenta que el puerto de origen es 0x599 o 1433 en formato decimal. Esto significa que el paquete que viene de un equipo típico que ejecuta SQL Server y que se ejecuta en el puerto 1433 predeterminado. Tenga en cuenta también que se establecen el campo de confirmación y los indicadores de Restablecer la conexión . Si está familiarizado con el filtrado de una traza de Monitor de red, puede filtrar el valor de los indicadores TCP por 0 x 14 hexadecimal para ver sólo los paquetes ACK + RESET en la traza del Monitor de red.

Tenga en cuenta que también puede ver los paquetes ACK + RESET similares si el equipo que ejecuta SQL Server no se ejecuta en absoluto, o si el equipo que ejecuta SQL Server no está escuchando en el protocolo TCP/IP, para ver los paquetes ACK + RESET no es confirmación definitiva que tiene este problema. Si la WinsockListenBacklog es demasiado bajo, alguna conexión intentos de reciban paquetes de aceptación y algunas conexiones recibirán inmediatamente los paquetes ACK + RESET en el mismo período de tiempo.

Tenga en cuenta que en casos muy raros, tendrá que ajustar esta configuración, incluso si la agrupación está habilitada en los equipos cliente. Por ejemplo, si muchos equipos cliente están hablando a un único equipo que está ejecutando SQL Server, un gran número de intentos de conexión entrantes simultáneas puede producirse en cualquier momento, incluso si está habilitada la agrupación.

Nota:Si ajusta la configuración de WinsockListenBacklog , no es necesario reiniciar Windows para que esta configuración surta efecto. Simplemente, detenga y reinicie el servicio SQL Server para que la configuración surta efecto. La configuración de registro de WinsockListenBacklog es sólo para el equipo que está ejecutando SQL Server. No tiene ningún efecto en cualquier equipo cliente que se está conectando a SQL Server.

Warning: This article has been translated automatically

Propiedades

Id. de artículo: 328476 - Última revisión: 03/15/2015 04:53:00 - Revisión: 12.0

Microsoft SQL Server 2000 Standard Edition, Microsoft ADO.NET 1.1, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbsqlsetup kbinfo kbmt KB328476 KbMtes
Comentarios