SQLServer2016クエリストアGUIの調査

はじめに

クエリストアはSQLServer2016で導入された新機能であり、データベース管理者はSQL Server Management Studioで使用可能なGUIを使用してクエリとそれに関連する計画を履歴で確認したり、特定の動的管理ビューを使用してクエリのパフォーマンスを分析したりできます。クエリストアはデータベーススコープの構成オプションであり、問題のデータベースの互換性レベルが130の場合に使用できます。

クエリストアは、自動ワークロードリポジトリ（AWR）などのOracleデータベースプラットフォームのテクノロジーに似ています。 AWRは、クエリストアよりもさらに大規模なパフォーマンス統計をキャプチャし、データベース管理者がパフォーマンスを履歴的に分析できるようにします。収集されたデータの保持期間やストレージ制限などの概念は、クエリストアと同様にAWRアーキテクチャでも利用できます。クエリストアを有効にすると、次の主要な構成オプションを使用できます。

操作モード： クエリストアが新しくキャプチャされたデータを受け入れるか（読み取り/書き込みモード）、レポートに使用できる古いデータを単に保存するか（読み取り専用モード）を決定します
データフラッシュ間隔： クエリストアのメモリバッファがディスクにフラッシュされる頻度を決定します。クエリストアのデータは、クエリストアが有効になっているデータベースに保存されていることを思い出してください。デフォルト値は15分です。
統計収集間隔： クエリストアの実行時統計が収集される頻度を決定します。
最大サイズ： クエリストア統計のリポジトリをどれだけ増やすことができるかを決定します。デフォルトでは100MBです。
クエリストアキャプチャモード： クエリキャプチャの粒度を決定します。 ALL、AUTO、およびNONEが使用可能なオプションです。デフォルト値はAUTOです。
サイズベースのクリーンアップモード： 最大サイズに達したときにクエリストアが古いデータをフラッシュするかどうかを決定します。
古いクエリのしきい値： クエリストアがデータを保持する日数を決定します。デフォルト値は30日に設定されています。

図2クエリストアオプション

クエリストアはデータベーススコープの機能であり、GUI（SQL Server Management Studio）を使用するか、次のコマンドを実行することで有効にできます。

 ALTER DATABASE [WideWorldImporters] SET QUERY_STORE =ON;

クエリストアによって収集されたクエリテレメトリは、クエリストアが有効になっているデータベース内のシステムテーブルに保存されます。

サンプルクエリとデフォルトレポート

これまでのところ、私が書いたものはすべて他の多くのソースから入手できます。それらのいくつかは、参照セクションにあります。

このセクションでは、簡単な例を使用してクエリストアを有効にした後、クエリストアで実際に何ができるかをもう少し詳しく見ていきます。次の2つのクエリについて考えてみましょう。

リスト1：特定のフィルターを使用したレコードの取得

use WideWorldImportersgoselecta.ContactPersonID、a.OrderDate、a.DeliveryMethodID、a.Comments、b.OrderedOutersfromPurchasing.PurchaseOrders ainner join Purchasing.PurchaseOrderLines bon a.PurchaseOrderID =b.PurchaseOrderIDwhere a.SupplierReference =' pre>

リスト2：範囲を使用したレコードの取得

大文字で書かれたこれらのクエリの代替バージョンに注意してください：

リスト1：特定のフィルターを使用したレコードの取得（大文字）

USE WIDEWORLDIMPORTERSGOSELECTA.CONTACTPERSONID、A.ORDERDATE、A.DELIVERYMETHODID、A.COMMENTS、B.ORDEREDOUTERSFROMPURCHASING.PURCHASEORDERS AINNER JOIN PURCHASING.PURCHASEORDERLINES BON A.PURCHASEORDERID =B pre>

リスト2：範囲を使用したレコードの取得（大文字）

ご覧のとおり、GOキーワードを使用してこれらのクエリを複数回実行しました。したがって、処理するデータの量はある程度あります。クエリストアを使用してパフォーマンスを分析するときに最初に注意する必要があるのは、図3に示すように、SQLServer2016クエリストアに6つのデフォルトレポートが組み込まれていることです。

図3クエリストアレポート

レポートの名前は、以前の記事とMicrosoftのドキュメントで詳しく説明されています。これらのレポートによって提供されるデータは、以下にリストされている主要な動的管理ビューから取得されます。

計画統計DMV

