Azure SQL Database での高い CPU の診断とトラブルシューティング

適用対象: Azure SQL データベース

Azure SQL Database は、高 CPU 使用率の原因を特定し、ワークロードのパフォーマンスを最適化するための組み込みツールを提供します。 これらのツールを使用して、高 CPU 使用率のトラブルシューティングを、発生中、またはインシデントの完了後に事後対応的に行うことができます。 また、自動チューニングを有効にして、データベースの CPU 使用率を時間の経過とともに事前に削減することもできます。 この記事では、Azure SQL Database の組み込みツールを使用して高 CPU 使用率の診断とトラブルシューティングを行う方法と、CPU リソースを追加する場合について説明します。

仮想コア数について

高 CPU 使用率のインシデントを診断する場合は、データベースで使用できる仮想コア (仮想コア) の数を把握すると便利です。 仮想コアは論理 CPU と同等です。 仮想コアの数は、データベースで使用できる CPU リソースを理解するのに役立ちます。

Azure portal で仮想コア数を特定する

プロビジョニングされたコンピューティング レベルで仮想コアベースのサービス レベルを使用している場合は、Azure portal でデータベースの仮想コア数をすばやく特定できます。 この場合、データベースの [概要] ページに表示される価格レベルには、仮想コア数が表示されます。 たとえば、データベースの価格レベルは "General Purpose: Standard シリーズ (Gen5)、16 仮想コア" です。

サーバーレス コンピューティング レベル のデータベースの場合、仮想コア数は常にデータベースの最大仮想コア設定と同じになります。 仮想コア数は、データベースの [概要] ページに表示される価格レベルに表示されます。 たとえば、データベースの価格レベルは "General Purpose: サーバーレス、Standard シリーズ (Gen5)、16 仮想コア" です。

DTU ベースの購入モデルでデータベースを使用している場合は、Transact-SQL を使用してデータベースの仮想コア数のクエリを実行する必要があります。

Transact-SQL を使用して仮想コア数を特定する

Transact-SQL を使用して、任意のデータベースの現在の仮想コア数を特定できます。 SQL Server Management Studio (SSMS)、Azure Data Studio、または Azure portal クエリ エディター を使用して、Azure SQL データベースに対して Transact-SQL を実行できます。

データベースに接続し、次のクエリを実行します。

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

高 CPU 使用率の原因を特定する

Azure portal、SSMS のクエリ ストア対話型ツール、および SSMS と Azure Data Studio の Transact-SQL クエリを使用して、CPU 使用率を測定および分析することができます。

Azure portal とクエリ ストアには、完了したクエリの実行統計情報 (CPU メトリックなど) が表示されます。 1 つ以上の実行時間の長いクエリによって引き起こされている可能性がある高 CPU 使用率のインシデントが現在発生している場合は、Transact-SQL で現在実行中のクエリを特定します。

新規および異常な高 CPU 使用率の一般的な原因は次のとおりです。

• 大量の CPU を使用するワークロード内の新しいクエリ。
• 定期的に実行されるクエリの頻度の増加。
• パラメーター依存プラン (PSP) の問題による回帰を含むクエリ プランの回帰。その結果、1 つ以上のクエリがより多くの CPU を消費します。
• クエリ プランのコンパイルまたは再コンパイルの大幅な増加。
• クエリが過剰な並列処理を使用するデータベース。

高 CPU 使用率のインシデントの原因を理解するには、データベースに対して高 CPU 使用率が発生している時期と、その時点で CPU を使用している上位のクエリを特定します。

次のことを確認します。

• かなりの CPU を使用する新しいクエリがワークロードに表示されていますか、それとも定期的に実行されているクエリの頻度が増加していますか? 調査するには、次のいずれかの方法を使用します。 履歴が制限されているクエリ (新しいクエリ) と、履歴がより長いクエリの実行頻度を探します。
  • Azure portal で CPU メトリックと関連する上位クエリを確認する
  • Transact-SQL を使用して、CPU 使用率別に上位 15 件のクエリを実行する。
  • SSMS で対話形式のクエリ ストア ツールを使用して、CPU 時間で上位のクエリを識別する
