Jak mogę wyczyścić pamięć podręczną zapytań programu SQL Server?


199

Mam proste zapytanie uruchomione przeciwko SQL Server 2005

SELECT * 
FROM Table 
WHERE Col = 'someval'

Pierwsze uruchomienie zapytania może zająć > 15 secs. Kolejne wykonania są z powrotem < 1 sec.

Jak mogę uzyskać, aby SQL Server 2005 nie używał żadnych wyników w pamięci podręcznej? Próbowałem biegać

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

Ale wydaje się, że nie ma to wpływu na szybkość zapytania (nadal < 1 sec).


Odpowiedzi:


259

Oto kilka dobrych wyjaśnień. sprawdź to.

http://www.mssqltips.com/tip.asp?tip=1360

CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO

Z powiązanego artykułu:

Jeśli wszystkie testy wydajności są przeprowadzane w SQL Server, najlepszym rozwiązaniem może być wydanie PUNKTU KONTROLNEGO, a następnie wydanie polecenia DBCC DROPCLEANBUFFERS. Chociaż proces CHECKPOINT jest automatycznym wewnętrznym procesem systemowym w programie SQL Server i występuje regularnie, ważne jest, aby wydać to polecenie, aby zapisać wszystkie brudne strony dla bieżącej bazy danych na dysku i wyczyścić bufory. Następnie można wykonać polecenie DBCC DROPCLEANBUFFERS, aby usunąć wszystkie bufory z puli buforów.


14
Jedną z nocy może być także DBCC FREEPROCCACHE
jaraics

1
Kiedy korzystasz z dropcleanbuffers, dotyczy to każdego, kto jest podłączony do bazy danych, czy tylko tego użytkownika?
Kris Nobels

1
@Kris: DBCC DROPCLEANBUFFERS, usuwa wszystkie czyste bufory z puli buforów. Jest to niezbędny krok dostrajania wydajności zapytań i nie należy go używać na żywo SQL Server.
Saar

Działa to dobrze w przypadku SQL Server, ale należy pamiętać, że to nie działa w SQL Azure - poniżej zamieściłem alternatywne rozwiązanie do obsługi scenariusza SQL Azure.
MSC

1
Dobrze, to jedyne polecenie, które faktycznie działa, próbowałem wielu innych i nie działało.
Gabriel Rodriguez

15

Osiem różnych sposobów na wyczyszczenie pamięci podręcznej planu

1. Usuń wszystkie elementy z pamięci podręcznej planu dla całej instancji

DBCC FREEPROCCACHE;

Użyj tego, aby ostrożnie wyczyścić pamięć podręczną planu. Zwolnienie pamięci podręcznej planu powoduje na przykład rekompilację procedury składowanej zamiast ponownego użycia z pamięci podręcznej. Może to spowodować nagły, tymczasowy spadek wydajności zapytań.

2. Opróżnij pamięć podręczną planu dla całej instancji i pomiń komunikat o regularnym zakończeniu

„Wykonanie DBCC zakończone. Jeśli DBCC wydrukuje komunikaty o błędach, skontaktuj się z administratorem systemu.”

DBCC FREEPROCCACHE WITH NO_INFOMSGS;

3. Opróżnij pamięć podręczną ad hoc i przygotowany plan dla całej instancji

DBCC FREESYSTEMCACHE ('SQL Plans');

4. Opróżnij pamięć podręczną ad hoc i przygotowany plan dla jednej puli zasobów

DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');

5. Opróżnij całą pamięć podręczną planu dla jednej puli zasobów

DBCC FREEPROCCACHE ('LimitedIOPool');

6. Usuń wszystkie elementy z pamięci podręcznej planu dla jednej bazy danych (nie działa w SQL Azure)

-- Get DBID from one database name first
DECLARE @intDBID INT;
SET @intDBID = (SELECT [dbid] 
                FROM master.dbo.sysdatabases 
                WHERE name = N'AdventureWorks2014');

DBCC FLUSHPROCINDB (@intDBID);

7. Wyczyść pamięć podręczną planu dla bieżącej bazy danych

USE AdventureWorks2014;
GO
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

8. Usuń jeden plan zapytań z pamięci podręcznej

USE AdventureWorks2014;
GO

-- Run a stored procedure or query
EXEC dbo.uspGetEmployeeManagers 9;

-- Find the plan handle for that query 
-- OPTION (RECOMPILE) keeps this query from going into the plan cache
SELECT cp.plan_handle, cp.objtype, cp.usecounts, 
DB_NAME(st.dbid) AS [DatabaseName]
FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st 
WHERE OBJECT_NAME (st.objectid)
LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE); 

-- Remove the specific query plan from the cache using the plan handle from the above query 
DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);
 

Źródło 1 2 3


9

Pytanie jest nieco stare, ale może pomóc. Mam podobne problemy i skorzystanie z opcji poniżej pomogło mi. Nie jestem pewien, czy jest to trwałe rozwiązanie, ale na razie to naprawia.

OPTION (OPTIMIZE FOR UNKNOWN)

Wtedy twoje zapytanie będzie takie

select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)

1
Niepoprawna składnia w pobliżu słowa kluczowego „OPTION”. lub Niepoprawna składnia w pobliżu „NIEZNANY”.
pabrams

1
@pabrams Te idą po (w ramach) zapytania w ten sposób:select * from Table where Col = 'someval' OPTION (OPTIMIZE FOR UNKNOWN)
Mark Avenius

1
Upewnij się ABSOLUTNIE, że nie przypadkowo upuścisz coś takiego w kodzie PRODUKCJI - ponieważ może to spowodować poważne problemy na drodze.
Michael K. Campbell

4
OPTYMALIZUJ DLA NIEZNANE nie ignoruje planów buforowanych. Podczas generowania planu instruuje on serwer SQL, aby wybrał „średnie wartości dystrybucji, niezależnie od jakiejkolwiek [automatycznej] parametryzacji” w celu podjęcia decyzji o utworzeniu planu - skutkuje to planami, które mogą być bardziej spójne w niejednorodnych statystykach. OPCJA (RECOMPILE) tworzy nowy plan, ale w inny sposób nie czyści / nie zwalnia pamięci podręcznej danych - zwykle generuje to bardziej idealne plany kosztem regeneracji planu i kosztów buforowania planu.
user2864740,

6
EXEC sys.sp_configure N'max server memory (MB)', N'2147483646'
GO
RECONFIGURE WITH OVERRIDE
GO

Podana wartość pamięci serwera nie jest ważna, o ile różni się od bieżącej.

Btw, rzeczą, która powoduje przyspieszenie nie jest pamięć podręczna zapytań, ale pamięć podręczna danych.


3

Należy pamiętać, że ani DBCC DROPCLEANBUFFERS;ani nie DBCC FREEPROCCACHE;jest obsługiwany w usłudze SQL Azure / SQL Data Warehouse.

Jeśli jednak musisz zresetować pamięć podręczną planu na SQL Azure, możesz zmienić jedną z tabel w zapytaniu (na przykład po prostu dodaj, a następnie usuń kolumnę), będzie to miało efekt uboczny usuwania planu z pamięci podręcznej .

Osobiście robię to jako sposób testowania wydajności zapytań bez konieczności radzenia sobie z buforowanymi planami.

Więcej informacji o pamięci podręcznej procedur SQL Azure tutaj


Nie działało to dla mnie, a potem plan się nie zmienił. Zobacz tutaj stackoverflow.com/questions/46987785/…
Meneghino
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.