Operación asincrónica de creación de reflejo de la base de datos (Modo de alto rendimiento)

Actualizado: 5 de diciembre de 2005

Si la seguridad de las transacciones está configurada en OFF, la sesión de creación de reflejo de la base de datos funciona de forma asincrónica. La operación asincrónica sólo admite el modo operativo de alto rendimiento. Este modo mejora el rendimiento a costa de la alta disponibilidad. El modo de alto rendimiento utiliza solamente el servidor principal y el servidor reflejado. Los problemas del servidor reflejado nunca afectan al servidor principal. Al perderse el servidor principal, la base de datos reflejada se marca como DISCONNECTED, pero está disponible como base de datos en espera semiactiva.

El modo de alto rendimiento sólo admite un formato de conmutación de funciones: el servicio forzado (con posible pérdida de datos), que utiliza el servidor reflejado como servidor en espera semiactiva. El servicio forzado es una de las posibles respuestas a los errores del servidor principal. Dado que es posible la pérdida de datos, debe considerar otras alternativas antes de forzar el servicio en el servidor reflejado. Para obtener más información, vea "Responder ante los errores del servidor principal" más adelante en este tema.

En la siguiente ilustración se muestra la configuración de una sesión con el modo de alto rendimiento.

En el modo de alto rendimiento, en cuanto el servidor principal envía el registro de una transacción al servidor reflejado, el servidor principal envía una confirmación al cliente, sin esperar una confirmación del servidor reflejado. Las transacciones se confirman sin esperar a que el servidor reflejado escriba el registro en el disco. La operación asincrónica permite que el servidor principal se ejecute con la mínima latencia de transacciones.

El servidor reflejado intenta hacer frente a las entradas de registro enviadas por el servidor principal. Sin embargo, la base de datos reflejada puede retrasarse un poco con respecto a la base de datos principal, aunque la diferencia entra ambas suele ser pequeña. No obstante, la diferencia puede ser considerable si el servidor principal soporta una gran carga de trabajo o el sistema del servidor reflejado se encuentra sobrecargado.

Cuándo está indicado utilizar el modo de alto rendimiento

El modo de alto rendimiento puede resultar útil en un caso de recuperación de desastres en el que los servidores principal y reflejado se encuentran separados por una distancia considerable y no se desea que los pequeños errores afecten al servidor principal.

[!NOTA] El trasvase de registros puede complementar a la creación de reflejo de la base de datos y es una alternativa conveniente a la creación asincrónica de reflejo de la base de datos. Para obtener información acerca de las ventajas del trasvase de registros, vea Configurar una alta disponibilidad. Para obtener información acerca de cómo utilizar el trasvase de registros con la creación de reflejo de la base de datos, vea Creación de reflejo de la base de datos y trasvase de registros.

El impacto de un testigo en el modo de alto rendimiento

Si se utiliza Transact-SQL para configurar el modo de alto rendimiento, siempre que la propiedad SAFETY esté establecida en OFF, se recomienda encarecidamente que la propiedad WITNESS también se establezca en OFF. Un testigo puede coexistir con el modo de alto rendimiento, pero no proporciona ventaja alguna y genera riesgo.

Si el testigo está desconectado de la sesión y uno de los asociados se bloquea, la base de datos no estará disponible. Esto es así porque, aun cuando el modo de alto rendimiento no necesita un testigo, si se establece uno, la sesión requiere un quórum compuesto de dos o más instancias de servidor. Si la sesión pierde el quórum, no puede servir a la base de datos.

Cuando se establece un testigo en una sesión en modo de alto rendimiento, la aplicación de quórum implica que:

• Si se pierde el servidor reflejado, el servidor principal se debe conectar al testigo. De lo contrario, el servidor principal mantiene su base de datos sin conexión hasta que el testigo o el servidor reflejado vuelven a unirse a la sesión.
• Si se pierde el servidor principal, forzar el servicio en el servidor reflejado requiere que éste se conecte al testigo.

[!NOTA] Para obtener información acerca de los tipos de quórum, vea Quórum: cómo un testigo afecta a la disponibilidad de la base de datos.

Responder ante los errores del servidor principal

Si se produce un error en el servidor principal, el propietario de la base de datos tiene varias opciones:

• Dejar la base de datos inactiva hasta que el servidor principal vuelva a estar disponible.
  Si la base de datos principal y su registro de transacciones están intactos, esta opción conserva todas las transacciones confirmadas a costa de la disponibilidad.

• Detener la sesión de creación de reflejo de la base de datos, actualizar manualmente la base de datos y, después, iniciar una nueva sesión de creación de reflejo.
  Si la base de datos principal se pierde pero el servidor principal sigue en funcionamiento, intente inmediatamente realizar una copia de seguridad del final del registro en la base de datos principal. Si la copia de seguridad de registros después del error se realiza correctamente, la mejor opción puede ser eliminar la creación de reflejo. Tras eliminar la creación de reflejo, puede restaurar el registro en la base de datos reflejada anterior, que conserva todos los datos.

  [!NOTA] Si no se puede realizar la copia de seguridad de registros después del error y no puede esperar a que el servidor principal se recupere, considere la posibilidad de forzar el servicio, que ofrece la ventaja de mantener el estado de la sesión.

• Forzar el servicio (con posible pérdida de datos) en el servidor reflejado.
  El servicio forzado es estrictamente un método de recuperación de desastres y no se debe utilizar demasiado a menudo. Sólo es posible forzar el servicio si el servidor principal está inactivo, la sesión es asincrónica (la seguridad de transacciones está configurada en OFF) y la sesión no tiene un testigo (la propiedad WITNESS está configurada en OFF) o el testigo se ha conectado al servidor reflejado (esto es, hay quórum).
  Al forzar el servicio, el servidor reflejado asume la función de servidor principal y ofrece su copia de la base de datos a los clientes. Una vez forzado el servicio, los registros de transacciones que el servidor principal no haya enviado todavía al servidor reflejado se pierden. Por lo tanto, el servicio forzado debe limitarse a situaciones en las que sea aceptable la posible pérdida de datos y sea crucial la disponibilidad inmediata de la base de datos. Para obtener información acerca del funcionamiento del servicio forzado y las prácticas recomendadas para utilizarlo, vea Servicio forzado (con posible pérdida de datos).

Vea también

Conceptos

Servicio forzado (con posible pérdida de datos)
Creación de reflejo sincrónico de la base de datos (modo de alta seguridad)
Configuración de Transact-SQL y modos de funcionamiento de la creación de reflejo de la base de datos
Descripción del trasvase de registros

Ayuda e información

Obtener ayuda sobre SQL Server 2005