Números de secuencia de registro y planeamiento de la restauración
Este tema es relevante para las bases de datos de SQL Server que utilizan el modelo de recuperación completa.
Para planear la restauración, los números de secuencia de registro (LSN) más importantes son el primero y el último. Los LSN pueden obtenerse en las ubicaciones siguientes:
La tabla backupset en msdb. Las columnas se denominan first_lsn y last_lsn.
La instrucción RESTORE HEADERONLY. Las columnas se denominan FirstLSN y LastLSN.
En la tabla siguiente se definen estos términos para copias de seguridad diferentes.
Término |
Definición |
|---|---|
first_lsn o FirstLSN |
Número de secuencia de registro de la primera entrada de registro del conjunto de copia de seguridad o de la más antigua. En copias de seguridad diferenciales o de datos, el primer LSN identifica el primer registro que se necesita para realizar la recuperación con esta copia de seguridad. En copias de seguridad de registros, el primer LSN identifica el primer registro incluido en la copia de seguridad. |
last_lsn o LastLSN |
Número de secuencia de registro del siguiente registro después del conjunto de copia de seguridad. El último LSN identifica el siguiente registro posterior al final de la copia de seguridad. En copias de seguridad diferenciales o de datos (y en copias de seguridad de registros que contienen operaciones de registro masivo), la puesta al día debe llegar, al menos, hasta este LSN. Si no fuera así, los datos copiados durante la restauración serían incoherentes. Las copias de seguridad de registros incluyen registros hasta este LSN, pero sin incluirlo. |
Números de secuencia de registro y copias de seguridad diferenciales o de datos
En las copias de seguridad diferenciales o de datos, los datos del registro entre first_lsn y last_lsn se incluyen en la copia de seguridad. Esto permite que se utilice la copia de seguridad sin copias de seguridad de registros para recuperar hasta last_lsn.
En las copias de seguridad diferenciales o de datos, last_lsn es el primer punto de recuperación posible si utiliza la copia de seguridad en una secuencia de restauración. Si se necesita un punto de recuperación anterior, debe utilizarse una copia de seguridad anterior.
Al planear qué copia de seguridad de registros se debe utilizar para la puesta al día tras la restauración de una copia de seguridad diferencial o de datos, normalmente se empieza con la primera copia de seguridad de registros tras esa copia de seguridad diferencial o de datos. Al examinar las propiedades de la copia de seguridad, encontrará una copia de seguridad de registros cuyo first_lsn es menor o igual que el last_lsn de la copia de seguridad diferencial o de datos, y cuyo last_lsn es mayor que el last_lsn de la copia de seguridad de registros diferencial o de datos.
Números de secuencia de registro y copias de seguridad de registros en una cadena de registros
Una cadena de registros nueva comienza por la primera copia de seguridad de base de datos completa realizada tras la creación de la base de datos o tras el cambio del modelo de recuperación simple al de recuperación completa o al de recuperación optimizado para cargas masivas de registros. En la primera copia de seguridad de registros de una cadena, backupset.begins_log_chain = 1.
Los valores first_lsn y last_lsn se utilizan para vincular copias de seguridad de registros en una secuencia consecutiva (cadena de registros). Puede utilizar una secuencia de copias de seguridad de registros consecutivas para poner al día una base de datos a partir de la copia de seguridad diferencial o de datos más reciente, o bien a partir de una copia de seguridad más antigua después de realizar copias de seguridad diferenciales y de datos dañadas o que no se pueden encontrar.
En una copia de seguridad de registros, first_lsn es el LSN de la primera entrada de registro de la copia de seguridad y, empezando con esta entrada, esta copia de seguridad contiene las entradas de registro que van hasta la entrada de registro cuyo LSN es last_lsn, sin incluirla. Dos copias de seguridad de registros son consecutivas sólo si el LSN de la última entrada de registro de la primera copia de seguridad (Backup_A) es mayor o igual que el LSN de la primera entrada de registro de la copia de seguridad siguiente (Backup_B); es decir, Backup_A.last_lsn >= Backup_B.first_lsn. Si esta condición no se cumple, existe una discontinuidad entre las dos copias de seguridad.
La importancia de la relación existente entre estos LSN se explica a continuación:
A.last_lsn = B.first_lsn
Si A.last_lsn = B.first_lsn, B suele ser la copia de seguridad de registros realizada inmediatamente después de A.
Esta relación se muestra en la ilustración siguiente. Tenga en cuenta que la entrada de registro n, que tiene lugar en la copia de seguridad de registros B, se registró como last_lsn en la copia de seguridad de registros A y como first_lsn en la copia de seguridad de registros B.
.gif "last_lsn de la copia de seguridad de registros A=first_lsn de la copia de seguridad de registros B")
A.last_lsn > B.first_lsn
Si A.last_lsn > B.first_lsn, existe una superposición. Una superposición así suele provenir de la creación de una copia de seguridad de registros sólo de copia o de la primera copia de seguridad de registros realizada tras una recuperación a un momento dado. La superposición puede implicar varias bifurcaciones en la recuperación. Para obtener más información, vea Rutas de recuperación.
Causas de cadenas de registros rotas
En general, SQL Server Database Engine (Motor de base de datos de SQL Server) evita discontinuidades en la secuencia de las copias de seguridad de registros y mantiene la cadena de registros intacta. Sin embargo, un administrador de base de datos puede romper la cadena de registros si cambia el modelo de recuperación de simple a completa o por medio de registros de operaciones masivas.
No se pueden poner al día cambios en el modelo de recuperación simple, ya que la cadena de registros se rompería. Después de efectuar el cambio al modelo de recuperación completa o al de recuperación optimizado para cargas masivas de registros, debe tomar una nueva base diferencial o conjunto de bases diferenciales. También puede utilizar copias de seguridad diferenciales para cubrir una discontinuidad.
Vea también