Comando DBCC CHECKDB
Cuando
iniciamos la serie de Comandos DBCC
se mencionó que este es el comando más conocido y utilizado por los DBA
y que este comando pertenece a los clasificados de validación, asimismo se
indicó que este comando comprueba la integridad física y lógica de todos los
objetos de la base de datos especificada mediante la realización de las
siguientes operaciones:
· Se
ejecuta DBCC CHECKALLOC en la base de datos.
· Se
ejecuta DBCC CHECKTABLE en cada tabla y vista en la base de datos.
· Se
ejecuta DBCC CHECKCATALOG en la base de datos.
· Valida
el contenido de cada vista indizada de la base de datos.
· Valida
la coherencia de nivel de vínculo entre los archivos y directorios del sistema
de archivos y metadatos de tabla al almacenar varbinary (max) datos del sistema
de archivos con FILESTREAM.
· Valida
los datos de Service Broker en la base de datos.
La sintaxis
de este comando en su forma más simple es:USE database_name;
GO
GO
DBCC
CHECKDB
Como puede
apreciarse no se ha especificado una base de datos, por lo que de ésta forma se
llevara a cabo la integridad física y lógica de todos los objetos de la base de
datos actual, esto es por omisión se tomara la base de datos que se haya
seleccionado, hay que recordar que la base de datos por omisión cuando
accedemos a Microsoft SQL Server, ya sea a través de SQL Server Management Studio o de SQLCMD, es master.La sintaxis que se usa más a menudo es:
USE master;
GO
GO
DBCC
CHECKDB (database_name)
Donde,
database_name es el nombre de la base de datos que se desea validar. Es importante indicar que aunque se puede
indicar el identificador de base de datos (database_id), éste es un número que
está asociado al nombre de la base de datos, por lo que es más común el uso del
nombre de la base de datos.
Existen
algunos argumentos opcionales que pueden ser utilizados con el comando, estos
son:
NOINDEX
|
Especifica que no se
deben realizar comprobaciones intensivas de índices no clúster para las
tablas de usuario.
|
REPAIR_ALLOW_DATA_LOSS
|
Intenta reparar
todos los errores indicados.
|
REPAIR_FAST
|
La sintaxis se
mantiene únicamente por compatibilidad con versiones anteriores. No se
realizan acciones de reparación.
|
REPAIR_REBUILD
|
Realiza reparaciones
que no tienen ninguna posibilidad de pérdida de datos. Este argumento no repara
los errores que implican datos de FILESTREAM.
|
ALL_ERRORMSGS
|
Muestra todos los
errores notificados por objeto. De forma predeterminada, se muestran todos
los mensajes de error. Especificar u omitir esta opción no tiene ningún
efecto.
|
EXTENDED_LOGICAL_CHECKS
|
Si el nivel de
compatibilidad es 100 ( Microsoft SQL Server 2008) o superior, realiza comprobaciones
de coherencia lógica en una vista indexada, en índices XML y en índices
espaciales, en caso de que los haya.
|
NO_INFOMSGS
|
Suprime todos los
mensajes de información.
|
TABLOCK
|
Hace que DBCC
CHECKDB obtenga bloqueos en lugar de utilizar una instantánea de base de
datos interna. Se incluye un bloqueo exclusivo (X) a corto plazo en la base
de datos. TABLOCK hace que DBCC CHECKDB se ejecute más rápido en una base de
datos con mucha carga, pero disminuye la simultaneidad disponible en la base
de datos mientras DBCC CHECKDB está en ejecución.
|
ESTIMATEONLY
|
Muestra la cantidad
estimada de espacio de tempdb que se requiere para ejecutar DBCC CHECKDB con
todas las demás opciones especificadas. No se realiza la comprobación real de
la base de datos.
|
PHYSICAL_ONLY
|
Limita la
comprobación a la integridad de la estructura física de los encabezados de
página y registro y la coherencia de la asignación de la base de datos. Esta
comprobación se ha diseñado para proporcionar una pequeña comprobación de
sobrecarga de la coherencia física de la base de datos; también detecta
páginas rasgadas, errores de suma de comprobación y errores de hardware
comunes que pueden comprometer los datos del usuario.
|
DATA_PURITY
|
Hace que DBCC
CHECKDB compruebe si la base de datos contiene valores de columna que no son
válidos o están fuera del intervalo correcto.
|
MAXDOP = num_of_procs
|
Invalida el grado
máximo de paralelismo opción de configuración de sp_configure para la
instrucción. El MAXDOP puede superar el valor configurado con sp_configure.
|
Ejemplos de DBCC CHECKDB
Mostraré
algunos ejemplos de uso de este comando:
USE master;GO
DBCC CHECKDB (db1, REPAIR_ALLOW_DATA_LOSS)
Este
comando efectuará la comprobación de integridad física y lógica de la base de
datos db1 e intentara reparar las páginas permitiendo la perdida de datos.
USE master;
GO
GO
DBCC CHECKDB (db1) WITH ALL_ERRORMSGS
Este
comando efectuará la comprobación de integridad física y lógica de la base de datos
db1 mostrando todos los mensajes de error, como se ha indicado, el uso del
parámetro ALL_ERRORMSGS no tiene efecto ya que por omisión se muestran todos
los mensajes.
USE master;
GO
GO
DBCC CHECKDB (db1) WITH NO_INFOMSGS
Este comando
efectuará la comprobación de la integridad física y lógica de la base de datos
db1, sin mostrar los mensajes de lo realizado, solo indicara que el comando
termino.
USE master;
GO
GO
DBCC
CHECKDB (db1) WITH ESTIMATEONLY
Este
comando efectuará un estimado de espacio requerido en tempdb para realizar la
comprobación de integridad física y lógica de la base de datos db1.
Comentarios
Si bien,
DBCC CHECKDB nos permite llevar a cabo la reparación de alguna página con
pérdida de datos, se recomienda llevar a cabo la restauración de la base de
datos a partir de una copia de seguridad
que se tenga. Debe tenerse en cuenta que
de no existir una copia de seguridad, entonces proceda con la reparación, pero
recuerde llevar a cabo la copia de seguridad una vez que ha finalizado con las
reparaciones. Se recomienda que la base de datos se establezca en modo de
emergencia mediante el uso de la instrucción ALTER DATABASE, de tal forma que DBCC
CHECKDB pueda realizar algunas reparaciones especiales en la base de datos si
se especifica la opción REPAIR_ALLOW_DATA_LOSS. Estas reparaciones permitirán
que las bases de datos que no se puedan recuperar vuelvan a estar en línea con
un estado físicamente coherente.
Como se ha
establecido, las reparaciones solo deben utilizarse como último recurso y sólo
cuando no se puede restaurar la base de datos a partir de una copia de
seguridad. Cuando la base de datos se establece en modo de emergencia, la base
de datos está marcada como READ_ONLY, el registro está deshabilitado y el acceso
está limitado a los miembros del rol sysadmin. Se recomienda la ejecución de DBCC CHECKCONSTRAINTS para
identificar los errores de lógica de negocios e inmediatamente realizar una
copia de la base de datos una vez que se ha reparado la base de datos.
Hay que
tener presente que si el comando DBCC CHECKDB produce un error, no se puede
reparar la base de datos aunque se utilice el argumento REPAIR_ALLOW_DATA_LOSS.
Muchas gracias por su aporte
ResponderBorrar