Hola a todos, en entradas anteriores veíamos cómo se podía comprobar en qué fecha se realizó el último CHECKDB. En esta ocasión vamos a explicaros cómo realizar un DBCC CHECKDB en SQL Server.
Para empezar, debemos saber qué realiza, y para qué nos puede servir. Cuando hablamos de CHECKDB, realmente estamos hablamos de la instrucción «DBCC CHECKDB» nativa de SQL Server. Como vemos en la documentación oficial, su sintaxis es la siguiente:
DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]
Opciones de ejecución de DBCC CHECKDB
Aunque tenga varias opciones, principalmente se podría resumir en 3 modos, que son los más comunes y que detallaremos a continuación:
Ejecución sin parámetros
Este tipo de ejecución, sería el primer paso. En ella chequea la base de datos, tanto de manera física (ficheros de la base de datos en el disco duro), como de manera lógica (por ejemplo, la coherencia en los datos e índices). Este sería el primer paso a realizar. Su función se limita a chequear la base de datos, pero no los corrige, solo informa de ellos en caso de haberlos. La forma de ejecutarlo, sería:
DBCC CHECKDB ('DatabaseName')
Esta operativa, carga bastante el servidor y tarda en realizar los chequeos en las bases de datos. Cuanto más grande sea, más tardará. Aun así, es importante programar la tarea periódicamente para poder tener tiempo de reacción en caso de que haya errores. Por ejemplo, una vez a la semana, los fines de semana cuando haya menos carga.
Reparar errores con DBCC CHECKDB
Si tras ejecutar el comando anterior, se han detectado errores, habría que reparar la base de datos. Para ello, podemos intentar restaurar el último backup y comprobar nuevamente que se ha corregido. O bien intentar repararla añadiendo parámetros al checkdb. En cualquiera de los casos, necesitaríamos hacer un backup de la base de datos actual.
Una vez hecho el backup, primero intentaremos reparar la base de datos con la opción «REPAIR_REBUILD«. Esta opción intentará corregir pequeños errores, sin pérdida de datos.
En caso de que con la opción «REPAIR_REBUILD» no sea suficiente, habría que intentar la reparación con la opción «REPAIR_ALLOW_DATA_LOSS«. Como su nombre indica, pueden producirse pérdidas de datos, por lo que ha de usarse como último recurso. El hecho de usar la opción «REPAIR_ALLOW_DATA_LOSS» no implica que sí o sí vayan a perderse datos. Pero sí que es posible que se pierdan, por lo que hay que usarlo sabiendo los riesgos a los que nos enfrentamos.
Esperamos que tras este artículo, hayas podido recuperar tu base de datos. Si prefieres que lo intentemos nosotros, o quieres que lo incluyamos en tu entorno con un plan de mantenimiento, contacta con nosotros.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn