DBCC freeproccache?

vaše otázky jsou všude, takže se pokusím je všechny oslovit. Mezipaměť procedur je pouze tak velká. Mezipaměť procedur může být vyplněna plány na jedno použití (to nemá žádný dopad na statistiky, i když statistiky mohou ovlivnit mezipaměť plánu). Si můžete přečíst spoustu informací o single-použití plánů v Kimberly Tripp blogu, „Plán cache a optimalizovat pro ad hoc pracovní vytížení“ – včetně dotazu proti sys.dm_exec_cached_plans které vám pomohou určit, kdy je vyrovnávací paměť naplněna spoustu single-použití plánů. Jak navrhuje, můžete tomuto nadýmání zabránit pomocí optimalizace pro pracovní zátěž ad hoc. Pokud zjistíte, že je třeba to udělat často, řekl bych, že plánování freeproccache jako práce je náplast, ne řešení.

Chcete-li vymazat „špatný“ plán, musíte nejprve identifikovat „špatný“ plán. Může to být plán, který přesahuje určitou velikost a / nebo nebyl proveden v určitém čase, nebo který jste identifikovali dlouhodobým dotazem atd. Bohužel není jednoduché identifikovat plán, který je obětí čichání parametrů, pokud již neznáte dotaz nebo dotazy, které jsou ovlivněny. Předpokládejme, že chcete najít nejstarší plány v mezipaměti, který nebyl spustit přes týden:

;WITH x AS ( SELECT TOP 10 qs., qs.plan_handle, txs = qs.statement_start_offset, txe = qs.statement_end_offset, = cp.size_in_bytes, = SUM(cp.usecounts), = MAX(qs.last_execution_time) FROM sys.dm_exec_query_stats AS qs INNER JOIN sys.dm_exec_cached_plans AS cp ON qs.plan_handle = cp.plan_handle WHERE qs.last_execution_time < DATEADD(DAY, -7, CURRENT_TIMESTAMP) GROUP BY qs., qs.plan_handle, cp.size_in_bytes, qs.statement_start_offset, qs.statement_end_offset ORDER BY DESC) SELECT x.plan_handle, size, uses, , = COALESCE(NULLIF( SUBSTRING(t., x.txs/2, CASE WHEN x.txe = -1 THEN 0 ELSE (x.txe - x.txs)/2 END ), ''), t.) FROM x CROSS APPLY sys.dm_exec_sql_text(x.) AS t;

Nyní je třeba ověřit, že jste opravdu chcete vymazat tento plán. Pokud například poznáte tento dotaz jako něco, co by generální ředitel mohl spustit zítra, možná je nejlepší ho tam nechat. Pokud chcete plán vymazat, můžete jej vymazat přímo slovy:

DBCC FREEPROCCACHE();

to zní jako mnohem více práce než běh DBCC FREEPROCCACHE globálně, ale pokud máte v mezipaměti spoustu dobrých plánů, bude to pro vaše uživatele celkově lepší.

přesto to opravdu zní jako náplast. Pokud vyrovnávací paměť je plná harampádí a výkon jde do hajzlu, dokud si zdarma cache, musíte se podívat na vyšší úrovni v architektuře, jak se dotazy budou předloženy atd. To je chování, které bych očekával od první iterace LINQ2SQL, kde by cache verze plánu pro dotaz pro každý řetězec argument, že byla jiná délka. Takže pokud byste měli parametr „Leden“, měli byste jiný plán než s parametrem „únor“, protože by definoval datový typ jako VARCHAR(7) vs. VARCHAR(8). Jsem si jistý, že chování je opraveno, ale nevím dost o vašem prostředí / aplikaci, abych navrhl, kde přesně hledat “ špatné nápady.“