Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Correction automatique du plan dans SQL Server

Combien de temps passez-vous à résoudre les problèmes de performances en tant qu'administrateur ou développeur de base de données ? L'avez-vous déjà suivi ? En tant que pourcentage total moyen de votre journée, cela peut ne pas sembler beaucoup de temps, mais lorsque le problème est grave, vous pouvez passer des heures à le rechercher et à analyser les causes profondes. Parfois, le problème disparaît et vous ne connaissez pas la véritable origine. Et encore pire ? Lorsque vous devez lutter contre ces problèmes au milieu de la nuit ou le week-end. Non seulement vous vous démenez pour résoudre un problème, mais vous perdez votre temps libre personnel. Comment atténuons-nous cela? Comment réduire notre temps et nos efforts à l'équation, tout en améliorant les performances ?

La fonctionnalité de réglage automatique de SQL Server 2017 Enterprise Edition et d'Azure SQL Database est la première étape pour réduire le temps que les professionnels des données consacrent au dépannage et à la résolution des problèmes de performances. La fonctionnalité inclut la correction automatique du plan et la gestion automatique de l'index (uniquement disponibles dans Azure SQL Database), qui sont activées indépendamment. Dans cet article, je souhaite me concentrer sur la fonctionnalité de correction automatique du plan. Avec la correction automatique du plan, si SQL Server constate qu'une requête a régressé de manière significative, il forcera le dernier bon plan connu pour la requête à stabiliser les performances. Essentiellement, plutôt que vous, le DBA ou le développeur, soyez appelé le week-end à propos des performances du système, SQL Server s'en chargera pour vous. Cela semble trop facile, non ? Jetons un coup d'œil.

Sous les couvertures

Tout d'abord, il est essentiel de comprendre que la correction automatique du plan utilise le magasin de requêtes, il doit donc être activé pour la base de données. Deuxièmement, la correction automatique du plan est simplement un forçage automatique du plan. Bien que Query Store soit commercialisé comme enregistreur de vol pour votre base de données qui suit le texte de la requête, les plans, les statistiques d'exécution et les statistiques d'attente, il vous permet également de forcer un plan pour une requête afin de permettre des performances cohérentes. La correction automatique du plan consiste à forcer le plan sans votre intervention.

Activer la correction automatique du plan

Comme mentionné, Query Store doit d'abord être activé pour la base de données utilisateur. Cela peut être fait dans SSMS, avec T-SQL et avec l'API REST pour Azure SQL DB. Notez que Query Store est activé par défaut pour les bases de données dans Azure, et ce depuis le 4e trimestre 2016.


Activation du magasin de requêtes via SSMS 

USE [master];
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE = ON;
GO
ALTER DATABASE [WideWorldImporters] 
	SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

Activation du magasin de requêtes à l'aide de T-SQL

Le code ci-dessus est le T-SQL par défaut de SSMS si vous le scriptez. Dans Azure SQL Database, vous n'exécutez pas l'instruction USE. Si vous souhaitez modifier l'une des options par défaut, veuillez lire mon article sur les paramètres du magasin de requêtes sur ce que sont ces options et les considérations pour les valeurs alternatives.

Une fois le magasin de requêtes activé, vous pouvez utiliser le portail Azure, T-SQL ou l'API EST pour activer la correction automatique du plan dans Azure SQL Database (et C# et PowerShell sont en préparation). Il ne peut être activé qu'avec T-SQL dans SQL Server 2017.


Activation de la correction automatique des plans dans le portail Azure 

ALTER DATABASE [WideWorldImporters] 
	SET AUTOMATIC_TUNING (
		FORCE_LAST_GOOD_PLAN = ON
	);
GO

Activation de la correction automatique du plan dans le T-SQL

Notez que la correction automatique du plan sera activée par défaut pour les nouvelles bases de données dans Azure dans un futur proche. Depuis janvier 2018, le réglage automatique est activé pour les bases de données Azure SQL qui ne l'étaient pas déjà, avec des notifications envoyées aux administrateurs afin que l'option puisse être désactivée si vous le souhaitez.

Comment ça marche

Lorsque la correction automatique du plan est activée, SQL Server surveille les performances des requêtes à l'aide des données du magasin de requêtes. Il recherche un changement significatif* dans les performances du CPU** avec une fenêtre de 48 heures***. Remarquez les astérisques dans cette phrase… ils sont intentionnels :

  • *Le seuil de ce qui constitue un changement significatif n'est pas documenté car Microsoft se réserve le droit de le modifier.
  • ** La métrique utilisée pour déterminer la variation des performances (CPU) n'est pas documentée, car Microsoft se réserve le droit de la modifier. Cela signifie que Microsoft pourrait envisager des dimensions supplémentaires pour examiner les performances si cela était meilleur / plus performant que le processeur seul.
  • ***La période pendant laquelle les données de performances des requêtes sont comparées n'est pas documentée pour la même raison, Microsoft se réserve le droit de la modifier.
  • Remarque :bien que les éléments susmentionnés ne soient pas documentés, j'ai confirmé auprès des personnes appropriées chez Microsoft que ces informations pouvaient être partagées sans enfreindre un NDA. Il est extrêmement important de comprendre que les valeurs ne sont pas fixes et peuvent changer, dans l'espoir qu'elles changeront pour améliorer la fiabilité de la fonctionnalité.

