AKTUALIZACJE statystyk

W ostatnich kilku wydaniach SQL Server wprowadzono wiele nowych funkcji, a także ulepszenia istniejącej funkcjonalności. Jednym z obszarów silnika, który łatwo przeoczyć, są statystyki. W końcu statystyki nadal są tworzone w ten sam sposób, nadal informują o dystrybucji danych, nadal są używane przez Optymalizator zapytań… co się zmieniło? Podstawowa funkcja statystyk pozostaje taka sama, ale sposób ich wykorzystania przez Optymalizator zapytań zmienia się w zależności od używanego estymatora kardynalnego. Wprowadzono również kilka godnych uwagi zmian związanych z aktualizacją statystyk oraz dodano nową funkcjonalność związaną z wyświetlaniem informacji statystycznych. W sumie te zmiany w najnowszych wydaniach mogą spowodować nieoczekiwane zmiany w zachowaniu programu SQL Server.

Uwaga:ten post dotyczy głównie SQL Server 2012 i nowszych, ale niektóre szczegóły dotyczące wcześniejszych wydań są zawarte w celach informacyjnych (i zabawnych).

SQL Server 7.0

• Liczba kroków w histogramie jest ograniczona do 300. W programie SQL Server 6.5 i wcześniejszych histogram zawierałby liczbę kroków, która mogłaby zmieścić się na stronie o rozmiarze 2K, na podstawie rozmiaru pierwszej kolumny w kluczu.
• Wprowadzono opcję bazy danych „automatycznie aktualizuj statystyki”; poprzednie statystyki były aktualizowane tylko ręcznie.

SQL Server 2000

• Liczba kroków w histogramie jest zmniejszona z 300 do 200 (technicznie 201, jeśli uwzględnisz krok dla NULL, zakładając, że pierwsza kolumna w kluczu pozwala na NULL).

Serwer SQL 2005

• Aktualizacje statystyk korzystających z FULLSCAN mogą działać równolegle.
• Flagi śledzenia 2389 i 2390 zostały wprowadzone w dodatku SP1, aby pomóc w rozwiązaniu problemu z kluczem rosnącym, opisanego w poście, Klucze rosnące i automatyczne szybkie korygowanie statystyk. Szczegółowy przykład tego scenariusza znajduje się w moim wpisie Trace Flag 2389 i nowym module szacowania kardynalności.
• Wprowadzono opcję instancji „Automatycznie aktualizuj statystyki asynchronicznie”. Pamiętaj, że aby to zadziałało, opcja „Automatycznie aktualizuj statystyki” musi być również włączona. Jeśli nie wiesz, co robi ta opcja, przejrzyj dokumentację w opcji ALTER DATABASE SET Options. Jest to ustawienie, które zaleca Glenn (jak zauważono w jego poście, do którego odwołuje się poniżej), ale myślę, że ważne jest, aby być świadomym potencjalnych problemów, jak wspomniano w artykule Jak automatyczne aktualizacje statystyk mogą wpływać na wydajność zapytań.
  
  Uwaga: Wystąpił przeciek pamięci związany z tym ustawieniem w SQL Server 2008 do SQL Server 2012; Więcej informacji można znaleźć w poście Glenna „Ważna poprawka dla SQL Server 2008”.

SQL Server 2008

