La restauración de la página en línea alcanza el límite de 1000

Se me ha encomendado la tarea de intentar recuperar una base de datos que sufrió daños (debido a un error de E / S, que se ha solucionado desde entonces). No estoy familiarizado con la base de datos o lo que contiene.

Me dieron una copia de seguridad completa antigua (~ 3 semanas) y una serie de registros de transacciones ... sin embargo, faltan registros de transacciones, por lo que solo puedo recuperar hasta una fecha determinada. Faltan aproximadamente 2.5 semanas de datos (y se agregan muchos datos a esta base de datos constantemente).

También me han dado una copia de la base de datos corrupta (que es accesible, pero con muchas páginas corruptas / faltantes).

He probado los DBCC CHECKDBcomandos típicos (todavía no repair_allow_data_loss, ese será mi último recurso si nada más funciona).

Después de que muchos van y vienen a la base de datos (el db es un pequeño monstruo de 1.5 terabytes y todo lo que hago es lento y lleva un tiempo), he intentado hacer una restauración de página en línea desde la última copia de seguridad buena conocida para las páginas corruptas.

Para hacer eso, hice un script que crea muchos RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'comandos a partir de la DBCC CHECKDBsalida (básicamente, una expresión regular y una distintiva) ... hasta ahora tan bueno, funcionó hasta un punto en el que decía que había alcanzado un límite de 1000 páginas. por archivo (hay 8 archivos en esta base de datos) por comando de restauración.

Entonces me pide que "complete la restauración en línea", pero no sé cómo hacerlo ... No tengo un registro de cola ni nada más completo que la copia de seguridad completa con la que estoy comenzando, así que Básicamente no sé cómo completar la restauración para seguir intentando con el resto de páginas.

He intentado un RESTORE DATABASE <foo> WITH RECOVERYpero que tampoco funcionó, me pide un registro que no tengo.

¿Alguien tiene algún consejo sobre cómo podría intentar recuperar algo de aquí? ¿O cómo "completar" la restauración en línea para poder seguir intentando recuperar más páginas? ¿Tendría el mismo problema si intento una restauración sin conexión (básicamente agrego WITH NORECOVERYa todo y luego trato de recuperarlo al final)?

Trabajar la base de datos a mano es básicamente imposible de deshacer ... hay cientos de tablas con millones de filas y no hay un significado claro de cuáles son. La base de datos corrupta fallará en las SELECTconsultas después de un millón de filas, pero no estoy seguro de poder averiguar dónde. Intenté reconstruir todos los índices no agrupados, pero hay páginas corruptas con datos de fila, por lo que tampoco funcionó.

Alguna pérdida de datos sería aceptable, pero la coherencia en la base de datos debería al menos intentar alcanzarse.

La base de datos corrupta está todavía en línea y los clientes están trabajando en ella (por lo que sigue obteniendo datos nuevos), por lo que cualquier proceso que realice en el banco de laboratorio debería ser reproducible en la base de datos de producción después (el tiempo de inactividad será difícil).

Esto es SQL Server 2014 Enterprise

PD: No soy un DBA ... Soy un programador, pero el cliente ha probado algunos servicios de recuperación de desastres sql "expertos" y se han rendido, así que me han pedido que lo vea y vea si puedo hacer nada.

Actualización : después de muchas pruebas, la restauración de página por página fue imposible, por lo que hemos abandonado la idea. Vamos a realizar una recuperación manual (seleccionando manualmente los registros que faltan de las tablas corruptas e insertándolos en la última copia de seguridad válida conocida), haciendo algunas herramientas automatizadas para ello (de nuevo, hay cientos y cientos de tablas).

El procedimiento estándar sería:

1. Obtenga las ID de página que deben restaurarse.
2. Inicie una restauración de página con una base de datos completa.
3. Aplique la copia de seguridad diferencial más reciente.
4. Aplicar copias de seguridad de registros posteriores.
5. Crear nueva copia de seguridad de registro.
6. Restaurar la nueva copia de seguridad lob.

Una vez que se ha aplicado la nueva copia de seguridad del registro, se completa la restauración de la página y las páginas se pueden usar.

Restauración de ejemplo

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

Referencia: Restaurar páginas (SQL Server) (Microsoft Docs) Referencia: RESTAURAR declaraciones (Transact-SQL) (Microsoft Docs)

Sin embargo, tiene agujeros en sus copias de seguridad de TLOG, y la restauración con el procedimiento anterior podría devolver su base de datos a un estado en el tiempo que no desea.

Estás en una situación complicada.

1. Su base de datos tiene páginas corruptas y su empresa agrega constantemente nuevos datos a una base de datos con problemas. Esto podría resultar en un tiempo de inactividad total de la base de datos. ¿Es usted quiere correr el riesgo de que?

