DBCC freeproccache?

dine spørgsmål er overalt, så jeg vil prøve at adressere dem alle. Proceduren cache er kun så stor. Din procedurecache er muligvis fyldt med engangsplaner (dette har ingen indflydelse på statistikker, selvom statistikker kan påvirke plancachen). Du kan læse en masse detaljer om engangsplaner i Kimberly Tripps blogindlæg, “Planlæg cache og optimering til adhoc-arbejdsbelastninger” – inklusive en forespørgsel mod sys. Som hun foreslår, kan du forhindre denne oppustethed ved at bruge Optimer til ad hoc-arbejdsbyrder. Hvis du finder behovet for at gøre dette ofte, vil jeg sige, at planlægning af freeproccache som et job er et båndhjælpemiddel, ikke en løsning.

for at rydde en “dårlig” plan skal du først identificere den “dårlige” plan. Dette kan være en plan, der overstiger en bestemt størrelse og/eller ikke er blevet udført i nogen tid, eller som du har identificeret ved en langvarig forespørgsel osv. Desværre er det ikke nemt at identificere en plan, der er et offer for parameter sniffing, medmindre du allerede kender forespørgslen eller forespørgsler, der er påvirket. Lad os antage, at du vil finde de ældste planer i cachen, der ikke er kørt i over en uge:

;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 skal du kontrollere, at du virkelig vil rydde denne plan. Genkender denne forespørgsel som noget, som administrerende direktør muligvis kører i morgen, er det måske bedst at lade den være der. Hvis du vil rydde planen, kan du rydde den direkte ved at sige:

DBCC FREEPROCCACHE();

dette lyder som meget mere arbejde end at køre DBCC FREEPROCCACHE globalt, men hvis du har mange gode planer i cachen, vil det helt sikkert være bedre for dine brugere generelt.

stadig lyder dette virkelig som et båndhjælpemiddel. Hvis din cache er fyldt op med junk og ydeevne går i toilettet, indtil du frigøre cachen op, skal du se på et højere niveau på arkitekturen, hvordan forespørgsler indsendes, etc. Dette er den adfærd, jeg ville forvente fra den allerførste iteration af LINK2S, hvor det ville cache en version af en plan for en forespørgsel for hvert strengargument, der var en anden længde. Så hvis du havde en parameter af ‘januar’, ville du få en anden plan end med en parameter af’ februar’, fordi den ville definere datatypen som VARCHAR(7) vs. VARCHAR(8). Temmelig sikker på, at adfærd er fast, men jeg ved ikke nok om dit miljø / applikation til at foreslå, hvor præcist man skal kigge efter “dårlige ideer.”