No se puede restaurar (error 3456)

9

Tengo una situación que no es fácil de resolver, y pensé en preguntar en este foro si otros podrían tener sugerencias.

Estoy ejecutando SQL Server 2008 R2 Standard SP3 en Windows Server 2008R2 Enterprise.

Una base de datos necesitaba un poco de mantenimiento, y después del hecho, necesitaba restaurar en otro servidor. Tengo una copia de seguridad de db completa con COPY_ONLY más un conjunto de 4 copias de seguridad de tlog.

  1. antes de comenzar, cree tlogbackup1
  2. cambiar de FULLal BULK_LOGGEDmodelo de recuperación
  3. agregar nuevo grupo de archivos
  4. agregar archivo a newfilegroup
  5. establecer newfilegroup como predeterminado
  6. seleccionar en la tabla (en newfilegroup)
  7. soltar la mesa original
  8. eliminar archivo original
  9. eliminar grupo de archivos original
  10. cambiar el nombre de la nueva tabla para que coincida con la tabla original
  11. cambiar el nombre de archivo del grupo de archivos nuevos para que coincida con el grupo de archivos original
  12. cambiar el nombre del archivo en el catálogo para que coincida con el nombre del archivo original
  13. cambiar el nombre del archivo a nivel del sistema operativo para que coincida con el nombre del archivo original
  14. configura el grupo de archivos predeterminado para que sea el original
  15. traer db en línea
  16. cambiar de BULK_LOGGEDal FULLmodelo de recuperación
  17. Después de completar todos los pasos, cree tlogbackup2

La restauración de todas las copias de seguridad debe usarse WITH MOVE, debido a los cambios de letra de unidad en el servidor de restauración.

Pasos de recuperación:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

La restauración final de tlog llega al 100% y luego falla con el error 3456:

Se procesaron 368 páginas para la base de datos 'SomeDB', archivo 'SystemData' en el archivo 1.

Se procesaron 7656520 páginas para la base de datos 'SomeDB', archivo 'SystemDataPDS' en el archivo 1.

Se procesaron 172430 páginas para la base de datos 'SomeDB', archivo 'SystemData_log' en el archivo 1.

Msg 3456, Nivel 16, Estado 1, Línea 1
No se pudo rehacer el registro de registro (210388: 123648: 232), para ID de transacción (0: 1016710921), en la página (4: 8088), base de datos 'SomeDB' (ID de base de datos 6) . Página: LSN = (0: 0: 1), tipo = 11. Registro: OpCode = 4, contexto 11, PrevPageLSN: (210388: 122007: 1). Restaurar desde una copia de seguridad de la base de datos, o reparar la base de datos. Msg 3013, Nivel 16, Estado 1, Línea 1 RESTORE LOG está terminando anormalmente.

Solo para verificar que la copia de seguridad db completa estaba bien, restauré la CHECKDBejecución y no hubo errores.

Todos los comentarios son bienvenidos.

Gracias por adelantado,

Nutria Ned

sql-server sql-server-2008-r2 recovery restore NedOtter
fuente
1
¿Podría explicar por qué cree que tiene una cadena de registro ininterrumpida? En el momento en que cambiaste la base de datos al modo BULK_LOGGED y comenzaste a jugar con el esquema, todas las apuestas para que la cadena de registro esté intacta están desactivadas.
Thomas Kejser
Gracias por tu respuesta, Thomas. Ahora veo que el título de mi publicación era incorrecto. No necesito un punto en el tiempo de recuperación, pero una restauración completa al final de la cuarta copia de seguridad de tlog. Por lo tanto, configurar BULK_LOGGED no debería haber causado ningún problema con eso. No veo cómo lo que hice habría causado el fallo de la segunda copia de seguridad de tlog: SQL Server admitió todos los comandos, y ejecuté exactamente los mismos pasos (aunque no en los mismos datos) en una base de datos más pequeña, y pude para restaurar la segunda copia de seguridad de tlog sin problemas.
NedOtter
El error parece corrupción. Es un error interno. ¿Se puede verificar la integridad de todos los archivos de respaldo? ¿Están con sumas de verificación?
usr
Verifiqué que la copia de seguridad db completa tenía 0 errores ejecutando CHECKDB. Tendré que comprobar si se utilizó CHECKSUM.
NedOtter
1
Si las copias de seguridad tienen la suma de verificación habilitada, entonces también debería usar la suma de verificación para la restauración. El tipo de página 11 es una página PFS, lo que significa que no puede solucionarlo, solo puede hacer una restauración completa. Además, no dice cuándo se tomó la copia de seguridad de solo copia. ¿Dónde estaba ese respaldo en la línea de tiempo?
Robert L Davis

