Hola, soy Kirk. Soy ingeniero principal sénior y trabajo con el equipo de GSE. Este video está dedicado a analizar la herramienta de base de datos TSQL DE MICROSOFT SQL, DBCC CHECKDB. Analizaremos por qué y cuándo se debe ejecutar DBCC CHECKDB, junto con las opciones de comandos que determinan el nivel de comprobación de la base de datos y el tiempo de ejecución involucrados.
Queremos abordar algunos puntos antes de empezar la demostración. DBCC CHECKDB es una herramienta TSQL que analiza la integridad lógica y física de todos los objetos dentro de una base de datos de SQL Server determinada. Tenemos algunas opciones de reparación que también están disponibles, y tenemos algo llamado "TABLOCK" como una opción que implica el uso o no uso de una instantánea de la base de datos. Vamos a ver la opción "ESTIMATEONLY", por qué querríamos usarla, y eso es relativo al uso de "TEMPDB" durante un proceso CHECKDB.
Además, veremos "PHYSICAL_ONLY", por qué querríamos usar esa opción y cuándo. Y también vamos a ver cómo podemos controlar la cantidad de procesadores involucrados en el proceso CHECKDB con algo llamado "MAXDOP". En este punto, veremos algunos de los ejemplos de lo que veríamos cuando ejecutamos DBCC CHECKDB. Por lo tanto, el primer comando en sí comprobará literalmente todo lo que es posible que DBCC CHECKDB vea dentro de una base de datos determinada.
Estos son los resultados. La línea de retorno que más nos interesa cuando ejecutamos esto es la cantidad de "errores de asignación" y "errores de coherencia" que se encuentran en la base de datos. Por lo tanto, tengo una base de datos "AdventureWorks2019" en buen estado, por lo que todo se devuelve sin errores. Esta es una base de datos pequeña, por lo que el proceso se ejecuta muy rápidamente. Si tenemos una base de datos mucho más grande, por ejemplo, 100 veces el tamaño de esta, nos llevará mucho más tiempo ejecutarla.
Y muchas personas se preguntan con qué frecuencia debemos intentar ejecutar DBCC CHECKDB y, por lo general, los maestros de SQL le dirán que desea intentar ejecutarlo lo antes posible. Si hay alguna inconsistencia o algún tipo de daño de software en la base de datos, desea descubrirlo lo más rápido posible y solucionarlo. La siguiente opción que vamos a ver es la llamada "CON PHYSICAL_ONLY".
Es el mismo comando, excepto que, en este caso, literalmente solo se trata de comprobar la entidad física o la estructura de la base de datos en sí. Por lo general, se ejecutará mucho más rápido que una comprobación completa, y es por eso que querríamos ejecutarlo en entornos de producción donde tenemos limitaciones en nuestros tiempos de mantenimiento. También tenemos otra opción llamada "WITH TABLOCK", así que una cosa que debemos entender sobre DBCC CHECKDB es que una de las primeras cosas que hace es crear un archivo de instantánea que se encuentra en la base de datos "TEMPDB", y hay ocasiones en las que es posible que no podamos usar "TEMPDB" para algo así con un proceso CHECKDB.
Por lo tanto, independientemente de lo que designemos "CON TABLOCK", le estamos diciendo a DBCC CHECKDB que no cree un archivo de instantánea, por lo que no ocupará ese espacio en "TEMPDB" y, por lo general, se ejecutará más rápido como resultado de eso. Otra de las cosas que podemos ejecutar como opción es "WITH ESTIMATEONLY". Este comando en particular nos dirá cuánto espacio esperaríamos haber usado dentro de nuestra base de datos "TEMPDB" al ejecutar CHECKDB.
Y este es un ejemplo de la salida de eso, regresa en kilobytes, es decir, alrededor de 230 megabytes. Otra opción que tenemos es “WITH MAXDOP”. Ahora, independientemente de lo que DBCC CHECKDB ejecute, intenta usar tantos procesadores como sea necesario para ejecutarse en paralelo. Desea ejecutar varios subprocesos para intentar ejecutarlos lo más rápido posible. Por lo tanto, puede haber limitaciones en cuanto a la cantidad de procesadores que queremos permitir que se ejecuten en este proceso, por lo que podemos limitar eso con la instrucción "WITH MAXDOP".
En este caso, le estoy diciendo a SQL que solo use un procesador para nuestra ejecución de CHECKDB. Y, cuando hacemos eso, son menos procesadores dedicados a esto, pero, por lo general, tomará más tiempo ejecutar su DBCC CHECKDB. Ahora, analicemos las opciones de reparación. Hay diferentes opciones. La más drástica es “REPAIR_ALLOW_DATA_LOSS”. Literalmente, puede perder datos cada vez que usamos esta opción para intentar reparar una base de datos que regresa con errores. O bien se podría utilizar “REPAIR_REBUILD”.
REPAIR_REBUILD se considera una opción de reparación parcial, y lo que queremos decir con eso es que garantiza que no perderemos datos disponibles en la base de datos cuando ejecutemos esto. Por lo tanto, en la forma en que está diseñado este comando, usaremos el contexto de la base de datos "Master". Siempre que hagamos algo así, debemos poner la base de datos en modo "SINGLE_USER" para permitir una operación de reparación. En este caso, ejecutaremos eso.
Ahora bien, tenemos la opción de "ESTIMATEONLY" y, una vez más, "ESTIMATEONLY" nos dirá cuánto espacio vamos a ceder en "TEMPDB" para hacer esto. Nuestro archivo de instantáneas ocupará alrededor de 230 megabytes, según nuestro retorno aquí. Después de realizar una reparación con esto, debemos volver a ponerlo en modo "MULTI_USER". Ahora, con "ESTIMATEONLY" en realidad no ejecutamos la reparación, solo hicimos la estimación. Echemos un vistazo a la ejecución del comando con el "REPAIR_REBUILD".
Una vez más, vamos a ejecutar eso, lo volveremos a poner en "MULTI_USER". Una vez más, en el contexto de la base de datos "Master", la pondremos en modo "SINGLE_USER". En este caso, ejecutaremos una operación de reparación. Esta es la operación de reparación moderada. Lo que verá es mucho de lo que veríamos en una comprobación regular de la base de datos y, por supuesto, una vez más, queremos comprobar si hay errores informados. En este caso, de nuevo no hay ninguno.
Tengo una base de datos en buen estado. Y la última parte de esta operación es volver a ponerlo en modo "MULTI_USER". El comando de reparación "REPAIR_ALLOW_DATA_LOSS" es exactamente igual que el "REPAIR_REBUILD", excepto que usamos la opción "REPAIR_ALLOW_DATA_LOSS". Por lo general, ejecutamos esto cuando intentamos ejecutar el "REPAIR_REBUILD" y el "REPAIR_REBUILD" regresa y nos dice que no pudo completar la reparación de la base de datos.
Entonces, nuestro último recurso sin un buen respaldo, y sí, debemos usar un buen respaldo antes de vernos obligados a hacer un "REPAIR_ALLOW_DATA_LOSS". Si no existe una copia de seguridad, esta es nuestra única opción para volver a poner la base de datos en línea y disponible. Así concluye nuestra demostración de analizar DBCC CHECKDB, considerar cuándo usar CHECKDB y algunas de las opciones de comandos disponibles más comunes. Espero que este video lo haya ayudado a comprender el valor de usar DBCC CHECKDB cuando intenta mantener una instalación de base de datos de SQL Server coherente y estable.
Gracias por su tiempo.