sys.query_store_query_text –データベースに対して実行された一意のクエリテキストが含まれています
sys.query_store_plan –コンパイル時の統計を含むクエリの推定計画が含まれています
sys.query_context_settings –クエリが実行される設定に影響を与える計画のいくつかの固有の組み合わせが含まれています
sys.query_store_query –クエリストアで個別に追跡および強制されるクエリエントリ

実行時統計DMV

sys.query_store_runtime_stats_interval –クエリストアは、時間を自動的に生成された時間枠（間隔）に分割し、実行された計画ごとにその間隔で集計された統計を保存します
sys.query_store_runtime_stats –実行された計画の集計された実行時統計が含まれます

これらのDMVの使用方法の詳細については、参照されているMicrosoftのドキュメントを参照してください。この記事では、主にGUIを使用します。

図4からわかるように、全体的なリソース消費レポートを確認します。次のセクションでは、前にリストしたクエリと、これらの単純なクエリから取得できるデータに絞り込みます。

図4全体的なリソース消費レポート

GUIを使用したクエリの分析

クエリストアレポートを使用する際には、いくつかの重要な点が役立つと考えてください。

図4で強調表示されているボタンをクリックすると、環境を構成できます。図5は、ユースケースに合わせて変更できる詳細（返されるデータの基準、日付範囲、返されるデータセット）を示しています。たとえば、レビューしているクエリに関連付けられているクエリIDを明確に表示したい場合は、データセットをデフォルトのトップ25からトップ10に減らします。
図5レポート構成オプション

図62018年5月1日に実行された上位25のクエリ

図72018年5月1日に実行された上位10のクエリ
棒グラフは主にx軸に時間とともにデータを表示しますが、特定のデータポイントをドリルダウンして、クエリIDに基づいてデータを表示できます。各クエリIDは、特定のクエリを決定します。クエリはテキストをハッシュすることで一意に識別されることに注意することが重要です。したがって、小文字のクエリは大文字の同じクエリとは異なります。これは一般的な知識である必要があります。アドホッククエリはプランキャッシュの懸念事項であり、スペース使用量と適切な分析の両方の観点からクエリストアにも悪影響を及ぼします。
図8リスト1のクエリ（小文字、クエリ42480）

図9リスト3のクエリ（大文字、クエリ42490）
3番目の重要な観察事項は、データポイントが緑色で強調表示されている場合、下のペインに表示される詳細な実行プランがそのデータポイントに関連しているという事実です。図7では、このデータポイントは以前に実行したクエリID 42481を参照しています（リスト2に示す完全なクエリ）。このデータポイントにマウスを合わせると、クエリ、そのID、およびこのクエリに関連付けられているプランの数が表示されます（図8を参照）。
図10クエリ42481の詳細

クエリストアによって正確にキャプチャされ、図10の棒グラフのy軸（実行回数）に表示されるため、クエリは1391回実行されました。バッチの実行中にレポートがプルされていました。したがって、クエリが実行されるたびにデータがリアルタイムでキャプチャされることを通知するフルカウント（1500）はありません。右側には、これらの複数の実行に使用されているプラン（プラン675）も表示されます。これは、リスト5のクエリを使用して確認できます。

リスト5

 USE WideWorldImportersGOSELECT Txt.query_text_id、Txt.query_sql_text、Pl.plan_id、Qry。* FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt .query_text_idwhere Qry.query_id =42481;

図11DMVからのクエリIDとプランID

少し調整

別のクエリを見てみましょう。

リスト6のクエリを実行し、クエリストアの詳細を調べると、実行プランの詳細から、51％の改善を得るにはインデックスが必要であることがわかります。

リスト6：次善のクエリ

 SELECT TOP（1000）[OrderLineID]、[OrderID]、[StockItemID]、[Description]、[PackageTypeID]、[Quantity]、[UnitPrice]、[TaxRate]、[PickedQuantity]、[PickingCompletedWhen]、[LastEditedBy ]、[LastEditedWhen]FROM[WideWorldImporters]。[Sales]。[OrderLines]whereunitPrice> 1000 GO 2000

図12次善のクエリの詳細

図13次善のクエリ実行プラン

リスト7のステートメントを使用して推奨インデックスを作成したら、QueryOptimizerに新しい実行プランを生成させます。この場合、新しい実行プランによってパフォーマンスが向上することが期待されます。ただし、統計を効果的に無効にしたり、インデックスの数を減らしたりするデータ量の大幅な変更など、特定の変更によってパフォーマンスが低下する場合があります。このようなクエリはパフォーマンスが低下したと言われ、クエリストアの低下したクエリレポートを使用して調べることができます。

