DBCC freeproccache?

uw vragen zijn overal, dus Ik zal proberen ze allemaal te beantwoorden. De procedure cache is maar zo groot. Uw procedure cache kan zijn gevuld met plannen voor eenmalig gebruik (dit heeft geen invloed op de statistieken, hoewel statistieken kunnen invloed hebben op de plan cache). U kunt veel details lezen over plannen voor eenmalig gebruik in Kimberly Tripp ‘ s blog post, “Plan cache and optimizing for adhoc workloads”-inclusief een query tegen sys.dm_exec_cached_plans die zal helpen identificeren wanneer de cache is gevuld met veel plannen voor eenmalig gebruik. Zoals ze suggereert, kunt u deze opgeblazen gevoel te voorkomen met behulp van optimize voor ad hoc workloads. Als je de noodzaak vindt om dit vaak te doen, zou ik zeggen dat het plannen van freeproccache als baan een pleister is, geen oplossing.

om een “slecht” plan op te ruimen, moet u eerst het “slecht” plan identificeren. Dit kan een plan zijn dat een bepaalde grootte overschrijdt en / of niet in enige tijd is uitgevoerd, of dat u hebt geïdentificeerd door een langlopende query, enz. Helaas is het niet eenvoudig om een plan dat is een slachtoffer van parameter snuiven te identificeren, tenzij u al weet dat de query of query ‘ s die worden beïnvloed. Laten we aannemen dat je de oudste plannen in de cache wilt vinden die al meer dan een week niet is uitgevoerd:

;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;

nu moet je controleren of je echt wilt wissen van dit plan. Bijvoorbeeld, als je die vraag herkent als iets wat de CEO morgen zou kunnen uitvoeren, is het misschien het beste om het daar te laten. Als u het plan wilt wissen, kunt u het direct wissen door te zeggen:

DBCC FREEPROCCACHE();

dit klinkt als veel meer werk dan het draaien van DBCC FREEPROCCACHE globaal, maar als je veel goede plannen in de cache hebt, zal het zeker beter zijn voor je gebruikers over het algemeen.

toch klinkt dit echt als een pleister. Als uw cache wordt gevuld met rommel en de prestaties gaat in het toilet totdat u de cache vrij te maken, je nodig hebt om te kijken naar een hoger niveau op de architectuur, hoe query ‘ s worden ingediend, enz. Dit is het gedrag dat ik zou verwachten van de allereerste iteratie van LINQ2SQL, waar het een versie van een plan zou cachen voor een query voor elke string argument dat een andere lengte was. Dus als je een parameter van ‘januari’ had, zou je een ander plan krijgen dan met een parameter van ‘februari’ omdat het het gegevenstype zou definiëren als VARCHAR(7) vs. VARCHAR(8). Vrij zeker dat het gedrag is vastgesteld, maar ik weet niet genoeg over uw omgeving / toepassing om te suggereren waar precies te zoeken “slechte ideeën.”