次の方法で共有

Azure SQL Database および Azure SQL Managed Instance での自動チューニング

  • [アーティクル]

適用対象: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database および Azure SQL Managed Instance の自動チューニングでは、AI と機械学習に基づく継続的なパフォーマンス チューニングによって、最大限のパフォーマンスと安定したワークロードが実現されます。

自動チューニングはフル マネージドのインテリジェントなパフォーマンス サービスであり、組み込みのインテリジェンスを使用してデータベースに対して実行されるクエリを継続的に監視し、パフォーマンスを自動的に改善します。 これは変動するワークロードに対してデータベースを適応させること、およびチューニングの推奨事項を適用することを動的に実施することで実現しています。 自動チューニングは、AI を介して Azure 上のすべてのデータベースから水平方向に学習し、チューニング操作を動的に改善します。 自動チューニングが有効な状態で Azure SQL Database を実行している時間が長くなるほど、パフォーマンスが向上します。

Azure SQL Database と Azure SQL Managed Instance の自動チューニングは、安定して最高のパフォーマンスのデータベース ワークロードを提供できるようにする機能の中で、最も影響の大きいものの 1 つかもしれません。

Azure SQL の自動チューニングの核となるロジックは、データベース エンジンの SQL Server 自動チューニング機能でも使用されています。 組み込みインテリジェンスのしくみに関する技術的な情報の詳細については、SQL Server の自動チューニングに関する記事をご覧ください。

自動チューニングでできること

  • データベースのパフォーマンスの自動チューニング
  • パフォーマンス向上の自動検証
  • 自動ロールバックと自己修正
  • チューニングの履歴
  • 手動でデプロイするためのアクション Transact-SQL (T-SQL) スクリプトのチューニング
  • 数十万のデータベースのスケールアウト機能
  • DevOps リソースと総保有コストに対する良い影響

安全性、信頼性、実証済み

データベースに適用されるチューニング操作は、最も負荷の高いワークロードのパフォーマンスに対して完全に安全な操作です。 このシステムは、ユーザーのワークロードに干渉しないように注意して設計されています。 自動チューニングの推奨事項は、CPU、データ IO、ログ IO の使用率が低い時間帯にのみ適用されます。 システムは、ワークロードのパフォーマンスを損なわないように、自動チューニング操作を一時的に無効にすることもできます。 その場合、"システムによって無効にされている" というメッセージが、Azure portal と sys.database_automatic_tuning_options DMV に表示されます。 自動チューニングは、ユーザー ワークロードのリソースの優先度が最高になるように設計されています。

自動チューニングは非常に成熟したしくみですが、Azure で実行されている数百万のデータベース上でさらに洗練されたものになりました。 適用される自動チューニング操作は自動的に検証されて、ワークロードのパフォーマンスが明らかに改善していることが確認されます。 改善していない場合、またはほとんどありませんがパフォーマンスが低下している場合は、自動チューニングによって行われた変更が速やかに元に戻されます。 記録されたチューニングの履歴には、Azure SQL Database の各データベースに対して行われたチューニングによる改善の明確なトレースが存在します。

自動チューニングのしくみ

自動チューニングの有効化

自動チューニング オプション

Azure SQL Database および Azure SQL Managed Instance で使用可能な自動チューニング オプションは次のとおりです。

