Sesiones de creación de reflejo de la base de datos
La creación de reflejo de la base de datos se produce en el contexto de una sesión de creación de reflejo de la base de datos. En este tema se supone que está familiarizado con las funciones entidad de seguridad, reflejo y token, los modos operativos y la conmutación de funciones en la creación de reflejo de la base de datos. Para obtener más información, vea Información general sobre la creación de reflejos de la base de datos.
Cuando la base de datos reflejada esté preparada y las instancias del servidor estén configuradas, el propietario de la base de datos podrá iniciar la creación de reflejo de la base de datos. En cuanto se inicia la creación de reflejo, cada asociado comienza a mantener información de estado en su base de datos sobre esa base de datos y sobre el otro asociado y el token, si existen. Esta información de estado permite que las instancias de servidor mantengan una relación conocida como sesión de creación de reflejo de la base de datos. Durante una sesión de creación de reflejo de una base de datos, las instancias de servidor se supervisan entre sí. La información de estado se mantiene hasta que el propietario de la base de datos detiene la sesión. Para obtener más información, vea Estados de creación de reflejo y Supervisar la creación de reflejo de la base de datos.
Al inicio de una sesión de creación de reflejo de la base de datos, el servidor reflejado identifica el número de secuencia de registro (LSN) del último registro de transacciones aplicado en la base de datos reflejada y solicita al servidor de la entidad de seguridad el registro de transacciones de todas las transacciones posteriores, si las hay. En respuesta, el servidor de la entidad de seguridad envía al servidor reflejado las entradas del registro activo acumuladas desde último registro restaurado en la base de datos reflejada o enviado al servidor reflejado. El registro sin enviar que se ha acumulado en el disco lógico de la base de datos de la entidad de seguridad se conoce como cola de envío.
El servidor reflejado escribe inmediatamente el registro entrante en el disco, donde se mantiene hasta que se aplica a la base de datos reflejada. El registro que permanece en espera en el disco del reflejo se conoce como la cola rehecha. La parte del registro sin restaurar que espera en la cola rehecha es un indicador del tiempo necesario para conmutar por error a la base de datos reflejada. Para obtener más información, vea Calcular la interrupción del servicio durante la conmutación de funciones.
El servidor de la entidad de seguridad continúa poniendo la base de datos de la entidad de seguridad a disposición de los clientes y de las conexiones de cliente. Tras el inicio de la creación de reflejo, cada vez que un cliente actualiza la base de datos de la entidad de seguridad, al escribir la transacción en el registro de la base de datos de la entidad de seguridad, el servidor de la entidad de seguridad también envía esa entrada del registro al servidor reflejado. Ahí, el servidor reflejado escribe inmediatamente la entrada del registro en el disco como la última entrada de la cola rehecha.
En segundo plano, el servidor reflejado rehace el registro en la base de datos reflejada, entrada por entrada, empezando por la entrada del registro más antigua, tan pronto como sea posible. Al rehacer el registro, se aplican secuencialmente las entradas del registro en cola a la base de datos reflejada, comenzando por la entrada más antigua. Cada entrada del registro sólo se rehace una vez. A medida que el servidor reflejado rehace el registro, la base de datos reflejada se pone al día de forma continua. Si el servidor de la entidad de seguridad trunca o reduce el registro de la base de datos de la entidad de seguridad, el servidor reflejado también reduce el registro en el mismo punto de la secuencia.
Generalmente, al rehacer el registro, la base de datos reflejada se pone inmediatamente al nivel de la base de datos de la entidad de seguridad. El modo operativo de la sesión determina si la base de datos reflejada alcanza totalmente el nivel de la base de datos de la entidad de seguridad. En el modo de alta seguridad sincrónico, el servidor de la entidad de seguridad espera para confirmar las transacciones nuevas hasta que se graban en el disco del registro del servidor reflejado. Cuando las entradas del registro acumuladas se han enviado al servidor reflejado, la base de datos reflejada se sincroniza con la base de datos de la entidad de seguridad.
Durante una sesión, si el servidor de la entidad de seguridad no puede enviar todas las entradas del registro inmediatamente, las entradas del registro sin enviar se acumulan en la cola de envío. En el modo de alta seguridad sincrónico, después de la sincronización, las nuevas entradas del registro sin enviar se acumulan sólo cuando la creación del reflejo se pone en pausa o se suspende. Por el contrario, en el modo de alto rendimiento asincrónico, el registro sin enviar se acumula siempre que el servidor reflejado se retrasa durante la creación del reflejo, además de cuando el reflejo se pone en pausa o se suspende. La cantidad del registro sin enviar es un indicador de la posible pérdida de datos en el caso de que el servidor de la base de datos no funcione.
[!NOTA]
Si se producen errores al rehacer, el servidor reflejado pausa la sesión poniendo la base de datos en el estado SUSPENDED. Para poder reanudar la sesión, el propietario de la base de datos debe resolver la causa del error.
Sesiones simultáneas
Una determinada instancia de servidor puede participar en varias sesiones simultáneas de creación de reflejo de la base de datos (una por cada base de datos reflejada) con la misma instancia o con instancias de servidor distintas. Con frecuencia, una instancia de servidor sirve exclusivamente como asociado o como token en todas las sesiones de creación de reflejo de la base de datos. Sin embargo, puesto que cada sesión depende de las demás, una instancia de servidor puede actuar como asociado en algunas sesiones y como token en otras. Por ejemplo, considere las siguientes cuatro sesiones entre tres instancias de servidor (SSInstance_1, SSInstance_2 y SSInstance_3). Cada estancia de servidor sirve como asociado en algunas sesiones y como token en otras:
Instancia de servidor |
Sesión para la base de datos A |
Sesión para la base de datos B |
Sesión para la base de datos C |
Sesión para la base de datos D |
|---|---|---|---|---|
SSInstance_1 |
Testigo |
Asociado |
Asociado |
Asociado |
SSInstance_2 |
Asociado |
Testigo |
Asociado |
Asociado |
SSInstance_3 |
Asociado |
Asociado |
Testigo |
Testigo |
En la siguiente ilustración se muestran dos instancias de servidor que participan como asociados en dos sesiones de creación de reflejo. Una sesión es para una base de datos llamada Db_1 y la otra sesión es para una base de datos llamada Db_2.
.gif "Dos instancias de servidor en dos sesiones simultáneas")
Cada una de las bases de datos es independiente de las demás. Por ejemplo, una instancia de servidor puede ser inicialmente el servidor reflejado de dos bases de datos. Si en una de esas bases de datos se produce una conmutación por error, la instancia de servidor se convierte en el servidor de la entidad de seguridad de la base de datos en la que se ha realizado la conmutación por error y, a la vez, sigue siendo el servidor reflejado de la otra base de datos.
Como ejemplo adicional, suponga una instancia de servidor que sea el servidor de la entidad de seguridad de dos o más bases de datos que se ejecutan en modo de alta seguridad con conmutación automática por error. Si se produce un error en la instancia de servidor, todas las bases de datos realizan automáticamente la conmutación por error a sus respectivas bases de datos reflejadas.
Al configurar una instancia de servidor para que actúe como asociado y token, asegúrese de que el extremo de reflejo de la base de datos admite ambas funciones (para obtener más información, vea Extremo de creación de reflejo de la base de datos). Asegúrese también de que el sistema dispone de suficientes recursos para reducir la contención de recursos.
[!NOTA]
Dado que las bases de datos reflejadas son independientes entre sí, no pueden realizar la conmutación por error en grupo.
Subprocesos creados para una sesión de creación de reflejo de la base de datos
Los tipos de subprocesos que una instancia de servidor crea para una sesión de creación de reflejo de la base de datos dependen en parte de las funciones de creación de reflejo que dicha instancia está realizando. Una sesión determinada tiene algunos o todos los subprocesos siguientes:
Un subproceso global para las comunicaciones de la creación de reflejo de la base de datos. Este subproceso lo inicia Service Broker.
Si la instancia del servidor está actuando como un asociado de creación de reflejo (si es el servidor principal o el servidor reflejado):
Un subproceso por base de datos reflejada para el procesamiento de eventos.
Un subproceso por base de datos reflejada para las tareas asincrónicas (como el envío del registro o la escritura en el registro) que de otra forma bloquearían el subproceso de evento.
Siempre que la instancia esté actuando como un servidor reflejado:
Un subproceso de administración de puesta al día, que envía el registro para su puesta al día, realiza la lectura anticipada de páginas, la adquisición de bloqueos, etc.
En SQL Server Standard, un subproceso de puesta al día por base de datos reflejada, o en SQL Server Enterprise, un subproceso de puesta al día por base de datos reflejada por cada cuatro CPU. Estos subprocesos realizan la puesta al día real del registro.
Si la instancia está actuando como testigo:
- Un subproceso global para procesar los mensajes del testigo de todas las sesiones de creación de reflejo de la base de datos en las que la instancia está actuando como testigo.
Requisitos previos para una sesión de creación de reflejo de la base de datos
Para que pueda comenzar una sesión de creación de reflejo, el propietario de la base de datos o el administrador del sistema deben crear la base de datos reflejada, configurar los extremos e inicios de sesión, y en algunos casos, crear y configurar certificados. Para obtener más información, vea Configurar la creación de reflejo de la base de datos.
La creación de una base de datos reflejada requiere como mínimo que se realice una copia de seguridad completa de la base de datos de la entidad de seguridad y una siguiente copia de seguridad de registros, y que ambas se restauren en la instancia de servidor reflejado mediante WITH NORECOVERY. Además, antes de que pueda iniciar la creación de reflejo, si se realizan copias de seguridad de registros adicionales posteriores a la copia de seguridad de registros requerida, también debe aplicar manualmente cada copia de seguridad de registros adicional (siempre usando WITH NORECOVERY). Tras aplicar la copia de seguridad de registros más reciente, puede iniciar la creación de reflejo. Para obtener más información, vea Preparar una base de datos reflejada para la creación de reflejo.
Impacto al pausar una sesión en el registro de transacciones del servidor principal
En cualquier momento, el propietario de la base de datos puede pausar una sesión. La pausa preserva el estado de la sesión mientras se quita la creación de reflejo. Cuando se pausa una sesión, el servidor de la entidad de seguridad no envía ninguna entrada del registro nueva al servidor reflejado. Todas estas entradas permanecen activas y se acumulan en el registro de transacciones de la base de datos de la entidad de seguridad. Mientras una sesión de creación de reflejo de la base de datos permanece pausada, el registro de transacciones no se puede truncar. Por tanto, si se realiza una pausa demasiado larga en la sesión de creación de reflejo de la base de datos, el registro puede llenarse.
Para obtener más información, vea Pausar y reanudar la creación de reflejo de la base de datos.
Conexiones de cliente
El proveedor de datos de Microsoft .NET para SQL Server proporciona compatibilidad con la conexión de cliente en sesiones de creación de reflejo de la base de datos. Para obtener más información, vea Conectar clientes a una base de datos reflejada.
Vea también