クエリプランキャッシュの異常と思われる問題に気づきました。キャッシュ内のプランは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_plans
のCacheObjType
はすべてCompiled Plan StubではなくCompiled Planです=。
アドホックワークロードモードを使用する場合、usecounts
が1より大きくなるまで、プランをCompiled Plan Stubにしないでください。それともこれはどのように機能しないのですか?
アドホッククエリについて話すときに誰も参照しないように見えるrefcounts
フィールドもあります。 refcountsは、タイプがCompiled Plan Stubの場合は常に1で、タイプがCompiled Planの場合は2です。 [〜#〜] bol [〜#〜] を読んでも、このフィールドの意味がよくわかりません。誰かが明確にできますか?
this によると、アドホックバッチの2回目の実行でスタブが削除され(これは1回だけ使用されました)、プランが作成されてキャッシュされます(最初に使用されます)。
また、refcounts
への参照は、キャッシュオブジェクトによる参照の数であるということを除いて、あまり見かけません。アドホックコンパイル済みプランオブジェクトは、refcount
が1のままになる可能性があるため、プランの永続性が原因であるとは限りません。