• ワークロード内の一部のクエリは、実行ごとに以前よりも多くの CPU を使用していますか? その場合、クエリ実行プランは変更されていますか? これらのクエリは、パラメーター依存プラン (PSP) の問題が発生している可能性があります。 調査するには、次のいずれかの手法を使用します。 CPU 使用率が大幅に変化する複数のクエリ実行プランを含むクエリを探します。
  • Transact-SQL を使用して、CPU 使用率別に上位 15 件のクエリを実行する。
  • SSMS で対話形式のクエリ ストア ツールを使用して、CPU 時間で上位のクエリを識別する
• 大量のコンパイルまたは再コンパイルが発生している証拠はありますか? 最も頻繁にコンパイルされるクエリをクエリ ハッシュでクエリを実行し、それらがコンパイルされる頻度を確認します。
• クエリは過剰な並列処理を使用していますか? MAXDOP データベース スコープ構成のクエリを実行し、仮想コア数を確認します。 多くの場合、過剰な並列処理は、MAXDOP が 0 に設定されているデータベースで、仮想コア数が 8 より大きい場合に発生します。

Note

Azure SQL Database には、高可用性とディザスター リカバリー、データベースのバックアップと復元、監視、クエリ ストア、自動調整などのコア サービス機能を実装するためのコンピューティング リソースが必要です。これらのコンピューティング リソースの使用は、仮想コア数が少ないデータベースや、高密度エラスティック プール内のデータベースで特に顕著になる可能性があります。 Azure SQL Database でのリソース管理について説明します。

Azure portal で CPU 使用率メトリックと関連する上位クエリを確認する

Azure portal を使用して、時間の経過とともにデータベースで使用される使用可能な CPU の割合など、さまざまな CPU メトリックを追跡します。 Azure portal では、CPU メトリックとデータベースのクエリ ストアからの情報を組み合わせます。これにより、特定の時点でデータベース内の CPU を使用したクエリを特定することができます。

CPU 割合メトリックを見つけるには、次の手順に従います。

1. Azure portal でデータベースに移動します。
2. 左側のメニューの [インテリジェント パフォーマンス] で、[Query Performance Insight] を選択します。

Query Performance Insight の既定のビューには、24 時間分のデータが表示されます。 CPU 使用率は、データベースに使用される使用可能な CPU の合計に対する割合として表示されます。

その期間に実行されている上位 5 つのクエリは、CPU 使用率グラフの上の縦棒に表示されます。 グラフで時間帯を選択するか、[カスタマイズ] メニューを使用して特定の期間を調べます。 表示されるクエリの数を増やすこともできます。

高 CPU 使用率を示す各クエリ ID を選択して、クエリの詳細を開きます。 詳細には、クエリ テキストとクエリのパフォーマンス履歴が含まれます。 最近クエリの CPU が増加したかどうかを確認します。

クエリ ID をメモして、次のセクションのクエリ ストアを使用してクエリ プランをさらに調査します。

Azure portal で特定された上位クエリのクエリ プランを確認する

次の手順に従って、SSMS の対話型クエリ ストア ツールでクエリ ID を使用して、時間の経過に伴うクエリの実行プランを確認します。

1. SSMS を開きます。
2. オブジェクト エクスプローラーで Azure SQL Database に接続します。
3. オブジェクト エクスプローラーで、データベース ノードを展開します。
4. [クエリ ストア] フォルダーを展開します。
5. [追跡対象のクエリ] ウィンドウを開きます。
6. 画面の左上にある [追跡クエリ] ボックスにクエリ ID を入力し、Enter キーを押します。
7. 必要に応じて、[構成] を選択して、CPU 使用率が高かった時間に一致するように時間間隔を調整します。

このページには、最新の 24 時間のクエリの実行プランと関連するメトリックが表示されます。

