Zauważyłem, że niektóre DBA restartują SQL Server bardzo często, czasem nawet co noc. Sądzę, ż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 taka korzyść przynosi korzyść.
Czy to prawda, że codzienne ponowne uruchamianie programu SQL Server przyspiesza jego działanie?
Odpowiedzi:
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 o tym, że odrzucając wszystkie statystyki zebrane w statystykach operacyjnych DMV, zmniejszasz swoje szanse na udane zbadanie czegoś.
Nie ma oficjalnych wskazówek popierających tę praktykę, nigdy nie widziałem o niej wspominanej w żadnej renomowanej pracy dobrej praktyki, nigdy nie słyszałem o renomowanym ekspercie, który wspominałby o tym jako praktyce. Nie rób tego
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 wymusza na SQL zrezygnowanie z pamięci, co pozwala Windowsowi uzyskać więcej, a stronicowanie zatrzymuje się chwilowo. 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ą Dynamicznej pamięci podręcznej plików, jak opisano w powyższych postach na blogu.
Jeśli przyspieszy to zapytania, może być zaangażowany wykrywanie 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.
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 niepotrzebnych prac rozruchowych .
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 żadnych innych aplikacji lub ról serwera.
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 i częścią tego jest tworzenie całych schematów baz danych od podstaw i, niestety , praca z bazami danych innych firm, nad którymi absolutnie NIE mam kontroli.
Ludzie, którzy utworzyli i utrzymują jedną z naszych głównych baz danych stron trzecich, ledwo sprawili, że funkcjonuje.
Czy wspomniałem, że nie jestem również ekspertem od bezpieczeństwa ani inżynierem sieci?
Dla mnie pytanie brzmi: czy powinienem restartować SQL Server częściej niż co 3 miesiące?
Planowanie restartów dla obietnicy dodatkowego centymetra występu jest jak taniec dla deszczu.
Może to nadejdzie, może nie, ale nie wiadomo na pewno, co spowodowało, że spadł deszcz.
Ja nie twierdzę, że jak nigdy nie trzeba go ponownie uruchomić, aby rozwiązać problem lub zweryfikować pracy awaryjnej, ale zrobić problem z restartuje planowania zachować nieznany problem wydajności z losowo występujące.
Tylko Wyjątkiem jest jeśli uda fałszywego 3rd party bazy danych, gdzie restartowania go co tydzień lub dwa wydaje się być jedynym sposobem, aby utrzymać to działa i nie są dopuszczone do poprawki lub nawet go dotknąć.
Nawet wtedy powinieneś szukać poprawek, dzielić się nimi z właścicielem i wznosić piekło, dopóki nie zostanie rozwiązane.