Calcular la interrupción del servicio durante la conmutación de funciones

Artículo
12/15/2008

Actualizado: 5 de diciembre de 2005

Durante una conmutación de funciones, la cantidad de tiempo que la creación de reflejo de la base de datos estará fuera de servicio depende del tipo y la causa de la conmutación de funciones.

En la conmutación por error automática hay dos factores que contribuyen a que el tiempo de servicio se interrumpa: el tiempo necesario para que el servidor reflejado reconozca que la instancia del servidor principal no se ha ejecutado correctamente, es decir, la detección de errores, más el tiempo necesario para realizar la conmutación por error de la base de datos, es decir, el tiempo de conmutación por error.
En una operación de servicio forzado, aunque se produzca un error, la detección y respuesta ante el error depende de la capacidad de respuesta humana. Sin embargo, la estimación de la interrupción potencial del servicio se limita a la estimación del tiempo que tarda el servidor reflejado en conmutar las funciones una vez que se emite el comando de servicio forzado.

[!NOTA] Para reducir el tiempo necesario para detectar condiciones específicas, como algunos tipos de error, puede definir las alertas para estas condiciones.
En el caso de la conmutación por error manual, el único factor es el tiempo necesario para realizar la conmutación por error de la base de datos una vez que se emite el comando de conmutación por error.

Detección de errores

El tiempo que necesita el sistema para detectar un error depende del tipo de error; por ejemplo, un error de red se detecta casi al instante, mientras que la detección de un bloqueo del servidor tarda 10 segundos de forma predeterminada, ya que ése es el tiempo de espera predeterminado.

Para obtener información acerca de los errores que pueden causar un error durante una sesión de creación de reflejo de la base de datos y la detección del tiempo de espera en modo de seguridad alta con conmutación por error automática, vea Posibles errores durante la creación de reflejo de la base de datos.

Tiempo de la conmutación por error

El tiempo de la conmutación por error depende principalmente del tiempo que el servidor reflejado anterior necesita para confirmar los registros pendientes en su cola rehecha más un breve tiempo adicional (para obtener más información acerca de cómo se procesan las entradas de registro en el servidor reflejado, vea Sesiones de creación de reflejo de la base de datos). Para obtener información acerca de cómo calcular el tiempo de la conmutación por error, vea Calcular la tasa de puesta al día de la conmutación por error, más adelante en este tema.

Importante:
Si la conmutación por error se produce durante una transacción en la que se crea un índice o tabla y después se cambia, es posible que tarde más de lo habitual. Por ejemplo, conmutar por error durante la siguiente serie de operaciones puede aumentar el tiempo de la conmutación por error: BEGIN TRANSACTION, CREATE INDEX en una tabla y SELECT INTO la tabla. Existe la posibilidad de un mayor tiempo de conmutación por error durante una transacción de este tipo hasta su finalización con una instrucción COMMIT TRANSACTION o ROLLBACK TRANSACTION.

Si la conmutación por error se produce durante una transacción en la que se crea un índice o tabla y después se cambia, es posible que tarde más de lo habitual. Por ejemplo, conmutar por error durante la siguiente serie de operaciones puede aumentar el tiempo de la conmutación por error: BEGIN TRANSACTION, CREATE INDEX en una tabla y SELECT INTO la tabla. Existe la posibilidad de un mayor tiempo de conmutación por error durante una transacción de este tipo hasta su finalización con una instrucción COMMIT TRANSACTION o ROLLBACK TRANSACTION.

Cola rehecha

La confirmación de la base de datos conlleva aplicar las entradas de registro que se encuentren en la cola rehecha del servidor reflejado. La cola rehecha está formada por las entradas de registro que se han escrito en el disco del servidor reflejado, pero todavía no se han puesto al día en la base de datos reflejada.

El tiempo de la conmutación por error para la base de datos depende de la rapidez con la que el servidor reflejado pueda poner al día el registro en la cola rehecha, que, a su vez, se determina principalmente por el hardware del sistema y la carga de trabajo actual. Potencialmente, una base de datos principal puede estar tan ocupada que el servidor principal envía los registros al servidor reflejado mucho más rápidamente de lo que puede confirmarlos. En esta situación, la conmutación por error puede tardar mucho tiempo mientras el servidor reflejado pone al día el registro en la cola rehecha. Para conocer el tamaño actual de la cola rehecha, utilice el contador Cola rehecha en el objeto de rendimiento de creación de reflejo de la base de datos. Para obtener más información, vea Database Mirroring (objeto de SQL Server).