Transact-SQL を使用して現在実行中のクエリを特定する

Transact-SQL を使用すると、現在実行中のクエリを、これまでに使用した CPU 時間で特定できます。 Transact-SQL を使用して、データベース内の最近の CPU 使用率、CPU 別の上位クエリ、最も頻繁にコンパイルされたクエリを照会することもできます。

SQL Server Management Studio (SSMS)、Azure Data Studio、または Azure portal クエリ エディターを使用して、CPU メトリックのクエリを実行できます。 SSMS または Azure Data Studio を使用する場合は、新しいクエリ ウィンドウを開き、(master データベースではなく) お使いのデータベースに接続します。

次のクエリを実行して、CPU 使用率と実行プランを含む現在実行中のクエリを検索します。 CPU 時間はミリ秒単位で返されます。

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

このクエリは、実行プランの 2 つのコピーを返します。 列 query_plan には、sys.dm_exec_query_plan からの実行プランが含まれています。 このバージョンのクエリ プランには行数の見積もりだけが含まれ、実行の統計は含まれません。

列 query_plan_with_in_flight_statistics が実行プランを返す場合、このプランは詳細を提供します。 query_plan_with_in_flight_statistics 列は sys.dm_exec_query_statistics_xml からデータを返します。これには、現在実行中のクエリによってこれまでに返された実際の行数など、"処理中" の実行統計が含まれます。

最後の 1 時間の CPU 使用率メトリックを確認する

sys.dm_db_resource_stats に対する次のクエリは、直前の約 1 時間の 15 秒間隔の平均 CPU 使用率を返します。

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

avg_cpu_percent 列にのみ注目しないことが重要です。 avg_instance_cpu_percent 列には、ユーザーと内部の両方のワークロードで使用される CPU が含まれています。 avg_instance_cpu_percent が 100% に近い場合、CPU リソースは飽和状態です。 この場合、アプリのスループットが不十分な場合、またはクエリの待機時間が長い場合は、高 CPU 使用率のトラブルシューティングを行う必要があります。

Azure SQL Database でのリソース管理について説明します。

その他のクエリについては、sys.dm_db_resource_stats の例を参照してください。

CPU 使用率別に上位 15 件のクエリを実行する

クエリ ストアは、クエリの実行の統計 (CPU 使用率を含む) を追跡します。 次のクエリは、過去 2 時間に実行された上位 15 件のクエリを CPU 使用率で並べ替えたクエリを返します。 CPU 時間はミリ秒単位で返されます。

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

このクエリは、クエリのハッシュ値でグループ化されます。 number_of_distinct_query_ids 列に高い値が見つかった場合は、頻繁に実行されるクエリが適切にパラメーター化されていないかどうかを調べてください。 パラメーター化されていないクエリは、実行ごとにコンパイルされる可能性があります。これは、CPU を大量に消費し、クエリ ストアのパフォーマンスに影響を与えます。

個々のクエリの詳細については、クエリ ハッシュをメモし、それを使用して特定のクエリ ハッシュの CPU 使用率とクエリ プランを特定します。

最も頻繁にコンパイルされたクエリをクエリ ハッシュで照会する

クエリ プランのコンパイルは、CPU を集中的に使用するプロセスです。 Azure SQL Database は再利用のためにプランをメモリ内にキャッシュします。 一部のクエリは、パラメーター化されていない場合、または RECOMPILE ヒントによって強制的に再コンパイルされる場合に、頻繁にコンパイルされる可能性があります。

クエリ ストアは、クエリがコンパイルされる回数を追跡します。 次のクエリを実行して、クエリ ストアの上位 20 の クエリを、コンパイル数と 1 分あたりの平均コンパイル数で特定します。

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

個々のクエリの詳細については、クエリ ハッシュをメモし、それを使用して特定のクエリ ハッシュの CPU 使用率とクエリ プランを特定します。

特定のクエリ ハッシュの CPU 使用率とクエリ プランを特定する

