Właśnie dowiedziałem się, że firma kliencka, dla której pracuję, postanowiła wyłączyć opcje statystyk automatycznych aktualizacji dla niektórych swoich serwerów SQL, a DBA ręcznie rozwiązują problemy z wydajnością, gdy się pojawią.
Jednak ten rodzaj nie ma dla mnie sensu. Dlaczego chcesz zapobiegać aktualizacji statystyk?
Odpowiedzi:
Moja rada:
sp_updatestatszaktualizuje wszystkie statystyki dla wszystkich tabel w bazie danych, ale spowoduje to również rekompilację zapisanych proc, więc ostrożnie wybieraj swój czas (tj. sp_updatestatstuż przed raportowaniem na koniec miesiąca prawdopodobnie nie jest optymalny).To, jak często trzeba uruchamiać statystyki konserwacji / odbudowywania indeksu, zależy od obciążenia bazy danych, a zwłaszcza od tego, jak często dane są modyfikowane (tj. INSERT/ UPDATE/ DELETE). Jeśli modyfikujesz dane w całym programie (tj. Tabelę pomostową dla tygodniowego procesu wsadowego), prawdopodobnie chcesz aktualizować statystyki / reorganizować indeksy co noc. Jeśli twoje dane są bardziej statyczne, prawdopodobnie możesz ustawić je na tygodniowy lub dwutygodniowy harmonogram.
Widziałem to tylko raz ze złą aplikacją, która źle indeksowała stosy i miała ciężki ETL.
To były śmieci i na szczęście nie moje.
W przeciwnym razie nie ma powodu.
Jeśli otrzymujesz aktualizacje statystyk w nieodpowiednich momentach, oznacza to, że robisz nieprawidłowe utrzymanie indeksu / statystyk lub masz masowe usuwanie / ładunki, które osiągnęły próg.
W SQL Server 2005+ i tak możesz odroczyć aktualizację statystyk.
Zobacz „Kiedy używać aktualizacji synchronicznych lub asynchronicznych”
Byłoby ciekawie zobaczyć artykuł, który śledzili lub czytali, aby dokonać tego wyboru ...
W dawnych czasach (SQL Server 2000) włączenie statystyki automatycznej aktualizacji mogło powodować duże „przerwy” w aplikacjach OLTP, gdy SQL zdecydował się na aktualizację statystyk.
Począwszy od SQL Server 2005, dostępna jest opcja asynchroniczna, która nie spowoduje „pauzy”, gdy statystyki są nieaktualne, a następnie ponownie skompilowane. Statystyki zostaną ponownie skompilowane asynchronicznie, gdy będą potrzebne.
Pamiętaj jednak, że należy zachować równowagę - w przypadku dużych zestawów danych może być konieczne, aby bieżące zapytanie uwzględniało najbardziej aktualne statystyki, ponieważ zapytanie może potrwać wykładniczo dłużej przy nieefektywnym planie zapytań.
Możesz także monitorować liczbę ponownych kompilacji na sekundę i inne kluczowe wskaźniki wydajności za pomocą liczników perfmon, które są publikowane przez SQL Server, jak mówią, dowód jest w puddingu.
Jak aktywne są systemy?
Jeśli są to głównie systemy odczytu, możesz przejść bez aktualizacji, jeśli zdarzy im się to zrobić ręcznie, gdy zmieniają dane (wstawianie, aktualizowanie, usuwanie).
Jednak w celu uzyskania najlepszych praktyk zaleca się, aby zachować tę kontynuację, ponieważ myślę, że rzadko występowałby problem z wydajnością. Prawdopodobnie wysyłałbym im artykuły i posty na blogu sugerujące, że należy je pozostawić. Kimberly Tripp ma kilka dobrych.
Chociaż nigdy nie będę w żaden sposób zaprzeczać ani celowo nie dezorientować MrDenny'ego (zbyt duży szacunek dla jego wiedzy i wkładu w społeczność) zauważyłem dokumentację MS zalecającą wyłączenie statystyk automatycznych aktualizacji.
W przypadku planowania i konfiguracji pojemności i SQL Server (SharePoint Server 2010) MS zaleca wyłączenie tej opcji.
Przeczytałem również tę samą rekomendację MS dla wcześniejszych wersji SP, ale nie mogę teraz znaleźć linków.
Ale NIE JESTEM ekspertem SP, więc możesz również sprawdzić, co Chun Liu, inżynier terenowy MS Permier, ma do powiedzenia na ten temat w Chun Liu na SharePoint lub po prostu zignorować ten post i pozostawić włączony.
Zazwyczaj wyłączasz je tylko wtedy, gdy masz metodę ich samodzielnej aktualizacji. Robię to cały czas, ponieważ potrzebujemy lepszego lub po prostu innego próbkowania niż zrobią to automatyczne statystyki. Jest to dość powszechne, ale nie można go po prostu wyłączyć i nic więcej nie robić.