SQL Server DBCC SHRINKDATABASE

Comando DBCC SHRINKDATABASE

Como se estableció, tratándose de un comando de mantenimiento,  cuando mencionamos los Comandos DBCC,  que este comando lleva a cabo la reducción del tamaño de los archivos de datos y de registro de la base de datos especificada.

Es importante mencionar que este comando debe utilizarse cuando se desea la reducción del tamaño de ambos tipos de archivo, de datos y de registro de transacciones de la base de datos, en caso de que se requiera únicamente llevar a cabo sólo uno de los archivos, entonces se recomienda el uso del comando DBCC SHRINKFILE, que veremos posteriormente.

Se recomienda que para obtener la cantidad de espacio disponible actualmente, esto es, espacio sin asignar en la base de datos, se ejecute el procedimiento sp_spaceused.

Es relevante, en este caso, indicar que los archivos se reducen de uno en uno, sin embargo, reduce los archivos de registro de transacciones como si todos estuvieran en un grupo contiguo de registros.

La sintaxis en su forma mas simple es:

USE master;
GO

DBCC SHRINKDATABASE (database_name);

En el comando se indica que se lleve a cabo la reducción del tamaño de los archivos de la base de datos indicada.  Es necesario indicar que aunque se puede indicar el identificador correspondiente (database_id), éste es un número que está asociado al nombre, pero es mas común el uso del nombre correspondiente. Es importante recordar que los nombres  deben seguir las reglas para los identificadores.

La sintaxis que se usa más a menudo es:

USE master;
GO

DBCC SHRINKDATABASE (database_name, target_percent);

En el comando se indica el nombre de la base de datos, indicando, además, un porcentaje de espacio libre que se desea mantener después de realizada la operación. 

Existen algunos argumentos opcionales que pueden ser utilizados con el comando, estos son:

NOTRUNCATE	Compacta los datos de archivos de datos moviendo páginas asignadas del final de un archivo a páginas no asignadas del principio del archivo. El porcentaje de destino es opcional. NOTRUNCATE solo es aplicable a archivos de datos. No afecta al archivo de registro.
TRUNCATEONLY	Devuelve al sistema operativo todo el espacio disponible del final del archivo, pero no realiza ningún movimiento de página dentro del archivo. El archivo de datos solo se reduce hasta el último tamaño asignado. El porcentaje de destino se omite si se especifica con TRUNCATEONLY. Este argumento afecta al archivo de registro de transacciones únicamente.
WITH NO_INFOMSGS	Suprime todos los mensajes informativos con niveles de gravedad entre 0 y 10.

Se hace necesario indicar, cuando se ejecuta este comando se puede obtener información correspondiente a actividad realizada por la comando, dicha información es:

Columna	Descripción
DbId	Número de identificación de la base de datos del archivo que SQL Server intentó reducir.
FileId	Número de identificación del archivo que SQL Server intentó reducir.
CurrentSize	El número de páginas que el archivo ocupa actualmente.
MinimumSize	El número de páginas que el archivo podría ocupar, como mínimo. Esto corresponde al tamaño mínimo o tamaño de creación original de un archivo.
UsedPages	El número de páginas que utiliza actualmente el archivo.
EstimatedPages	El número de páginas al que SQL Server estima que se puede reducir el archivo

Nota: SQL Server no presentará filas para los archivos que no se reducen

Ejemplos de DBCC SHRINKDATABASE

Mostraré algunos ejemplos de uso de este comando:

USE master;
GO

DBCC SHRINKDATABASE (db1) WITH NO_INFOMSGS;

Este comando lleva a cabo la reducción de archivos en la base de datos db1 indicada, sin emitir mensajes.

USE master;
GO

DBCC SHRINKDATABASE (db1, 10);

Este comando lleva a cabo la reducción de archivos de datos y de registro de transacciones en la base de datos db1 indicada, reservando un 10 por ciento de espacio disponible en la misma base de datos.

USE master;
GO

DBCC SHRINKDATABASE (db1, TRUNCATEONLY);

Este comando lleva a cabo la reducción de archivos de datos y de registro de transacciones en la base de datos db1 indicada, al último tamaño asignado, manteniendo el tamaño del archivo de datos para preservar la información almacenada.