次のクエリを実行して、特定の query_hash の個々のクエリ ID、クエリ テキスト、およびクエリ実行プランを検索します。 CPU 時間はミリ秒単位で返されます。

@query_hash 変数の値をワークロードに対して有効な query_hash に置き換えます。

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

このクエリは、クエリ ストアの履歴全体にわたって、query_hash の実行プランのバリエーションごとに 1 つの行を返します。 結果は合計 CPU 時間で並べ替えられます。

対話型クエリ ストア ツールを使用して、CPU 使用率の履歴を追跡する

グラフィック ツールを使用する場合は、次の手順に従って SSMS で対話型クエリ ストア ツールを使用します。

1. SSMS を開き、オブジェクト エクスプローラーでデータベースに接続します。
2. オブジェクト エクスプローラーで、データベース ノードを展開します
3. [クエリ ストア] フォルダーを展開します。
4. [全体的なリソース消費量] ウィンドウを開きます。

過去 1 か月間のデータベースの合計 CPU 時間 (ミリ秒単位) は、ウィンドウの左下の部分に表示されます。 既定のビューでは、CPU 時間は日別に集計されます。

ウィンドウの上部にある [構成] を選択して、別の期間を選択します。 集計の単位を変更することもできます。 たとえば、特定の日付範囲のデータを表示し、時間別にデータを集計することができます。

対話型クエリ ストア ツールを使用して CPU 時間別に上位クエリを特定する

グラフのバーを選択して詳しく見て、特定の期間に実行されているクエリを確認します。 [最もリソース消費量の多いクエリを特定し調整する] が開きます。 または、オブジェクト エクスプローラーでデータベースの下にある クエリ ストア ノードから [最もリソースを消費するクエリ] を直接開くこともできます。

既定のビューでは、[最もリソースを消費するクエリ] ウィンドウに、[期間 (ミリ秒)] でクエリが表示されます。 継続時間は CPU 時間よりも短い場合があります。並列処理を使用するクエリでは、全体的な継続時間よりもはるかに多くの CPU 時間が使用される場合があります。 待機時間が長いと、継続時間は CPU 時間よりも長くなる場合もあります。 CPU 時間別のクエリを表示するには、ウィンドウの左上にある [メトリック] ドロップダウンを選択し、[CPU 時間 (ミリ秒)] を選択します。

左上のボックスの各バーがクエリを表します。 バーを選択すると、そのクエリの詳細が表示されます。 画面の右上のボックスには、そのクエリのクエリ ストア内の実行プランの数が表示され、実行された日時と選択したメトリックの使用量に応じてマップされています。 各プラン ID を選択して、画面の下半分に表示されるクエリ実行プランを制御します。

Note

クエリ ストア ビューと、上位のリソース コンシューマー ビューに表示される図形を解釈するガイドについては、「クエリ ストアを使用する際のベスト プラクティス」を参照してください

CPU 使用率を削減する

トラブルシューティングの一部には、前のセクションで特定したクエリの詳細を含める必要があります。 CPU 使用率は、インデックスの調整、アプリケーション パターンの変更、クエリのチューニング、データベースの CPU 関連の設定の調整を行うことで削減できます。

• ワークロードに大量に CPU を使用する新しいクエリが表示されることがわかった場合は、それらのクエリに対してインデックスが最適化済みであることを確認します。 インデックスを手動で調整したり、インデックスの自動チューニングを使用して CPU 使用率を減らしたりすることができます。 ワークロードの増加に対して並列処理の最大限度設定が正しいかどうかを評価します。
• クエリの全体的な実行回数が以前よりも多いことがわかった場合は、CPU 消費量のクエリが最も多いインデックスを調整し、インデックスの自動チューニングを検討してください。 ワークロードの増加に対して並列処理の最大限度設定が正しいかどうかを評価します。
• パラメーター依存プラン (PSP) に問題があるワークロードでクエリが見つかった場合は、プランの自動修正 (プランの強制) を検討してください。 クエリ ストアでプランを手動で強制的に適用したり、クエリの Transact-SQL を調整したりして、一貫して高パフォーマンスのクエリ プランにすることもできます。
• 大量のコンパイルまたは再コンパイルが発生している証拠が見つかった場合は、クエリを調整して、適切にパラメーター化されるか、再コンパイルのヒントを必要としないようにします。
• クエリで過剰な並列処理が使用されていることがわかった場合は、並列処理の最大限度を調整します。

