Planear una secuencia de restauración por etapas para un archivo en el estado de restauración, recuperación pendiente o sin conexión
Este tema es relevante sólo para bases de datos de SQL Server que contienen varios grupos de archivos (y, en el modelo simple, sólo para grupos de archivos de sólo lectura) cuando se planea una recuperación por etapas de una base de datos.
Si una secuencia de restauración incluye un archivo en el estado de restauración, recuperación pendiente o sin conexión, es posible que pueda recuperar el archivo sin restaurar sus datos. Para determinar si debe restaurar una copia de seguridad completa del archivo o si puede simplemente recuperar el archivo, puede usar metadatos almacenados en en las vistas de catálogo sys.database_files y sys.master_files.
LSN de puesta al día
El primer paso consiste en inspeccionar las columnas de vista de catálogo que contienen los LSN de puesta al día: redo_start_lsn, redo_start_fork_guid, redo_target_lsn y redo_target_fork_guid. La siguiente tabla describe los LSN de puesta al día y cómo interpretarlos.
Columnas |
Descripción |
---|---|
redo_start_lsn y redo_start_fork_guid |
Juntas, estas columnas describen un par (lsn,guid) que representa el punto en el tiempo del archivo. Conforme se pone al día el archivo, los valores de estas columnas cambian. La puesta al día continúa a partir de este punto.
Importante
Si redo_start_lsn = NULL, el estado en disco del archivo es desconocido y se debe restaurar a partir de una copia de seguridad completa.
|
redo_target_lsn y redo_target_fork_guid |
Juntas, estas columnas describen un par (lsn,guid) que define el punto de recuperación al que el archivo debe restaurarse para ser coherente con la base de datos en línea (el punto de recuperación de destino). |
Decidir si usar sys.database_files o sys.master_files
Las vistas de catálogo sys.database_files y sys.master_files contienen las columnas LSN de puesta al día, pero estas vistas no son siempre coherentes. En general, si la base de datos está en línea, los valores de sys.database_files y sys.master_files son coherentes. Sin embargo, los valores serán incoherentes en las siguientes situaciones:
Si la base de datos es de sólo lectura, sys.database_files no se actualiza con los cambios causados por la copia de seguridad y sólo sys.master_files contiene información actualizada.
[!NOTA]
Para saber si un archivo es de sólo lectura, examine las columnas is_read_only y read_only_lsn. is_read_only indica si el archivo es de sólo lectura. Si lo es, read_only_lsn es el punto en el que el archivo pasa al estado de sólo lectura.
Si la base de datos está sin conexión (por ejemplo, cuando se está restaurando), no se puede obtener acceso al catálogo de la base de datos. En el caso de una base de datos sin conexión, debe utilizar sys.master_files para obtener información.
Si una operación de restauración afecta al archivo, los LSN de puesta al día del archivo se actualizan y son incoherentes. Debería examinar las columnas LSN de puesta al día sólo entre restauraciones.
Interpretación de estas columnas
[!NOTA]
En esta sección se supone que está familiarizado con los conceptos "ruta de recuperación" y "bifurcación de recuperación". Para obtener más información, vea Rutas de recuperación.
Esta sección sólo es relevante si ha realizado una recuperación a un momento dado y todavía tiene copias de seguridad de alguna ruta de recuperación inactiva. Cuando restaura un archivo en el estado de restauración, recuperación pendiente o sin conexión, las bifurcaciones de recuperación son relevantes. Con el análisis de las bifurcaciones de recuperación, puede identificar las rutas de recuperación potenciales. En general, una ruta de recuperación será claramente mejor para recuperar la base de datos.
Para identificar la mejor ruta de recuperación, debe averiguar si el archivo está en la bifurcación de recuperación de destino o en una bifurcación de recuperación distinta:
El archivo está en una bifurcación de recuperación diferente.
Si redo_start_fork_guid != redo_target_fork_guid no es un antecesor de redo_target_fork_guid, el archivo se encuentra en una bifurcación de recuperación diferente de la bifurcación de destino.
[!NOTA]
Para buscar una bifurcación antecesora, siga la cadena del registro hacia atrás. Para obtener más información, vea Rutas de recuperación.
En este caso, el archivo se debe restaurar a partir de una copia de seguridad completa. Esta restauración sitúa el archivo en un punto que es un antecesor válido del punto de recuperación actual de la base de datos.
[!NOTA]
Para restaurar un archivo, la copia de seguridad del mismo debe ser un antecesor del punto de recuperación de la base de datos. Utilice siempre la copia de seguridad completa más reciente del archivo. Los datos se deben poner al día hasta el punto de destino. La única excepción es que la copia de seguridad de un archivo de sólo lectura no tiene que ponerse al día si el archivo era de sólo lectura ya antes de realizar la copia de seguridad. Si es necesario, después de restaurar la copia de seguridad de archivos, restaure una copia de seguridad diferencial de archivos, si las hay, y copias de seguridad de registros para poner el archivo en el punto de recuperación de destino.
El archivo se encuentra en la bifurcación de recuperación actual (de destino) o es un antecesor de la bifurcación de destino.
[!NOTA]
Si ha realizado una copia de seguridad del archivo desde la recuperación de la base de datos, el archivo se encuentra en la bifurcación de recuperación de destino.
En estos casos, si el archivo se debe restaurar o no depende de la relación de redo_start_lsn con redo_target_lsn, como se explica en la tabla siguiente.
Si...
Entonces...
redo_start_lsn =redo_target_lsn
No es necesario restaurar el archivo.
El archivo es coherente con la base de datos y se puede poner en línea sin utilizar RESTORE DATABASE database_name WITH RECOVERY.
redo_start_lsn <redo_target_lsn
Para poder poner el archivo en línea, la puesta al día debe llegar a redo_target_lsn.
redo_start_lsn >redo_target_lsn
La base de datos es anterior al archivo. Se debe restaurar el archivo a partir de una copia de seguridad completa (o se puede restaurar de nuevo la base de datos a un punto posterior en el tiempo con otra secuencia de restauración parcial).
NotaEsta situación puede darse sólo en una restauración sin conexión, porque tan pronto como se recupera el grupo de archivos principal, se genera una nueva bifurcación de recuperación. Los grupos de archivos secundarios no recuperados no están ya en la misma ruta de recuperación que el grupo de archivos principal.
[!NOTA]
Después de restaurar copias de seguridad de una de esas rutas de recuperación, las rutas de recuperación alternativas ya no será válidas. Las copias de seguridad que son específicas de una ruta de recuperación no válida quedarán inactivas. Una práctica recomendada es eliminar las copias de seguridad inactivas o ponerlas aparte y marcarlas claramente como inactivas.
Vea también