Dlaczego warto ustawić Statystyka automatycznych aktualizacji na Fałsz?


10

Właśnie odziedziczyłem około 20 wystąpień SQL Server w ramach szerszego projektu akwizycji. Jestem w trakcie oceny wydajności i nie podoba mi się sposób wdrożenia planów konserwacji.

Widzę codzienne przebudowy indeksu koców (mogę sobie z tym poradzić), a także codzienną ręczną aktualizację statystyk.

Około połowa baz danych została ustawiona na Automatyczną aktualizację statystyk = Fałsz, z powodów, które nie są jasne, z wyjątkiem tego, co powiedziano mi, aby zmniejszyć „problemy z wydajnością” ...

Zawsze myślałem i pracowałem nad najlepszą praktyką ustawiania tego na Prawda i czułem, że Ręczna Aktualizacja nie byłaby konieczna, jeśli to ustawienie było Prawdą. Czy się mylę?

Czy ktoś może wyjaśnić, jakie korzyści przyniosłoby ustawienie tego zestawu jako False, ale zamiast tego przeprowadzałby codzienną ręczną aktualizację?

Powinienem wspomnieć, że niektóre bazy danych są wysoce transakcyjne (miliony wstawek, usunięć, aktualizacji dziennie). Inne są niskie pod względem stawek transakcyjnych, a niektóre są tylko do odczytu. Nie ma rymowania ani powodu, dla którego ustawienie Automatycznej aktualizacji jest ustawione na Fałsz. Wygląda na loterię.

Odpowiedzi:


6

Masz rację, uważam również, że w większości przypadków Auto Update statisticspowinno być ustawione na true, powinniśmy pozwolić SQL Serverowi zdecydować, kiedy zaktualizować statystyki i uwierzyć, że robi to dobrze. Gdy ta wartość jest ustawiona na wartość true, upewnij się, że statystyki są aktualizowane o dystrybucji danych w terenie, co ostatecznie pomoże optymalizatorowi przygotować lepszy plan. Ważną rzeczą do zapamiętania jest to, że statystyki automatycznych aktualizacji są uruchamiane, gdy 20% danych zmienia się w tabeli. Dlatego nie powinieneś czuć, że w tabeli z 100 000 wierszy, jeśli 10 wierszy jest zaktualizowanych, aktualizacja statusu zostanie uruchomiona.

Dokładniejszą analizę przeprowadził Paul Randal w blogu Zrozumienie, kiedy statystyki będą automatycznie aktualizowane . Nie widziałem żadnej wady, jeśli ta opcja jest ustawiona na true. Tak, możesz zobaczyć aktywność we / wy, gdy ta opcja jest ustawiona na true.

Ważny wniosek, który można wyciągnąć z bloga

Nawet jeśli statystyka stanie się nieaktualna w wyniku modyfikacji, nie zostanie automatycznie zaktualizowana po zakończeniu modyfikacji. Statystyka zostanie automatycznie zaktualizowana przy następnym użyciu planu zapytań.

W przypadkach, w których tylko czytasz tylko bazy danych lub bazy danych, w których po prostu wykonujesz operację wyboru i nie ma operacji DML, w takim przypadku możesz zachować opcję fałszywą, ale ponownie nie wyrządziłoby to szkody, gdybyś ją zachował. Przeważnie widzimy bazę danych z pewną ilością aktywności.


10

To za długo na komentarz, więc włączę inny przypadek, w którym ktoś może chcieć wyłączyć statystyki automatycznych aktualizacji. Pracowałem z bazami danych obsługującymi duże ilości obciążeń OLTP i rygorystyczną SLA dotyczącą wydajności zapytań w milisekundach. Niemal wszystkie zapytania były trywialne, z dużą uwagą na szczegóły dostrajania zapytań i indeksów, a niektóre tabele były dość duże. W tej sytuacji nie było wiele wartości w aktualizowaniu statystyk w okresach szczytu, a statystyki automatycznej aktualizacji naruszyłyby umowę SLA. W związku z tym konserwacja została wykonana w okresach poza szczytem za pośrednictwem zaplanowanego zadania.

Inną opcją jest włączenie obu opcji AUTO_UPDATE_STATISTICSi AUTO_UPDATE_STATISTICS_ASYNCopcji bazy danych. Umożliwi to kwerendom kontynuowanie planów wykonania opartych na nieaktualnych statystykach, zamiast ponosić nakłady związane z aktualizowaniem statystyk synchronicznie. Jest to szczególnie odpowiednie w przypadku obciążenia OLTP, o ile rozmiar serwera jest dostosowany do obciążenia związanego z zapytaniami oraz aktualizacji statystyk w tle.


Próbowałem wymyślić przykład, w którym auto_update_stats faktycznie spowodowałoby problemy, i to jest świetny - głosowałbym dwa razy (jeśli mógłbym), aby uzyskać doskonałe obejście, unikając normalnego opóźnienia statystyk, które towarzyszyłoby zapytanie
SqlRyan

1
Miałem sytuacje z większymi bazami danych (VLDB), że opcja statystyki auto_update jest WŁĄCZONA, a SQL uruchamia się w nieodpowiednich porach dnia roboczego. Wyłączyłem go i musiałem bardziej strategicznie podchodzić do ręcznych aktualizacji określonych tabel i statystyk, zamiast pozwolić serwerowi określać tabele i kiedy. Dzięki temu mój system był bardziej przewidywalny, ale kosztem wyższego zarządzania (bez wątpienia), ale musiał się zdarzyć, aby uniknąć ingerencji w zadania aktualizacji. Jeśli Twoim celem jest „ukrycie” systemu z typowym zarządzaniem indeksami / statystykami, pozostaw to włączone. W przeciwnym razie niektóre sytuacje mogą wymagać szczegółowej strategii.
SnapJag

6

Ogólnie powiedziałbym, że posiadanie statystyk automatycznych aktualizacji jest korzystne. Ale jak każde ustawienie, istnieją powody, dla których możesz je włączyć lub wyłączyć.

Jednym z nich jest to, że niektóre tabele mają dużą zmienność i być może zapytania nie są bardzo wrażliwe na dokładne statystyki. Pomyśl o ETL lub innych scenariuszach zbiorczych, w których zmieniasz dużo danych, ale albo ich nie odczytujesz, albo nie odczytujesz zbyt wiele. Nie ma sensu uruchamiać automatycznych aktualizacji statystyk i powodować, że kilka wejść / wyjść zapewnia dokładniejsze statystyki, które nigdy nie będą używane.

Możesz również mieć scenariusze, w których dane aktualizujesz wiele razy w ciągu dnia, ale niekoniecznie chcesz aktualizować statystyki po każdej aktualizacji. (Powiedzmy, że dane są sprawdzane tylko w określonych godzinach dnia - nie trzeba aktualizować statystyk wiele razy, jeśli dane nie będą w międzyczasie sprawdzane).

A może po prostu masz duże obciążenie pracą. Lub odczyty są zwykle pełnymi skanami, w których statystyki nie są niezwykle ważne.

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.