Descripción de las conexiones de cliente de servidor virtual SQL

Seleccione idioma Seleccione idioma
Id. de artículo: 273673 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Este artículo describen algunos de los conceptos básicos sobre conexiones de cliente de servidor virtual de Microsoft SQL.

Más información

importante Esta sección, el método o la tarea contiene pasos que indican cómo modificar el registro. Sin embargo, pueden producirse problemas graves si modifica incorrectamente el registro. Por tanto, asegúrese de que siga estos pasos cuidadosamente. Realice una para agregar protección, copia de seguridad del registro antes de modificarlo. A continuación, puede restaurar el registro si se produce un problema. Para obtener más información acerca de cómo realizar una copia de seguridad y restaurar el registro, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
322756Cómo realizar una copia de seguridad y restaurar el registro de Windows


Comportamiento de cliente servidor virtual SQL

Cluster Server (MSCS) proporciona una plataforma confiable y robusta en el que puede crear aplicaciones críticas de SQL Server. No es necesario modificar la mayoría de los aplicaciones de servidor para utilizarlos con MSCS. Sin embargo, aplicaciones basadas en transacciones (por ejemplo, base de datos de servidores, como Microsoft SQL Server) normalmente requieren modificaciones adicionales de modo que si se produce un error en el servidor, compatibilidad con conmutación por error correctamente impide la pérdida de integridad transaccional. Desarrollar una aplicación cliente para funcionar con MSCS es relativamente sencillo. Debe diseñar aplicaciones con recuperación de la base de datos y comprobación de errores en cuenta.

Incluso sin usar de clústeres, un servidor SQL Server servidor recupera automáticamente todas las bases de datos cuando se reinicia el servidor. Para asegurarse de que una base de datos se recupera en un estado coherente de la aplicación, las transacciones de base de datos de uso para que se produce conmutación por error en la base de datos correctamente y en un estado coherente. Las transacciones que están incompletas cuando se produce conmutación por error se deberían deshacer, mientras que deben conservarse los efectos de todas las transacciones confirmadas.

Durante la conmutación por error, las aplicaciones de cliente pierdan su conexión a servidor SQL server y deben volver a conectarse para continuar procesando. Si la conexión cliente al servidor está sin estado, (por ejemplo, las aplicaciones desarrolladas utilizando Microsoft Internet Information Server [IIS] son sin estado) el cliente vuelve a conectar al servidor y continúa el procesamiento. El cliente y el servidor no tiene un estado común (por ejemplo, cursores abiertos, las variables de sesión, las variables globales de Transact-SQL o datos de tempdb), no es transparente para el cliente de conmutación por error. En estos casos, debe diseñe la aplicación de cliente para informar al usuario que la conexión estaba perdidos, restablecer o tiene la aplicación automáticamente restablecer su conexión al servidor. Se deshace cualquier transacción que no se ha confirmado cuando se produce una conmutación por error.

La explicación de cómo los clientes tratan errores de servidor es un estándar para cualquier aplicación de cliente de SQL Server, incluso sin usar de clústeres y servidores virtuales. El proceso de comprobación de error es bastante similar para una aplicación de base de datos de cliente para un clúster. Cuando el clúster comienza la conmutación por error, el programa cliente recibe un mensaje de error en la conexión de base de datos. Los mensajes de error encontrados dependen de lo que el programa cliente intenta realizar en ese momento.

Si un servidor SQL Server es un error por el Administrador de clúster, no se envían los paquetes de restablecimiento TCP. Si finaliza el proceso de SQL Server por el sistema operativo (por Kill.exe), se envían los paquetes de restablecimiento.

Esto puede afectar la aplicación cliente si la aplicación no especifica un parámetro de tiempo de espera de consulta o un tiempo de espera consulta de cero (0).

Si la aplicación no tiene un valor de tiempo de espera de consulta, a continuación, abra conexiones quedará en el estado ESTABLISHED cuando se produce una conmutación por error. El hecho de que no se cierran las conexiones abiertas y que no más paquetes TCP se envían desde las conexiones indica que las conexiones son totalmente inactivas. Debido a que la conmutación por error no se envió ningún TCP restablece paquetes a la aplicación cliente, las conexiones abiertas esperar los resultados de consulta indefinidamente (suponiendo un tiempo de espera infinito consulta) y causar potencialmente la conexión deja de responder (se bloquea).

Para solucionar este problema desde una perspectiva de aplicación de cliente, cambie el tiempo de espera de consulta a un número finito.

Comportamiento de error de base de datos virtual

Cuando falla un servidor virtual de la base de datos, un mensaje de error de error de vínculo de conexión se devuelve al cliente espera. La base de datos en el nodo del clúster apagar y reiniciada en el mismo nodo por los parámetros configurados:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
				
El umbral de predeterminada de conmutación por error el grupo es 10 reinicios en un período de 6 horas antes de que una conmutación por error se produzca en el nodo restante. Sin embargo, SQL Server reiniciar el umbral, que se puede comprobar a través de las propiedades de SQL Server en el recurso de clúster de SQL Server, tiene un umbral predeterminado de reinicios de tres en que SQL Server en el 900 segundos y de forma predeterminada afecta el grupo. Si un cliente intenta conectar con el servidor mientras se está recuperando una base de datos, el cliente recibe una espera para mensaje de error de recuperación de base de datos y debe reintentar tras una breve pausa.