このセクションでは、次の戦略を検討してください。

インデックスの自動チューニングを使用して CPU 使用率を削減する

インデックスの効果的なチューニングにより、多くのクエリの CPU 使用率が削減されます。 最適化されたインデックスは、クエリの論理および物理読み取りを減らし、多くの場合、クエリで必要な作業が少なくなります。

Azure SQL Database は、プライマリ レプリカ上のワークロードに対する自動インデックス管理を提供します。 自動インデックス管理では、機械学習を使用してワークロードを監視し、データベースの行ストア ディスク ベースの非クラスター化インデックスを最適化します。

Azure portal で、インデックス推奨設定を含むパフォーマンスに関する推奨事項を確認します。 これらの推奨事項を手動で適用するか、CREATE INDEX 自動チューニング オプションを有効にして、データベース内の新しいインデックスのパフォーマンスを作成して確認することができます。

プランの自動修正 (プランの強制) を使用して CPU 使用率を削減する

高 CPU 使用率のインシデントのもう 1 つの一般的な原因は、実行プランの選択の機能低下です。 Azure SQL Database では、プライマリ レプリカ上のワークロードのクエリ実行プランの機能低下を特定するためのプランの強制の自動チューニング オプションが提供されます。 この自動チューニング機能を有効にすると、Azure SQL Database は、クエリ実行プランの強制により、実行プランの機能低下でクエリのパフォーマンスが確実に向上するかどうかをテストします。

データベースが 2020 年 3 月より後に作成された場合、プランの強制の自動チューニング オプションが自動的に有効になります。 この時期より前にデータベースが作成された場合は、プランの強制の自動チューニング オプションを有効にすることができます。

インデックスを手動で調整する

「高 CPU 使用率の原因を特定する」で説明されている方法を使用して、CPU 消費量が上位のクエリのクエリ プランを特定します。 これらの実行プランを使用すると、クエリを高速化するために、非クラスター化インデックスを特定して追加することができます。

データベース内の各ディスク ベースの非クラスター化インデックスは、ストレージ領域を必要とし、SQL ストレージ エンジンによって維持される必要があります。 可能な場合は新しいインデックスを追加するのではなく既存のインデックスを変更し、新しいインデックスによって CPU 使用率が正常に削減されるようにしてください。 非クラスター化インデックスの概要については、「非クラスター化インデックスのデザイン ガイドライン」を参照してください。

一部のワークロードでは、頻繁に読み取るクエリの CPU 使用率を削減する場合に、列ストア インデックスが最適な選択肢になる可能性があります。 列ストア インデックスが適切な場合のシナリオに関する高度な推奨事項については、「列ストア インデックス - 設計ガイダンス」を参照してください。

アプリケーション、クエリ、およびデータベース設定を調整する

上位のクエリを調べると、"煩雑な" 動作、シャーディングの恩恵を受けるワークロード、最適でないデータベース アクセス設計など、アプリケーションのアンチパターンが見つかる場合があります。 読み取り負荷の高いワークロードの場合は、頻繁に読み取るデータをスケールアウトするための長期的な戦略として、読み取り専用クエリ ワークロードをオフロードする読み取り専用レプリカとアプリケーション層のキャッシュを検討してください。

また、ワークロードで特定されたクエリを使用して、上位の CPU を手動で調整することもできます。 手動チューニング オプションには、Transact-SQL ステートメントの書き換え、クエリ ストアでのプランの強制、クエリ ヒントの適用が含まれます。

