Azure SQL Managed Instance - Cuidado! Por que el Shrink puede arruinar tu rendimiento

¡Hola, chicos! ¿Cómo estás? ¿Emocionado por otra publicación?

Introducción

Hoy quiero conversar con ustedes sobre algo que puede ser un verdadero problema para quienes están migrando de SQL Server local (o incluso Azure SQL Database) a Azure SQL Managed Instance (MI) y que aprendí en la práctica.

¿Conoce esa rutina clásica de DBA de mirar un archivo de registro que ha crecido demasiado después de un mantenimiento intenso y pensar: "Voy a ejecutar una reducción aquí para liberar este espacio no utilizado"? Bueno, en Instancia administrada, específicamente en el nivel Estándar - Propósito general, esta "buena práctica" puede convertirse en su peor pesadilla de rendimiento.

El escenario: el hábito de encogerse

En el mundo local, mantener los archivos de registro y datos en el tamaño "justo" es casi un mantra para ahorrar almacenamiento y mantener la organización.

En mi caso, estaba trabajando en un entorno muy grande, vi un archivo de registro que tenía 900 GB de espacio asignado y menos de 1 GB utilizado. Especialmente cuando se trata de archivos de registro, es natural que cualquier administrador de bases de datos de SQL Server piense inmediatamente en ejecutar una reducción para recuperar este espacio asignado, ¿verdad? Aquí es donde radica el problema cuando la base de datos en cuestión está en una Instancia administrada de Azure SQL en el nivel de uso general.

En Instancia administrada de Azure SQL, si usa los niveles más nuevos, como Propósito general de próxima generación o Crítico para el negocio, tiene mayor flexibilidad y el problema que detallaré en esta publicación no ocurre. Pero la gran mayoría de los entornos todavía se ejecutan en uso general (estándar), y aquí es donde el error se hace evidente.

A diferencia de un disco local donde las IOPS generalmente se fijan según el tipo de disco, en Instancia administrada de uso general, el rendimiento de E/S (IOPS y rendimiento) es directamente proporcional al tamaño que asigna al archivo.

Esto significa que Azure reserva el rendimiento según el tamaño del archivo, ya sea el archivo de datos (mdf) o el archivo de registro (ldf). Si tiene un archivo de registro de 1,1 TB, tiene un límite de 7500 IOPS. Si ejecuta una reducción y este archivo cae a 100 GB, acaba de reducir las IOPS del disco a 500, reduciendo el rendimiento de su disco (y del banco) en 15 veces, a menudo sin darse cuenta.

Según el documentación oficial de Microsoft, el escalado funciona en bandas.

Tamaño de archivo y rangos de IOPS:

El verdadero problema: el “efecto dominó”

Imagine que ejecuta la reducción en el registro a las 9 p.m. en una rutina de mantenimiento. El archivo pasó de 600GB a 50GB. A las 8 de la mañana, varios trabajos tardan mucho más en ejecutarse, la aplicación funciona con lentitud y todo el mundo se queja. Dado que el registro ahora solo tiene 500 IOPS (en lugar de 5000), cada INSERT, UPDATE o DELETE tarda 10 veces más en enviar la confirmación al disco.

¿El resultado? Espera tipos de LOG_RATE_GOVERNOR o WRITELOG en la parte superior, aplicación lenta, usuarios quejándose y miras la CPU y ves que todo está bajo. Entonces piensas: "¡Pero no cambié nada, solo limpié el tronco!" jajaja.

Y ahora ¿qué hacer?
La recomendación aquí cambia un poco la mentalidad del DBA tradicional:

• Evite la reducción: si su archivo de registro ha crecido a 200 GB y sabe que periódicamente necesita ese espacio para mantenimiento o cargas, déjelo allí. El costo del almacenamiento adicional es mucho menor que el costo del tiempo de inactividad o la lentitud de las aplicaciones.
• Supervise los rangos de IOPS: incluso puede ejecutar Shrink, pero tenga cuidado de no cambiar los rangos de rendimiento de IOPS y si esta reducción en la velocidad del disco tendrá un impacto. Antes de reducir un archivo, consulte la documentación para asegurarse de no caer en un "rango de rendimiento" inferior.
• Evalúe la GP de próxima generación: si el rendimiento del disco es un cuello de botella constante y necesita flexibilidad, considere pasar al nivel de uso general de próxima generación, donde los IOPS están aislados del tamaño del archivo (puede pagar tantos IOPS como desee).

Para ayudarte a identificar el rango de velocidad de cada archivo en tu entorno, preparé un script simple para ayudarte en el día a día:

SELECT 
    DB_NAME(database_id) AS [Database Name],
    [name] AS [Logical Name],
    [type_desc] AS [File Type],
    CAST(size * 8.0 / 1024 / 1024 AS DECIMAL(10, 2)) AS [Size (GiB)],
    
    -- Lógica baseada nos tiers oficiais de IOPS
    CASE 
        WHEN (size * 8.0 / 1024 / 1024) <= 129 THEN 500
        WHEN (size * 8.0 / 1024 / 1024) <= 513 THEN 2300
        WHEN (size * 8.0 / 1024 / 1024) <= 1025 THEN 5000
        ELSE 7500
    END AS [Official IOPS],

    -- Lógica baseada nos tiers oficiais de Throughput (MiB/s)
    CASE 
        WHEN (size * 8.0 / 1024 / 1024) <= 129 THEN 100
        WHEN (size * 8.0 / 1024 / 1024) <= 513 THEN 150
        WHEN (size * 8.0 / 1024 / 1024) <= 1025 THEN 200
        ELSE 250
    END AS [Official Throughput (MiB/s)],
    
    physical_name AS [Physical Path]
FROM 
    sys.master_files
WHERE 
    database_id > 4 
ORDER BY 
    [Size (GiB)] DESC;

Conclusión

Si siente que su WRITELOG es alto, eche un vistazo al tamaño del archivo de registro. Si son 100 GB, estás limitado a 500 IOPS. Si aumenta este archivo a 514 GB (incluso si no usa todo ese espacio), ¡Azure le liberará 5000 IOPS al instante!

Vale la pena recordar que esto también se aplica al tamaño del archivo de datos, no se trata sólo del archivo de registro.

A veces “desperdiciar” un poco de almacenamiento es la mejor inversión que puedes hacer en el rendimiento de tu base de datos en Azure.

Espero que hayas disfrutado de esta actualización, un fuerte abrazo y ¡hasta la próxima!