sql >> Base de Datos >  >> RDS >> Database

Descripción general del comando DBCC SHRINKFILE

Ejecutar comandos DBCC Shrink es un tema bastante controvertido en la comunidad de SQL Server. En este artículo, revisaremos los detalles sobre este comando y brindaremos una breve descripción general de su uso, y también le advertiremos sobre los riesgos de ejecutar este comando. Como DBA, se entregaron varias bases de datos de otros equipos o proveedores, y no siempre podemos administrar las bases de datos que creamos. Como administradores de bases de datos, siempre que estemos involucrados en migraciones o nuevos proyectos, debemos asegurarnos de planificar cuidadosamente una transición sin problemas de la base de datos a producción y uso regular. Es en esta etapa que debemos tener en cuenta el tamaño de la base de datos. ¿Te imaginas configurar una aplicación de base de datos sin considerar el pronóstico de crecimiento para el primer año más o menos? ¿Qué tal si crea una base de datos de SQL Server con un tamaño tan pequeño que necesita crecer cada dos días aumentando las alertas de capacidad del disco en medio de la noche? Puede sonar tonto, pero en realidad, la verdad es que esto sucede y, a veces, es posible que no esté bajo su control.

Pocos puntos a considerar para el DBA proactivo

Antes de hacerse cargo del soporte de las bases de datos de producción, asegúrese de consultar con su predecesor cuáles son las previsiones en términos de crecimiento de la base de datos. ¿El tamaño inicial de las bases de datos que administrará es adecuado? No se preocupe demasiado si el tamaño actual de la base de datos es mucho mayor que los datos que tiene actualmente. Recuerde, no quiere esas llamadas de capacidad de disco a las 3:00 a. m. de la mañana cuando podría haberlas evitado por completo si tuviera una base de datos del tamaño correcto. Es una tendencia general que los administradores de bases de datos de toda la industria sacrifiquen sus vidas a altas horas de la noche por problemas mundanos que, en primer lugar, no deberían haber ocurrido. Además, junto con el tamaño de la base de datos, tenga en cuenta la capacidad de disco del servidor. No desea que el tamaño del disco sea demasiado pequeño de lo que puede acomodar una base de datos. Estas son todas las cosas simples que vienen muy bien en el momento de la planificación. Sin embargo, como sabe, no siempre es un profesional de bases de datos quien instala o configura bases de datos en primer lugar. El punto importante a tener en cuenta es obtener los conceptos básicos correctos con su base de datos en términos de tamaño y es posible que no necesite ejecutar este comando nunca. Sin embargo, como siempre, como DBA, hay momentos en los que las cosas pueden no estar bajo su control y durante este tiempo puede usar los comandos DBCC Shrink file para un uso eficiente.

¿Cuándo puedo usar DBCC ShrinkFile?

Acaba de recibir una alerta de espacio en disco justo en medio de su sueño y tiene estrictos SLA que cumplir. El nivel de prioridad es P2 y el SLA puede incumplirse muy pronto. Y se da cuenta de que la expansión del disco no va a ocurrir en el corto plazo, bueno, en ese caso, tenga a mano sus comandos DBCC ShrinkFile para que pueda usarlos para recuperar el espacio. Como sugiere el nombre, reduce el archivo de datos o el archivo de registro de la base de datos. Pero antes de comenzar a ejecutar los comandos DBCC ShrinkFile, intente verificar por qué el archivo de la base de datos está creciendo en primer lugar.

  • ¿El archivo creció debido a una transacción de larga duración?
  • ¿Hay algún tipo de bloqueo en el servidor?
  • ¿Hay algún lanzamiento de aplicación importante del que no haya sido informado? (Esto sucede la mayor parte del tiempo)
  • ¿Hay algún tipo de problema de replicación o duplicación de la base de datos que provoque el crecimiento de la base de datos?

Es importante obtener respuestas a estas preguntas lo más rápido posible. Generalmente, hay una respuesta a todas estas preguntas y es una gran herramienta gratuita llamada sp_whoisactive. No hay palabras para describir el enorme uso de esta herramienta y la he usado en múltiples ocasiones para solucionar numerosos problemas relacionados con la producción. Puede descargar el código más reciente desde este enlace:http://whoisactive.com/. Es fácil y simple de usar y devuelve la salida en poco tiempo. Si eres DBA experimentado, ya tendrás esto a tu disposición.

DBCC ShrinkFile con ejemplos

La sintaxis de DBCC ShrinkFile es simple y directa, consulte este ejemplo a continuación.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

El ejemplo anterior reduce el nombre de archivo que pertenece a YOURDATABASE a 1024 MB. Puede realizar la misma operación con SQL Server Management Studio (SSMS). Haga clic derecho en la base de datos, vaya a Tareas , seleccione Reducir y luego Archivos .

