Tak więc w SQL Server 2016 aktualizacje statystyk przy użyciu trybu próbkowania działają teraz równolegle na poziomie zgodności 130 i tak to działa domyślnie dla wszystkich automatycznych i ręcznych aktualizacji statystyk. Wyjaśniono to pokrótce tutaj:
- Dodatki do Optymalizatora zapytań w SQL Server 2016
(Dokumentacja została również zaktualizowana, zarówno temat Poziom zgodności, jak i temat AKTUALIZACJA STATYSTYK).
Czy nie byłoby jednak miło móc określić, ile procesorów może być faktycznie użytych do tych operacji (poza zezwoleniem na ograniczenie 16)? Myślę, że możliwość ograniczenia tego do 4 lub 8 byłaby oczywistą i logiczną rzeczą do poparcia. Zwłaszcza dla klientów korzystających z systemów z 16 lub mniej rdzeniami lub wieloma instancjami na pudełku, którzy nie mogą polegać na funkcjach Enterprise, takich jak Resource Governor (których większość klientów Enterprise nie może zawracać sobie głowy używaniem IMHO).
Uzasadnienie biznesowe byłoby takie samo, jak uzasadnienia użyte do dodania obsługi MAXDOP REBUILD, DBCC CHECKDB i rodziny operacji konserwacyjnych itp. Chcesz zapobiec przejęciu przez tego typu aktywności wszystkich rdzeni, bez robienia czegoś tak drastycznego jako wyłączanie automatycznych aktualizacji lub używanie MAXDOP dla całej instancji – ponieważ nie każdy ma luksus okien konserwacyjnych.
W tym przypadku MAXDOP dla całej instancji i tak nie pomoże , ponieważ SQL Server 2016 RTM ma błąd, w którym MAXDOP jest ignorowany dla próbkowanych aktualizacji statystyk. Nadchodzi poprawka, ale pomyślałem, że powinieneś wiedzieć; jeśli to powoduje problem, jedną z opcji jest użycie niższego poziomu zgodności.
Ale powtórzę coś, o czym często mówię:poziom kompatybilności staje się zbyt ciasny. Jeśli chcę mieć równoległe próbkowane statystyki w mojej bazie danych, ale mam wystarczająco dużo regresji szacowania kardynalności, aby wymagać starego CE, muszę wybrać jedną lub drugą.
I jeszcze jedna rzecz:Resource Governor to przesada w tym przypadku użycia, a ograniczanie użycia rdzenia przez aktualizacje statystyk nie powinno tak naprawdę być funkcją Enterprise (tak jak wspomniane powyżej REBUILD i CHECKDB). Proszę nie mówić mi, że RG jest akceptowalną alternatywą, ponieważ jest to możliwe tylko dla użytkowników z klasyfikacjami obciążenia *i* Enterprise Edition, które powinny być ograniczone przez MAXDOP cały czas . Powinienem być w stanie ograniczyć to przez określoną operację (lub, powiedzmy, tylko dla moich największych/problematycznych tabel), a nie przez ograniczenie całej sesji logowania.
Jak chciałbym, żeby to zrobili
W idealnej sytuacji byłoby to możliwe na poziomie bazy danych przy użyciu nowej opcji KONFIGURACJA W ZAKRESIE BAZY DANYCH oraz na poziomie instrukcji przy użyciu znanej składni OPCJA (MAXDOP n). Poziom instrukcji wygrałby, a wszelkie aktualizacje statystyk trybu próbkowania (w tym automatyczne) bez wyraźnej wskazówki MAXDOP powróciłyby do ustawienia poziomu bazy danych. To pozwoliłoby mi ustawić MAXDOP na przykład na 4 dla wszystkich automatycznych aktualizacji statystyk, które mają miejsce w nieprzewidywalnych godzinach, ale 8 lub 16 dla operacji ręcznych w znanych oknach obsługi. Jako jeden przykład.
Jeśli chcesz na to zagłosować, zapoznaj się z następującym elementem Connect i dodaj uzasadnienie biznesowe (tak jak Michael Campbell):
- Połącz #628971:Dodaj parametr MAXDOP do aktualizacji statystyk
Oczywiście ta pozycja istnieje od 2010 roku, więc nie ma żadnej wzmianki o alei KONFIGURACJA BAZY DANYCH, dlatego też zostawiłem komentarz.
W międzyczasie, jeśli chcesz wyłączyć równoległość dla trybu próbkowania, istnieje flaga śledzenia, aby skutecznie powrócić do starszego zachowania (możesz to również zrobić, przywracając poziom zgodności mniejszy niż 130, ale nie polecam tego, ponieważ wpływa na wiele innych rzeczy). Zaktualizuję to miejsce, gdy dostanę zgodę na publiczne ujawnienie flagi śledzenia, ale w tej chwili Microsoft mocno ją trzyma.
