Dlaczego dostrajanie wydajności SQL jest tak ważne dla zarządzania bazą danych?
Ponieważ może to zaoszczędzić dużo pieniędzy. Wytrzymaj ze mną, a zobaczysz jak.
Dostrajanie wydajności SQL i zarządzanie bazą danych — łączenie kropek
Większość specjalistów zajmujących się bazami danych spędza swój czas na utrzymywaniu włączonych świateł. Inwestują większość swojego wysiłku w zapewnienie dostępności, monitorując zasoby, takie jak pamięć, pamięć masowa i przepustowość sieci. To duża część zarządzania bazami danych, ale ponieważ coraz więcej firm przenosi swoje bazy danych do niemal nieograniczonych zasobów w chmurze, takich jak AWS i Azure, inne aspekty stają się ważniejsze.
Jednym z tych aspektów jest dostrajanie wydajności SQL. Gdy światła są bezpiecznie utrzymywane i przesuwasz się w górę hierarchii potrzeb w zarządzaniu bazami danych, następną rzeczą, której potrzebujesz, jest lepsza wydajność, która wymaga dostrojenia.
Pierwsze pytania, które należy zadać podczas dostrajania wydajności w SQL
Wcześniej czy później wielu specjalistów od baz danych znajdzie się przed serwerem SQL, którego nie zbudowali. Nie ma wielu poradników dotyczących takiej sytuacji. Dostrajanie wydajności SQL to ćwiczenie polegające na zagłębianiu się w informacje, ustaleniu, co jest nie tak, a następnie iteracyjnym naprawianiu tego.
W pierwszych poprawkach możesz w ogóle nie dotykać instrukcji SQL. Niektórzy specjaliści od baz danych zaczynają od poziomu użytkownika/sesji. Idą tam, gdzie użytkownicy są niezadowoleni, słuchają, jak brzmią ich skargi i zadają pytania.
- Które ekrany lub strony trwają zbyt długo, aby się renderować?
- Czy aplikacja działa wolniej podczas tworzenia nowego zgłoszenia lub otwierania istniejącego?
- Czy zapisanie rekordu zajmuje dużo czasu?
- Jak długo trwa „długi czas?”
Po uzyskaniu tych odpowiedzi sprawdzają, co w bazie danych je powoduje.
To lepsze niż usiąść pierwszego dnia i decydować się na coś takiego jak fragmentacja, która może w ogóle nie wpływać na użytkowników. Chodzi o to, aby zacząć od tego, na czym zależy użytkownikom.
Pomyśl także o poziomie instancji/bazy danych. Na przykład w świecie Microsoft zadania SQL Server Agent są dobrym miejscem do rozpoczęcia. Są to serie działań, które zwykle definiują zadanie administracyjne, które można monitorować pod kątem powodzenia lub niepowodzenia. Mają być wygodne, ale podobnie jak wiele rzeczy w zarządzaniu bazami danych, mają tendencję do gromadzenia się, gdy ludzie zapominają, jak powstały i co robią.
Możesz znaleźć wiele zadań wykonujących to samo, na przykład uruchamianie różnych wersji skryptu indeksującego lub, co gorsza, współdziałanie ze sobą. Zbadaj już skonfigurowane zadania w świetle dwóch pytań:„Co robi ta praca?” i, co ważniejsze, „Jeśli przestanę tę pracę, czy stanie się coś złego?”
Jakich czynników należy szukać?
Kiedy już dojdziesz do poziomu dostrajania wydajności, SQL bierze swoje wskazówki na zachowanie z kilku czynników. Jak opisano w naszym audycji internetowej Ask the Experts:Database Performance Roundtable, możesz poświęcić mniej czasu na dostrajanie samego kodu SQL, jeśli znajdziesz i poprawnie zinterpretujesz takie czynniki:
- Blokowanie — Jeśli serwer blokuje, to jest jak tykająca bomba zegarowa. Załóżmy, że skrypt rozpoczyna transakcję i jej nie zamyka; może to prowadzić do pliku dziennika, który po prostu rośnie i rośnie, aż skończy się miejsce. Blokowanie to zła wiadomość dla wydajności, więc szukaj jej od razu.
- Agenci — W przypadku zadań SQL Server Agent, administratorzy byli znani z tego, że nieumyślnie umieszczali zadania obniżające wydajność w zadaniach. Mogą wykonywać transakcje lub odbudowywać indeksy w zadaniu lub zmniejszać bazę danych w transakcji. W takim przypadku rozważ tymczasowe wyłączenie agenta, aby zamknąć wszystkie powiązane zadania. To agresywna technika, ale jeśli poprawi wydajność, będziesz wiedział dlaczego.
- Statystyki oczekiwania — Zadaj sobie pytanie:„Na co teraz czeka serwer?” Metryki, takie jak oczekiwana długość życia strony i długość kolejki dyskowej, mają kilka odpowiedzi, ale oferują tylko zawężony widok. Statystyki oczekiwania pokazują wszystko przez pryzmat rodzajów oczekiwania i kategorii oczekiwania, co pozwala skupić się na około pięciu zdarzeniach oczekiwania, które pochłaniają najwięcej czasu. Sp_BlitzFirst Brenta Ozara to zaufana procedura składowana służąca do wykrywania, na co czekają Twoje zapytania SQL Server. Następnie, jeśli chcesz przeanalizować długoterminowe wzorce w statystykach oczekiwania serwera, skorzystaj z narzędzia do monitorowania wydajności.
- Aktywność administratora — Jest to również znane jako „błąd pilota”, ponieważ pewne problemy z wydajnością wynikają z tego, co sam robisz. Załóżmy, że jednocześnie używasz SQL Server Activity Monitor i SQL Server Profiler, próbując poznać Query Store. Nie da się uciec przed efektem obserwatora; kiedy śledzisz wszystko w ten sposób, po prostu prosisz, aby baza danych zwolniła.
- Indeksy — W przypadku czegoś, co ma być korzystne, indeksy z pewnością mogą przyprawić o ból karku. W rzeczywistości zasługują na więcej niż jeden pocisk. Czytaj dalej.
Dostrajanie wydajności SQL oznacza dokładne przyjrzenie się indeksom
W dużej mierze dostrajanie wydajności SQL sprowadza się do dostrajania indeksów. Na szczęście, jeśli opanujesz to dla lokalnego zarządzania bazą danych, Twoje umiejętności można łatwo przenieść do zarządzania bazą danych w chmurze.
Dostrajanie indeksów zyskuje na znaczeniu ze względu na ewoluującą różnorodność indeksów:klastrowane, nieklastrowane, unikalne, filtrowane, magazyn kolumn, hash, nieklastrowane zoptymalizowane pod kątem pamięci, XML, przestrzenne i pełnotekstowe, żeby wymienić tylko kilka. Ale jedna rzecz, która nigdy się nie zmieniła, to pierwsza kolumna indeksu, która kieruje decyzjami dotyczącymi indeksowania podejmowanymi przez silnik bazy danych.
Wielu dostawców sprzedaje i wdraża aplikacje z dużą ilością indeksów o dobrych intencjach, które ostatecznie nigdy nie są używane lub, co gorsza, faktycznie utrudniają wydajność. Jeśli przyjrzysz się nieużywanym skryptom indeksowania lub skryptom zużywającym indeksy w niektórych produktach oprogramowania, znajdziesz nadmiar indeksów w kluczu obcym. Jeśli produkt używa, powiedzmy, 20 kluczy obcych, dostawcy mogą dostarczyć do 20 indeksów, plus dziesięć indeksów jednokolumnowych, plus kolejne dziesięć indeksów w unikalnym indeksie klastrowym i tak dalej.
Zawsze, gdy masz taką możliwość, lepszym sposobem podejścia do architektury bazy danych jest rozpoczęcie od jednego indeksu klastrowego, który Twoim zdaniem najlepiej reprezentuje tabelę. Następnie pozwól systemowi działać przez chwilę. Jeśli potrzebujesz więcej indeksów, utwórz je. Dodanie indeksów to ćwiczenie polegające na wyrównywaniu lepszej wydajności tutaj z problemami, takimi jak zapełnianie miejsca na dysku i blokowanie tam. Trudno jest zobaczyć, jak każdy dodatkowy indeks wpływa ogólnie na system.
Jeśli o to chodzi, rozważ wyeliminowanie indeksów — sposób, w jaki osoba z alergią wyeliminowałaby grupy żywności — aby zobaczyć, jak zmienia się wydajność. Spróbuj upuścić każdy indeks w swojej instancji deweloperskiej i zobacz, które z nich wpływają na pięć najważniejszych zapytań.
Dostrajanie wydajności w SQL Server — narzędzia z nim związane
Pamiętaj, że nie jesteś sam w tym przedsięwzięciu. SQL Server zawiera funkcje zaprojektowane w celu poprawy wydajności.
Przewodniki po planach pozwalają zmienić sposób, w jaki SQL Server uruchamia dane zapytanie, i chociaż nie jest to zwykłe dostrajanie wydajności SQL, ma to wpływ na wydajność. Wiele aplikacji zawiera zapytania SQL napisane przez zewnętrznego dostawcę i nawet jeśli te zapytania powodują niską wydajność, niektórzy specjaliści od baz danych, co zrozumiałe, niechętnie je zmieniają. Dzięki przewodnikom po planach możesz dołączyć do zapytania wskazówkę dotyczącą zapytania lub ustalony plan i wpłynąć na jego działanie.
Jednak wadą przewodników po planach jest to, że chociaż nie zmieniają się w czasie, środowisko wokół nich zmienia się. Podobnie jak drukowany plan działania, mogą działać dobrze w krótkim okresie i wkrótce stać się przestarzałe, więc jeśli masz na nich polegać, lepiej je od czasu do czasu odwiedzać.
Powiązana z przewodnikami planu jest Query Store, funkcja programu SQL Server, która pomaga identyfikować i dostrajać zapytania zużywające najwięcej zasobów w systemie. Magazyn zapytań nie jest domyślnie włączony dla nowych baz danych SQL Server i Azure Synapse Analytics (SQL DW). Ale jest to domyślnie włączone w nowych bazach danych Azure SQL.
Ogólnie rzecz biorąc, włączenie Query Store nie jest trudne, ale nie każdy SQL Server potrzebuje go od samego początku. Niektórzy administratorzy nie wiedzą o Query Store, a niektórzy wiedzą o tym, ale nie poświęcili jeszcze czasu, aby odpowiednio go zbadać; lepiej zostawić to wyłączone. Później, gdy zrozumieją, jak działa Query Store, będą mogli użyć go do znalezienia różnic w wydajności spowodowanych zmianami planu zapytań.
Na koniec Doradca dostrajania silnika bazy danych analizuje obciążenia i zaleca indeksy lub strategie partycjonowania w celu poprawy wydajności zapytań. Dobrym pomysłem jest uruchomienie Tuning Advisor w swojej bazie danych; po prostu nie uruchamiaj go zbyt wcześnie. Upewnij się, że baza danych zawiera wystarczającą ilość danych, aby zalecenia dotyczące indeksów były prawidłowe. Kiedy tworzysz swoją aplikację po raz pierwszy, możesz mieć tylko tysiąc wierszy w każdej tabeli. Zalecenia Doradcy dostrajania są bardziej przydatne, gdy baza danych się rozrośnie.
Pokaż mi pieniądze
Jak wspomniałem na początku, dostrajanie wydajności SQL jest ważne dla zarządzania bazami danych, ponieważ pozwala zaoszczędzić pieniądze. Jak?
Zwłaszcza w chmurze, gdzie skalowanie za pomocą karty kredytowej jest popularne, zespoły IT dowiadują się, jak kosztowna może być miesięczna pamięć masowa. Co więcej, zaczynają rozumieć, że uruchamianie źle napisanych zapytań i pozwolenie AWS i Azure na zarządzanie ich indeksami zwiększa koszty przetwarzania w chmurze. Powolne zapytania i złe indeksy kosztują Cię pieniądze.
Dostrajanie wydajności SQL polega na prawidłowym wykonaniu wszystkich tych rzeczy. W ten sposób, niezależnie od tego, czy pozostajesz w świecie lokalnych OpEx, czy migrujesz do świata CapEx w chmurze, zachowujesz kontrolę nad wydatkami.
