Od wielu lat uczę i piszę o typowych błędach SQL Server. Napisałem o tym na blogu też lata temu, jednak z biegiem czasu wytyczne nieco się zmieniły. Ten artykuł rozwinie mój poprzedni artykuł i wskaże, w jaki sposób odnoszą się one do SQL Server, Azure SQL Database i Azure SQL Managed Instance.
Od wielu lat spotykam użytkowników popełniających te same błędy. Nazywam je błędami, jednak w większości przypadków chodzi raczej o to, że rzeczy nie są wykonywane prawidłowo, ponieważ ludzie zarządzający środowiskiem nie wiedzą nic lepszego. Oto niektóre z najważniejszych elementów, o których powinien wiedzieć każdy, kto instaluje i wspiera SQL Server:
- Kopie zapasowe
- DBCC CHECKDB
- Ustawienia pamięci
- Statystyki
- Utrzymanie indeksu
- MAXDOP i próg kosztów dla równoległości
- Alerty agenta SQL Server
Kopie zapasowe
Zawsze najpierw sprawdzam kopie zapasowe, gdy patrzę na nowy system. Posiadanie odpowiednich kopii zapasowych, aby spełnić cele odzyskiwania, ma kluczowe znaczenie. Utrata danych może być szkodliwa dla organizacji. Przeglądając kopie zapasowe, sprawdzam model odzyskiwania i aktualną historię kopii zapasowych dla każdej bazy danych. Zwykle znajduję kombinację następujących elementów:
- Brak kopii zapasowej – brak zapisu jakiejkolwiek kopii zapasowej dla bazy danych
- Brakujące kopie zapasowe – brak kopii zapasowych dziennika dla bazy danych przy użyciu modelu pełnego odzyskiwania
- Brak ostatnich kopii zapasowych – ostatnia kopia zapasowa miała tygodnie/miesięcy/lata
Źle skonfigurowane kopie zapasowe są szkodliwe dla organizacji, gdy pojawia się sytuacja odzyskiwania. Praca z klientami i mówienie im, że stracili dane, nigdy nie jest zabawne ani łatwe. Posiadanie odpowiednich kopii zapasowych w celu spełnienia umów SLA powinno być dla każdej organizacji najwyższym priorytetem, oprócz upewnienia się, że kopie tych kopii są przechowywane w dodatkowej lokalizacji poza siedzibą.
Ta sytuacja dotyczy lokalnych SQL Server i IaaS. Azure SQL Database i Azure Managed Instance mają zarządzane kopie zapasowe.
DBCC CHECKDB
Niestety zdarza się uszkodzenie bazy danych. Bez regularnego sprawdzania, czy nie ma uszkodzeń, klienci mogą znaleźć się w złym miejscu, ponieważ nie mają kopii zapasowych w celu odzyskania, gdy uszkodzenie wpływa na fizyczne dane. Aby sprawdzić, czy nie ma korupcji, DBCC CHECKDB należy regularnie uruchamiać w każdej bazie danych. To, co znalazłem, jest bardzo podobne do kopii zapasowych:
- W ogóle nie wykonano DBCC CHECKDB
- DBCC CHECKDB są wykonywane tylko na wybranych bazach danych
- DBCC CHECKDBs ostatnio wykonane miesiące lub lata temu
Najgorszy przypadek to zaplanowane zadanie zgłaszania nieudanych DBCC CHECKDB
Nigdy nie jest przyjemne znalezienie korupcji lub skontaktowanie się z klientem z problemem korupcji, gdy korupcja jest stertą lub indeksem klastrowym i nie ma kopii zapasowych przed wystąpieniem korupcji. W takich przypadkach uszkodzeniem są rzeczywiste dane, a rozpoczęcie przywracania sprzed uszkodzenia jest w większości przypadków jedyną opcją. W przypadkach, gdy uszkodzenie jest indeksem nieklastrowym, odbudowanie indeksu jest poprawką.
W kilku sytuacjach musiałem pracować z klientami, którzy mają paskudne korupcje bez odpowiednich kopii zapasowych, gdzie mogłem opisać bazę danych i ręcznie skopiować wszystkie użyteczne dane do nowo utworzonej bazy danych. Tych kosztownych sytuacji można łatwo uniknąć, uruchamiając DBCC CHECKDB i odpowiednio zachowując kopie zapasowe.
Radzę klientom uruchamiać DBCC CHECKDB lokalnie, IaaS, Azure SQL Database i Azure SQL Managed Instance. Platforma Azure świetnie sprawdza się, sprawdzając fizyczne uszkodzenia; jednak uważam, że konsumenci muszą sprawdzać, czy nie ma logicznej korupcji.
Ustawienia pamięci
Domyślna instalacja programu Microsoft SQL Server ma minimalną wartość pamięci ustawioną na 0, a maksymalną wartość pamięci serwera ustawioną na 2147483647 MB, czyli 2 petabajty. Przed SQL Server 2012 maksymalna wartość pamięci serwera dotyczyła tylko puli buforów, więc klienci musieli ograniczyć ilość pamięci, jaką pula buforów mogła wykorzystać do oszczędzania pamięci dla systemu operacyjnego i innych procesów. W SQL Server 2012 wprowadzono przepisanie menedżera pamięci, aby maksymalna wartość pamięci serwera dotyczyła wszystkich alokacji pamięci SQL Server.
Zdecydowanie zaleca się ustawienie maksymalnej wartości dla instancji SQL Server. Jonathan Kehayias napisał wpis na blogu Ile pamięci faktycznie potrzebuje mój SQL Server, z formułą, która pomaga ustalić punkt odniesienia dla maksymalnej wartości pamięci. W przypadku współdzielonego serwera SQL zalecam moim klientom ustawienie minimalnej wartości na 30% pamięci na serwerze.
W sytuacjach z wieloma instancjami lub gdy serwer jest używany dla SQL Server, SSIS, SSAS lub SSRS, należy ocenić, ile pamięci potrzebują te inne systemy i zmniejszyć maksymalną wartość pamięci serwera, aby zapewnić odpowiednią pamięć dla systemu operacyjnego i innych usługi.
Ten problem dotyczy lokalnego, IaaS i częściowo wystąpienia zarządzanego Azure SQL. Wystąpienie zarządzane ustawia maksymalną wartość pamięci serwera na podstawie wdrożonej warstwy, jednak podczas testowania zmiany rozmiaru środowiska maksymalna wartość pamięci nie została zmieniona dynamicznie. W takiej sytuacji należałoby ręcznie zaktualizować wartość. Ten problem nie dotyczy Azure SQL Database.
Statystyki
Optymalizator zapytań używa statystyk do tworzenia planów wykonania. Oznacza to, że SQL Server potrzebuje aktualnych statystyk, aby optymalizator zapytań miał większą szansę na zbudowanie dobrego planu wykonania. Domyślnie statystyki są aktualizowane po modyfikacji 20% +500 wierszy danych. Na większych stołach może to zająć dużo czasu. Począwszy od poziomu zgodności 130, próg aktualizacji statystyk dla dużych tabel został obniżony. W przypadku programu SQL Server 2008R – 2014 można obniżyć ten próg za pomocą flagi śledzenia 2371.
Regularnie stwierdzam, że klienci nie aktualizują statystyk ręcznie i nawet przy niższym progu zauważyłem, że ręczne aktualizowanie sprawia, że środowisko jest bardziej stabilne.
Zalecam, aby klienci korzystali ze skryptu innej firmy do aktualizacji statystyk. Ola Hallengren opublikował szeroko stosowane rozwiązanie Maintenance Solution dla SQL Server. Częścią tego procesu jest jego procedura Index Optimize, która może pobierać dodatkowe parametry w celu aktualizacji statystyk.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Odkryłem, że klienci, którzy używają produktów lub skryptów innych firm do wykonywania konserwacji indeksu na podstawie poziomu fragmentacji indeksu, nie biorą pod uwagę, że reorganizacje nie aktualizują statystyk, tak jak robią to przebudowy. Wiele z tych aplikacji innych firm ma opcje aktualizacji statystyk, podobnie jak procedura Optymalizacja indeksu Ola, wystarczy ją włączyć.
Aktualizowanie statystyk dotyczy lokalnych, IaaS, Azure SQL Database i Azure SQL Managed Instance.
Utrzymanie indeksu
Wykonywanie konserwacji indeksu przez usunięcie fragmentacji z indeksów jest nadal ważne. W niektórych wycofanych dokumentach Microsoftu stwierdzono, że fragmentacja indeksu może mieć negatywny wpływ od 13 do 460% w zależności od rozmiaru środowiska i poziomu fragmentacji. Podczas gdy sprzęt, taki jak inteligentne sieci SAN, dyski półprzewodnikowe i inne udoskonalenia, pomogły przyspieszyć wszystko, marnowanie miejsca w indeksie może przełożyć się na marnowanie miejsca w puli buforów, a także marnowanie większej liczby operacji we/wy.
Fragmentacja odbywa się poprzez regularne operacje, takie jak wstawianie, aktualizowanie i usuwanie. Aby temu zaradzić, potrzebna jest odpowiednia konserwacja indeksu polegająca na przebudowie lub reorganizacji indeksów. Ponownie zwracam się do Oli Hallengren, za jego skrypt Index Optimize. Skrypt Oli daje możliwość określenia przebudowy lub reorganizacji na podstawie poziomu fragmentacji i minimalnej liczby stron. Wiele narzędzi innych firm oferuje tę samą logikę. Plany konserwacji bazy danych SQL Server wcześniejsze niż SQL Server 2016 umożliwiały jedynie odbudowę lub reorganizację wszystkich indeksów. Począwszy od SQL Server 2016, można teraz określić podobną logikę na podstawie poziomów fragmentacji. Nie zapomnij jednak o tych statystykach, jeśli używasz inteligentnej logiki opartej na poziomach fragmentacji.
Podoba mi się skrypt Oli i narzędzia firm trzecich, które logują się do tabeli. Następnie mogę wysłać zapytanie do tabeli, aby sprawdzić, czy mam jakieś gorące punkty indeksu, w których fragmentacja stale występuje na wysokich poziomach, i rozwiązać problem, dlaczego fragmentacja jest tak powszechna i można cokolwiek zrobić.
Istnieją wyjątki od każdej zasady lub najlepszej praktyki. Niektóre wzorce dostępu do danych prowadzą do ciągłej fragmentacji. Koszt ciągłej przebudowy/reorganizacji tych stołów może nie być tego wart i może być wyłączony z konserwacji. Sytuacje te należy oceniać indywidualnie dla każdego przypadku.
Dotyczy to lokalnych, IaaS, Azure SQL Database i Azure SQL Managed Instance.
MAXDOP
Uważam, że maksymalny stopień równoległości i próg kosztów dla równoległości są zwykle pozostawiane na serwerach klienckich przy wartościach domyślnych. W przypadku MAXDOP wartość domyślna to zero, co oznacza, że do wykonania równoległego regionu zapytania można użyć „nieograniczonej” liczby procesorów. Technicznie do 64 procesorów, chyba że włączysz flagę śledzenia, aby użyć więcej.
Dziesięć lat temu, gdy procesory miały mniejszą liczbę rdzeni, ta wartość była akceptowalna. Dzisiaj, przy dużej gęstości rdzeni i serwerach wieloprocesorowych, nieograniczona liczba procesorów dla równoległości nie jest tak dobra. Firma Microsoft udzieliła wskazówek dotyczących tego, jakich wartości użyć dla MAXDOP.
Jeśli korzystasz z programu SQL Server 2008 — SQL Server 2014, w przypadku pojedynczego węzła NUMA z mniej niż 8 procesorami logicznymi utrzymuj wartość MAXDOP na poziomie lub niższym od liczby procesorów logicznych. Jeśli masz więcej niż 8 procesorów logicznych, zachowaj wartość MAXDOP na poziomie 8. Jeśli masz wiele węzłów NUMA z mniej niż 8 procesorami logicznymi na węzeł NUMA, zachowaj wartość MAXDOP na poziomie lub poniżej liczby procesorów logicznych na węzeł NUMA. Większe niż 8, utrzymuj MAXDOP na poziomie 8.
SQL Server 2016 wprowadził miękkie węzły NUMA. Podczas uruchamiania usługi, jeśli Aparat baz danych wykryje więcej niż 8 rdzeni fizycznych na węzeł lub gniazdo NUMA, węzły miękkie NUMA są tworzone automatycznie. Silnik zajmuje się umieszczaniem procesorów logicznych z tego samego rdzenia fizycznego w różnych węzłach soft-NUMA. Z tego powodu mamy nieco inne wytyczne dotyczące MAXDOP dla SQL Server 2016 i nowsze.
Jeśli korzystasz z programu SQL Server 2016 lub nowszego, w przypadku pojedynczego węzła NUMA z mniej niż 16 procesorami logicznymi utrzymuj MAXDOP na poziomie lub poniżej liczby procesorów logicznych. Jeśli masz więcej niż 16 procesorów logicznych, zachowaj wartość MAXDOP na poziomie 16. Jeśli masz wiele węzłów NUMA z mniej niż 16 procesorami logicznymi na węzeł NUMA, zachowaj wartość MAXDOP na poziomie lub poniżej liczby procesorów logicznych na węzeł NUMA. Większe niż 16, utrzymuj MAXDOP na poziomie połowy liczby procesorów logicznych na węzeł NUMA z wartością MAX wynoszącą 16.
Jeśli jesteś w większości zwirtualizowany na maszynach z 8 lub mniej procesorami logicznymi z domyślnym MAXDOP, prawdopodobnie wszystko jest w porządku. Jeśli masz duży sprzęt fizyczny z ustawieniami domyślnymi, powinieneś przyjrzeć się optymalizacji MAXDOP.
Wszystkie powyższe liczby to wskazówki, a nie twarde prawdy. Twoje obciążenia są różne i należy wziąć pod uwagę to, jaka wartość jest najbardziej optymalna dla Twojego obciążenia.
Konfigurowanie MAXDOP dotyczy lokalnych, IaaS i wystąpienia zarządzanego Azure SQL. Istnieje jednak konfiguracja z zakresem bazy danych, którą można zastosować dla każdej bazy danych, począwszy od SQL Server 2016 i dotyczy to Azure SQL Database.
Próg kosztów dla równoległości
Próg kosztów dla równoległości ma domyślną wartość 5. Historia tej liczby sięga początków SQL Server i stacji roboczej, na której przeprowadzono testowanie obciążenia. Przy nowoczesnym sprzęcie kosztorys 5 jest przestarzały. Testy wykazały, że zwiększenie liczby z 5 do wyższej wartości sprawi, że krócej działające zapytania nie będą miały równoległego planu. Zwykle zalecam zwiększenie tej wartości do wyższej wartości po zbadaniu pamięci podręcznej planu. W wielu przypadkach zaczynam od wartości 25, a następnie monitoruję dalej i w razie potrzeby dostosowuję się od tego miejsca. Aby uzyskać więcej informacji na temat dostrajania progu kosztu równoległości, Jonathan Kehayias napisał:Dostrajanie „prógu kosztu równoległości” z pamięci podręcznej planu.
Dotyczy to lokalnych, IaaS i zarządzanego wystąpienia Azure SQL.
Alerty agenta SQL Server
Wszyscy powinni korzystać z alertów programu SQL Agent, chyba że mają monitorowanie aplikacji innej firmy pod kątem tych samych warunków błędów. Konfiguracja alertów jest łatwa i bezpłatna, a ich skonfigurowanie zapewni Ci krytyczne informacje, gdy Twoje serwery będą miały problemy.
Napisałem artykuł zatytułowany SQL Server Agent Alerts, zawierający instrukcje krok po kroku, jak tworzyć alerty dla błędów o wadze 19-25 i błędu 825. Włączenie tych alertów jest łatwe:włącz pocztę bazy danych, utwórz operator poczty, a następnie utwórz alerty. Można to osiągnąć za pomocą GUI lub T-SQL. Zachęcam wszystkich do opisania tego procesu przy użyciu T-SQL i uczynienia go częścią standardowej budowy serwera.
Dotyczy to lokalnych, IaaS i zarządzanego wystąpienia Azure SQL.
Podsumowanie
Jak widać, istnieje wiele ustawień, które należy zmienić z domyślnych po zainstalowaniu SQL Server. To nie jest pełna lista; jednak obejmuje wiele z bardziej krytycznych i wpływających na wydajność problemów, które znalazłem, i które wrzuciłem do kategorii „Niepowodzenia w SQL Server”.
