DBCC CHECKDB Error "8967" en SQL Server 2005

Me topé con este error por primera vez atendiendo a un cliente, el escenario era el siguiente: Windows 2003 Server SP3 corriendo un SQL Server 2005 SP2 apuntando las BD a unos Storages Hitachi, se cambiaron los storages por unos HP, y en la migración de un storage a otro, las BD se corrompieron, ya que migraron sin tener certificada la comunicación entre el servidor y los storages, en consecuencia, fue necesario reparar las 30 BD para poder dejarlas operativas, y lo típico... ni hablar de respaldos.

Ahora tengo que aclarar una cosa, nunca antes había tenido problemas con ninguno de los comandos DBCC, pero esta vez obtenía error tras error, cabe señalar que el Error “8967” solamente lo vas a ver si tu BD está corrupta, es raro pero cierto, y el error obtenido es:

Msg 8967, Level 16, State 216, Line 1
An internal error occured in DBCC which prevented further processing. Please contact Product Support.
 

Ok, analicemos el asunto, CHECKDB utiliza un snapshop de la BD al momento de analizarla y chequear su consistencia, a las páginas de esta “foto” le asigna un LSN (Log Sequence Number) y al chequear la BD debe asegurarse de que el LSN no sea diferente del que se creo en el snapshop, de ser así, esto supondría que la página fue modificada después de que el snapshop fue creado, por lo tanto CHECKDB estaría trabajando con una vista de la BD inconsistente. Cuando CHECKDB detecta esto, se detiene inmediatamente.

Buscando la forma de poder solucionar este problema encontré que se trata de un BUG del CHECKDB el que bajo ciertas circunstancias en que una página de la BD está corrupta la auditoría interna del CHECKDB falla pero el chequeo del LSN se realiza de todos modos, si la corrupción afecta al LSN estampado en el header de la página entonces se gatilla el error “8967”. A continuación adjunto el error que entrega cuando el LSN ha sido corrompido:

2008-05-22 14:55:01.95 spid53   DBCC encountered a page with an LSN greater than the current end of log LSN (31:0:1) for its internal database snapshot. Could not read page (1:143), database [DatabaseName]
 (database ID 15), LSN = (-1:65535:18), type = 255, isInSparseFile = 0. Please re-run this DBCC command.
2008-05-22 14:55:01.95 spid53   DBCC CHECKDB [DatabaseName] WITH all_errormsgs, no_infomsgs executed by [DomainName]\[User] terminated abnormally due to error state 1. Elapsed time: 0 hours 0 minutes 0 seconds.

El error muestra y detalla que no puede leer el Header de una determinada página dentro del snapshop que toma de la BD, cuando llegamos a este punto pensamos que teníamos todo perdido, pero nos quedaban un par de opciones, según Microsoft podemos correr el comando DBCC CHECKDB acompañado de la opción CONTINUE_AFTER_ERROR, esto lo que hará es chequear consistencia de la BD y si encuentra errores seguirá su ejecución. 

Ahora bien, tranquilos, no está todo perdido, este problema es un bug que en determinadas circunstancias el CHECKDB no puede ejecutarse, ya que por defecto se ejecuta con la BD online y fallará en el control del LSN. Una forma de evitar esto es usando la opción WITH TABLOCK del CHECKDB, esta opción realiza un chequeo de la BD offline y por lo tanto no necesita un snapshop.

Después de unos cuantos días viviendo con estos problemas reparando BD y probándolas, logramos restaurarlas en su 100%, las BD siguieron entregando errores de corrupción (8967) pero las consultas ejecutadas sobre ellas respondían sin problemas ni errores.

Vale la pena señalar que este problema es un caso conocido para Microsoft y aún no han conseguido repararlo. (Ver el articulo KB 960791).

Bueno, resumiendo, no se podrán eliminar los errores de corrupción, pero cuando las opciones CHECKALLOC, CHECKCATALOG y CHECKTABLE no entreguen errores de corrupción y el CHECKDB entregue el error "8967" se debería tender a pensar que la BD está reparada, esto basado en que el error se produce SOLO en BD que ya estan corruptas, por lo tanto, nunca dejaremos de obtener ese error aunque tengamos la BD 100% reparada.

Saludos!