Comentarios

El comando intenta reducir cualquier archivo de registro físico a su tamaño final de forma inmediata. Si ninguna parte del registro lógico se encuentra en los registros virtuales más allá del tamaño final del archivo de registro, el archivo se trunca de manera correcta y finalizará sin mensajes. No obstante, si parte del registro lógico está en los registros virtuales más allá del tamaño final, Microsoft SQL Server libera tanto espacio como sea posible y emitirá un mensaje informativo. El mensaje indicará las acciones que se deben llevar a cabo para mover el registro lógico de los registros virtuales al final del archivo. Una vez que se realicen estas acciones, se puede utilizar el comando para liberar el espacio restante.

Hay que tener en cuenta que cuando vaya a reducir una base de datos; la reducción es más efectiva después de que se ha llevado a cabo operación que crea mucho espacio inutilizado, como puede ser una operación para truncar o eliminar tablas.  

La mayoría de las bases de datos requieren que haya espacio disponible para realizar las operaciones diarias normales. Si se reduce una base de datos en forma continua y su tamaño vuelve a aumentar, esto indica que el espacio que se redujo es necesario para las operaciones normales. En estos casos, no sirve reducir la base de datos reiteradamente.

La reducción no mantiene el estado de fragmentación de los índices de la base de datos y generalmente aumenta la fragmentación hasta cierto punto. Esta es otra razón para no reducir la base de datos reiteradamente. A menos que tenga un requisito específico, no establezca la opción de base de datos AUTO_SHRINK en ON.

Es recomendable ejecutar la instrucción CHECKPOINT en la base de datos antes de utilizar el comando para que las páginas modificadas que se encuentren en la memoria se almacenen adecuadamente en el disco, asimismo, es oportuno indicar que el comando se lleve a cabo cuando la carga de uso de la base de datos haya disminuido y exista la menor cantidad de transacciones abiertas.

SQL Server DBCC INDEXDEFRAG

Comando DBCC INDEXDEFRAG           

Ya hemos establecido, que se trata de un comando de mantenimiento,  cuando mencionamos los Comandos DBCC,  que lleva a cabo la desfragmentación de los índices de la tabla o la vista especificada en el comando. Este comando se ha utilizado desde las primeras versiones de Microsoft SQL Server, que sin bien aún se mantiene en el catálogo de comandos de consola, Microsoft ha indicado que esta característica se quitará en el futuro de Microsoft SQL Server, es por ello que se solicita que para nuevos trabajos de desarrollo no se utilice y se modifique lo antes posible en las aplicaciones que actualmente la utilizan. Se recomienda el uso de la sentencia ALTER INDEX en su lugar.

La desfragmentación se lleva a cabo a nivel hoja del índice para que el orden físico de las páginas coincida con el orden lógico de izquierda a derecha de los nodos hoja, lo que mejora el rendimiento de recorrido del índice.

No se admite el uso de este comando DBCC INDEXDEFRAG en los siguientes objetos:

•          Tablas del sistema
•          Un índice deshabilitado. 
•          Un índice con bloqueo de página establecido en OFF. 
•          Un índice espacial.

La sintaxis de este comando en su forma más simple es:

USE master;

GO

DBCC INDEXDEFRAG ({database}, [table_name | view_name]);

En el comando se indica que se lleve a cabo la desfragmentación de todos los índices de la tabla denominada table_name o de la vista view_name, en la base de datos indicada.  Es necesario indicar que aunque se puede indicar el identificador correspondiente (database_id, table_id o view_id), éste es un número que está asociado al nombre, pero es mas común el uso del nombre correspondiente. Es importante recordar que los nombres  deben seguir las reglas para los identificadores.

Es trascendental mencionar, que si bien muchos comandos DBCC registran actividad en el Log de Microsoft SQL Server, este  comando no genera una entrada ya que no afecta el funcionamiento de la base de datos.

La sintaxis que se usa más a menudo es:

USE master;
GO

DBCC INDEXDEFRAG ({database}, [table_name], index_name);

En el comando se indica el nombre de la base de datos, el nombre de la tabla y el nombre del índice que se va a desfragmentar, en este caso, también es posible colocar el numero asociado del índice (index_id), aunque lo más usual es colocar el nombre, siguiendo las reglas de los identificadores. 