Le manque de documentation et la possibilité de changements de seuil peuvent être frustrants pour certaines personnes, mais voici ce qu'il est vraiment important de retenir :

Microsoft capture quotidiennement des téraoctets de données de télémétrie opérationnelle à partir des bases de données SQL Azure, et ces données sont essentielles pour les fonctionnalités automatiques en cours de développement. Ces données incluent des éléments tels que query_id, query_plan_id et query_hash, et Microsoft ne capture PAS query_text ou query_plan (ils ne consultent pas vos données réelles). Microsoft ne se contente pas d'archiver cette télémétrie opérationnelle ou de l'utiliser pour le dépannage, ils exploitent ces données et les utilisent pour développer des algorithmes et des modèles permettant à SQL Server de prendre des décisions indépendantes et intelligentes.

SQL Server peut tirer parti de la pléthore de données dans le magasin de requêtes qui détaillent les performances des requêtes, et la correction automatique du plan commence par comparer les performances actuelles d'une requête aux performances passées pour déterminer s'il y a une régression des performances. Les performances ont-elles diminué ou se sont détériorées ? Si tel est le cas, sont-elles significatives ?

S'il y a eu une régression des performances de la requête, SQL Server forcera le dernier bon plan connu pour cette requête, qui est bien sûr extrait de Query Store. Mais cela ne s'arrête pas là. SQL Server continue ensuite à surveiller les performances - toujours en utilisant Query Store - pour confirmer que le plan forcé est toujours un bon plan pour cette requête, ce qui signifie que la requête avec le plan forcé fonctionne mieux que la version régressée. Si cette requête ne fonctionne pas mieux, le plan sera annulé. Un plan peut également être non forcé s'il y a une recompilation ou si le forçage échoue.

Ce cycle continue; si une requête a un plan forcé, et que ce plan n'est pas forcé pour l'une des raisons susmentionnées, ce même plan peut être forcé à nouveau plus tard, ou il peut y avoir un autre plan forcé pour cette requête ultérieurement. Il s'agit d'un processus continu qui se produit tant que l'option Correction automatique du plan est activée pour la base de données. Maintenant, ce qui est intéressant, c'est que vous pouvez consulter les mêmes informations que cette fonctionnalité capture et l'utiliser manuellement pour forcer les plans. Autrement dit, dans SQL Server 2017 Enterprise Edition et dans Azure SQL Database, ces données sont collectées dans le DMV sys.dm_db_tuning_recommendations même lorsque la fonctionnalité de correction automatique du plan n'est pas activée, vous pouvez donc examiner ces données et suivre ses recommandations pour forcer les plans pour des requêtes spécifiques par vous-même. Notez que si vous forcez un plan en utilisant les recommandations de sys.dm_db_tuning_recommendations, il ne sera jamais automatiquement dé-forcé. De plus, si vous avez activé la correction automatique du plan et que vous forcez manuellement un plan, il ne sera jamais automatiquement dé-forcé. Seuls les plans qui sont forcés avec la fonction de correction automatique du plan seront automatiquement déforcés.

Est-ce que je vais vraiment laisser le contrôle à SQL Server ?

Si vous êtes sceptique et que vous vous demandez si vous pouvez vraiment faire confiance à SQL Server pour prendre une décision contraignante, voici ce que je vous encourage à retenir :

  1. Cette fonctionnalité a été développée avec une quantité impressionnante de données capturées à partir de près de deux millions de bases de données SQL Azure. Il s'agit d'une nouvelle fonctionnalité de SQL Server 2017, mais elle est devenue disponible dans le monde entier en 2016 dans Azure. Cette fonctionnalité est donc vraiment disponible depuis plus d'un an et a été affinée.
  2. Les ingénieurs ont apporté des modifications à l'algorithme au fil du temps, car ils ont capturé davantage de données. Il se peut qu'il ne trouve pas toutes les régressions qui se produisent - car une régression n'est peut-être pas assez grave, mais je parierais que beaucoup d'entre vous préféreraient avoir cette force caractéristique moins souvent que trop souvent.
  3. En plus de cela, si un plan est forcé mais finit par causer un problème, la capacité de SQL Server à s'en remettre et à annuler le plan est extrêmement fiable et se produit très rapidement.

Résumé

Vous n'êtes peut-être pas à l'aise avec l'idée que SQL Server traite les problèmes de performances pour vous. Mais est-ce un malaise parce que vous pensez qu'il va prendre une mauvaise décision ? Ou craignez-vous que l'automatisation ne prenne le dessus sur votre travail ? Question assez directe, je sais. Si c'est le premier, ma recommandation est de regarder les données capturées dans sys.dm_db_tuning_recommendations (sans activer la correction automatique du plan) et de voir ce que SQL Server voudrait faire. Cela correspond-il à ce que vous feriez ? Trouve-t-il des régressions que vous pourriez manquer ? Si vous ne souhaitez pas activer la fonctionnalité parce que vous craignez de ne plus avoir assez à faire, je vous encourage à lire le récent article de Conor Cunningham, Comment la vitesse du cloud aide les administrateurs de base de données SQL Server. Microsoft n'essaie pas de vous exclure d'un emploi. Ils essaient simplement de gérer les fruits à portée de main afin que vous puissiez vous concentrer sur des tâches plus importantes.