SQLServerでの自動プラン修正

データベース管理者または開発者として、パフォーマンスの問題のトラブルシューティングにどのくらいの時間を費やしていますか？あなたはそれを追跡したことがありますか？ 1日の平均合計パーセンテージとしては、それほど時間はかからないように見えるかもしれませんが、問題が深刻な場合は、何時間もかけて問題を追跡し、根本原因分析を行うことができます。問題が解決し、本当の原因がわからない場合があります。そしてさらに悪いことに？深夜や週末にこれらの問題と戦わなければならないとき。問題を解決するためにスクランブリングをしているだけでなく、個人的な自由時間を失っています。どうすればそれを軽減できますか？時間と労力を方程式から取り除き、同時にパフォーマンスを修正するにはどうすればよいですか？

SQL Server 2017EnterpriseEditionとAzureSQLDatabaseの自動調整機能は、データの専門家がトラブルシューティングとパフォーマンスの問題の解決に費やす時間を削減するための最初のステップです。この機能には、自動プラン修正と自動インデックス管理（Azure SQLデータベースでのみ使用可能）が含まれ、これらは個別に有効になります。この投稿では、自動プラン修正機能に焦点を当てたいと思います。自動プラン修正を使用すると、SQL Serverがクエリが大幅に後退したことを検出すると、クエリの最後に認識された適切なプランによってパフォーマンスが安定します。基本的に、DBAまたは開発者ではなく、週末にシステムパフォーマンスについて呼び出されると、SQLServerがそれに対処します。簡単すぎると思いませんか？見てみましょう。

カバーの下

まず、自動プラン修正はクエリストアを使用するため、データベースで有効にする必要があることを理解することが重要です。第二に、自動計画修正は単に自動計画強制です。クエリストアは、クエリテキスト、プラン、実行時統計、待機統計を追跡するデータベースのフライトレコーダーとして販売されていますが、クエリのプランを強制して一貫したパフォーマンスを実現することもできます。自動計画修正は、ユーザーの介入なしに計画を強制することです。

自動プラン修正の有効化

前述のように、クエリストアは最初にユーザーデータベースに対して有効にする必要があります。これは、SSMS、T-SQL、およびAzureSQLDB用のRESTAPIを使用して実行できます。クエリストアはAzureのデータベースでデフォルトで有効になっており、2016年第4四半期から有効になっていることに注意してください。

SSMSによるクエリストアの有効化

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

T-SQLを使用したクエリストアの有効化

上記のコードは、スクリプトを作成した場合のSSMSのデフォルトのT-SQLです。 Azure SQL Databaseでは、USEステートメントを実行しません。デフォルトのオプションのいずれかを変更する場合は、それらのオプションとは何か、および代替値に関する考慮事項についてのクエリストア設定の投稿をお読みください。

クエリストアを有効にすると、Azure Portal、T-SQL、またはEST APIを使用して、Azure SQLデータベースで自動プラン修正を有効にできます（（C＃とPowerShellが機能しています）。T-SQLでのみ有効にできます。 SQLServer2017で。

Azureポータルでの自動プラン修正の有効化

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

T-SQLでの自動プラン修正の有効化

近い将来、Azureの新しいデータベースで自動プラン修正がデフォルトで有効になることに注意してください。 2018年1月以降、自動チューニングはまだ有効になっていないAzure SQLデータベースで有効になり、管理者に通知が送信されるため、必要に応じてオプションを無効にできます。

仕組み

自動プラン修正を有効にすると、SQLServerはクエリストアデータを使用してクエリのパフォーマンスを監視します。これは、48時間のウィンドウ***でCPU**パフォーマンスの大幅な変化*を探します。その文のアスタリスクに注意してください…それらは意図的なものです：

• *重要な変更を構成するしきい値は、Microsoftが変更する権利を留保しているため、文書化されていません。
• **パフォーマンスの変化（CPU）を決定するために使用されるメトリックは、Microsoftが変更する権利を留保しているため、文書化されていません。つまり、Microsoftは、CPUだけの場合よりもパフォーマンスが優れている/パフォーマンスが優れている場合は、パフォーマンスを確認するために追加のディメンションを検討できます。
• ***クエリパフォーマンスデータが比較される期間は、同じ理由で文書化されていないため、Microsoftはそれを変更する権利を留保します。
• 注：前述の項目は文書化されていませんが、この情報がNDAの違反と共有される可能性があることをMicrosoftの適切な担当者に確認しました。値は固定されておらず、変更される可能性があることを理解することが非常に重要です。機能の信頼性を向上させるために値が変更されることを期待しています。

ドキュメントが不足していることや、しきい値が変更される可能性があることは、一部の個人にとっては苛立たしいことかもしれませんが、覚えておくべき本当に重要なことは次のとおりです。