Existen algunos argumentos opcionales que pueden ser utilizados con el comando, estos son:

número_de_partición	Es el número de partición del índice que se va a desfragmentar. Si no se especifica o se especifica 0, la instrucción desfragmenta todas las particiones del índice especificado.
WITH NO_INFOMSGS	Suprime todos los mensajes informativos con niveles de gravedad entre 0 y 10.

Se hace necesario indicar, cuando se ejecuta este comando se puede obtener información correspondiente a actividad realizada por la desfragmentación del índice, a excepción que se haya indicado WITH NO_INFOMSGS, dicha información es:

·         Paginas escaneadas

·         Paginas Movidas

·         Paginas Removidas

Ejemplos de DBCC INDEXDEFRAG

Mostraré algunos ejemplos de uso de este comando:

USE master;
GO

DBCC INDEXDEFRAG (db1, 'Sche1.Table1', index_name) WITH NO_INFOMSGS;

Este comando lleva a cabo la desfragmentación en la base de datos db1 del denominado index_name de la tabla Sche1.Table1  indicada, sin emitir mensajes.

USE master;
GO

DBCC INDEXDEFRAG (db1, 'Sche1.Table1');

Este comando lleva a cabo la desfragmentación en la base de datos db1 de todos los índices de la tabla ‘Sche.Table1’ indicada, en este caso llevará a cabo la emisión de mensajes por cada índice de la tabla, dado que se indica que sean todos los índices.

USE master;
GO

DBCC INDEXDEFRAG (db1, 'Sche1.Table1', index_name);

Este comando lleva a cabo la desfragmentación en la base de datos db1 del denominado index_name de la tabla ‘Sche.Table1’ indicada, en este caso se mostrara el resumen de la operación efectuada al índice

Comentarios

El comando también compacta las páginas de un índice, tomando en cuenta el factor de relleno especificado cuando se creó el índice. Las páginas vacías creadas como consecuencia de esta compactación se eliminan.

A diferencia del comando DBCC DBREINDEX, este comando lleva a cabo una operación en línea. Lo cual indica que no mantiene bloqueos a largo plazo. Por consiguiente, no bloquea la ejecución de consultas o actualizaciones. Es posible que se tarde menos en desfragmentar un índice relativamente poco fragmentado que en generar un índice nuevo porque el tiempo de desfragmentación está relacionado con el volumen de la fragmentación. Sin embargo, un índice muy fragmentado puede tardar mucho más en tiempo desfragmentarse que en volver a generarse.

Cómo se ha indicado, este comando desaparecerá en el futuro, por lo que se recomienda se familiaricen con la sentencia ALTER INDEX, que es la que debe utilizarse y es la que quedará en el futuro.

SQL Server DBCC FREEPROCCACHE

Comando DBCC FREEPROCCACHE      

Ya hemos indicado, cuando se mencionaron los Comandos DBCC,  indicado como comando de mantenimiento,  que quita todos los elementos de la memoria caché del plan de ejecución, quita un plan de ejecución concreto de la misma especificando un identificador de plan o un identificador SQL, o quita todas las entradas de caché asociadas a un grupo de recursos de servidor especificado.

Se debe hacer notar que el comando no borra las estadísticas de ejecución para los procedimientos almacenados compilados de forma nativa.

La sintaxis de este comando, en su forma más simple, es:

USE master;
GO

DBCC FREEPROCCACHE

Lo cual permitirá quitar todos los elementos de la memoria caché de planes de ejecución.

La sintaxis que se usa más a menudo es:

USE master;
GO

DBCC FREEPROCCACHE ({ plan_handle | sql_handle | pool_name })

Como puede observarse, se utilizara un número de plan_handle o sql_handle, definido como varbinary(64) que puede ser obtenido usando algunas consultas a las vistas de administración dinámica;

•          Sys.dm_exec_cached_plans 
•          Sys.dm_exec_requests 
•          Sys.dm_exec_query_memory_grants 
•          Sys.dm_exec_query_stats

pool_name es del tipo  sysname y puede obtenerse consultando la vista de administración dinámica sys.dm_resource_governor_resource_pools.

