SQLコンパイルはSQL Serverのパフォーマンスにどの程度影響しますか?


20

SQL Server 2005のインスタンスをプロファイリングしていますが、PerfMonのSQLServer:SQL Statistics - SQL Compilations/secメトリックを使用すると、平均が約170程度であることがわかります。

SQLプロファイラーを作成し、SP:CompileまたはSQL:Compileイベントを探しました。どうやら存在しません。私が見つけたStored Procedure/SP:RecompileTSQL/SQL:StmtRecompileのイベント。プロファイラーに表示されるデータの量は、これらが間違ったイベントであることを示唆していますが、よくわかりません。

だから私の質問。これらのいずれかの答えは素晴らしいでしょう。

  1. SQL Serverで何がコンパイルされているかを正確に確認するにはどうすればよいですか?
  2. 間違った指標を選んで調べましたか?PerfmonまたはSQL Profilerのどちらですか?
  3. Stored Procedure/SP:RecompileおよびTSQL/SQL:StmtRecompileSQLプロファイラでのイベント...彼らは、期間メトリックが含まれていません。これらのイベントがシステムへのタイミングの影響を確認する方法を提供しない場合、システムへのこれらのイベントの影響をどのように測定できますか。

回答:


33

SQL Compilations / secは良い指標ですが、Batch Requests / secと組み合わせた場合のみです。単独では、1秒あたりのコンパイル数はあまりわかりません。

170が表示されています。1秒あたりのバッチリクエストが200にすぎない場合(実際には少し誇張されています)、はい、原因の最下部に到達する必要があります(アドホッククエリと使い捨てプランの過剰使用)。しかし、1秒あたりのバッチ要求が約5000である場合、1秒あたり170のコンパイルはまったく悪くありません。一般的な経験則として、Compilations / secBatch Requests / secの合計の10%以下にする必要があります。

キャッシュされているものにドリルダウンする場合は、適切なDMVを使用する次のクエリを実行します。

select
    db_name(st.dbid) as database_name,
    cp.bucketid,
    cp.usecounts,
    cp.size_in_bytes,
    cp.objtype,
    st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

すべての使い捨てプラン(カウント)を取得するには:

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

キャッシュされたすべてのプランと比較した、使い捨てカウントプランの数の比率を取得するには:

declare @single_use_counts int, @multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,
    @multi_use_counts as multi_use_counts,
    @single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

SQL Serverトレースを介してキャプチャされた期間に関しては、再コンパイルイベントでは使用できません。ケースバイケースの状況でできることはあまりないので、計画のコンパイルが引き起こす期間や痛みを見るのはそれほど重要ではありません。解決策は、計画の再利用(パラメーター化されたクエリ、ストアドプロシージャなど)によってコンパイルと再コンパイルを制限することです。


9

PerfMon(または別のサードパーティソリューション)を使用して記録する必要がある3つの関連するカウンターがあります。重要な点は、これらの統計を何らかの形で記録することです。

  • SQL Statistics \バッチ要求/秒
  • SQL統計\ SQLコンパイル/秒
  • SQL Statistics \ SQL再コンパイル/秒

トーマス・ストリンガーが述べた、それはコンパイル/バッチ要求の比率に目を維持するために良いことです。明らかに、低いほど良いですが、「良い」ものに対するガイドラインのみがあり、あなただけが許容できるものを決定できます。コンパイルの回数を減らすことによって表示されるパフォーマンスゲインの絶対量は、多くの要因に依存します。

また、クエリプランの再利用の量を把握するために、再コンパイル/コンパイルの比率を調べるのも好きです。繰り返しますが、低いほど良いです。ただし、この場合、統計の変化に応じてシステムで再コンパイルを実行する必要があります(DBが読み取り専用で再コンパイルがある場合...何かが間違っている可能性があります)。前に言ったように、「良い」ことについてのガイドラインのみがあります。

あなたが本当にしたいのは、これらの数値を経時的にトレンド化することですので、どちらかの比率に大きなスパイクが見られる場合、クエリプランを正しく使用していないものが展開されました(理想的にはテスト中にキャッチされます)-Sharkのを使用してください分析クエリにより、犯人を見つけます。さらに、頻繁に再コンパイルされるクエリを見つけるための1つを次に示します。

SELECT TOP 50
    qs.plan_generation_num,
    qs.execution_count,
    qs.statement_start_offset,
    qs.statement_end_offset,
    st.text
    FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    WHERE qs.plan_generation_num > 1
    ORDER BY qs.plan_generation_num DESC

CPU使用率の統計も記録している場合は、すべての統計を相互に関連付けて、どれだけ痛いのか、修正がどれだけ役立つのかを知ることができます。実際には、コアsprocでの1つの悪いクエリプラン戦略でさえ、サーバーをひざまずかせることがあります。明らかにYMMV。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.