Podczas tworzenia nowej bazy danych w programie SQL Server opcja Statystyki automatycznej aktualizacji jest domyślnie włączona. Ogólnie zaleca się pozostawienie tej opcji włączonej. W idealnym przypadku statystyki są zarządzane przez zaplanowane zadanie, a opcja automatyczna jest używana jako siatka bezpieczeństwa – dostępna do aktualizacji statystyk w przypadku, gdy zaplanowana aktualizacja nie nastąpi lub przypadkowo nie obejmuje wszystkich istniejących statystyk.
Niektórzy administratorzy baz danych polegają wyłącznie na automatycznych aktualizacjach zarządzania statystykami i dopóki nie występują problemy z wydajnością związane z nieaktualnymi lub słabo próbkowanymi statystykami, jest to akceptowalne. Jeśli korzystasz z tej opcji do zarządzania statystykami i masz bardzo duże tabele, warto zaimplementować flagę śledzenia 2371. Podobnie jak w przypadku każdej flagi śledzenia, upewnij się, że testujesz z reprezentatywnym obciążeniem przed wdrożeniem go w środowisku produkcyjnym. Być może już wiesz, że czasami automatyczna aktualizacja może wpłynąć na wydajność systemu. Na przykład, aktualizacja statystyki może spowodować skok w CPU lub we/wy podczas odczytywania danych z tabeli lub indeksu, a także opóźnić wykonanie zapytania podczas trwania aktualizacji. Istnieje inna opcja bazy danych, którą możesz włączyć, aby rozwiązać to opóźnienie zapytania, i omówię to w dalszej części tego postu.
Często słyszę pytanie:„Skąd wiadomo, czy automatyczne aktualizacje statystyk powodują problemy z wydajnością?” Jedną z opcji jest ich śledzenie i powiązanie aktualizacji ze zmianą wydajności. Istnieje wiele opcji śledzenia aktualizacji, a w tym poście przyjrzymy się kilku dostępnym metodom, aby można było wybrać, a następnie zaimplementować opcja, która najlepiej pasuje do istniejącej metody monitorowania problemów z wydajnością.
Śledzenie SQL
Jeśli korzystasz z programu SQL Server 2008 R2 lub starszego w swoim środowisku, SQL Trace jest jedną z metod przechwytywania automatycznych aktualizacji. Skrypt definicji śledzenia używany poniżej przechwytuje tylko zdarzenie Auto Stats, które przechwytuje, gdy statystyka jest aktualizowana automatycznie i gdy statystyka jest automatycznie tworzona. Po pewnym czasie działania tego śledzenia w środowisku można go załadować do tabeli, a następnie przeszukać dane wyjściowe, aby zobaczyć, jakie aktualizacje wystąpiły. Zawarty poniżej skrypt przedstawia przykład przy użyciu przykładowej bazy danych statystyk baseballu.
Wydarzenia rozszerzone
Jeśli korzystasz z programu SQL Server 2012 lub nowszego, zalecam używanie zdarzeń rozszerzonych do przechwytywania automatycznych aktualizacji. Podobnie jak skrypt SQL Trace, dołączony skrypt definicji sesji przechwytuje tylko zdarzenia Auto Stats — ponownie, zarówno automatyczne aktualizacje, jak i automatycznie tworzone. Po pewnym czasie działania sesji XE można załadować dane wyjściowe do tabeli za pośrednictwem interfejsu użytkownika, a następnie wysłać zapytanie, aby zobaczyć, jakie aktualizacje wystąpiły. Dołączony skrypt przechodzi przez ten sam przykład, co poprzednio, ale tym razem do zbierania danych używa rozszerzonych zdarzeń.
sys.dm_db_stats_properties
Trzecią opcją, którą możesz rozważyć do monitorowania aktualizacji statystyk, jest sys.dm_db_stats_properties DMF, który jest dostępny tylko w SQL Server 2008 R2 SP2 i nowszych oraz SQL Server 2012 SP1 i nowszych. Chociaż uwielbiam ten DMF, to rozwiązanie jest trudniejsze, jeśli chodzi o upewnienie się, że przechwyciłeś wszystkie dane, a przeglądanie wyników wymaga więcej pracy. Dzięki DMF każda automatyczna aktualizacja nie jest śledzona, po prostu aktualizujemy statystyki trendów, aby zobaczyć, kiedy nastąpią aktualizacje.
To proste zadanie:tworzysz tabelę do przechowywania informacji statystycznych, a następnie regularnie umieszczasz w tabeli informacje z DMF. Kluczem jest tutaj ustalenie, jak często przechwytywać dane. Każda godzina to prawdopodobnie przesada, raz dziennie może nie być wystarczająco częste. Zalecam rozpoczęcie od zadania SQL Agent, które co cztery godziny wykonuje migawki danych DMF. Pozwól temu działać przez kilka dni, a następnie sprawdź swoje dane. Jeśli statystyki są aktualizowane co najwyżej raz dziennie, możesz zwiększyć interwał do co osiem lub dwanaście godzin. Jeśli statystyki można łatwo aktualizować co cztery godziny, zmniejsz interwał do co dwie godziny — chcesz mieć pewność, że rejestrujesz każdą aktualizację. Z tego powodu w przypadku niektórych systemów sys.dm_db_stats_properties może nie być warte wysiłku; sesja XE lub Trace mogą być prostsze.
Ostatni przykładowy skrypt przedstawia przykład użycia sys.dm_db_stats_properties do aktualizacji trendów do statystyk. Należy pamiętać, że ten skrypt przechwytuje informacje statystyczne tylko dla jednej tabeli. Jeśli zmienisz skrypt tak, aby przechwytywał każdą tabelę w bazie danych, będzie o wiele więcej danych do analizy.
Dalsze kroki
Pobierz przykładowe skrypty i zdecyduj, której metody powinieneś użyć do śledzenia aktualizacji statystyk.
Gdy masz już dane, które pokazują, kiedy pojawiają się aktualizacje automatyczne, musisz powiązać je ze znanymi problemami z wydajnością. W związku z tym, jeśli nie śledzisz żadnych metryk wydajności, dane aktualizacji statystyk automatycznych nie pomogą w żadnej korelacji. Zakładając, że masz znaczniki czasu dla dowolnego problemu z wydajnością, możesz porównać go z StartTime i EndTime z Trace, timestamp z XE lub last_updated z sys.dm_db_stats_properties DMF, aby określić, czy automatyczna aktualizacja wpłynęła na wydajność systemu.
Jeśli nie możesz powiązać aktualizacji z problemami z wydajnością, możesz wykluczyć aktualizacje jako przyczynę problemu i skupić się na innym obszarze. Jeśli aktualizacje są główną przyczyną, masz dwie możliwości:wyłącz opcję Automatycznej aktualizacji statystyk lub włącz opcję Automatyczne aktualizowanie statystyk asynchronicznie. Oba mają wady i zalety, które musisz wziąć pod uwagę jako DBA.
Wyłączanie statystyk automatycznych aktualizacji
Jeśli zdecydujesz się wyłączyć opcję automatycznej aktualizacji statystyk, dwie najważniejsze rzeczy, o których musisz wiedzieć, to:
- Bezwzględnie musisz zarządzać swoimi statystykami za pomocą zadania konserwacyjnego lub niestandardowego zadania.
- Kwerendy nie zostaną ponownie skompilowane podczas aktualizacji statystyk w SQL Server 2008 R2 i niższych.
Drugą pozycję postrzegam jako większe wyzwanie – jestem wielkim zwolennikiem zarządzania statystykami i spodziewam się, że i tak robią to administratorzy baz danych. Większym problemem jest to, że mimo aktualizowania statystyk normalnie powoduje ponowną kompilację zapytań (aby skorzystać ze zaktualizowanych statystyk), nie występują, gdy opcja statystyk automatycznej aktualizacji jest wyłączona. Pisałem o tym wcześniej i zalecamy zapoznanie się z tymi informacjami, jeśli nie znasz tego zachowania. Zobacz także kolejny post, aby zapoznać się z opcjami rozwiązania tego problemu.
Generalnie nie jest to droga, którą polecam. Istnieją bardzo specyficzne przypadki brzegowe, w których może to być właściwe, ale wolałbym, aby administrator danych przeprowadzał ręczne aktualizacje (poprzez zaplanowane zadania), aby uniknąć automatycznych aktualizacji i pozostawić opcję włączoną jako środek bezpieczeństwa.
Włączanie asynchronicznych statystyk automatycznych aktualizacji
Po włączeniu opcji Automatycznie aktualizuj statystyki asynchronicznie, jeśli statystyka została unieważniona i zostanie uruchomione zapytanie korzystające z tej statystyki, statystyka nie zostanie zaktualizowana do czasu zakończenia zapytania — aktualizacja jest asynchroniczna. Zaletą jest to, że aktualizacja nie wpłynie na uruchomione zapytanie; wadą jest to, że zapytanie użyje istniejącego planu, który może nie być już optymalnym planem. To, czy plan jest nadal optymalny, będzie zależeć od Twojego obciążenia (np. obciążenie raportowania z długotrwałymi zapytaniami). Jako administrator baz danych musisz rozważyć zalety i wady włączenia tej opcji i określić, co jest najlepsze dla Twojej bazy danych. Należy zauważyć, że jeśli używasz programu SQL Server 2008 do 2012, istnieje przeciek pamięci skojarzony z tym ustawieniem. Firma Microsoft udostępnia aktualizacje zbiorcze, które zapewniają poprawkę, ale jeśli jeszcze ich nie zastosowano, stajesz przed inną decyzją:zastosuj CU, aby móc włączyć tę opcję, lub nie stosuj CU i nie włączaj opcja.
Podsumowanie
Jedynym sposobem sprawdzenia, czy automatyczne aktualizacje statystyk mają wpływ na wydajność zapytań, jest zobaczenie aktualizacji w tym samym czasie, co problem, lub przechwycenie wystąpienia aktualizacji i skorelowanie danych z dodatkowymi informacjami o problemach z wydajnością. Ta ostatnia opcja pozwala być proaktywnym — nawet jeśli nie masz problemów z wydajnością, dobrym pomysłem może być wiedza, jak często pojawiają się automatyczne aktualizacje. Częste aktualizacje mogą oznaczać konieczność ponownego odwiedzenia zadania agenta, które ręcznie zarządza statystykami. Ogólnie rzecz biorąc, pozostaw opcję automatycznej aktualizacji statystyk włączoną, ale miej metodę zarządzania statystykami i używaj tej opcji jako siatki bezpieczeństwa.