Existen algunas opciones que pueden ser utilizadas con el comando, estas opciones son:

WITH NO_INFOMSGS	Suprime todos los mensajes informativos.
COMPUTE	Purgar la caché del plan de consulta de cada nodo de ejecución. Es el valor predeterminado..  Este parámetro es aplicable en SQL Azure y Parallel Data Warehouse.
ALL	Purgar la caché del plan de consulta de cada nodo de ejecución y desde el nodo de Control. Este es el valor predeterminado si no especifica un valor. Parámetro aplicable en SQL Azure y Parallel Data Warehouse.

Ejemplos de DBCC FREEPROCCACHE

Mostraré algunos ejemplos de uso de este comando:

USE master;
GO

DBCC FREEPROCCACHE WITH NO_INFOMSGS

Este comando quita todos los elementos de la memoria caché del plan de ejecución, sin informar sobre la ejecución, sólo indicando finalización.

DBCC FREEPROCCACHE (0x060006001ECA270EC0215D05000000000000000000000000);

Este comando borrar únicamente el plan de ejecución indicado de la memoria caché del plan. Hay que recordar que este puede obtenerse de una vista de administración dinámica que ya se han indicado.

DBCC FREEPROCCACHE (COMPUTE) WITH NO_INFOMSGS;

Este comando quita todas las cachés de plan de consulta existente de los nodos de proceso, en una base de datos que se encuentre en SQL Azure o en Parallel Data Warehouse.

Comentarios

Es importante mencionar el uso de este comando puede ocasionar una disminución repentina y temporal en el rendimiento de las consultas debido al incremento del número de nuevas compilaciones. Es posible que se lleve a cabo la limpieza de los búferes cuando se lleva a cabo alguna modificación a las siguientes opciones de configuración de Microsoft SQL Server:

•          access check cache bucket count 
•          access check cache quota 
•          clr enabled 
•          cost threshold for parallelism 
•          cross db ownership chaining 
•          index create memory 
•          max degree of parallelism 
•          max server memory
•          max text repl size 
•          max worker threads 
•          min server memory
•          min memory per query
•          query governor cost limit 
•          query wait 
•          remote query timeout 
•          user options FILESTREAM stores binary large objects (BLOBS) on the file system.

FILESTREAM stores binary large objects (BLOBS) on the file system.

Si se llega a modificar alguna de las opciones anteriores, en un servidor del ambiente de producción, es posible que el rendimiento de ejecución de las consultas se vea degradado, ya que se debe generar nuevamente el plan de ejecución.

Nota: En posteriores entregas se llevará a cabo un análisis de las opciones de configuración de servicios de Microsoft SQL Server, como las que aquí se indican, para que se vaya entendiendo cada uno de ellos.

SQL Server DBCC DROPCLEANBUFFERS

Comando DBCC DROPCLEANBUFFERS

Ya hemos indicado, cuando se mencionaron los Comandos DBCC,  que este comando de mantenimiento que quita todos los búferes borrados del grupo de búferes y los objetos columnstore del grupo de objetos columnstore, si estos son utilizados. Principalmente el comando se utiliza para probar consultas con una memoria caché del búfer en frío sin apagar y reiniciar el servidor.

La sintaxis de este comando es:

USE database_name;
GO

DBCC DROPCLEANBUFFERS

Existen algunas opciones que pueden ser utilizadas con el comando, estas opciones son:

WITH NO_INFOMSGS	Suprime todos los mensajes informativos.
COMPUTE	Purga la caché del plan de consulta de cada nodo de ejecución.  Este parámetro es aplicable en SQL Azure y Parallel Data Warehouse.
ALL	Purgar la caché del plan de consulta de cada nodo de ejecución y desde el nodo de Control. Este es el valor predeterminado si no especifica un valor. Parámetro aplicable en SQL Azure y Parallel Data Warehouse.

Para llevar a cabo la ejecución de este comando, se recomienda que se lleve a cabo, en primer lugar el uso del comando CHECKPOINT para generar una caché de búferes en frio. Así se obliga a que todas las páginas desfasadas de la base de datos actual se escriban en el disco y se borren los búferes. Una vez hecho esto, puede emitir el comando DBCC DROPCLEANBUFFERS.

