Aktualizuj statystyki z pełnym skanowaniem w SQL Server 2014 używa 100% procesora, w 2008 R2, 15%


10

Dlaczego statystyki aktualizacji pełnego skanowania wykorzystują 100% procesora na SQL Server 2014, kiedy zużywa może 20% procesora na SQL Server 2008 R2 dla tych samych tabel z podobnymi możliwościami sprzętowymi?

Patrzyłem na MAXDOPinne opcje i naprawdę nie widziałem niczego, co by się wyróżniało. Zdaję sobie sprawę, że mogą istnieć ustawienia, które mogą to powodować, ale ustawienia są bardzo podobne dla obu baz danych (na przykład MAXDOPwynosi 4 dla obu, przy czym oba mają wiele rdzeni). Oba są wersją Enterprise Edition.

Czy w programie SQL Server 2014 i SQL Server 2008 R2 jest coś „innego”, co mogłoby to wyjaśnić? Mam opcję pamięci na 90% dla obu serwerów. Masz jakieś przemyślenia na temat tego, czego szukać?

Raz w tygodniu uruchamiam statystyki aktualizacji z pełnym skanowaniem (100%) na dwóch serwerach przy użyciu SQL Server 2008 R2 / SP3 i SQL Server 2014 / SP2, a bazy danych mają tę samą strukturę. Na serwerze 2008 R2 statystyki aktualizacji dwóch bardzo dużych tabel zajmują kilka godzin, czego się spodziewam, ale procesor pozostaje w użyciu przez około 20%. Na serwerze 2014 procesor przechodzi w 100% na około 40 minut. Tabele są nieco mniejsze na serwerze 2014. Widzę to za pomocą menu analizy SQL Monitor.

Oto dane wyjściowe pliku dziennika Ola na serwerze SQL 2014, procesor przechodzi w 100% z około 2:10 do 2:45:

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  
Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

Oto dane wyjściowe pliku dziennika Ola na serwerze SQL 2008 R2 dla dwóch powyższych statystyk, ale procesor może wynosić może 15%:

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  
Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

Nie mogę uruchomić ich z serwerem maxdop = 1, ponieważ eliminuje to generowanie wszystkich planów równoległych, co może zaszkodzić aplikacji. Planuję pójść w przeciwnym kierunku i zwiększyć go do 8 (na pudełku jest 16 rdzeni) i zobaczyć, co się stanie. Może działać szybciej, aby skrócić czas ustalania procesora. To zadanie działa, gdy użytkownicy w większości znikają.


Czy sprawdziłeś, czy proces jest związany z IO na serwerze 2008 R2? Czy tempdbkonfiguracja jest taka sama? Można go używać, gdy UPDATE STATISTICSjest uruchomiony, więc może to również stanowić problem.
MicSim

1
Też podejrzewam, że winowajcą jest prawdopodobnie winowajca. Czy przypadkiem sprawdziłeś próg kosztu dla równoległości? Dobrym pomysłem może być pobranie pełnej listy sp_configure z obu pól i różnicowanie ich, aby zobaczyć, co jeszcze jest inne.
DBADon,

Odpowiedzi:


1

Aktualizacje statystyk mogą przebiegać równolegle w oparciu o wiele różnych opcji w SQL Server:

  • Próg kosztów dla równoległości - zapytanie musi być tak wysokie, aby jechać pociągiem równoległości. Twoje dwa serwery mogą mieć różne ustawienia CTFP, które powodują, że aktualizacja 2008R2 przechodzi w tryb jednowątkowy, podczas gdy w 2014 może być wielowątkowy.
  • Maksymalny stopień równoległości - określa, ile rdzeni może użyć zapytanie, jeśli SQL Server zdecyduje się je zrównoleglać tak daleko. Pole 2008R2 może mieć wartość MAXDOP ustawioną na 1, podczas gdy pole 2014 może mieć wartość domyślną 0 (nieograniczona).
  • Resource Governor - ta funkcja Enterprise Edition pozwala dławić różne grupy użytkowników lub aplikacji do różnych MAXDOP.

W późniejszych wersjach SQL Server (2016 i nowszych) jest to jeszcze bardziej skomplikowane:

  • Opcje zakresu na poziomie bazy danych - możesz kliknąć bazę danych prawym przyciskiem myszy, przejść do właściwości i ustawić poziom MAXDOP dla tej bazy danych.
  • Wskazówki dotyczące paralelizmu statystyk - od wersji SP2 2016 instrukcje tworzenia i aktualizacji statystyk akceptują wskazówki MAXDOP

Jak zauważyłeś, twój 2008R2 będzie jednowątkowy, podczas gdy 2014 będzie wielowątkowy (w ten sposób kończy się szybciej, ale maksymalizuje procesor podczas pracy).

Aby znaleźć odpowiednią równowagę dla swoich statystyk, zastanów się:

  • Jakie inne obciążenia występują w bazie danych jednocześnie? Czy możesz sobie pozwolić na dominację na polu w krótkich okresach? Na przykład w hurtowniach danych, które pozostają bezczynne przez większość weekendów, widziałem, jak ludzie chrupią podczas aktualizacji statystyk pełnymi skanami, gdy wiedzą, że i tak nikt nie korzysta z serwera. W ciężkich środowiskach transakcyjnych musisz zacząć wywierać mniejszy wpływ na zadania konserwacyjne, jeśli użytkownicy narzekają nawet podczas północy.
  • Czy fullscan jest naprawdę potrzebny? Czy widzisz zapytania, które mają dobre plany tylko wtedy, gdy korzystasz z opcji fullscan, czy tylko robisz to jako najlepszą praktykę? Gdy baza danych rośnie, jeśli Twoje inwestycje sprzętowe nie nadążają, może być konieczne rozpoczęcie kompromisów w próbkowaniu statystyk zamiast wykonywania pełnych skanów.
  • Czy możesz rzadziej aktualizować statystyki? Na przykład aktualizuj 1/4 swoich statystyk w każdy weekend, a następnie co miesiąc wszystko będzie otrzymywać statystyki?
  • Czy możesz zaktualizować mniej obiektów? Często widzę ludzi aktualizujących statystyki nawet w ogromnych tabelach audytu lub archiwum po prostu dlatego, że zrobiono kilkadziesiąt nowych wstawek, ale te wstawki tak naprawdę nie wpływają na statystyki w tabeli (i i tak nikt o to nie pyta).

0

Odpowiedź wiki społeczności :

Najlepsze przypuszczenie: plan wybrany do aktualizacji statystyk jest albo równoległy, albo bardziej równoległy, na polu 2014 niż na polu 2008 R2.

Równoległe statystyki aktualizacji fullscanistnieją od 2005 r., A statystyki próbkowane od 2016 r., Patrz Dodatki do Optymalizatora zapytań w SQL Server 2016 autorstwa Gjorgji Gjeorgjievski na blogu silnika bazy danych SQL Server.

Jeśli masz wersję Enterprise, możesz użyć narzędzia Resource Governor, aby ograniczyć użycie procesora przez zadanie konserwacji.

Rozważ także głosowanie na sugestię Połącz Dodaj MAXDOPparametr do aktualizacji statystyk przez Javiera Villegasa.

Powiązane pytania i odpowiedzi: Aktualizacja statystyk równoległych

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.