it-swarm.dev

Czy ponowne uruchomienie programu SQL Server przyspiesza?

Zauważyłem, że niektóre DBA restartują SQL Server bardzo często, czasem nawet co noc. Wierzę, że robią to, aby zwolnić trochę pamięci lub przyspieszyć zapytania. Wiem, że po ponownym uruchomieniu kwerendy plany muszą zostać ponownie skompilowane, ale nawet uwzględniając to, zastanawiam się, czy ta praktyka przynosi korzyści netto.

Czy to prawda, że ​​codzienne ponowne uruchamianie programu SQL Server przyspiesza jego działanie?

22
MAK

Ponowne uruchomienie serwera jest prawdopodobnie jedną z najbardziej szkodliwych rzeczy dla wydajności. Oznacza to, że wymuszasz zimną pamięć podręczną dla danych, zimną pamięć podręczną dla planów zapytań, a wszystkie wewnętrzne pamięci podręczne programu SQL Server są również niszczone w tym procesie. Nie wspominając już o tym, że odrzucając wszystkie statystyki zebrane w statystykach operacyjnych DMV, zmniejszasz swoje szanse na udane zbadanie czegoś.

Nie ma żadnych oficjalnych wskazówek popierających tę praktykę, nigdy nie widziałem, by była wspomniana w jakiejkolwiek renomowanej pracy dobrej praktyki, nigdy nie słyszę o renomowanym ekspercie, który wspominałby o tym jako praktyce. Nie rób tego.

37
Remus Rusanu

Podczas gdy inne odpowiedzi są dobre, brakuje w nich ważnego elementu: pamięci podręcznej plików systemu Windows.

W 64-bitowym systemie Windows nie ma ograniczenia ilości pamięci używanej przez system Windows do buforowania plików. System Windows może całkowicie pozbawić system pamięci i wtedy zaczniesz zamieniać się na dysk. Zostało to udokumentowane w kilku miejscach:

Ponowne uruchomienie programu SQL Server powoduje wymuszenie przez SQL rezygnacji z pamięci, co pozwala Windowsowi uzyskać więcej, a stronicowanie zostaje tymczasowo zatrzymane. SQL uruchomi się ponownie przy prawie zerowym zużyciu pamięci i będzie stopniowo wzrastał, a gdy w polu ponownie zabraknie pamięci, ponowne uruchomienie pomoże tymczasowo. Ponowne uruchomienie całego systemu operacyjnego wymusi również użycie pamięci podręcznej plików systemu Windows.

Prawdziwa poprawka: przestań kopiować pliki z serwera Windows lub ogranicz ilość pamięci podręcznej plików używanej z usługą Dynamic File Cache Service, jak opisano w powyższych postach na blogu.

28
Brent Ozar

Jeśli przyspieszy zapytania, może być zaangażowany wąchanie parametrów . Jeśli plan bzdur zostanie zapisany w pamięci podręcznej i zastosowany do niewłaściwych kolejnych wywołań, wówczas cud ponownego uruchomienia pozwoli na buforowanie wspólnego/poprawnego planu. W takim przypadku istnieją nieskończenie lepsze sposoby korygowania zachowania, jak wskazali inni. Ale dopóki nie przestaną ponownie uruchamiać urządzenia, nie ma możliwości przeprowadzenia analizy pierwotnych przyczyn.

11
billinkc

Nie powinieneś ponownie uruchamiać programu SQL Server, chyba że zmieniłeś właściwości usługi lub ustawiłeś ślady uruchamiania, które chcesz natychmiast zastosować.

Ponieważ @RemusRusanu stwierdził wiele punktów, usuwa wiele pamięci podręcznych i powoduje, że SQL Server wykonuje wiele niepotrzebnej pracy przy uruchamiani.

Wygląda na to, że ten serwer nie jest dedykowanym serwerem SQL Server/bazą danych. Najlepszą praktyką jest, aby produkcyjny serwer bazy danych miał tylko jeden cel ... być serwerem bazy danych. W takim przypadku zarezerwujesz wystarczającą ilość pamięci i zasobów dla systemu operacyjnego i oddasz wszystko inne SQL Serverowi. Doprowadziłoby to do nie głodzenia innych aplikacji lub ról serwera.

11
Thomas Stringer

Zgadzam się z opinią, że jeśli wszystko robisz dobrze, może nie być konieczne ponowne uruchomienie/zrestartowanie serwera MSSQL.
Dla mnie dotyczy to scenariusza, w którym każdy jest kompetentny i możesz naprawić wszystko.

Nie jestem DBA. Jestem architektem oprogramowania, a częścią tego jest tworzenie całych schematów baz danych od podstaw i niestety praca z bazami danych innych firm, które mam absolutnie NO kontrola.
Ludzie, którzy stworzyli i utrzymują jedną z naszych głównych baz danych stron trzecich, ledwo sprawili, że funkcjonuje.

Czy wspomniałem, że nie jestem również ekspertem ds. Bezpieczeństwa ani inżynierem sieci?

  • Co najmniej jedna aktualizacja głównego systemu operacyjnego Windows, aktualizacja zabezpieczeń, aktualizacja systemu BIOS, dodatek Service Pack do systemu OS/MSSQL lub aktualizacja zbiorcza MSSQL będą pojawiać się co miesiąc lub dwa.
  • Zastosowanie ich w odpowiednim czasie oznacza ponowne uruchamianie/restartowanie serwera mniej więcej co kwartał.
  • Nawet jeśli działasz w intranecie, dlaczego nie miałbyś stosować aktualizacji zabezpieczeń?
  • Gdybym mógł mieć SSL na naszych stronach intranetowych PHI, zrobiłbym to, ponieważ żadna sieć nie jest niezawodna. Chyba jestem paranoikiem.


Pytanie do mnie brzmi: Czy powinienem restartować SQL Server częściej niż co 3 miesiące?

Zaplanowanie ponownego uruchomienia dla obietnicy dodatkowego centymetra występu jest jak taniec dla deszczu.
Może nadejdzie, może nie, ale nie wiesz na pewno, co spowodowało deszcz.

  • Jeśli zauważysz znaczny spadek wydajności po ponownym uruchomieniu serwera z powodu regularnej konserwacji, powinieneś dowiedzieć się, dlaczego tak się dzieje.
  • Jeśli masz problemy i nie masz pewności, co je powoduje, zmniejsz swoje zmienne, zatrzymując usługi i zadania, aby znaleźć coś w rodzaju wycieku pamięci (w takich ekstremalnych przypadkach) może być możliwe ponowne uruchomienie/ponowne uruchomienie serwera z niektórymi usługami włączonymi wyłączona (lub włączone ślady) pomoże Ci wykluczyć inne usługi jako przyczynę.

Nie lubię mówić, że [~ # ~] nigdy [~ # ~] musisz go ponownie uruchomić, aby rozwiązać problem problem lub weryfikacja trybu failover, ale I do mam problem z planowaniem Ponowne uruchomienie, aby zapobiec przypadkowemu wystąpieniu nieznanego problemu z wydajnością.

Tylko wyjątek od tej zasady ma miejsce, jeśli zarządzasz nieuczciwą bazą danych innej firmy, w której ponowne uruchamianie jej co tydzień lub dwa wydaje się być jedynym sposobem na utrzymanie jej działania i nie możesz jej naprawić ani nawet dotknąć.
Nawet wtedy powinieneś szukać poprawek, dzielić się nimi z właścicielem i wznosić piekło, dopóki nie zostanie rozwiązane.

2
MikeTeeVee