Podczas porównywania czasu wykonania dwóch różnych zapytań ważne jest wyczyszczenie pamięci podręcznej, aby mieć pewność, że wykonanie pierwszego zapytania nie zmieni wydajności drugiego.
W wyszukiwarce Google mogłem znaleźć następujące polecenia:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
W rzeczywistości moje zapytania zajmują więcej czasu po kilku egzekucjach niż wcześniej. Nie jestem jednak pewien, czy jest to zalecana technika.
Jaka jest najlepsza praktyka?
Odpowiedzi:
Osobiście dla wspólnego zapytania drugie i kolejne wykonania mają większe znaczenie.
Czy testujesz wydajność We / Wy dysku lub zapytanie?
Zakładając, że twoje zapytanie jest uruchamiane często i ma kluczowe znaczenie, chcesz zmierzyć to w rzeczywistych warunkach. I nie chcesz wyczyścić pamięci podręcznej serwerów prod za każdym razem ...
Jeśli chcesz to możesz:
DBCC DROPCLEANBUFFERSusuwa czyste (niezmodyfikowane) strony z puli buforów CHECKPOINTaby najpierw spłukać brudne strony na dyskDBCC FLUSHPROCINDB usuwa plany wykonania dla tej bazy danychZobacz także (na DBA.SE)
DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOstąd: stackoverflow.com/questions/7962789/...
Późna odpowiedź, ale może być przydatna dla innych czytelników
DBCC DROPCLEANBUFFERS to często używane polecenie do testowania zapytań i mierzenia prędkości wykonywania zapytań. To polecenie (po uruchomieniu) pozostawia tylko brudne strony, które w rzeczywistości są niewielką porcją danych. Usuwa wszystkie czyste strony dla całego serwera.
Należy pamiętać, że tego polecenia nie należy uruchamiać w środowisku produkcyjnym. Uruchomienie tego polecenia spowoduje głównie pustą pamięć podręczną buforów. Uruchomienie dowolnego zapytania po wykonaniu polecenia DBCC DROPCLEANBUFFERS spowoduje użycie fizycznych odczytów w celu przywrócenia danych do pamięci podręcznej, co najprawdopodobniej będzie znacznie wolniejsze niż pamięć.
Ponownie potraktuj to polecenie podobnie jak DBCC FREEPROCCACHE - nie powinno ono być uruchamiane na żadnym serwerze produkcyjnym, chyba że absolutnie wiesz, co robisz.
Może to być przydatne narzędzie programistyczne, ponieważ można wielokrotnie uruchamiać zapytanie w środowisku testowania wydajności bez żadnych zmian prędkości / wydajności spowodowanych buforowaniem danych w pamięci.
Dowiedz się więcej na: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
Zawsze kazano mi używać:
dbcc dropcleanbuffers;Z MSDN :
Użyj DBCC DROPCLEANBUFFERS do testowania zapytań z zimnym buforem buforowym bez zamykania i restartowania serwera.
Aby usunąć czyste bufory z puli buforów, najpierw użyj PUNKTU KONTROLNEGO, aby utworzyć bufor bufora na zimno. Wymusza to zapisanie wszystkich brudnych stron bieżącej bazy danych na dysku i czyszczenie buforów. Po wykonaniu tej czynności możesz wydać polecenie DBCC DROPCLEANBUFFERS, aby usunąć wszystkie bufory z puli buforów.
DBCC FREEPROCCACHEwyczyścić wszelkie buforowane plany wykonania ...
Pozostałe odpowiedzi są poprawne odnośnie powodów, dla których nie należy uruchamiać DBCC FREEPROCCACHE. Istnieje jednak kilka powodów:
Jeśli chcesz porównać dwa różne zapytania lub procedury, które próbują zrobić to samo na różne sposoby, prawdopodobnie trafią na te same strony. Jeśli naiwnie uruchomisz zapytanie nr 1, a następnie zapytanie nr 2, drugie może być znacznie szybsze po prostu dlatego, że te strony były buforowane przez pierwsze zapytanie. Jeśli wyczyścisz pamięć podręczną przed każdym wykonaniem, zaczną one działać równo.
Jeśli chcesz przetestować wydajność buforowania na gorąco, pamiętaj, aby uruchomić zapytania kilka razy, naprzemiennie i odrzucić pierwsze kilka uruchomień. Średnia wyników.
Załóżmy, że masz zapytanie, które trwa jedną sekundę w przypadku gorącej pamięci podręcznej, ale jedną minutę w przypadku zimnej pamięci podręcznej. Optymalizacja, która powoduje, że zapytanie w pamięci jest o 20% wolniejsze, ale zapytanie związane z IO o 20% szybciej może być dużą wygraną: podczas normalnych operacji nikt nie zauważy dodatkowych 200 ms w normalnych okolicznościach, ale jeśli coś zmusi zapytanie do uruchomić na dysku, a 48 sekund zamiast 60 może zaoszczędzić na sprzedaży.
Jest to mniejszy problem w nowoczesnych systemach z dziesiątkami gigabajtów pamięci i stosunkowo szybką pamięcią SAN i SSD, ale nadal ma to znaczenie. Jeśli jakiś analityk uruchomi masową kwerendę skanowania tabeli w bazie danych OLTP, która wyczyści połowę bufora pamięci podręcznej, zapytania efektywnie korzystające z pamięci szybciej przywrócą szybkość.
DBCC FLUSHPROCINDBWystąpił błąd podczas działania : do instrukcji DBCC podano niepoprawną liczbę parametrów.