クエリでパフォーマンスに最適ではない実行プランが使用されるケースを特定する場合は、パラメーター依存プラン (PSP) の問題が発生しているクエリに関するページに記載されている回避策を確認してください

多数のプランを含むパラメーター化されていないクエリを特定する場合は、長さと精度を含むパラメーター データ型を完全に宣言するようにして、これらのクエリをパラメーター化することを検討してください。 これは、クエリの変更、特定のクエリのパラメーター化を強制するプラン ガイドの作成、またはデータベース レベルでの強制パラメーター化の有効化によって実行できます。

コンパイル率が高いクエリを特定する場合は、頻繁なコンパイルの原因を特定します。 頻繁なコンパイルの最も一般的な原因は、RECOMPILE ヒントです。 可能な限り、RECOMPILE ヒントがいつ追加され、どのような問題が解決されたのかを特定します。 代替のパフォーマンス チューニング ソリューションを実装して、頻繁に実行されるクエリに対して RECOMPILE ヒントなしで一貫したパフォーマンスを提供できるかどうかを調査します。

並列処理の最大限度を調整して CPU 使用率を削減する

並列処理の最大限度 (MAXDOP) の設定は、データベース エンジンのクエリ内並列処理を制御します。 通常、MAXDOP 値が高いほど、クエリあたりの並列スレッドの数が増え、クエリの実行が高速化されます。

場合によっては、多数の並列クエリが同時に実行されていると、ワークロードの速度が低下し、CPU 使用率が高くなる可能性があります。 過剰な並列処理は、MAXDOP が高い数またはゼロに設定されている仮想コアの数が多いデータベースで発生する可能性が最も高くなります。 MAXDOP がゼロに設定されている場合、データベース エンジンによって、並列スレッドで使用されるスケジューラの数が、論理コアの合計数または 64 のいずれか小さい方に設定されます。

Transact-SQL を使用して、データベースの並列処理の最大限度を特定できます。 SSMS または Azure Data Studio を使用してデータベースに接続し、次のクエリを実行します。

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

データベースレベルで MAXDOP 構成を少し変更するか、クエリ ヒントを使って問題のあるクエリを個別に変更して既定以外の MAXDOP を使用することを検討してください。 詳細については、並列処理の最大限度の構成に関するページの例を参照してください。

CPU リソースを追加するタイミング

ワークロードのクエリとインデックスが適切にチューニングされていることや、パフォーマンス チューニングには内部プロセスなどの理由で短期的に行えなかった変更が必要であることがわかる場合があります。 CPU リソースの追加は、これらのデータベースにとってメリットがある可能性があります。 最小限のダウンタイムでデータベースのリソースをスケーリングすることができます。

仮想コア購入モデルを使用して、仮想コア数またはデータベースのハードウェア構成を構成することで、Azure SQL Database に CPU リソースをさらに追加できます。

DTU ベースの購入モデルでは、サービス レベルを上げ、データベース トランザクション ユニット (DTU) の数を増やすことができます。 DTU は、CPU、メモリ、読み書きを組み合わせた指標を表します。 仮想コア購入モデルの利点の 1 つは、使用中のハードウェアと仮想コア数を細かく制御できるという点です。 Azure SQL Database を DTU ベースのモデルから仮想コア ベースのモデルに移行して、購入モデル間で移行できます。

関連するコンテンツ

次の記事で、Azure SQL Database の監視とパフォーマンス チューニングの詳細について確認します。

• 動的管理ビューを使用した Azure SQL Database および Azure SQL Managed Instance のパフォーマンスの監視
• SQL Server のインデックスのアーキテクチャとデザイン ガイド
• クエリの監視とワークロード パフォーマンスの向上のために Azure portal で自動チューニングを有効にする
• クエリ処理アーキテクチャ ガイド
• クエリ ストアを使用する際のベスト プラクティス
• Azure SQL Database での検出可能なクエリ パフォーマンス ボトルネックの種類
• Azure SQL Database でのデッドロックの分析と防止