web-dev-qa-db-ja.com

「アドホックワークロード用に最適化」を使用しても、アドホッククエリによって肥大化したクエリプランキャッシュ

クエリプランキャッシュの異常と思われる問題に気づきました。キャッシュ内のプランは1日以上前のものではありません。

次のクエリを実行すると( Kimberly Tripp による)、プランの大部分(4.5Gbの6Gbキャッシュプランまたは44813の〜50000)は、使用回数のあるアドホッククエリであることがわかりましたの1。

SELECT objtype AS [CacheType]
    , count_big(*) AS [Total Plans]
    , sum(cast(size_in_bytes as decimal(18,2)))/1024/1024 AS [Total MBs]
    , avg(usecounts) AS [Avg Use Count]
    , sum(cast((CASE WHEN usecounts = 1 THEN size_in_bytes ELSE 0 END) as decimal(18,2)))/1024/1024 AS [Total MBs - USE Count 1]
    , sum(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS [Total Plans - USE Count 1]
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY [Total MBs - USE Count 1] DESC

私は問題のクエリ(動的、もちろんEXECを使って...)を決定しました。これはかなりひどいですが、「修正」するだけでも複雑なので、製。

インスタンスはアドホックワークロードの最適化を使用するようにすでに設定されていますが、sys.dm_exec_cached_plansCacheObjTypeはすべてCompiled Plan StubではなくCompiled Planです=。

アドホックワークロードモードを使用する場合、usecountsが1より大きくなるまで、プランをCompiled Plan Stubにしないでください。それともこれはどのように機能しないのですか?

アドホッククエリについて話すときに誰も参照しないように見えるrefcountsフィールドもあります。 refcountsは、タイプがCompiled Plan Stubの場合は常に1で、タイプがCompiled Planの場合は2です。 [〜#〜] bol [〜#〜] を読んでも、このフィールドの意味がよくわかりません。誰かが明確にできますか?

7
Mark Sinkinson

this によると、アドホックバッチの2回目の実行でスタブが削除され(これは1回だけ使用されました)、プランが作成されてキャッシュされます(最初に使用されます)。

また、refcountsへの参照は、キャッシュオブジェクトによる参照の数であるということを除いて、あまり見かけません。アドホックコンパイル済みプランオブジェクトは、refcountが1のままになる可能性があるため、プランの永続性が原因であるとは限りません。

6
SQLFox