• Wprowadzono filtrowane statystyki, które można tworzyć niezależnie od filtrowanego indeksu. Istnieją pewne ograniczenia dotyczące filtrowanych indeksów w odniesieniu do Optymalizatora zapytań (zobacz post Tima Chapmana The Pains of Filtered Indexes i post Optimizer Limitations with Filtered Indexes autorstwa Paula White'a) i ważne jest, aby zrozumieć zachowanie licznika, który śledzi modyfikacje (i w ten sposób może wywołać automatyczne aktualizacje). Zobacz wpis Kimberly Filtrowane indeksy i filtrowane statystyki mogą stać się poważnie nieaktualne, aby uzyskać więcej informacji. Polecam również zapoznanie się z jej procedurą składowaną, która analizuje przekrzywienie danych i zaleca, gdzie można tworzyć filtrowane statystyki, aby dostarczyć więcej informacji do Optymalizatora zapytań. Zaimplementowałem to dla kilku dużych klientów, którzy mają VLT i skośną dystrybucję w kolumnach często używanych w predykatach.
• Dwa nowe widoki katalogu, sys.stats i sys.stats_columns, zostały dodane, aby zapewnić łatwiejszy wgląd w statystyki i zawarte kolumny. Użyj tych dwóch widoków zamiast sp_helpstats, który jest przestarzały i dostarcza mniej informacji.

SQL Server 2008R2 SP1

• Udostępniono flagę śledzenia 2371, której można użyć do zmniejszenia liczby modyfikacji wymaganych do automatycznego aktualizowania statystyk. Przypominam, że jestem fanem regularnego aktualizowania statystyk za pomocą zaplanowanej pracy i pozostawiania włączonej automatycznej aktualizacji dla bezpieczeństwa.

SQL Server 2008R2 SP2

• Dołączona jest funkcja sys.dm_db_stats_properties, która zawiera te same informacje, które można znaleźć w nagłówku DBCC SHOW_STATISTICS, a także kolumnę modyfikacji, której można użyć do śledzenia zmian i programowego określenia, czy aktualizacja była potrzebna. Czy pamiętasz moje preferencje dotyczące korzystania z oferty pracy do aktualizacji statystyk? Ta praca właśnie stała się o wiele mądrzejsza dzięki temu DMF… teraz mogę sprawdzić, ile danych zostało zmodyfikowanych i zaktualizować statystyki TYLKO, jeśli pewien procent danych się zmienił. Zgrabny.

Serwer SQL 2012

• Aktualizacja statystyk nie spowoduje unieważnienia planów JEŚLI żadne wiersze nie uległy zmianie. Jest to taki, który zaskakuje wiele osób, a Kimberly ma zabawny post, Co spowodowało, że ten plan się nie powiódł – czy powinieneś zaktualizować statystyki?, który przedstawia jej przygodę z odkrywaniem tego.

SQL Server 2012 SP1

• DBCC SHOW_STATISTICS wymaga tylko uprawnienia SELECT — wcześniej wymagało to, aby użytkownik był członkiem sysadmin lub członkiem roli bazy danych db_owner lub db_ddladmin. Można to globalnie wyłączyć za pomocą flagi śledzenia 9485.
• Zawiera sys.dm_db_stats_properties (patrz uwaga dotycząca dodatku SP2 2008R2 powyżej)

SQL Server 2012 SP2

• Zbiorcza aktualizacja 1 wprowadza poprawkę związaną z nieprawidłowym identyfikowaniem kluczy rosnących nawet przy użyciu flag śledzenia 2389 i 2390. Wymaga to flagi śledzenia 4139 oprócz CU1, jak wspomniano w KB 2952101.

Serwer SQL 2014

• Wprowadzono nowy moduł szacowania kardynalizacji, zaimplementowany przez ustawienie trybu zgodności bazy danych na 120 lub za pomocą flagi śledzenia 2312. Jeśli nie czytałeś nic o nowym CE, zalecam rozpoczęcie od dokumentacji szacowania kardynacji, a następnie przeczytanie Joe Oficjalny dokument firmy Sack, Optymalizacja planów zapytań za pomocą narzędzia do szacowania kardynacji SQL Server 2014, zawiera szczegółowe informacje.
• Zachowanie z flag śledzenia 2389 i 2390 dla kluczy rosnących jest teraz zaimplementowane w trybie zgodności bazy danych. Jeśli tryb zgodności baz danych jest ustawiony na 120 (lub wyższy w nowszych wersjach), nie trzeba używać flag śledzenia 2389 i 2390 dla programu SQL Server do identyfikowania statystyk, które mają klucze rosnące.
• Statystyki przyrostowe są wprowadzane dla partycji i można je przeglądać za pomocą nowego DMF sys.dm_db_incremental_stats_properties. Statystyki przyrostowe umożliwiają aktualizowanie statystyk partycji bez aktualizowania ich dla całej tabeli. Jednak dodatkowe informacje statystyczne ze statystyk przyrostowych nie są używane przez Optymalizator zapytań, ale są umieszczane w głównym histogramie tabeli.
• CU2 zawiera tę samą poprawkę, o której mowa powyżej, dla dodatku SP2 dla programu SQL Server 2012, który wymaga również flagi śledzenia 4139.

SQL Server 2014 z dodatkiem SP1

• Flaga śledzenia 7471 jest przeniesiona z powrotem do CU6, pierwotnie dostępna w SQL Server 2016, jak wspomniano poniżej.

Serwer SQL 2016

• Flaga śledzenia 2371 nie jest już potrzebna do obniżenia progu automatycznych aktualizacji statystyk, jeśli tryb zgodności bazy danych jest ustawiony na 130. Zobacz Kontrolowanie zachowania funkcji Autostat (AUTO_UPDATE_STATISTICS) w programie SQL Server.
• Aktualizacje statystyk mogą być wykonywane równolegle podczas korzystania z SAMPLE, a nie tylko FULLSCAN. Jest to powiązane z trybem zgodności (musi wynosić 130), ale może potencjalnie zapewnić szybsze aktualizacje, a tym samym skrócić okresy konserwacji. Aaron Bertrand mówi o tym ulepszeniu w swoim poście, Potencjalne ulepszenie aktualizacji statystyk:MAXDOP.
• W CU1 wprowadzono flagę śledzenia 7471, aby umożliwić jednoczesne uruchamianie wielu poleceń UPDATE STATISTICS dla pojedynczej tabeli, a Jonathan podaje kilka świetnych przykładów tego, jak można to wykorzystać w swoim poście Ulepszone wsparcie dla równoległych przebudów statystyk.

SQL Server 2016 SP1

• Wprowadzono opcję wskazówki dotyczącej zapytania ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS wraz z argumentem FOR WSKAZÓWKA, który jest odpowiednikiem flagi śledzenia 4139.
• DMF sys.dm_db_stats_histogram jest widoczny w CU2, co jest alternatywą dla danych wyjściowych histogramu z DBCC SHOW_STATISTICS. Informacje w obu są takie same, użyj tego, co jest dla Ciebie łatwiejsze lub lepiej pasuje do problemu, który musisz rozwiązać.
• Opcja PERSIST_SAMPLE_PERCENT została wprowadzona w CU4, której można użyć do wymuszenia używania tej samej częstotliwości próbkowania za każdym razem, gdy statystyka jest aktualizowana w przyszłości, a przykłady tego zachowania można znaleźć w poście, Utrzymująca się częstotliwość próbkowania statystyk.

Serwer SQL 2017

• Opcja PERSIST_SAMPLE_PERCENT jest dostępna w CU1 (zobacz wpis 2016 SP1, aby uzyskać dodatkowe informacje).
• Atrybuty StatsInfoType i OptimizerStatsUsageType są dodawane do planu zapytań, który zawiera statystyki używane podczas optymalizacji zapytań. Jest to dostępne w CU3 i jest powiązane z wersją CE (120 i wyższą). To jest całkiem niezłe! Nie miałem jeszcze okazji się tym bawić, ale aby uzyskać te informacje wcześniej, trzeba było użyć nieudokumentowanych flag śledzenia.
• CU3 wprowadziła również opcję MAXDOP dla CREATE STATISTICS i UPDATE STATISTICS, której można użyć do zastąpienia wartości MAXDOP dla instancji lub bazy danych.
• Jeszcze jeden dodatek w CU3:atrybuty UdfCpuTime i UdfElapsedTime można znaleźć w planie zapytań, które reprezentują statystyki wykonania dla funkcji UDF o wartościach skalarnych.

Podsumowanie

Jeśli chcesz uaktualnić do nowszej wersji lub niedawno dokonałeś aktualizacji, zwróć uwagę, jak te zmiany wpływają na Twoje rozwiązanie. Wielu klientów kontaktowało się z nami po aktualizacji z wersji 2005/2008/2008R2 do 2014 lub 2016, skarżąc się na problemy z wydajnością. W wielu przypadkach odpowiednie testy nie zostały zakończone przed aktualizacją.

To jest coś, na czym naprawdę się koncentrujemy, pomagając w aktualizacji klienta. Poza czynnościami związanymi z przenoszeniem instancji produkcyjnej z jednej wersji do drugiej z niewielkimi przestojami, chcemy mieć pewność, że dzień po aktualizacji będzie nudny dla administratorów baz danych i programistów.

Nie testujemy po prostu procesu aktualizacji, testujemy, jak wygląda system po aktualizacji. Czy te same flagi śledzenia ze starego środowiska są potrzebne w nowym? Jakie ustawienia bazy danych należy dostosować? Czy zmienia się wydajność zapytań – na lepsze czy na gorsze? Jeśli nie znasz odpowiedzi na te pytania przed uaktualnieniem produkcji, to szykujesz się na jeden do wielu dni gaszenia pożarów, telefony Sev 1, posiłki przy biurku, za mało snu i kto wie co jeszcze .

Poświęć trochę czasu na zrozumienie wpływu nowych funkcji i zmian w funkcjonalności wymienionych powyżej, zaplanuj aktualizację i przetestuj jak najwięcej.