Wielkość próbki i czas trwania AKTUALIZACJI STATYSTYK:czy to ma znaczenie?

W przypadku każdej nowej bazy danych utworzonej w SQL Server domyślną wartością opcji statystyki automatycznej aktualizacji jest włączona . Podejrzewam, że większość administratorów baz danych pozostawia tę opcję włączoną, ponieważ pozwala ona optymalizatorowi automatycznie aktualizować statystyki, gdy są one unieważniane, i ogólnie zaleca się pozostawienie jej włączonej. Statystyki są również aktualizowane podczas przebudowy indeksów i chociaż nierzadko zdarza się, że statystyki są dobrze zarządzane za pomocą opcji automatycznej aktualizacji statystyk i przebudowy indeksów, od czasu do czasu administrator danych może uznać za konieczne skonfigurowanie regularnego zadania aktualizacji statystyka lub zestaw statystyk.

Niestandardowe zarządzanie statystykami często wiąże się z poleceniem UPDATE STATISTICS, które wydaje się dość łagodne. Można go uruchomić dla wszystkich statystyk dla tabeli lub widoku indeksowanego lub dla określonej statystyki. Można użyć próbki domyślnej, można określić określoną częstotliwość próbkowania lub liczbę wierszy do próbkowania lub można użyć tej samej wartości próbki, która była używana wcześniej. Jeśli statystyki są aktualizowane dla tabeli lub widoku indeksowanego, możesz zaktualizować wszystkie statystyki, tylko statystyki indeksowania lub tylko statystyki kolumn. I na koniec możesz wyłączyć opcję automatycznej aktualizacji statystyk dla statystyki.

W przypadku większości administratorów baz danych najważniejszą kwestią może być kiedy aby uruchomić instrukcję UPDATE STATISTICS. Ale administratorzy baz danych decydują również, świadomie lub nie, o wielkości próbki do aktualizacji. Wybrana wielkość próbki może wpłynąć na wydajność aktualnej aktualizacji, a także na wydajność zapytań.

Zrozumienie wpływu wielkości próbki

Domyślny rozmiar próbki dla UPDATE STATISTICS pochodzi z nieliniowego algorytmu, a rozmiar próbki zmniejsza się wraz ze wzrostem rozmiaru tabeli, jak wykazał Joe Sack w swoim poście, Auto-Update Stats Default Sampling Test. W niektórych przypadkach wielkość próbki może nie być wystarczająco duża, aby uchwycić wystarczającą ilość interesujących informacji lub właściwa informacje dotyczące histogramu statystycznego, jak zauważył Conor Cunningham w swoim poście dotyczącym statystyk próbkowania. Jeśli próbka domyślna nie tworzy dobrego histogramu, administratorzy baz danych mogą wybrać aktualizację statystyk z wyższą częstotliwością próbkowania, aż do FULLSCAN (skanowanie wszystkich wierszy w tabeli lub widoku indeksowanym). Jak jednak Conor wspomniał w swoim poście, skanowanie większej liczby wierszy wiąże się z pewnymi kosztami, a DBA stoi przed wyzwaniem podjęcia decyzji, czy uruchomić FULLSCAN, aby spróbować stworzyć „najlepszy” możliwy histogram, czy próbkować mniejszy procent, aby zminimalizować wpływ na wydajność aktualizacja.

Aby spróbować zrozumieć, w którym momencie próbka zajmuje więcej czasu niż FULLSCAN, uruchomiłem następujące instrukcje w odniesieniu do kopii tabeli SalesOrderDetail, które zostały powiększone za pomocą skryptu Jonathana Kehayiasa:

Miałem trzy kopie tabeli SalesOrderDetailEnlarged o następujących cechach*:

*Dodatkowe szczegóły dotyczące sprzętu znajdują się na końcu tego posta.

Wszystkie kopie tabeli miały następujące statystyki, a żadna z trzech statystyk indeksu nie zawierała kolumn:

Powyższą instrukcję UPDATE STATISTICS uruchomiłem cztery razy w odniesieniu do tabeli SalesOrderDetailEnlarged na moim laptopie i dwa razy w odniesieniu do tabel SalesOrderDetailEnlarged na serwerze TestServer. Instrukcje były uruchamiane za każdym razem w losowej kolejności, a pamięć podręczna procedur i bufor były czyszczone przed każdą instrukcją aktualizacji. Czas trwania i użycie bazy danych tempdb dla każdego zestawu instrukcji (uśrednione) przedstawiono na poniższych wykresach:

Średni czas trwania – zaktualizuj wszystkie statystyki dla SalesOrderDetailEnlarged

tempdb Użycie — zaktualizuj wszystkie statystyki dotyczące SalesOrderDetailEnlarged

Wszystkie czasy trwania dla tabeli 23 milionów wierszy były krótsze niż trzy minuty i zostały opisane bardziej szczegółowo w następnej sekcji. W przypadku tabeli na dyskach SSD_2 instrukcja FULLSCAN zajęła 1492 sekund (prawie 25 minut), a aktualizacja z 25% próbką zajęła 2051 sekund (ponad 34 minuty). W przeciwieństwie do tego, na dyskach 15K instrukcja FULLSCAN zajęła 2864 sekundy (ponad 47 minut), a aktualizacja z 25% próbką zajęła 2147 sekund (prawie 36 minut) – mniej niż czas FULLSCAN. Jednak aktualizacja z próbką 50% zajęła 4296 sekund (ponad 71 minut).

Użycie tempdb jest znacznie bardziej spójne, pokazując stały wzrost wraz ze wzrostem rozmiaru próbki i używając więcej miejsca tempdb niż FULLSCAN gdzieś między 25% a 50%. Godne uwagi jest to, że UPDATE STATISTICS robi użyj tempdb, o czym należy pamiętać podczas dopasowywania tempdb do środowiska SQL Server. Użycie Tempdb jest wymienione we wpisie UPDATE STATISTICS BOL: