Reducir tamaño de Base de Datos en SQL Server

Muchas veces hemos tenido limitaciones en el almacenamiento para nuestros servidores. Esto seguramente te ha llevado a pensar cómo comprimir estas necesidades y optimizar tus espacios. Ahora necesitas saber por qué, cómo y cuándo reducir tamaño de base de datos en SQL Server.

Primero evaluar puntos importantes

¿Por qué estamos sin espacio?

No siempre puedes culpar a las estimaciones en los proyectos o en los diseños. Si ya llegaste a los mensajes de errores o a caídas de servidores en Producción con pérdida de servicio, después de solucionarlo revisa estos puntos en el resto de servidores.

• Relación tamaño de Base(s) de Datos vs Espacio físico asignado
• Tendencias de crecimiento de información
• Recovery Model en configuración de Base de Datos
• Políticas de respaldos (basado en punto anterior)
• Cantidad y uso de índices

¿Existen estándares para saber cuándo alertar un problema de espacio?

Muchos dirán que sí y que un buen valor para saber cuándo alertar un pronto problema de espacio es cuando tu disco está entre 75-80% de uso. Después de haber visto diferentes sistemas, mi respuesta a la pregunta suele ser lamentablemente un no.

NO por una simple razón: cada base de datos debe evaluarse. No es lo mismo un Datawarehouse, una base IoT, una base transaccional bancaria o un repositorio de información histórica.

¿Entonces cuándo utilizamos SHRINK?

Ya sé que esta era la primera pregunta de la que querías la respuesta. No la estoy evitando pero es importante que primero busques el orígen de tus problemas de espacio.

No voy a hablar en contra de esta práctica de aplicar la reducción de espacio con SHRINKDATABASE pues necesito explicarte muchas cosas más que no alcanzaría esta publicación. Sin embargo quiero que sepas algo importantísimo.

DBCC SHRINKDATABASE es un comando que oficialmente por Microsoft, no está recomendado dado su uso intensivo de I/O.

Es muy fácil dejar sin servicio a tus usuarios mientras ejecutas un SHRINK así que ten cuidado la próxima vez que quieras hacerlo.

Para reducir tamaño de base de datos

Primero verifica los puntos señalados al principio de este artículo.

A veces cuando queremos darle velocidad a nuestras consultas, pecamos de llenar de índices las tablas y, muchas veces, algunos de ellos ni siquiera son utilizados. Obtén un Reporte de Uso de Índices y decide cuáles mantener y cuáles no.

Una de las tareas prinicipales del DBA de SQL Server también es crear buenas políticas de respaldos. Ten en cuenta que el Recovery Model de la base de datos en FULL generará más uso del datafile de log que una en modo SIMPLE.

Evita el SHRINK, evita diseños que generen muchos espacios vacíos pero sobre todo controla el crecimiento de tus bases de datos. SHRINK no es una tarea, no es una práctica de un DBA y mucho menos algo que pienses que debas tener en tareas programadas.