Una vez que haga clic en Archivos , obtendrá esta ventana.

Aquí, tiene la opción de seleccionar el tipo de archivo:Datos, Registro o Datos de flujo de archivos y realizar la "Acción de reducción" según sea necesario. Es más fácil usar el comando DBCC en sí para propósitos de reducción.

Uso de DBCC ShrinkFile con opciones adicionales

Puede ejecutar el comando DBCC ShrinkFile con opciones adicionales:archivo vacío, no truncado o solo truncado.

Archivo vacío

Puede usar el comando de archivo vacío como se muestra a continuación.

use YOURDATABASE
go
dbcc shrinkfile(FileName,emptyfile)

Esto ayudará a mover los datos a otros archivos dentro del mismo grupo de archivos. Una vez hecho esto, podrá eliminar un archivo de base de datos si ya no es necesario. Sin embargo, hay algunas cosas a tener en cuenta con esta opción de archivo vacío, ya que no podría hacer mucho para vaciar el contenido del archivo de datos principal con ID de archivo 1. Para obtener el número de ID de archivo, ejecute este script.

select file_id, name,physical_name from sys.database_files

Aquí, en este ejemplo, el nombre de archivo es "mo" y file_id es 1. Cuando intente vaciar el archivo mo que tiene file_id 1, encontrará este mensaje de error.

Esto se debe a que hay información del sistema dentro del archivo original, que no se puede vaciar. Pero, si intenta el mismo comando en el otro archivo de datos "mo2data", el comando de archivo vacío tendrá éxito.

No truncar

Como sugiere el nombre, no se libera espacio en el sistema operativo. Esto es más como una operación interna dentro del archivo donde las páginas se redistribuyen dentro del propio archivo sin cambiar el tamaño total del archivo de la base de datos. Debido a esto, existe una gran posibilidad de que se introduzca la fragmentación. Vea el ejemplo a continuación.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,notruncate);  
GO

Solo truncado

Como sugiere el nombre, el espacio libre se liberará al sistema operativo desde el final del archivo. Esta es, con mucho, la operación más segura que puede ejecutar con DBCC ShrinkFile. Vea el ejemplo a continuación.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,truncateonly);  
GO

¿Qué hacer cuando DBCC ShrinkFile en el registro de transacciones no funciona como se esperaba? Consulte este método seguro para solucionar el problema

Hay momentos en que este comando puede no funcionar como se esperaba. Suponiendo que tiene una situación en la que intenta reducir el archivo de registro de una base de datos y parece que no funciona. A continuación se muestran algunos de los pasos que puede seguir para comprender por qué el psiquiatra no funciona como se esperaba. Notará que el archivo de reducción se mostrará como exitoso, sin embargo, no hay reducción en el tamaño del archivo de registro. En ese caso, ejecute este comando para verificar algunas cosas sobre el uso del archivo de registro.

select name,log_reuse_wait_desc,* from sys.databases

En la captura de pantalla, puede ver que la columna log_reuse_wait_desc está esperando en la copia de seguridad del registro.

Aquí, puede ver que se debe realizar la copia de seguridad del registro de la base de datos antes de que realmente pueda reducir el archivo de registro. Si está en una base de datos de producción, intente realizar la copia de seguridad del registro en otra unidad donde haya espacio disponible. Para realizar la copia de seguridad del registro, use el siguiente comando de muestra.

backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn'
with init,stats,compression

Después de ejecutar el comando de copia de seguridad, vuelva a ejecutar el siguiente comando para ver el estado de la columna log_reuse_wait_desc.

select name,log_reuse_wait_desc,* from sys.databases

En la captura de pantalla, puede ver que el estado de la columna log_reuse_wait_desc ha cambiado a "Nada".

Aquí puede ver que el estado de la columna "log_reuse_wait_desc" ha cambiado a "Nada". En su caso, aún puede mostrarse como "LOG_BACKUP". Continúe realizando las copias de seguridad de registros para la base de datos hasta que el estado cambie a "Nada". La razón por la que aún puede ver el estado "LOG_BACKUP" incluso después de realizar copias de seguridad del registro de transacciones es porque es posible que no se haya borrado ningún VLF después de ejecutar la copia de seguridad del registro de transacciones. VLF significa archivos de registro virtuales y es parte de la arquitectura interna del registro de transacciones. Los archivos de registro de transacciones se componen de estos VLF. Puede obtener información sobre los VLF ejecutando este comando.

select * from sys.dm_db_log_info(5)

Aquí 5 representa el ID de la base de datos. Se muestra la captura de pantalla de la salida. El número de filas devueltas representa el número real de archivos de registro virtuales (VLF) en la base de datos. Puede consultar la columna "vlf_status" para comprobar el estado del archivo de registro virtual. El valor 2 significa que está activo. Con este comando, puede verificar los indicadores internos dentro del archivo de registro de transacciones para comprender por qué el registro de transacciones no se libera incluso después de realizar copias de seguridad del registro.

