Subir compatibilidad: un despliegue medido y verificable

Instalar un motor SQL Server más reciente y subir el nivel de compatibilidad son cambios relacionados, pero distintos. Combinarlos con cambios de esquema, mantenimiento de índices y una nueva aplicación dificulta explicar una regresión. Una actualización controlada crea puntos de comparación para identificar qué modificación alteró el comportamiento de consultas importantes.

Establecer dos referencias separadas

Registre versión exacta del motor, compatibilidad, configuración de base y ajustes importantes de la aplicación. Restaure una copia representativa en el destino conservando un nivel anterior admitido y evalúela antes de subirlo. Ese nivel no emula todo el motor antiguo: infraestructura, correcciones y otros comportamientos pueden cambiar.

El inventario de solo lectura se ejecuta en la base evaluada. La vista Query Store requiere permisos de consulta adecuados a la versión instalada. Guarde el resultado con fecha e identificador de carga.

SELECT SERVERPROPERTY('ProductVersion') AS EngineVersion;
SELECT name, compatibility_level
FROM sys.databases WHERE database_id=DB_ID();
SELECT actual_state_desc, desired_state_desc, readonly_reason,
       current_storage_size_mb, max_storage_size_mb
FROM sys.database_query_store_options;

El estado deseado READ_WRITE no prueba que Query Store esté registrando. Compruebe estado real, consumo de espacio y causa de solo lectura. Captura y retención deben conservar la referencia durante la comparación. Un repositorio lleno puede dejar de recoger pruebas precisamente durante el cambio crítico.

Elija una carga que cubra distribuciones importantes de parámetros y un ciclo de negocio completo. Incluya mayor cliente, resultados vacíos, cierre mensual y solicitudes concurrentes. Repetir búsquedas puntuales diurnas no valida informes nocturnos. Mantenga comparables datos, estadísticas, recursos y concurrencia, o documente sus diferencias expresamente.

Cambiar el nivel como experimento propio

En una instancia de pruebas SQL Server 2022, una base conservada en 150 puede evaluarse después en 160. La plantilla comentada utiliza deliberadamente una base de práctica. Confirme soporte en el motor real antes de adaptarla: un número no instala una versión inexistente.

-- Example only: SQL Server 2022, isolated practice database.
-- ALTER DATABASE [CompatibilityPractice]
-- SET COMPATIBILITY_LEVEL = 160;

Registre la hora del cambio para no mezclar intervalos de Query Store anteriores y posteriores. La transición puede causar recompilación. Distinga compilación inicial y calentamiento del comportamiento sostenido. No vacíe rutinariamente la caché de planes de toda la instancia; introduciría otro evento que afecta a bases ajenas.

Compare ejecuciones y costes conjuntamente. Una media mejor puede ocultar una consulta crítica infrecuente mucho más lenta, mientras mayor CPU total puede significar simplemente más solicitudes. Para cada consulta importante revise duración, CPU, lecturas, planes y concurrencia. Use telemetría de aplicación para distribuciones de latencia del usuario, sin suponer que los agregados de Query Store proporcionan todos los percentiles.

Cuando aparezca una regresión, examine filas estimadas y reales, combinaciones elegidas, concesiones de memoria y sensibilidad a parámetros. Preserve ambos planes y pruebe la hipótesis sobre los mismos datos. Un plan anterior puede mitigar un caso concreto, pero compruebe que forzarlo funciona y sirve para parámetros variados. Esa medida necesita responsable y fecha de revisión, no permanencia automática.

Definir aceptación y retorno real

Escriba antes criterios medibles: latencia crítica, plazo del proceso por lotes, errores y margen de recursos con la carga esperada. Nombre responsable de decisión y periodo de observación. Un trabajo mensual no queda validado por una mañana satisfactoria. Conserve resultados de controles funcionales además de las métricas de rendimiento.

Volver a un nivel anterior admitido puede mitigar ciertos cambios del procesador de consultas. No revierte el formato de archivos ni permite restaurar una copia del motor nuevo en uno antiguo. El retorno del motor necesita su propio plan probado de migración y conciliación, especialmente después de aceptar escrituras.

Considere también código que empiece a depender de funciones del nuevo nivel. Revertir solo el ajuste puede romper la aplicación. Evite esa dependencia durante el primer ensayo o coordine su reversión. Tras aceptar, conserve las referencias, retire mitigaciones temporales solo mediante mediciones y observe el siguiente ciclo completo. El resultado buscado es una decisión de rendimiento documentada, no únicamente un número mayor.

Referencias técnicas: Microsoft Learn: Upgrade workflow · Microsoft Learn: Compatibility levels · Microsoft Learn: Query Store state.