Números de secuencia de registro clFS
En el Sistema de archivos de registro común (CLFS), cada registro de una secuencia determinada se identifica de forma única mediante un número de secuencia de registro (LSN). Al escribir un registro en una secuencia, se obtiene un LSN que identifica ese registro para referencia futura.
Los LSN creados para una secuencia determinada forman una secuencia estrictamente creciente. Es decir, el LSN asignado a un registro de registro en una secuencia determinada siempre es mayor que los LSN asignados a los registros escritos anteriormente en esa misma secuencia. Las siguientes funciones están disponibles para comparar los LSN de los registros de una secuencia determinada.
Las constantes CLFS_LSN_NULL y CLFS_LSN_INVALID son los límites inferiores y superiores de todos los LSN válidos. Cualquier LSN válido es mayor o igual que CLFS_LSN_NULL. Además, cualquier LSN válido es estrictamente menor que CLFS_LSN_INVALID. Tenga en cuenta que CLFS_LSN_NULL es un LSN válido, mientras que CLFS_LSN_INVALID no es un LSN válido. Incluso así, puede comparar CLFS_LSN_INVALID con otros LSN mediante las funciones de la lista anterior.
Para cada secuencia, CLFS realiza un seguimiento de dos LSN especiales: el LSN base y el último LSN. Además, cada registro individual tiene dos LSN especiales (el LSN anterior y el LSN de deshacer siguiente) que puede usar para crear cadenas de registros relacionados. En las secciones siguientes se describen detalladamente estos LSN especiales.
Base LSN
Cuando un cliente escribe el primer registro de una secuencia, CLFS establece el LSN base en el LSN de ese primer registro. El LSN base permanece sin cambios hasta que un cliente lo cambia. Cuando los clientes de la secuencia ya no necesitan los registros antes de un determinado punto de la secuencia, pueden actualizar el LSN base llamando a ClfsAdvanceLogBase o ClfsWriteRestartArea. Por ejemplo, si los clientes ya no necesitan los cinco primeros registros de registro, pueden establecer el LSN base en el LSN del sexto registro.
Último LSN
A medida que los clientes escriben registros en una secuencia, CLFS ajusta el último LSN para que siempre sea el LSN del último registro escrito. Si los clientes ya no necesitan los registros después de un determinado punto de la secuencia, pueden actualizar el último LSN llamando a ClfsSetEndOfLog. Por ejemplo, si los clientes ya no necesitan ningún registro escrito después del décimo registro, pueden truncar la secuencia estableciendo el último LSN en el LSN del décimo registro.
Parte activa de una secuencia
La parte activa de una secuencia es la parte de una secuencia que comienza con el registro al que apunta el LSN base y termina con el registro al que apunta el último LSN. En el diagrama siguiente se muestra cómo el LSN base y el último LSN delimitan la parte activa de una secuencia.
Nota Si una secuencia tiene una cola de archivo, la parte activa de la secuencia comienza en el registro al que apunta el LSN base o la cola de archivo, lo que sea menor. Para obtener más información sobre el archivado, consulte Compatibilidad con CLFS para archivado.
LSN anterior
Supongamos que dos transacciones de base de datos activas (transacción A y transacción B) escriben registros en la misma secuencia al mismo tiempo. Cada vez que la transacción A escribe un registro, establece el LSN anterior del registro en el LSN del registro anterior escrito por la transacción A. Que forma una cadena de registros, que pertenece a la transacción A, que se puede recorrer en orden inverso. La cadena termina con el primer registro escrito por la transacción A, que tiene su LSN anterior establecido en CLFS_LSN_INVALID. De forma similar, la transacción B crea su propia cadena de registros estableciendo el LSN anterior de cada registro que escribe.
Las flechas del diagrama siguiente muestran cómo el LSN anterior de un registro apunta al registro anterior de una cadena que pertenece a una transacción determinada.
Deshacer-next LSN
Supongamos que una transacción realiza cinco actualizaciones de un objeto de datos en memoria volátil, revierte las actualizaciones cuarta y quinta y, a continuación, realiza una sexta actualización. A medida que la transacción realiza las actualizaciones, escribe los registros 1, 2, 3, 4, 5, 5, 4 y 6. Los registros de registro del 1 al 5 describen los cambios realizados por las actualizaciones del 1 al 5. El registro 5' describe los cambios realizados durante la reversión de la actualización 5 y el registro 4' describe los cambios realizados durante la reversión de la actualización 4. Por último, el registro 6 describe los cambios realizados por la actualización 6. Tenga en cuenta que los números 1, 2, 3, 4, 5, 5', 4' y 6 no son los LSN de los registros de registro; son solo números que se usan para asignar un nombre a los registros de registro con el fin de esta discusión.
Los registros de registro 5' y 4', que describen las reversiones, se denominan registros de compensación (CLR). La transacción establece el LSN undo-next de cada CLR en el predecesor (entre los registros escritos por la transacción) del registro cuyo registro se acaba de revertir (deshacer). En este ejemplo, el LSN undo-next del registro 5' es el LSN del registro 4, y el LSN de deshacer-next del registro 4' es el LSN del registro 3.
Los registros normales (aquellos que no son CLR), tienen sus LSN de deshacer a continuación establecidos en el registro de registro anterior escrito por la transacción. Es decir, para un registro normal, el LSN de deshacer y el LSN anterior son los mismos.
Ahora suponga que hay un error del sistema y, durante la recuperación de reinicio, se debe revertir toda la transacción. El código de recuperación lee el registro 6. Los datos del registro 6 indican que el registro 6 es un registro normal (no clR), por lo que el código de recuperación revierte la actualización 6. A continuación, el código de recuperación inspecciona el LSN de undo-next del registro 6 y encuentra que apunta al registro 4'. Los datos del registro 4' indican que es un CLR, por lo que el código de recuperación no revierte la actualización 4' . En su lugar, inspecciona el LSN de undo-next del registro 4' y encuentra que apunta al registro 3. El registro 3 no es CLR, por lo que el código de recuperación revierte la actualización 3. Novedades 5 y 4 no se revierten durante la recuperación porque ya se han revertado durante el procesamiento de reenvío normal. Por último, el código de recuperación revierte las actualizaciones 2 y 1.
Las flechas del diagrama siguiente muestran cómo el LSN de deshacer a continuación proporciona un mecanismo que el código de recuperación puede usar para omitir los registros cuyas actualizaciones ya se han revertido.
