Baza danych SQL Server 2017 Enterprise CU16 14.0.3076.1
Niedawno próbowaliśmy przejść z domyślnych zadań konserwacyjnych Index Rebuild do Ola Hallengren IndexOptimize
. Domyślne zadania przebudowy indeksu działały przez kilka miesięcy bez żadnych problemów, a zapytania i aktualizacje działały z akceptowalnymi czasami wykonania. Po uruchomieniu IndexOptimize
w bazie danych:
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'
wydajność bardzo się pogorszyła. Instrukcja aktualizacji, która wcześniej zajęła 100 ms, IndexOptimize
zajęła później 78 000 ms (przy użyciu identycznego planu), a zapytania były również gorsze o kilka rzędów wielkości.
Ponieważ nadal jest to testowa baza danych (migrujemy system produkcyjny z Oracle), przywróciliśmy kopię zapasową i wyłączono, IndexOptimize
a wszystko wróciło do normy.
Chcielibyśmy jednak zrozumieć, co IndexOptimize
różni się od „normalnego”, Index Rebuild
co mogło spowodować ten ekstremalny spadek wydajności, aby mieć pewność, że unikniemy go po przejściu do produkcji. Wszelkie sugestie dotyczące tego, czego szukać, byłyby bardzo mile widziane.
Plan wykonania instrukcji aktualizacji, gdy jest ona wolna. tj.
po IndexOptimize
Rzeczywisty plan wykonania (jak najszybciej)
Nie byłem w stanie dostrzec różnicy.
Zaplanuj to samo zapytanie, gdy jest szybkie
Rzeczywisty plan wykonania
źródło
Odpowiedź Johna jest poprawnym rozwiązaniem, jest to tylko dodatek do tego, które części planu wykonania uległy zmianie i na przykład, jak łatwo dostrzec różnice w eksploratorze Sentry One Plan
Przeglądając wszystkie plany zapytań, kiedy wydajność spadła, można łatwo dostrzec różnice.
Obniżona wydajność
Dwie liczby ponad 35 sekund czasu procesora i upływu czasu
Oczekiwana wydajność
Dużo lepiej
Główna degradacja występuje dwukrotnie w tym zapytaniu dotyczącym aktualizacji:
plan wykonania dla tego zapytania o obniżonej wydajności
Szacowany plan zapytań dla tego zapytania o aktualizację ma bardzo wysokie oszacowania, gdy wydajność spadła:
Podczas gdy w rzeczywistości (rzeczywisty plan wykonania) wciąż musi działać, po prostu nie jest to szalona kwota, którą pokazują szacunki.
Największy wpływ na wydajność mają poniższe dwa skany i połączenia dopasowania mieszania:
Rzeczywiste skanowanie przy obniżonej wydajności # 1
Rzeczywiste skanowanie przy obniżonej wydajności # 2
Plan wykonania dla tego zapytania z oczekiwaną wydajnością
Gdy porównasz to z szacunkami (lub wartościami rzeczywistymi) planu zapytań z normalną oczekiwaną wydajnością, różnice są łatwe do wykrycia.
Ponadto poprzednie dwa dostępy do tabeli nawet się nie zdarzyły:
Nie widać tej eliminacji przy łączeniu mieszającym, ponieważ wejście kompilacji (górne) jest najpierw wstawiane do tablicy mieszającej. Następnie w tej tabeli mieszającej sondowane są wartości zerowe, zwracające wartości zerowe.
źródło
Bez dodatkowych informacji możemy tylko w ciemności wykonać lekkie, świadomie dźgnięcia, więc powinieneś edytować pytanie, aby podać nieco więcej. Na przykład plany zapytań dla tej instrukcji aktualizacji, dla których podano czasy, zarówno przed operacjami konserwacji indeksu, jak i po nim, ponieważ plany mogą się różnić z powodu zaktualizowania statystyk indeksu ( https://www.brentozar.com/pastetheplan / jest przydatny do tego, zamiast wypełniać pytanie, co może być ogromną częścią XML lub dać zrzut ekranu, który nie zawiera niektórych istotnych informacji zawartych w tekście planu).
Dwa bardzo proste punkty od nietoperza:
źródło