Une base de données subit une dégradation des performances. Il est nécessaire d'identifier les requêtes les plus gourmandes en ressources, de suivre les changements de plan et de trouver les régressions de performance.
→Activer et utiliser Query Store.
Pourquoi: Query Store est l'enregistreur de données de vol intégré pour les performances des requêtes. Il capture automatiquement l'historique des requêtes, les plans et les statistiques d'attente, ce qui en fait l'outil principal pour diagnostiquer les problèmes de performance au fil du temps.
Référence↗
Une requête fonctionne bien parfois mais mal à d'autres moments en raison de problèmes de "parameter sniffing", où un plan d'exécution est optimisé pour une valeur de paramètre non représentative.
→Utiliser Query Store pour identifier les différents plans et forcer le plan d'exécution qui fonctionne constamment bien.
Pourquoi: Le forçage de plan dans Query Store offre un moyen rapide et efficace de stabiliser les performances des requêtes problématiques sans modifier le code. Il remplace le choix de l'optimiseur par un plan connu et performant.
Améliorer les performances des requêtes sans modification du code en tirant parti de fonctionnalités telles que le mode batch sur rowstore, le retour d'informations sur l'octroi de mémoire et la compilation différée des variables de table.
→Définir le niveau de compatibilité de la base de données à 150 (pour les fonctionnalités de SQL 2019) ou plus.
Pourquoi: L'ensemble de fonctionnalités Intelligent Query Processing (IQP) est activé par le niveau de compatibilité de la base de données. Le niveau 150+ active un large éventail d'améliorations de performance "sans modification de code" dans le processeur de requêtes.
L'équipe des opérations doit être avertie lorsque des indicateurs de performance clés, tels que le pourcentage d'utilisation du CPU ou les interblocages, dépassent un seuil défini.
→Utiliser Azure Monitor pour créer des alertes de métriques (pour le CPU) et des alertes de journaux (pour les interblocages) qui déclenchent un groupe d'actions.
Pourquoi: Azure Monitor est la plateforme centralisée pour la surveillance et l'alerte sur les ressources Azure. Les groupes d'actions offrent des canaux de notification flexibles (e-mail, SMS, webhook, etc.).
Améliorer les performances d'écriture en identifiant et en supprimant les index qui ne sont utilisés par aucune requête de lecture.
→Interroger la DMV `sys.dm_db_index_usage_stats`.
Pourquoi: Cette DMV suit l'utilisation de l'index (recherches, analyses, consultations) par rapport aux mises à jour. Les index avec des mises à jour élevées mais une utilisation nulle ou très faible sont les principaux candidats à la suppression, réduisant la charge de maintenance.
Il est nécessaire de capturer des informations détaillées sur les problèmes de blocage intermittents, y compris les instructions et les sessions impliquées dans la chaîne de blocage.
→Configurer une session Extended Events qui capture l'événement `blocked_process_report`.
Pourquoi: Cet événement fournit un rapport XML détaillé des chaînes de blocage lorsque le `blocked process threshold` est dépassé, offrant des informations de diagnostic approfondies non disponibles dans les DMV.
Une base de données doit adapter automatiquement sa stratégie d'indexation aux changements de schémas de charge de travail sans intervention manuelle.
→Activer l'option CREATE_INDEX dans le réglage automatique d'Azure SQL Database.
Pourquoi: Cette fonctionnalité permet à Azure d'analyser la charge de travail, d'identifier les index manquants à fort impact, de les créer et de valider leur bénéfice en termes de performances, automatisant ainsi une tâche clé du DBA.
Décharger les charges de travail de reporting gourmandes en lecture de la base de données OLTP primaire dans un niveau Business Critical ou Premium.
→Modifier les chaînes de connexion en lecture seule de l'application pour inclure `ApplicationIntent=ReadOnly`.
Pourquoi: Ces niveaux incluent une réplique secondaire lisible intégrée et gratuite. La propriété `ApplicationIntent` dans la chaîne de connexion redirige automatiquement les connexions en lecture seule vers cette réplique, isolant les charges de travail de lecture.
Une grande table de faits dans un entrepôt de données est fréquemment utilisée pour des requêtes d'agrégation (SUM, COUNT, AVG) qui sont lentes.
→Créer un index columnstore clusterisé sur la table de faits.
Pourquoi: Les index columnstore stockent les données dans un format colonnaire, offrant une très haute compression des données et permettant l'exécution en mode batch, ce qui accélère considérablement les requêtes analytiques gourmandes en agrégation et en analyse.
Une base de données subit une contention de blocage significative entre les requêtes de lecture (rapports) et les requêtes d'écriture (transactions).
→Activer Read Committed Snapshot Isolation (RCSI) sur la base de données.
Pourquoi: RCSI utilise le versionnement des lignes, permettant aux lecteurs de voir la dernière version validée des données sans prendre de verrous partagés, éliminant ainsi les blocages des écrivains. Les écrivains ne bloquent pas les lecteurs.
Une application utilisant une base de données Serverless subit des temps de connexion initiaux lents après une période d'inactivité.
→Diminuer le délai de pause automatique ou configurer une valeur minimale de vCore supérieure à zéro.
Pourquoi: Le délai est dû à la reprise de la base de données après un état de pause (démarrage à froid). La définition d'une valeur minimale de vCore empêche la base de données de se mettre complètement en pause, éliminant la latence de reprise au prix d'une certaine facturation continue du calcul.