Calcular la tasa de puesta al día de la conmutación por error

Puede medir la cantidad de tiempo que se necesita para poner al día las entradas de registro (tasa de puesta al día) utilizando una copia de prueba de la base de datos de producción.

El método para calcular el tiempo de confirmación durante la conmutación por error depende del número de subprocesos que el servidor reflejado utiliza durante la fase de puesta al día. El número de subprocesos depende de la edición de SQL Server y, en SQL Server 2005 Enterprise Edition, de la cantidad de CPU:

En SQL Server Standard Edition, el servidor reflejado siempre utiliza un solo subproceso para confirmar la base de datos.
En SQL Server 2005 Enterprise Edition, los servidores reflejados en equipos con menos de cinco CPU también utilizan un único subproceso. Con cinco CPU o más, un servidor reflejado distribuye las operaciones de puesta al día entre varios subprocesos durante una conmutación por error (esto se conoce como puesta al día en paralelo). La puesta al día en paralelo está optimizada para utilizar un subproceso por cada cuatro CPU.

Calcular la tasa de puesta al día con un único subproceso

En la puesta al día con un único subproceso, la puesta al día de la base de datos reflejada durante la conmutación por error tarda aproximadamente lo mismo que la puesta al día de igual cantidad de registro por parte de la restauración de una copia de seguridad del registro. Para calcular el tiempo de la conmutación por error, cree una base de datos de prueba en el entorno en el que pretende ejecutar la creación de reflejo. Después, realice una copia de seguridad de registros de la base de datos de producción. Para medir la tasa de puesta al día para esa copia de seguridad de registros, controle cuánto tiempo tarda en restaurar la copia de seguridad de registros con WITH NORECOVERY en la base de datos de prueba.

Cuando conozca la tasa de puesta al día del servidor reflejado, podrá calcular el tiempo necesario para realizar la conmutación por error de la base de datos en un momento dado, dividiendo la cantidad de registro actual que se debe poner al día en el servidor reflejado (según la medición efectuada por el contador de rendimiento Cola rehecha) entre la tasa de puesta al día. En condiciones normales, si el servidor reflejado puede hacer frente a la carga del servidor principal, el valor de Cola rehecha es pequeño o cercano a cero, y la conmutación por error sólo tarda unos segundos.

Calcular la tasa de puesta al día en paralelo

En Enterprise Edition, la puesta al día en paralelo está optimizada para utilizar un subproceso por cada cuatro CPU. Para calcular el tiempo de la puesta al día en paralelo, es más preciso obtener acceso a un sistema de prueba en ejecución que a una base de datos de prueba. Durante la supervisión de la cola rehecha en el servidor reflejado, aumente la carga en el servidor principal. Durante el funcionamiento normal, el valor de la cola rehecha es casi cero. Aumente la carga en el servidor principal hasta que el valor de la Cola rehecha comience a aumentar de forma continua; el sistema estará en su valor máximo de tasa de puesta al día y el contador de rendimiento Bytes rehechos/seg. en ese momento representa la tasa máxima de puesta al día. Para obtener más información, vea Database Mirroring (objeto de SQL Server).

Calcular la interrupción del servicio durante una conmutación por error automática

En la siguiente ilustración se muestra cómo la detección de errores y el tiempo de la conmutación por error influyen en el tiempo completo necesario para que una conmutación por error automática finalice en Partner_B. La conmutación por error necesita tiempo para confirmar la base de datos (fase de puesta al día) más una pequeña cantidad de tiempo para poner en conexión la base de datos. La fase de deshacer, que consiste en deshacer las transacciones no confirmadas, tiene lugar después de poner en conexión la nueva base de datos principal y continúa después de la conmutación por error. Durante esta fase, la base de datos está disponible.

Detección de errores y tiempo de la conmutación por error

Vea también

Historial de cambios

Versión	Historial
5 de diciembre de 2005	Contenido modificado: Se reorganizó la información para abarcar la interrupción de servicios en cada una de las formas de conmutación de funciones.