salut!
Dans une série d'articles, nous souhaitons partager notre expérience dans le développement et l'exploitation des systèmes de la famille MS Dynamics AX (anciennement Axapta).
À propos de nous
Nous sommes une chaîne de vente au détail relativement jeune de supermarchés "Da!" Au moment d'écrire ces lignes, nous avons un peu plus de 100 magasins. Les principaux processus des activités d'exploitation de la société sont automatisés dans un ensemble de systèmes MS Dynamics Ax 2012 + MS Dynamics 365 FO. Les systèmes fonctionnent 24/7. En moyenne, environ un million de lignes de réception et environ 70 000 lignes de commande d'assemblage passent par le système chaque jour.
Guides du plan
Le réglage des performances Axapts peut être effectué de différentes manières. Le moyen le plus efficace est bien sûr d'optimiser le code source de l'application. Mais il y a des situations où cela pose problème. Ensuite, vous pouvez utiliser l'outil fourni par MS SQL Server SGBD. Il s'appelle - Guide du plan. Apparu dans la version de SQL Server 2005. Mais selon notre ressenti au sein de la communauté Axapters (surtout si l'entreprise n'a pas de DBA professionnel), il n'est pas toujours connu et utilisé. Bien que dans certains cas, son utilisation puisse être très efficace.
Pourquoi?
Voici les principales raisons pour lesquelles vous devriez vous tourner vers cet outil:
1. Données incohérentes dans les paramètres de requête. Le résultat de l'échantillonnage (nombre d'enregistrements) pour le même critère d'échantillonnage (ensemble de champs) diffère selon les valeurs des variables dans les critères d'échantillonnage. Ou, d'une manière plus simple, lorsque la même requête pour différents paramètres d'entrée aboutit à un nombre radicalement différent d'enregistrements (parfois un, parfois dix mille). Cela est dû à ce que l'on appelle le «reniflement» des paramètres de requête. Lorsqu'un plan de requête est créé une fois sous le masque de requête, puis extrait du cache. Ne pas regarder les valeurs de ces mêmes paramètres.
C'est souvent le cas des requêtes qui impliquent des tables InventSum et InventDim. Par exemple, quand dans l'analyse, il n'y a qu'une seule partie pour certaines nomenklatura, et pour d'autres - plusieurs milliers. La première demande à la base de données peut être acheminée pour un article pour lequel la comptabilité par lots est désactivée. L'optimiseur construira un plan de requête pour cela. Et mettez-le dans le cache. La demande suivante à la base de données peut être traitée pour un élément pour lequel la comptabilité par lots est activée. Et distribuez plusieurs milliers d'enregistrements dans la sélection pour InventSum et InventDim. Et pour un tel échantillon, le plan du cache ne sera pas optimal.
Une façon de résoudre ce problème consiste à utiliser l'indicateur forceLiterals dans le corps de la requête. Cela signale au moteur SQL de générer un nouveau plan de requête à chaque fois. Mais cela donne une charge tangible supplémentaire sur le CPU. Et avec les mêmes demandes restantes, l'utilisation d'InventDim n'est pas une option acceptable. Eh bien, vous devez comprendre que l'optimiseur SQL Server n'est pas parfait et parfois, même avec des statistiques complètes, génère des plans étranges.
Et dans ce cas, le Guide du plan vient à la rescousse, à l'aide duquel vous pouvez choisir un plan de requête qui donne une vitesse d'exécution acceptable pour tous les paramètres d'entrée de requête. Et attachez ce plan au masque de requête à l'aide du Guide du plan.
2. L'optimiseur choisit un index qui entraîne des verrous longs. En utilisant le guide de plan, vous pouvez «clouer» l'utilisation d'un index spécifique, ce qui réduira l'échantillon et réduira le nombre de verrous.
3. La source (place dans le code) de la demande problématique ne peut pas être identifiée rapidement et le problème de la baisse des performances de la base de données doit être résolu rapidement.
4. Le code source de l'application ne peut pas être modifié pour une raison quelconque (solution partenaire, requêtes du noyau, etc.). Cela est particulièrement vrai pour D365, qui interdit les superpositions.
Comment?
Je ne décrirai pas en détail un guide étape par étape pour créer un guide de plan. Il y a une bonne description sur le site Web du fournisseur (nous sommes intéressés par le type de plan - SQL) et le réseau a une mer de tutoriels.
Mais il est important de savoir qu'il existe un autre outil SQL Server qui vous sera d'une grande aide si vous devez créer un nouveau guide de plan. Il s'appelle le magasin de requêtes. Apparu en 2016. Une description détaillée de celui-ci ici .
L'idée principale de l'outil est qu'en plus du plan de requête actuel dans le cache, il stocke l'historique complet des plans que l'optimiseur a générés pour un temps donné. Si vous savez que la fonctionnalité problématique fonctionnait "normalement" avant. Je n'ai pas ralenti. Il vous suffit de trouver le plan dont vous avez besoin dans le référentiel et de créer un guide de plan basé sur celui-ci. Malheureusement, en raison des particularités d'Axapta, il est impossible de créer un guide de plan avec un seul bouton «plan de force». Vous devrez copier le plan de requête à partir du référentiel et créer le guide du plan manuellement. Mais cela simplifie encore grandement la tâche.
Il faut également garder à l'esprit que l'utilisation de Query Store entraîne une légère surcharge sur les ressources de calcul du serveur SGBD utilisé. Mais dans notre pratique, ils sont insignifiants et cela peut être négligé.
Exemples de
Voici quelques exemples de Plan Guide tirés de notre véritable base de combat. Veuillez noter qu'il ne s'agit là que d'exemples pertinents pour nos processus commerciaux spécifiques. Ils peuvent ne pas être applicables ou même nuisibles à votre installation.
1. InventSum
Ce guide de plan résout le problème des plans sous-optimaux dans le cas de requêtes pour des éléments avec un petit nombre d'enregistrements dans la table InventDim. À l'aide de ce guide, vous pouvez toujours utiliser le plan optimal pour l'échantillonnage avec un grand nombre de combinaisons de SKU InventDim. Les requêtes d'articles avec peu de SKU seront légèrement plus lentes. Mais ce n'est pas un gros prix à payer pour une vitesse stable et prévisible pour toute combinaison de paramètres d'entrée.
Ces requêtes sont principalement générées par la méthode InventSum :: findSum (). Et selon le regroupement, les modèles de requête peuvent différer légèrement. Donc, en réalité, nous avons un guide de plan plus similaire adapté à différents groupes.
2. InventSumDelta
Ce guide de planification vous permet de créer un plan de requête optimal pour la table InventSumDelta, en évitant les verrous inutiles sur cette table. La spécificité de cette table est telle que les données n'y sont pas stockées. Mais ils sont ajoutés / supprimés de manière très intensive. C'est essentiellement une table de sémaphore. À cet égard, les statistiques normales ne peuvent pas être collectées sur ce tableau. Par conséquent, l'optimiseur générait parfois des plans sous-optimaux entraînant un blocage.
Un peu hors sujet - vous devez également désactiver les verrous de page sur les index pour cette table. Étant donné que la sélection dans ce tableau est toujours effectuée par un identifiant unique, l'escalade des verrous au niveau de la page n'a aucun sens et même nuisible ici.
conclusions
Mais dans le cas général, laissez-moi attirer votre attention une fois de plus, vous ne devez pas abuser de cet outil. Si le code est écrit de manière optimale, les statistiques sont régulièrement mises à jour, les index ne sont pas très fragmentés - l'optimiseur dans la plupart des cas sélectionnera lui-même le bon plan. Mais si le guide de plan est configuré, les critères d'entrée de la demande peuvent tomber de telle sorte que le guide de plan ne fera que nuire.