Microsoftは、SQL Azureデータベースからテラバイト単位の運用テレメトリデータを毎日キャプチャしており、そのデータは、開発中の自動機能にとって重要です。このデータには、query_id、query_plan_id、query_hashなどが含まれ、Microsoftはquery_textまたはquery_planをキャプチャしません（実際のデータを確認していません）。 Microsoftは、単にその運用テレメトリをアーカイブしたり、トラブルシューティングに使用したりするのではなく、そのデータをマイニングし、SQLServerが独立したインテリジェントな決定を行えるようにするアルゴリズムとモデルを開発するために使用しています。

SQL Serverは、クエリのパフォーマンスを詳細に示すクエリストア内の大量のデータを利用できます。自動プラン修正は、クエリの現在のパフォーマンスを過去のパフォーマンスと比較して、パフォーマンスに低下があるかどうかを判断することから始まります。パフォーマンスが低下したか、悪化しましたか？もしそうなら、それはかなりの量ですか？

クエリのパフォーマンスに低下があった場合、SQL Serverは、そのクエリの最後の既知の適切なプランを強制します。これは、もちろんクエリストアから取得されます。しかし、それだけではありません。次に、SQL Serverは、引き続きクエリストアを使用してパフォーマンスを監視し、強制プランがそのクエリに適したプランであることを確認します。つまり、強制プランを使用したクエリのパフォーマンスは、リグレッションバージョンよりも優れています。そのクエリのパフォーマンスが向上していない場合は、計画が強制されなくなります。再コンパイルがある場合、または強制が失敗した場合も、計画を強制解除することができます。

このサイクルは続きます。クエリに強制プランがあり、前述の理由の1つでそのプランが強制されていない場合、同じプランが後で再度強制されるか、後でそのクエリに対して別のプランが強制される可能性があります。これは、データベースに対して自動計画修正オプションが有効になっている限り発生する継続的なプロセスです。ここで興味深いのは、この機能がキャプチャするのと同じ情報を確認し、それを使用して計画を手動で強制できることです。つまり、SQL Server 2017EnterpriseEditionおよびAzureSQLDatabaseでは、自動プラン修正機能が有効になっていない場合でも、このデータはsys.dm_db_tuning_recommendations DMVに収集されるため、そのデータを調べて、その推奨事項に従ってプランを強制することができます。独自の特定のクエリ用。 sys.dm_db_tuning_recommendationsからの推奨事項を使用してプランを強制する場合、自動的に強制が解除されることはないことに注意してください。さらに、自動プラン修正が有効になっていて、手動でプランを強制した場合、自動的に強制が解除されることはありません。自動プラン修正機能で強制されたプランのみが自動的に強制解除されます。

本当にSQLServerに制御を任せるつもりですか？

懐疑的で、SQL Serverを信頼して計画を強制する決定を下せるかどうか疑問に思っている場合は、次のことを覚えておくことをお勧めします。

1. この機能は、約200万のAzureSQLデータベースからキャプチャされた膨大な量のデータを使用して開発されました。これはSQLServer2017の新機能ですが、2016年にAzureでグローバルに利用できるようになったため、この機能は1年以上にわたって実際に利用可能になり、改良されました。
2. エンジニアは、より多くのデータをキャプチャしたため、時間の経過とともにアルゴリズムに変更を加えてきました。発生するすべてのリグレッションが見つかるとは限りません。リグレッションは十分に深刻ではない可能性があるためですが、多くの人は、この機能を頻繁に使用するよりも少ない頻度で使用することをお勧めします。
3. さらに、計画が強制されても問題が発生した場合、SQL Serverがそれから回復して計画を強制解除する機能は非常に信頼性が高く、非常に迅速に実行されます。

概要

SQLServerがパフォーマンスの問題に対処するという考えに慣れていない可能性があります。しかし、あなたはそれが悪い決定をするだろうと思うので、その不快感はありますか？それとも、自動化があなたの仕事を引き継ぐことを心配していますか？かなり直接的な質問です、私は知っています。前者の場合は、sys.dm_db_tuning_recommendationsでキャプチャされたデータを（自動プラン修正を有効にせずに）調べて、SQLServerが何をしたいかを確認することをお勧めします。それはあなたがすることと一致していますか？あなたが見逃すかもしれない回帰を見つけますか？突然十分な機能がなくなるのではないかと心配してこの機能を有効にしたくない場合は、ConorCunninghamの最近の投稿「クラウド速度がSQLServerDBAにどのように役立つか」を読むことをお勧めします。マイクロソフトは、あなたを仕事から外そうとはしていません。彼らは、あなたがより重要なタスクに集中できるように、手に負えない果物を処理しようとしているだけです。