Anteriormente, el comando que se usaba era DBCC LOGINFO, que proporcionaba información similar.

¿Qué hacer cuando DBCC ShrinkFile en el registro de transacciones no funciona como se esperaba? Algo que puede realizar en un entorno no productivo. Sin embargo, no se recomienda en un entorno de producción

Se habría encontrado en varios sitios web con personas que recomiendan cambiar el modelo de recuperación a uno simple y luego ejecutar un archivo reducido para liberar espacio en el sistema operativo. Tenga en cuenta que cambiar el modelo de recuperación a uno simple afectará la recuperación de su base de datos, ya que no podrá recuperarse en un momento específico. Esto nuevamente depende de su SLA empresarial. Puede cambiar el modelo de recuperación usando T-SQL (abajo) o usando la GUI.

alter database DB_NAME set recovery simple

Usando la GUI, cambie el modelo de recuperación como se muestra. Haga clic derecho en la base de datos, vaya a "Propiedades", haga clic en "Opciones". En "Opciones", seleccione el "Modelo de recuperación".

Notará que simplemente cambiar el modelo de recuperación a Simple no liberará el espacio para el sistema operativo. Deberá ejecutar explícitamente el comando DBCC ShrinkFile para reducir el archivo y recuperar el espacio. Vea el script de muestra a continuación. Este comando reducirá su nombre de archivo a 1024 MB.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

Opción de base de datos de reducción automática

Notará que hay una opción conocida como "Reducción automática" dentro de las propiedades de la base de datos. Simplemente haga clic derecho en la base de datos para ver la propiedad de la base de datos. En la sección de opciones, verá esta opción como se muestra. Desde la configuración de la base de datos del modelo, puede ver que la opción "Reducción automática" está deshabilitada de forma predeterminada. Por lo tanto, cada vez que se crea una nueva base de datos, esta opción también está deshabilitada. Puede haber algunos casos en los que los profesionales de bases de datos dejen habilitada esta opción sin saberlo, sin ser conscientes de las consecuencias negativas de dejarla activada.

Ejecute este comando para verificar el estado de esta opción para las bases de datos en el servidor.

select name,is_auto_shrink_on,* from sys.databases

Verá este resultado.

Si por casualidad, ve que está habilitado, puede deshabilitarlo usando la GUI o puede ejecutar el siguiente comando en la base de datos.

ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF

Otras sugerencias de mantenimiento

Consulte estos pocos consejos adicionales para evitar el problema del crecimiento de la base de datos, por lo que debe ejecutar los comandos DBCC ShrinkFile.

  • Asegúrese de que el modelo de recuperación de sus bases de datos esté alineado con los SLA empresariales. Si su empresa no requiere una recuperación puntual para las bases de datos de prueba, simplemente déjelas en un modelo de recuperación simple. He visto varias ocasiones en las que el modelo de recuperación de las bases de datos estaba completo cuando las cosas están bien con la recuperación utilizando la última copia de seguridad completa
  • Asegúrese de implementar un monitoreo adecuado, especialmente con el crecimiento de la base de datos. Debería recibir una alerta cuando la utilización del archivo de registro alcance el 85 %. Esto le dará algo de tiempo para resolver el problema del espacio
  • Asegúrese de que se realicen copias de seguridad de registros periódicas si la base de datos está en el modelo de recuperación completa y debería recibir una alerta si alguna de las copias de seguridad de registros falla
  • Asegúrese de que haya suficiente espacio en las unidades de la base de datos para evitar problemas de escasez de espacio
  • Para las bases de datos que se pueden archivar, desarrolle algunas estrategias de archivo para que pueda mover los datos más antiguos a otra base de datos para crear informes y hacer que esa base de datos sea de solo lectura. Esto le dará más control en términos de tamaño de la base de datos
  • Asegúrese de realizar comprobaciones de integridad periódicas en su base de datos mediante DBCC CheckDB. Para obtener más información, consulte este artículo:https://codingsight.com/dbcc-checkdb-overview/

Conclusión

  • De este artículo, obtuvo una buena comprensión del uso del comando DBCC ShrinkFile
  • Aprendió sobre los riesgos de ejecutar los comandos DBCC ShrinkFile
  • Aprendió las diferentes opciones que podemos proporcionar usando los comandos DBCC ShrinkFile
  • Vio las opciones que podemos probar si el registro de transacciones no se reduce con los comandos DBCC ShrinkFile
  • Aprendió sobre la configuración predeterminada de reducción automática dentro de la propiedad de la base de datos
  • También aprendió otras sugerencias de mantenimiento de bases de datos para mantener sus bases de datos saludables
  • Por último, asegúrese de estar preparado en cualquier caso para esos días de descanso que pueden estar fuera de su control