Consideraciones de SQL Server 6.5 y SQL Server 7.0

SQL Server 6.5 y SQL Server 7.0 actúan exactamente como se describe en la sección "Comportamiento de error de base de datos virtual" anterior.

Cuando se ejecuta SQL Server 7.0 como un servidor virtual SQL Server 7.0 admite sólo una dirección IP, pero puede escuchar en puertos adicionales como se ha configurado por el cliente. Esto se describe en el tema "Múltiples escuchar en puertos TCP/IP" en el siguiente artículo de Microsoft Knowledge Base:
254321INF: Clústeres SQL Server Do's Don'ts y advertencias básicas

Consideraciones acerca de Microsoft SQL Server 2000

SQL Server 2000 presenta algunas diferencias en comportamiento de las versiones de SQL Server 6.5 y SQL Server 7.0.

uso del puerto de SQL Server 2000

De forma predeterminada, una instancia con nombre escucha en un puerto dinámico. La primera vez que el servidor se inicia con un puerto establecido en cero (0), el servidor solicita un número de puerto libre del sistema operativo y, a continuación, el servidor escucha en ese puerto. El servidor graba esto para el registro y, a continuación, utiliza el mismo puerto cada vez.

Si un servidor está configurado para escuchar en un puerto dinámico y el servidor no puede escuchar en el puerto dinámico en Inicio, el servidor elige otro puerto.

Si configura un puerto estático durante la instalación o después de la instalación mediante la utilidad de red de servidor no escucha en TCP/IP si este puerto está en uso.

Clientes detectan el número de puerto para conectar en el caso de una instancia con nombre o uno con un número de puerto no predeterminado.

La información de conexión se escribe en la caché "LastConnect" de esta clave del registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
Encontrará entradas para cada servidor y el método que se utilizó para conectarse a ellos en el registro.

El cliente intenta volver a utilizar la información de conexión en cada conexión a menos que se produce un error y re-negotiates a continuación, la nueva información. Esto puede suceder si ha cambiado el número de puerto porque alguien cambiado o si era un puerto dinámico que se reasignará debido a un puerto está en uso.

Conexiones interrumpidas

Hay tres formas de que una conexión se puede interrumpir:
  1. Se produce un error en el servidor; el proceso termina siendo eliminado (ID. de proceso de servidor [ spid ] kill sistema) o una infracción de acceso (AV) o algo hace que el sistema de operativo o el servicio requiere un error.
  2. Error de hardware del equipo o pérdida de energía.
  3. Apagado del servidor.
Cada una de estas conexiones rotos exhibir distintos comportamientos vistos en el equipo cliente.
  1. En el caso donde un servidor falla, el cliente recibe una conexión rotos mensaje de error inmediatamente. Puede simular este comportamiento mediante la conexión con OSQL, ejecutar una consulta larga y, a continuación, utilizar KILL para terminar el proceso de SQL Server. El cliente sale con un mensaje de error ODBC.
  2. Un error del equipo es más complicado. Puede cambiar el comportamiento ligeramente según cómo se detecta la pérdida de conexión.

    Si el cliente está en medio de leer la información, la pérdida de conexión puede detectarse inmediatamente porque deja los datos.

    Si el cliente sólo está esperando los resultados, el comportamiento es ligeramente diferente. El comportamiento depende de la configuración de mantenimiento de conexión del equipo cliente.

    En Microsoft Windows 2000 Keep Alive está establecida por el código cliente en cada conexión. De forma predeterminada, el mantenimiento de conexión se establece en 30 segundos. Esto significa que si el socket se muere se detecta dentro de 30 segundos y el cliente recibe un mensaje de error. En Microsoft Windows NT 4.0, mantenimiento de conexión no puede establecerse en una base por conexión. Mantener Alive debe establecerse para todo el equipo, así que afectan a todas las aplicaciones del servidor.

    Las claves del registro que se hace referencia a son:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime\REG_DWORD 30000

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveInterval\REG_DWORD 1000
  3. Cuando inicia un apagado del servidor, el servidor espera un tiempo para los clientes Finalizar. Sin embargo, si el cliente aún ejecuta el servidor elimina los subprocesos dentro del servidor. Eliminar los subprocesos también puede producir mensajes de error diferentes en el cliente. Los mensajes de error pueden incluir una conexión roto error; sin embargo, la mayor parte del tiempo verá este mensaje de error:
    "Error desconocido, la conexión puede que haya terminado por el servidor".
    El código de error nativo de ODBC se establece en cero (0) en este caso, pero se devuelven como un mensaje de error al cliente.

Referencias

Para obtener más información acerca de comportamiento de cliente de servidor virtual SQL en SQL Server 2005, visite el siguiente sitio Web de Microsoft Developer Network (MSDN):
http://msdn2.microsoft.com/en-us/library/ms189585.aspx

Propiedades

Id. de artículo: 273673 - Última revisión: martes, 04 de diciembre de 2007 - Versión: 7.3
La información de este artículo se refiere a:
  • Microsoft SQL Server 6.5 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Palabras clave: 
kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 KbMtes
Traducción automática
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): 273673

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com