Ejemplos de DBCC DROPCLEANBUFFERS

Mostraré algunos ejemplos de uso de este comando:

USE db1;
GO

DBCC DROPCLEANBUFFERS

Este comando efectuará la limpieza de los búferes de la base de datos actual.

USE db1;
GO

DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS

Este comando efectuará la limpieza de búferes en la base de datos actual, sin emitir información adicional, solo indicando el final del comando.

USE db1;
GO

DBCC DROPCLEANBUFFERS (ALL) WITH NO_INFOMSGS

Este comando efectuará la limpieza de búferes en la base de datos actual, sin emitir información adicional, solo indicando el final del comando. Este comando solo debe ejecutarse en SQL Azure y en Parallel Data Warehouse.

Comentarios

Es importante mencionar que dado que muchas veces las bases de datos tienen páginas en memoria que no se han guardado en disco, es necesario que se lleve a cabo el uso del comando CHECKPOINT, lo cual provoca que las páginas se sincronicen con disco, recomiendo efectuar un respaldo de la base de datos después de haber ejecutado el comando.FILESTREAM stores binary large objects (BLOBS) on the file system.

 

SQL Server DBCC DBREINDEX

Comando DBCC DBREINDEX

Ya he mencionado, cuando vimos los Comandos DBCC de mantenimiento, que este comando vuelve a generar uno o varios índices para una tabla en la base de datos especificada. Sin embargo, se ha indicado por parte de Microsoft que este comando no se utilice en nuevos trabajos de desarrollo y se modifique lo antes posible las aplicaciones que actualmente utilizan el comando. Se sugiere que se use ALTER INDEX en su lugar.

No se admite el uso de este comando DBCC DBREINDEX en los siguientes objetos:

·         Tablas del sistema

·         Índices espaciales

·         índices de almacén de columnas optimizados de memoria xVelocity

La sintaxis de este comando en su forma más simple es:

USE database_name;
GO

DBCC DBREINDEX ([table_name]);

En el comando se indica que se lleve a cabo la generación de todos los índices de la tabla denominada table_name, es importante recordar que los nombres de tablas deben seguir las reglas para los identificadores.

Es importante mencionar, que si bien muchos comandos DBCC registran actividad en el Log de Microsoft SQL Server, este  comando no genera una entrada ya que no afecta el funcionamiento de la base de datos.

La sintaxis que se usa más a menudo es:

USE database_name;
GO

DBCC DBREINDEX ([table_name], index_name);

En el comando se indica el nombre de la tabla y el nombre del índice que se va a recrear. 

Existen algunos argumentos opcionales que pueden ser utilizados con el comando, estos son:

Fillfactor	Es el porcentaje de espacio de cada página de índice que se utiliza para almacenar los datos cuando el índice se crea o se vuelve a generar.  El valor de FILLFACTOR reemplaza el factor de relleno cuando se creó el índice, se convierta en el nuevo valor predeterminado para el índice y para cualquier otro índice no clúster vuelve a generar porque se vuelve a generar un índice agrupado.
WITH NO_INFOMSGS	Suprime todos los mensajes informativos con niveles de gravedad entre 0 y 10.

Se hace necesario indicar que cuando fillfactor es 0, el comando utiliza el valor de factor de relleno para el índice que se especificó la última vez. Este valor se almacena en la vista de catálogo sys.indexes. Si fillfactor se especifica, table_name y index_name, ambos, deben especificarse, es posible indicar que se aplique para todos los índices indicando ‘’ en lugar de index_name. Si fillfactor no se especifica, se utiliza el factor de relleno predeterminado que es 100.

Ejemplos de DBCC CLEANTABLE

Mostraré algunos ejemplos de uso de este comando:

USE db1;
GO

DBCC DBREINDEX ('Sche1.Table1', index_name, 0) WITH NO_INFOMSGS;

Este comando vuelve a generar el índice denominado index_name de la table indicada, tomando el valor de fillfactor en 0, equivalente a 100, sin emitir mensajes.

USE db1;
GO

DBCC DBREINDEX ('Sche1.Table1', '', 80);

