Jak dobrze wie każdy, kto zarządza bazami danych, dostrajanie wydajności programu SQL Server to kluczowa funkcja zapewniająca optymalną wydajność. Ponieważ wydajność zależy od różnych czynników, takich jak pamięć, konfiguracja, projektowanie zapytań i wykorzystanie zasobów, wyizolowanie podstawowej przyczyny obniżenia wydajności jest niemałym wyczynem.
Zamiast czekać na wystąpienie problemów z wydajnością, proaktywne dostrajanie SQL Server zapewni jak najefektywniejsze działanie instrukcji SQL, pomagając SQL znaleźć najszybszą drogę do i z niej w celu dostarczenia wyników zapytania.
Jeśli zmagasz się z niską wydajnością — lub nie jesteś tym, który po prostu czeka na pojawienie się problemów — oto trzy kluczowe obszary, na których należy skoncentrować się na dostrajaniu wydajności SQL Server, aby osiągnąć optymalną wydajność i zdrowsze systemy.
Wskazówka nr 1:zoptymalizuj bazę danych TempDB
Nieprawidłowo skonfigurowana baza danych TempDB jest częstą przyczyną spadku wydajności. Jeśli często zapełniasz bazę danych TempDB, nadszedł czas, aby przyjrzeć się, co należy zmienić.
Najpierw sprawdź rozmiar TempDB. Nie ma sztywnej i szybkiej reguły określającej, jak duży powinien być, ale dobrą zasadą jest utrzymywanie TempDB na poziomie 25% największej bazy danych lub takim samym rozmiarze, jak największy indeks. Zapobiega to konieczności zwiększania TempDB podczas przebudowy.
Dzięki TempDB im szybszy dysk, tym lepiej. Gdy TempDB zostanie umieszczony na wolnym dysku lub na tym samym dysku, co system operacyjny, na pewno wystąpią problemy z wydajnością bazy danych. Jeśli to możliwe, zachowaj TempDB na dedykowanym lokalnym dysku SSD. Jeśli nie jest to możliwe, następną najlepszą opcją jest trzymanie go na własnym dedykowanym woluminie z wystarczającą ilością wstępnie przydzielonego miejsca na dysku.
Ważne jest również, aby oddzielić pliki danych i dzienników oraz ustawić dużą stałą wartość dla autowzrostu TempDB. W przeciwnym razie za każdym razem, gdy zapełni się baza danych TempDB, zostaniesz dotknięty niepotrzebnym obciążeniem.
Kontrolowanie liczby plików danych TempDB przyczynia się do optymalizacji TempDB. Ale najważniejsze pytanie brzmi:ile plików danych TempDB potrzebujesz? W idealnym przypadku będziesz mieć jeden plik danych TempDB dla każdego logicznego procesora, ale nie więcej niż osiem (z pewnymi wyjątkami). Na przykład, jeśli masz cztery logiczne procesory, potrzebujesz czterech plików danych TempDB. Jeśli masz 12 logicznych procesorów, możesz mieć osiem plików danych TempDB.
Wskazówka 2:zapobiegaj wąskim gardłom wydajności
Istnieją trzy główne typy wąskich gardeł wydajności programu SQL Server, które przyczyniają się do niskiej wydajności:procesor, pamięć i operacje we/wy. Przyczyny, objawy i diagnostyka różnią się w zależności od rodzaju wąskiego gardła, więc oto krótki przewodnik, na co należy uważać:
Wąskie gardła procesora
Przyczyna: Niewystarczające zasoby sprzętowe
Objawy: Stale wysokie wykorzystanie procesora
Wskaźniki do monitorowania: % czasu procesora, żądania wsadowe/s, kompilacje SQL/s i rekompilacje SQL/s
Wąskie gardła pamięci
Przyczyna: Ograniczenia w dostępnej pamięci i ciśnienie pamięci spowodowane przez SQL Server, system lub inną aktywność aplikacji
Objawy: Wolna reakcja aplikacji, ogólne spowolnienie systemu i awarie aplikacji
Wskaźniki do monitorowania: Dostępna pamięć (KB), Całkowita pamięć serwera (KB), Docelowa pamięć serwera (KB), Strony/s, Punkty kontrolne/s, Opóźnione zapisy/s i współczynnik trafień w pamięci podręcznej bufora
Wąskie gardła we/wy
Przyczyna: Nadmierne odczytywanie i zapisywanie stron bazy danych zi na dysk
Objawy: Długie czasy odpowiedzi, spowolnienia aplikacji i przerwy w zadaniach
Wskaźniki do monitorowania: Średnia długość kolejki dysku, Średnia s/odczyt dysku, Średnia s/zapis na dysku, %Czas na dysku, Średnia liczba odczytów dysku/s i Średnia liczba zapisów/s na dysku
Wskazówka 3:Upewnij się, że indeksy są odpowiednio zaprojektowane
Indeksy to świetny sposób na przyspieszenie niektórych operacji SQL Server, ale tylko wtedy, gdy są dobrze zaprojektowane. Źle zaprojektowane indeksy mają odwrotny skutek i są pewnym sposobem na obniżenie wydajności SQL Server.
Właściwe skonfigurowanie tych czterech obszarów może pomóc w zapewnieniu prawidłowego projektowania indeksów i pomóc, a nie szkodzić wydajności SQL Server.
Rozmiar stołu
Nie każda tabela jest dobrym kandydatem do indeksowania. W rzeczywistości, jeśli tabela jest zbyt mała, SQL Server znacznie efektywniej przeszukuje całą tabelę, niż musi przeszukiwać indeksy. Oczywiście w przypadku dużych tabel jest odwrotnie, więc przy podejmowaniu decyzji, które tabele skorzystają z indeksów, należy rozważyć potencjalne obciążenie.
Typy indeksów
Z technicznego punktu widzenia każda tabela bazy danych może mieć jeden indeks klastrowy i nieskończoną liczbę indeksów nieklastrowanych, ale wiesz, co mówią o „tylko dlatego, że możesz coś zrobić”…
Zbyt wiele indeksów nieklastrowanych może znacznie spowolnić operacje wstawiania i aktualizowania, więc trzymanie się jednego indeksu klastrowego i minimalnej liczby absolutnie niezbędnych indeksów nieklastrowych jest znacznie lepszym wyborem projektowym.
Przechowywanie indeksów
Na etapie projektowania wybór odpowiednich kryteriów przechowywania dla indeksów ma kluczowe znaczenie dla wydajności we/wy. Partycjonowane indeksy klastrowane i indeksy nieklastrowane mogą być przechowywane w tej samej grupie plików co tabela główna lub mogą być przechowywane w innej grupie plików. Przechowywanie indeksu nieklastrowanego w grupie plików znajdującej się na innym dysku może poprawić wydajność zapytań, które go używają, ponieważ nie ma na to wpływu współbieżne odczytywanie danych i stron indeksu SQL występujących na różnych dyskach.
FILLFACTOR
FILLFACTOR określa procent miejsca, które zostanie wypełnione na każdej stronie danych podczas tworzenia indeksu. Wartości FILLFACTOR mogą mieścić się w zakresie od 0 procent (żadna strona danych nie jest wypełniona) do 100 procent (strona danych jest całkowicie wypełniona). Projektując indeks, wybierz wartość FILLFACTOR, która zoptymalizuje wykorzystanie strony, jednocześnie minimalizując ryzyko nadmiernej fragmentacji indeksu.
Włączenie dostrajania wydajności SQL Server do standardowej procedury to doskonały sposób na zapewnienie najwyższej wydajności baz danych. Włączenie tych trzech prostych kroków do regularnych planów konserwacji SQL Server znacznie poprawi szybkość i wydajność użytkowników.
