Reparación de páginas inconsistentes en la base de datos

Tenemos un SQL 2000 DB. El servidor se bloqueó debido a una falla de la matriz Raid. Ahora cuando ejecutamos DBCC CHECKDB, recibimos un error de que hay 27 errores de consistencia en 9 páginas.

Cuando ejecutamos DBCC PAGE en estas páginas, obtenemos esto:

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

Dado que el índice indicado no está agrupado y se crea mediante una constarint única que incluye 2 columnas, intentamos soltar y recrear el índice. Esto dio como resultado el siguiente error:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

Sin embargo corriendo

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

devuelve 0 filas.

Esto es lo que estamos planeando hacer:

Restaure una copia de seguridad de la base de datos previa al servidor y ejecute DBCC CHECKDB
Si eso vuelve limpio, luego restaure nuevamente sin recuperación
Aplicar todas las copias de seguridad de TLOG subsiguientes
Detenga la aplicación de producción, realice una copia de seguridad del registro de cola y aplíquela también
Suelte la base de datos prod y cambie el nombre de la base de datos recién restaurada para que sea prod
Iniciar aplicación prod

¿Podría alguien hacer agujeros en este enfoque? Tal vez, sugiera un enfoque diferente? Lo que necesitamos es un tiempo de inactividad mínimo.

SQL 2000 DB Tamaño 94 GB La tabla que tiene páginas corruptas tiene 460 millones + filas de datos

Gracias por la ayuda.

Raj

sql-server dbcc

Me gusta tu enfoque. Tiene sentido para mi. Tal vez mantenga la base de datos dañada a un lado, como un seguro ...

— user24161

Además, cuando las cosas se

— calmen

(es decir, actualización de 2005 o 2008)

— user24161

+1 por tener un plan de recuperación válido y muy adecuado

— Andrew

Respuestas:

Su solución de recuperación es la forma de proceder del libro de texto. Suponiendo que tiene copias de seguridad apropiadas y siempre que pueda hacer una copia de seguridad del registro de transacciones para la base de datos corrupta, su estrategia es el libro de texto que debe implementar.

Sin embargo, antes de continuar, ¿ha considerado la posibilidad de recrear únicamente la tabla afectada?

A veces puede salirse con la suya creando una copia exacta de la tabla afectada haciendo un

select *
into NewTableFromOld
from DamagedTable

Luego simplemente suelte / cambie la tabla dañada con la nueva, recordando agregar restricciones e índices apropiados.

— John Sansom
fuente

Gracias por la respuesta. Su enfoque se ve bien, pero la preocupación es que, teniendo en cuenta que la tabla tiene 461 millones de filas de datos, ¿cuál sería el impacto en la producción cuando hago una selección *? ¿No sería eso una cerradura y golpear el rendimiento?

No si utiliza la consulta con (nolock) pista no. Sin embargo, es posible que desee validar que nada ha cambiado entre la tabla de origen y la de destino mientras tomó la copia. Sin embargo, es probable que esto sea necesario durante la compilación de la tabla si no evita que la aplicación realice cambios. Habrá una sobrecarga en el rendimiento del disco en dicha operación.

— John Sansom

Personalmente, probaría este enfoque primero, puede hacerlo con la opción nolock para probar, también puede verificar el tiempo requerido. Si funciona como debería, pondría el db en modo de usuario único mientras lo volviera a hacer, para asegurarme de que no ocurran cambios mientras se ejecuta el proceso. El tiempo de inactividad será mucho más corto durante este enfoque, si funciona.

— calvo

Si va a hacer esto, le recomendaría crear primero la tabla (mediante un script de la tabla original). Luego use "INSERT INTO en newTable SELECT" frente a "SELECT INTO". Puede encontrarse con problemas de rendimiento con un "SELECCIONAR EN".

— SQL3D

Primero intentaría agrupar los datos para archivarlos y luego volver a agruparlos en una nueva tabla. SELECT INTO no es apropiado (IMO) para ese número de registros ...

— m4rty
fuente