dbcc freeprocache?

dine spørsmål er over alt, så jeg skal prøve å ta dem alle. Prosedyrebufferen er bare så stor. Prosedyrebufferen kan ha blitt fylt med engangsplaner(dette har ingen innvirkning på statistikk, men statistikk kan påvirke planbufferen). Du kan lese mange detaljer om engangsplaner I Kimberly Tripps blogginnlegg, «Planlegg cache og optimalisering for adhoc-arbeidsbelastninger» – inkludert en spørring mot sys. dm_exec_cached_plans som vil bidra til å identifisere når hurtigbufferen fylles med mange engangsplaner. Som hun antyder, kan du forhindre denne oppblåsthet ved å bruke optimize for ad hoc-arbeidsbelastninger. Hvis du finner behovet for å gjøre dette ofte, vil jeg si at planlegging freeproccache som en jobb er et plaster, ikke en løsning.

for å rydde ut en «dårlig» plan, må du først identifisere den «dårlige» planen. Dette kan være en plan som overstiger en viss størrelse og/eller ikke har blitt utført på en stund, eller som du har identifisert ved en langvarig spørring, etc. Dessverre er det ikke enkelt å identifisere en plan som er et offer for parameter sniffing med mindre du allerede vet spørringen eller spørringer som er påvirket. La oss anta at du vil finne de eldste planene i hurtigbufferen som ikke har blitt kjørt i over en uke:

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

nå må du bekrefte at du virkelig vil rydde ut denne planen. For eksempel, hvis du gjenkjenner spørringen som NOE KONSERNSJEFEN kan kjøre i morgen, er det kanskje best å la det være der. Hvis du vil fjerne planen, kan du fjerne den direkte ved å si:

DBCC FREEPROCCACHE();

dette høres ut som mye mer arbeid enn å kjøre DBCC FREEPROCCACHE globalt, men hvis du har mange gode planer i cachen, vil det sikkert være bedre for brukerne dine generelt.

Likevel høres dette virkelig ut som et plaster. Hvis cachen din fyller opp med søppel og ytelsen går på toalettet til du frigjør cachen, må du se på et høyere nivå på arkitekturen, hvordan spørringer sendes, etc. Dette er oppførselen jeg forventer fra DEN aller første iterasjonen AV LINQ2SQL, hvor DEN ville cache en versjon av en plan for en spørring for hvert strengargument som var en annen lengde. Så hvis du hadde en parameter av ‘januar’, ville du få en annen plan enn med en parameter av ‘februar’ fordi den ville definere datatypen som VARCHAR(7) vs VARCHAR(8). Ganske sikker på at atferd er løst, men jeg vet ikke nok om ditt miljø / program for å foreslå hvor nettopp å lete etter » dårlige ideer.»