2. Alguien será considerado responsable y cuanto más intente arreglarlo, mayor será la inclinación de la gerencia a decidir que usted puede ser esa persona al final. ¿Es usted quiere correr el riesgo de que?

3. Te estás poniendo en una situación difícil al asumir un papel para el que no estabas empleado. Está tratando de lograr algo que ni los DBA de su empresa ni su consultor externo fueron capaces de hacer. Si bien puede parecer un gesto noble, te estás poniendo en riesgo. Es posible que haya "prometido implícitamente" algo que nunca podrá cumplir. ¿Es usted quiere correr el riesgo de que?

4. Cuando alguien que trabaja con la base de datos consulta datos dañados, posiblemente recibirá un mensaje de error. El trabajo diario ya está siendo afectado. Cuanto más espere con lo inevitable, más se verá afectada la productividad. ¿Es usted quiere correr el riesgo de que? (Esta pregunta también podría plantearse con la gerencia)

5. El procedimiento de copia de seguridad de su empresa parece estar defectuoso (de lo contrario, ¿cómo faltarían las copias de seguridad de TLOG?) Y todavía está ejecutando su base de datos de producción como si no hubiera problemas. ¿Es usted quiere correr el riesgo de que?

¡La mejor recomendación que puedo darle es detener la producción y llamar a Microsoft! O al menos llame a Microsoft y posiblemente detenga la producción.

Si bien mi escritura puede parecer demasiado cautelosa y ligeramente dramatizada desde su perspectiva, personalmente puedo relacionarme con una experiencia como DBA donde los datos se perdieron en una situación similar. Nosotros sólo se perdió la mitad de los datos de días, pero tuvimos que volver a sincronizar una gran cantidad de datos con los sistemas circundantes .

Cuanto más espere, más costosa será la recuperación.

En cuanto a la limitación en las restauraciones de la página, aquí una cita de la documentación oficial:

El número máximo de páginas que se pueden restaurar en cualquier archivo individual en una secuencia de restauración es 1000 . Sin embargo, si tiene más de un pequeño número de páginas dañadas en un archivo, considere restaurar todo el archivo en lugar de las páginas.

^{( énfasis mío)}

Referencia: RESTAURAR declaraciones - Argumentos (Transact-SQL) (Microsoft Docs)

Cuando todo vuelva a la normalidad, los DBA y / o consultores externos pueden considerar implementar una política / procedimiento de copia de seguridad / restauración diferente para su base de datos. Como tiene que estar activo 7x24, no puede arriesgarse a tener un procedimiento de respaldo que no brinde capacidades de restauración adecuadas para cualquier situación.

Veo que ha probado diferentes métodos, incluido trabajar con "expertos" en recuperación de datos para reparar esta base de datos corrupta, especialmente con un tamaño superior a 1 TB. Esto hace que el proceso sea mucho más difícil y una carrera contra el tiempo. Como un DBA experimentado, me he encontrado con situaciones similares donde la mayoría de las veces, hay buenas copias de seguridad disponibles para restaurar. En el caso de heredar copias de seguridad incorrectas y bases de datos corruptas, he confiado mucho en una herramienta de terceros llamada Stellar Phoenix SQL Database Repair tool . Esta herramienta es conocida por reparar bases de datos corruptas (.mdf y .ndf). A continuación se detallan las pocas funcionalidades de la herramienta:

• Repara archivos corruptos de la base de datos SQL (.mdf y .ndf)
• Recupera tablas, disparadores, índices, claves, reglas y procedimientos almacenados.

• Realiza la recuperación de registros eliminados de la base de datos SQL

• Guarda el resultado del escaneo de la base de datos para realizar la recuperación en una etapa posterior

• Permite guardar archivos reparados en formatos MSSQL, HTML, XLS y CSV
• Admite MS SQL Server 2016, 2014, 2012,2008 y versiones anteriores

La herramienta requiere que los archivos .mdf y .ndf estén fuera de línea, por lo que funciona muy bien que tenga una copia de la base de datos PROD corrupta y no tenga que detener los servicios de SQL Server.

La mejor parte es que la versión de prueba le proporciona la funcionalidad completa de la herramienta, excepto que la base de datos reparada no se puede exportar / guardar. Aún podrá ver todos los objetos de la base de datos recuperados y el extenso archivo de registro de reparación que proporciona detalles sobre las diferentes etapas del proceso de reparación.

Siéntase libre de descargar y ver si ayuda. Descarga aquí

También escribí un blog sobre cómo funciona la herramienta en este sitio: samosql blogs

¡Gracias y HTH por hacerte el HÉROE del día!

PD. Cuando termine esta tormenta, recuerde decirle a la gerencia que debe haber una revisión importante de sus procedimientos de respaldo, especialmente para dicha base de datos. ¡Una repetición de este escenario es totalmente inaceptable! :)