Niveau de compatibilité : préparer une migration mesurable

Installer un moteur SQL Server plus récent et augmenter le niveau de compatibilité sont des changements liés, mais distincts. Les mélanger avec un nouveau schéma, des index modifiés et une livraison applicative rend une régression inutilement difficile à expliquer. Une migration contrôlée crée des points de comparaison permettant de relier le comportement d'une requête à une modification précise.

Établir deux références séparées

Relevez version exacte du moteur, niveau de compatibilité, paramètres propres à la base et réglages applicatifs importants. Restaurez une copie représentative sur le moteur cible avec un ancien niveau encore pris en charge, puis évaluez ce premier état. Conserver le niveau ne reproduit pas intégralement l'ancien moteur : infrastructure, correctifs et autres comportements peuvent différer.

Cet inventaire en lecture seule s'exécute dans la base évaluée. La vue Query Store nécessite les permissions de consultation adaptées à la version installée. Conservez le résultat avec la date et l'identifiant de la charge de test.

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;

Un état souhaité READ_WRITE ne prouve pas que Query Store enregistre actuellement. Contrôlez état réel, espace consommé et cause éventuelle de lecture seule. Capture et rétention doivent conserver la référence pendant toute la comparaison. Un stockage plein peut arrêter l'enregistrement précisément quand les preuves deviennent indispensables.

Choisissez une charge couvrant distributions de paramètres et cycle métier complet : plus gros client, résultats vides, clôture mensuelle et concurrence. Rejouer uniquement des recherches ponctuelles de journée ne qualifie pas les rapports nocturnes. Gardez comparables données, statistiques, ressources et parallélisme des demandes, ou consignez explicitement les différences.

Traiter le niveau comme une expérience

Sur une instance de test SQL Server 2022, une base restée au niveau 150 peut être évaluée séparément au niveau 160. Le modèle commenté nomme volontairement une base d'exercice. Vérifiez la prise en charge sur le moteur réel avant adaptation. Un numéro de compatibilité ne fournit pas un moteur absent.

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

Notez l'heure du changement pour éviter de mélanger les intervalles Query Store avant et après. Une recompilation peut accompagner la transition. Distinguez compilation initiale, réchauffement du cache et exécution durable. Ne videz pas systématiquement le cache de plans de toute l'instance : vous introduiriez un autre événement affectant les bases voisines.

Comparez nombres d'exécutions et coûts ensemble. Une durée moyenne améliorée peut cacher une requête rare mais essentielle devenue très lente. Plus de CPU total peut simplement correspondre à davantage de demandes. Examinez durées représentatives, CPU, lectures, plans et concurrence. Utilisez la télémétrie applicative pour les distributions de latence utilisateur plutôt que d'attendre tous les percentiles des agrégats Query Store.

En cas de régression, comparez lignes estimées et réelles, choix de jointure, réservations mémoire et sensibilité aux paramètres. Gardez les deux plans et testez l'hypothèse sur les mêmes données. Un plan antérieur peut servir de mesure ciblée, mais vérifiez le succès du forçage et sa pertinence pour plusieurs paramètres. Donnez à cette mesure un responsable et une date de réexamen.

Définir validation et véritable repli

Écrivez les critères mesurables avant intervention : latence critique, échéance du traitement, taux d'erreur et réserve de ressources à charge attendue. Nommez décideur et durée d'observation. Si le cycle inclut un traitement mensuel, une journée réussie ne fournit qu'une preuve partielle.

Revenir à un ancien niveau pris en charge peut atténuer certains changements du traitement des requêtes. Cela ne rétrograde pas le format des fichiers et ne rend pas une sauvegarde du nouveau moteur restaurable sur un ancien. Le retour du moteur exige donc son propre plan testé de migration et rapprochement, surtout après de nouvelles écritures.

Tenez aussi compte du code applicatif utilisant des fonctions exigeant le nouveau niveau. Revenir uniquement sur le réglage peut casser ce contrat. Écartez cette dépendance du premier essai ou coordonnez explicitement son retour. Après validation, gardez la référence, retirez les mesures temporaires seulement après mesure et surveillez le prochain cycle métier complet.

Références techniques: Microsoft Learn: Upgrade workflow · Microsoft Learn: Compatibility levels · Microsoft Learn: Query Store state.