こんにちは！
一連の投稿で、MS Dynamics AXファミリー（以前のAxapta）のシステムの開発と運用における経験を共有したいと思います。
私たちに関しては
私たちは食料品スーパーマーケット「ダ！」の比較的若い小売チェーンです。この記事の執筆時点では、100を超える店舗があります。同社の営業活動の主なプロセスは、MS Dynamics Axe 2012 + MS Dynamics 365FOシステムのバンドルで自動化されています。システムは24時間年中無休で動作します。平均して、1日あたり約100万の受領ラインと約70,000の組立注文ラインがシステムを通過します。
計画ガイド
パフォーマンスチューニングAxaptsはさまざまな方法で実行できます。もちろん、最も効率的な方法は、アプリケーションのソースコードを最適化することです。しかし、これが問題となる状況があります。次に、MS SQL ServerDBMSが提供するツールを使用できます。それは呼ばれます-計画ガイド。SQL Server 2005のバージョンで登場しました。しかし、Axaptersコミュニティでの私たちの気持ちによると（特に会社にプロのDBAがいない場合）、彼は常に知られ、使用されているわけではありません。場合によっては、その使用は非常に効果的ですが。
何のために？
このツールに目を向けるべき主な理由は次のとおり
です。1。クエリパラメータのデータに一貫性がない。同じサンプリング基準（フィールドのセット）のサンプリング結果（レコード数）は、サンプリング基準の変数の値によって異なります。または、より簡単な方法で、異なる入力パラメーターに対する同じクエリの結果、レコード数が根本的に異なる場合（1つ、場合によっては1万）。これは、リクエストパラメータのいわゆる「スニッフィング」によるものです。クエリプランがクエリマスクの下で一度作成され、キャッシュから取得されたとき。これらの同じパラメータの値を見ていません。
これは、InventSumテーブルとInventDimテーブルを含むクエリの場合によくあります。たとえば、分析では、一部のnomenklaturaには1つのパーティしかなく、他のパーティには数千のパーティしかありません。データベースへの最初の要求は、バッチアカウンティングが無効になっているアイテムに対して実行できます。オプティマイザは、そのクエリプランを作成します。そしてそれをキャッシュに入れます。データベースへの次のリクエストは、バッチアカウンティングが有効になっているアイテムに対して実行できます。そして、InventSumとInventDimの選択で数千のレコードを配ります。そして、そのようなサンプルの場合、キャッシュからの計画は最適ではありません。
この問題を解決する1つの方法は、リクエスト本文でforceLiteralsヒントを使用することです。これは、SQLエンジンに、毎回新しいクエリプランを生成するように通知します。ただし、これにより、CPUに具体的な負荷が追加されます。また、同じ残りのリクエストでInventDimを使用することは受け入れられないオプションです。 SQL Serverオプティマイザは完全ではなく、完全な統計があっても、奇妙な計画が生成される場合があることを理解する必要があります。
そしてこの場合、プランガイドが役に立ちます。これを利用して、クエリ入力パラメータに対して許容可能な実行速度を提供するクエリプランを選択できます。そして、プランガイドを使用してこのプランをクエリマスクに添付します。
2.オプティマイザは、長いロックが発生するインデックスを選択します。プランガイドを使用すると、特定のインデックスの使用を「絞り込み」、サンプルを絞り込み、ロックの数を減らすことができます。
3.問題のある要求のソース（コード内の場所）をすばやく特定することはできず、データベースのパフォーマンス低下の問題を迅速に解決する必要があります。
4.アプリケーションのソースコードは、何らかの理由（パートナーソリューション、カーネルからの要求など）で変更できません。これは、オーバーレイを禁止するD365に特に当てはまります。
どうやって？
プランガイドを作成するためのステップバイステップガイドについては詳しく説明しません。ベンダーのウェブサイトに良い説明があります（私たちは計画のタイプに興味があります-SQL）そしてネットワークにはたくさんのチュートリアルがあります。
ただし、新しいプランガイドを作成する必要がある場合に非常に役立つ別のSQLServerツールがあることを知っておくことが重要です。これはクエリストアと呼ばれます。 2016年に登場。詳細な説明はこちら。
このツールの主なアイデアは、キャッシュ内の現在のクエリプランに加えて、オプティマイザーが特定の期間に形成したプランの履歴全体を保存することです。問題のある機能が以前は「正常に」機能していたことがわかっている場合。減速しませんでした。リポジトリで必要なプランを見つけて、それに基づいてプランガイドを作成するだけです。残念ながら、Axaptaの特性により、1つの「強制計画」ボタンで計画ガイドを作成することはできません。リポジトリからクエリプランをコピーして、プランガイドを手動で作成する必要があります。しかし、これでもタスクは大幅に簡素化されます。
また、クエリストアを使用すると、使用するDBMSサーバーの計算リソースにわずかなオーバーヘッドが発生することにも注意してください。しかし、私たちの実践では、それらは重要ではなく、これは無視することができます。
の例
これが私たちの実際のバトルベースからのプランガイドの例です。これらは、特定のビジネスプロセスに関連する単なる例であることに注意してください。それらは適用できないか、インストールに有害でさえないかもしれません。
1. InventSum
このプランガイドは、InventDimテーブルのレコード数が少ないアイテムのクエリの場合の次善のプランの問題を解決します。このガイドを使用すると、多数のInventDimSKUの組み合わせでサンプリングするための最適な計画をいつでも使用できます。 SKUが少ないアイテムのクエリは、少し遅くなります。しかし、これは、入力パラメータの任意の組み合わせに対して安定した予測可能な速度を支払うのに大きな代償ではありません。
これらのクエリは、主にInventSum :: findSum（）メソッドによって生成されます。また、グループ化によっては、クエリパターンが若干異なる場合があります。したがって、実際には、グループ化のさまざまなバリエーションに適合した、より類似したプランガイドがあります。
2. InventSumDelta
このプランガイドでは、InventSumDeltaテーブルの最適なクエリプランを作成して、このテーブルの不要なロックを回避できます。このテーブルの特異性は、データがテーブルに保存されないようなものです。しかし、それらは非常に集中的に追加/削除されます。これは本質的にセマフォテーブルです。この点で、このテーブルでは通常の統計を収集できません。したがって、オプティマイザは最適ではないプランを生成してブロックすることがありました。
少しオフトピック-このテーブルでも、インデックスのページロックを無効にする必要があります。このテーブルからの選択は常に一意のIDによって行われるため、ロックをページレベルにエスカレートすることは無意味であり、ここでは有害ですらあります。
結論
しかし、一般的なケースでは、もう一度注意を向けさせてください。このツールを悪用しないでください。コードが最適に記述されている場合、統計は定期的に更新され、インデックスはあまり断片化されていません。ほとんどの場合、オプティマイザは正しいプラン自体を選択します。ただし、プランガイドが構成されている場合、リクエストの入力基準が外れ、プランガイドが害を及ぼすだけになる可能性があります。