Respuestas:

9

Para entender por qué se lanzaría el error 3456, debemos dar un pequeño paso atrás y comprender cómo SQL Server maneja este rincón de recuperación.

Cuando SQL Server está rehaciendo una operación, y esa rehacer es una modificación de página, realiza una comprobación rápida. En el encabezado de la página, finalmente habrá un PageLSN, que es una indicación del último LSN que ha modificado esa página, registrada por la página. Piénselo así, la página realiza un seguimiento del último LSN que le hizo modificaciones. Este es el PageLSN.

Cada vez que hay una operación de modificación de página registrada, ese registro de registro incluye algunos LSN. A saber, el registro de registro LSN (piense ... LSN actual ), y luego tiene lo que se llama la página anterior LSN ( PrevPageLSNen adelante). Entonces, cuando modificamos una página, uno de los datos que se coloca en el registro es lo que la página indica como el último LSN antes de que haya modificado la página .

Piénselo de esta manera ... Su automóvil necesita que se le haga un trabajo. El mecánico John trabaja en su automóvil, y en el compartimento del motor tiene una pequeña etiqueta y el mecánico John escribe "John trabajó en este automóvil por última vez". Luego, la próxima vez que lleve su automóvil a otra tienda, el mecánico Mark mira en el compartimento del motor y ve que el mecánico John trabajó en este automóvil por última vez. En su hoja de datos escribe esta información. La misma idea con SQL Server.

Esto puede ser algo confuso, por lo que echar un vistazo a esta imagen a continuación en las modificaciones de páginas secuenciales, y cómo el PageLSNy PrevPageLSNse relacionan:

ingrese la descripción de la imagen aquí

Retrocedamos, ya que todo esto entra en juego cuando necesita rehacer una operación en una página (restauraciones, recuperación, HA, etc.). Cuando SQL Server necesita rehacer una operación de página, realiza una comprobación de estado para ver si PageLSNla página coincide con la PrevPageLSNque incluye el registro de registro. Si eso no es igual, verá que se arroja el error 3456.

¿ PageLSN es igual a PrevPageLSN ? ¿¿¿No??? Parar y elevar el error 3456 ...

Analicemos su mensaje de error, que incluye el cómo:

No se pudo rehacer el registro de registro (210388: 123648: 232), para el ID de transacción (0: 1016710921), en la página (4: 8088), la base de datos 'SomeDB' (ID de base de datos 6). Página: LSN = (0: 0: 1) , tipo = 11. Registro: OpCode = 4, contexto 11, PrevPageLSN: (210388: 122007: 1) . Restaurar desde una copia de seguridad de la base de datos, o reparar la base de datos. Msg 3013, Nivel 16, Estado 1, Línea 1 RESTORE LOG está terminando anormalmente.

He en negrita las dos piezas de datos que tienen una desigualdad que causa el error. Puede ver que nuestro PageLSNes 0: 0: 1 (esto se encontró en el encabezado de la página), y nuestro PrevPageLSNes 210388: 122007: 1 (esto se encontró en los datos en el registro de registro que intentaba rehacerse). Estos obviamente no son iguales, por lo tanto, err3456.

Entonces, para descubrir el por qué de este evento, sería descubrir por qué hay una disparidad aquí. Realmente necesitamos rastrear el ciclo de vida de la página 4: 8088 y ver dónde está la desconexión. Desafortunadamente, sin más información o solución práctica de problemas, no hay mucho más que pueda hacer además de brindarle los antecedentes de esta operación de recuperación y qué causa el error.

Thomas Stringer
fuente
Sé que ha pasado un tiempo pero aún así ... cosas buenas, ¡gracias por la explicación detallada!
RThomas