リスト7：インデックスの作成

 USE [WideWorldImporters] GOCREATE NONCLUSTERED INDEX [Custom_IX_UnitPrice] ON [Sales]。[OrderLines]（[UnitPrice]）INCLUDE（[OrderLineID]、[OrderID]、[StockItemID]、[Description]、[PackageTypeID]、[Quantity ]、[TaxRate]、[PickedQuantity]、[PickingCompletedWhen]、[LastEditedBy]、[LastEditedWhen]）GO

図14最適化されたクエリ（実行プランの変更）

図15最適化されたクエリ（2つのプラン）

図16最適化されたクエリ（強制計画）

図14と図16に示すように、クエリに複数のプランがある場合、[強制プラン]ボタンをクリックすることで、選択したプランを常に使用するようにオプティマイザーに指示できます。これは、以前のバージョンのSQLServerでは少し面倒な作業でした。

図17からわかるように、Query Storeでは、いくつかのメトリックを使用して、クエリに関連付けられたさまざまなプランを比較できます。

図17実行計画の比較

ここでも、リスト8のクエリを使用して、DMVを使用してこのクエリIDに関連付けられたプランを確認できます。（図11参照）

リスト8：クエリ42497に関連付けられたプラン

 USE WideWorldImportersGOSELECT Txt.query_text_id、Txt.query_sql_text、Pl.plan_id、Qry。* FROM sys.query_store_plan AS PlJOIN sys.query_store_query AS Qry ON Pl.query_id =Qry.query_idJOIN sys.query_store_query_text AS Txt .query_text_idwhere Qry.query_id =42497;

バリエーションの調査

クエリストアが利用できるもう1つの便利なレポートは、バリエーションの多いクエリです。このレポートは、特定の期間における特定のクエリの目的のメトリックがどれだけ離れているかを示します。これは、パフォーマンスの履歴分析に非常に役立ちます。リスト9のステートメントを使用して、バリエーションがどのように見えるかを示すことができるデータを生成します。手順の手順では、小さなテーブルを作成してから、さまざまなバッチサイズを使用してレコードを挿入するだけです。

リスト9：クエリ42497に関連付けられたプラン

 use WideWorldImportersgo-- Tablecreateテーブルを作成しますtableone（ID int Identity（1000,1）、FirstName varchar（30）、LastName varchar（30）、CountryCode char（2）、HireDate datetime2 default getdate（））;-異なるサイズのバッチでレコードを挿入するテーブルワン値に挿入（'Kenneth'、'Igiri'、'NG'、getdate（））; GO 10000テーブルワン値に挿入（'Kwame'、'Boateng'、'GH'、getdate（））; GO 10insert into tableone values（'Philip'、'Onu'、'NG'、getdate（））; GO 100000insert into tableone values（'Kwesi'、'Armah'、'GH'、getdate（））; GO 100

クエリストアには、関心のあるクエリの特定の実行間隔に対するこれらのメトリックの最小値や最大値などの詳細が表示されます。この例では、これは単に実行ごとのバッチ数の結果であることがわかります（パラメータは、実際にはINSERTステートメントの実行に使用されています）。制作では、他の要因がそのような変動の原因である可能性があります。

図18期間の変化

図19論理書き込みのバリエーション

図20物理的読み取りの変動

結論

この記事では、SQL Server 2016クエリストアのGUI環境と、クエリストアを使用したインスタンスのパフォーマンス（SQLに関して）に関して推測できるいくつかのことを確認しました。インターネット上には、さらに高度なユースケースと内部のより深い説明を示すいくつかの記事があります。この記事は、パフォーマンスの評価/調整にクエリストアを使用することを先取りしたい中堅のDBAに役立つはずです。

参考資料

クエリストアのベストプラクティス
Cristiman、L.（2016）クエリストア–設定と制限
クエリストアを使用したパフォーマンスの監視
クエリストアカタログビュー
クエリストアのストアドプロシージャ
クエリストア–その仕組みと使用方法
クエリストアの使用シナリオ
Van de Lar、E.（2016）SQL Server 2016クエリストア：クエリストアを使用した実行プランの強制

便利なツール：

dbForge Query Builder for SQL Server –ユーザーは、手動でコードを記述しなくても、直感的なビジュアルインターフェイスを介して複雑なSQLクエリをすばやく簡単に作成できます。