DBCC freeproccache?

Twoje pytania są wszędzie, więc postaram się odpowiedzieć na wszystkie. Pamięć podręczna procedury jest tylko tak duża. Pamięć podręczna procedury mogła być wypełniona planami jednorazowego użytku (nie ma to wpływu na statystyki, chociaż statystyki mogą mieć wpływ na pamięć podręczną planu). Możesz przeczytać wiele szczegółów na temat planów jednorazowego użytku w poście Kimberly Tripp na blogu „Plan cache and optimizing for adhoc workloads”-w tym zapytanie dotyczące sys.dm_exec_cached_plans, które pomoże zidentyfikować, kiedy pamięć podręczna jest wypełniona wieloma planami jednorazowego użytku. Jak sugeruje, możesz zapobiec tym wzdęciom, korzystając z optimize for ad hoc workloads. Jeśli znajdujesz potrzebę robienia tego często, powiedziałbym, że planowanie freeproccache jako pracy jest plastrem, a nie rozwiązaniem.

aby usunąć „zły” plan, najpierw musisz zidentyfikować „zły” plan. Może to być plan, który przekracza określony rozmiar i / lub nie został zrealizowany w pewnym czasie, lub który został zidentyfikowany przez długotrwałe zapytanie itp. Niestety nie jest łatwo zidentyfikować plan, który jest ofiarą wąchania parametrów, chyba że znasz już zapytanie lub zapytania, które są dotknięte. Załóżmy, że chcesz znaleźć najstarsze plany w pamięci podręcznej, które nie były uruchamiane od ponad tygodnia:

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

teraz musisz zweryfikować, czy naprawdę chcesz usunąć ten plan. Na przykład, jeśli uznasz to zapytanie za coś, co dyrektor generalny może uruchomić jutro, może najlepiej to zostawić. Jeśli chcesz wyczyścić plan, możesz go wyczyścić bezpośrednio, mówiąc:

DBCC FREEPROCCACHE();

to brzmi jak dużo więcej pracy niż uruchamianie DBCC FREEPROCCACHE na całym świecie, ale jeśli masz wiele dobrych planów w pamięci podręcznej, z pewnością będzie to lepsze dla Twoich użytkowników.

jednak to naprawdę brzmi jak plaster. Jeśli pamięć podręczna zapełnia się śmieciami, a wydajność idzie w Kiblu, dopóki nie zwolnisz pamięci podręcznej, musisz spojrzeć na wyższy poziom architektury, sposobu przesyłania zapytań itp. Jest to zachowanie, którego oczekiwałbym od pierwszej iteracji LINQ2SQL, gdzie buforowałoby wersję planu dla zapytania dla każdego argumentu łańcuchowego o innej długości. Więc gdybyś miał parametr 'January’, dostałbyś inny plan niż z parametrem 'February’, ponieważ zdefiniowałby on typ danych jako VARCHAR(7) vs. VARCHAR(8). Jestem pewien, że zachowanie jest stałe, ale nie wiem wystarczająco dużo o środowisku / aplikacji, aby zasugerować, gdzie dokładnie szukać ” złych pomysłów.”