Este comando vuelve a generar todos los índices de la tabla indicada, tomando el valor de fillfactor en 80.

Comentarios

Al permitir que los índices se vuelvan a generar dinámicamente, los índices que implementen restricciones PRIMARY KEY o UNIQUE se pueden volver a generar sin tener que quitar y volver a crear las restricciones. Esto significa que un índice puede volver a generarse sin conocer la estructura de una tabla ni sus restricciones.

SQL Server DBCC CLEANTABLE

Comando DBCC CLEANTABLE

Ya he mencionado los Comandos DBCC de validación, iniciaré ahora con los comandos del grupo de mantenimiento, e iniciaré recordando, que este comando recupera el espacio de las columnas de longitud variable quitadas en tablas o vistas indexadas. Hay que recordar que una columna de longitud variable puede tener uno de los siguientes tipos de datos: varchar, nvarchar, varchar (max), nvarchar (max), varbinary, varbinary (max), texto, ntext, imagen, sql_variant, y xml. No indicaré las diferencias entre cada uno de los tipos de datos indicados, eso lo haremos en alguna otra ocasión.

La sintaxis de este comando en su forma más simple es:

DBCC CLEANTABLE (database_name, [table_name]);

Que lleva a cabo la recuperación de espacio en la tabla denominada table_name de base de datos denominada database_name. Los nombres de base de datos y de tablas deben seguir las reglas para los identificadores. Es posible que se utilice el número de identificación de la base de datos (database_id) o de la tabla (table_id) o de una vista (view_id) si se prefiere.

Es importante indicar, que si bien muchos comandos DBCC registran actividad en el Log de Microsoft SQL Server, este  comando no genera una entrada ya que no afecta el funcionamiento de la base de datos.

La sintaxis que se usa más a menudo es:

USE database_name;
GO

DBCC CLEANTABLE (0, [table_name])

Lo anterior indica que se lleve a cabo la recuperación de espacio de la tabla denominada table_name en la base de datos indicada a través del comando USE. 

Existen algunos argumentos opcionales que pueden ser utilizados con el comando, estos son:

batch_size	Es el número de filas procesadas por transacción. Si no se especifica, o si su valor es 0, la instrucción procesa toda la tabla en una transacción.
WITH NO_INFOMSGS	Suprime todos los mensajes de información.

Es importante indicar en este punto que el si no se especifica batch_size, entonces el comando procesa toda la tabla en una transacción y la tabla se bloquea en modo exclusivo durante la operación. Para algunas tablas grandes, la longitud de una transacción y el espacio de registro necesario puede ser muy grande. Si se especifica un tamaño de proceso por lotes, el comando se ejecuta en una serie de transacciones; cada una de ellas incluye el número de filas especificado.

Ejemplos de DBCC CLEANTABLE

Mostraré algunos ejemplos de uso de este comando:

DBCC CLEANTABLE (db1,'Sche1.Table1', 0) WITH NO_INFOMSGS;

El comando anterior lleva cabo la recuperación de espacio en la base de datos db1 para la tabla Sche1.Table1 en una sola transacción sin emitir mensajes, solo el mensaje de terminación del comando.

DBCC CLEANTABLE (db1,'Sche1.Table1', 100) WITH NO_INFOMSGS;

El comando anterior lleva a cabo la recuperación de espacio, como el ejemplo anterior, pero ahora lo hará en lotes de 100 renglones.

Comentarios

Este comando no debe ejecutarse como una tarea de mantenimiento rutinaria. En lugar de ello, debe utilizarse después de realizar cambios significativos en columnas de longitud variable de una tabla o vista indizada, y hay que recuperar inmediatamente el espacio sin utilizar. Como alternativa, puede volver a generar los índices en la tabla o vista; no obstante, esta operación consume mas recursos.

DBCC CLEANTABLE no se puede ejecutar como una transacción dentro de otra transacción. Esta operación se registra por completo. DBCC CLEANTABLE no se admite para su uso en tablas del sistema, tablas temporales o la parte de índice de almacén de columnas optimizado en memoria xVelocity de una tabla.

SQL Server DBCC CHECKDB

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

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

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

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

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

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.FILESTREAM stores binary large objects (BLOBS) on the file system.