自動チューニング オプション 説明 単一データベースとプールされたデータベースのサポート インスタンス データベースのサポート
CREATE INDEX ワークロードのパフォーマンスを向上させる可能性があるインデックスを特定し、インデックスを作成して、クエリのパフォーマンスが向上したことを自動的に確認します。 新しいインデックスを推奨する場合、システムはデータベースで使用可能な領域を考慮します。 インデックスを追加すると、領域使用率が最大データ サイズの 90% を超えると推定される場合、インデックスの推奨事項は生成されません。 システムは、使用率の低い期間を識別し、インデックスの作成を開始すると、リソース使用率が予期せず増加しても、この操作を一時停止またはキャンセルすることはありません。 インデックスの作成が失敗した場合、その後の使用率が低い期間中に再試行されます。 クラスター化インデックスまたはヒープが 10 GB を超えるテーブルには、インデックスに関する推奨事項は提供していません。 はい いいえ
DROP INDEX 未使用 (過去 90 日間) と重複したインデックスを削除します。 一意なインデックス (主キーと一意制約をサポートするインデックスを含む) は削除されません。 このオプションは、インデックス ヒントを指定したクエリがワークロード内に存在する場合、またはワークロードがパーティションの切り替えを実行する場合に、自動的に無効になることがあります。 Premium および Business Critical サービス レベルでは、このオプションを使用しても未使用のインデックスは削除されませんが、重複するインデックスが存在する場合は削除されます。 はい いいえ
FORCE LAST GOOD PLAN (プランの自動修正) 以前の良好なプランより遅い実行プランを使用している Azure SQL クエリを特定し、その遅いプランの代わりに、最後に確認された良好なプランの使用をクエリに強制します。 はい はい

SQL Database の自動チューニング

Azure SQL Database の自動チューニングでは、CREATE INDEX、DROP INDEX、および FORCE_LAST_GOOD_PLAN データベース アドバイザーの推奨を使用して、データベースのパフォーマンスが最適化されます。 詳細については、Azure portal での Database Advisor の推奨事項、PowerShell、および REST API を参照してください。

Azure portal を使用してチューニングの推奨事項を手動で適用するか、または自動チューニングでチューニングの推奨事項を自律的に適用することができます。 システムで自律的にチューニングの推奨事項を自動適用する利点として、ワークロードのパフォーマンスが向上することが自動的に検証され、パフォーマンスの顕著な向上が検出されない場合、またはパフォーマンスが低下している場合は、行われた変更がシステムによって自動的に元に戻されます。 クエリの実行頻度によっては、検証プロセスに 30 分から 72 時間かかる場合があり、実行頻度が低いクエリほど時間がかかります。 検証中のいずれかの時点で回帰が検出された場合、変更はすぐに元に戻されます。

重要

T-SQL を使用してチューニングの推奨事項を適用する場合は、パフォーマンスの自動検証および取り消しメカニズムは使用できません。 そのような方法で適用された推奨事項は、24 時間から 48 時間、アクティブなままになり、チューニングの推奨事項の一覧に表示された後、システムによって自動的に取り消されます。 推奨事項をすぐに削除する場合は、Azure portal から破棄できます。

自動チューニング オプションをデータベースごとに個別に有効または無効にすることも、サーバーレベルで構成し、サーバーから設定を継承するすべてのデータベースに適用することもできます。 新しいサーバーは、自動チューニングに関する Azure の既定の設定を、既定で継承します。 Azure の既定値では、FORCE_LAST_GOOD_PLAN は有効、CREATE_INDEX は無効、DROP_INDEX は無効に設定されます。

自動チューニングの構成に推奨される方法は、サーバーで自動チューニング オプションを構成し、親サーバーに属するデータベースで設定を継承することです。 これにより、多数のデータベースの自動チューニング オプションの管理が簡単になります。

自動チューニングの推奨情報に関するメール通知の作成については、「自動チューニングの電子メール通知」を参照してください。

Azure SQL Managed Instance の自動チューニング

SQL Managed Instance の自動チューニングでは、FORCE LAST GOOD PLAN のみがサポートされます。 T-SQL による自動チューニング オプションの構成の詳細については、自動チューニングでの自動プラン修正の導入と自動プラン修正に関するページを参照してください。

自動チューニング履歴

Azure SQL Database の場合、自動チューニングによって行われた変更の履歴は 21 日間保持されます。 Azure portal のデータベースに関する [パフォーマンスの推奨事項] ページで、または PowerShell の Get-AzSqlDatabaseRecommendedAction コマンドレットを使って、それを見ることができます。 さらに長く保持するため、AutomaticTuning 診断設定を有効にすることで、複数の種類の宛先に履歴データをストリーミングすることもできます。

次のステップ