W złożonym ekosystemie SQL Server kwestie wydajności mogą czasami przypominać pracę detektywa, zwłaszcza podczas śledzenia nieuchwytnych winowajców blokad systemowych. Tym razem zbadamy, w jaki sposób nieefektywne zapytania (i źle przeprowadzone monitorowanie zapytań) mogą zatrzymać operacje. Zidentyfikujemy też „jak” i „dlaczego” stojące za zatrzymaniem oraz pokażemy Wam jak skuteczne monitorowanie zapytań SQL może zapobiegać blokadom.

Od analizowania trendów obciążenia po analizowanie historii blokad i udoskonalanie planów wykonania, upewniamy się, że żaden kamień – a raczej, żaden blok danych – nie pozostanie nieodwrócony w naszych dążeniach do tego, aby SQL Server poruszał się szybko jak sportowy samochód , a nie jak juczny muł.

Trendy obciążenia i użycie procesora

Ekran Load Trends DBPLUS PEROFMANCE MONITORa jest miejscem oferujacym coś dla każdej osoby chcącej dość do sedna zapytań SQL. Jest to dokładne spojrzenie na statystyki wydajności dla zapytań instancji SQL Server. Grupując statystyki według godzin od 4 do 11 kwietnia, początkowo skupiamy się na wykorzystaniu procesora przez uruchomione zapytania. Powodem dramatu, którego świadkiem stał się nasz klient, były znaczące incydenty blokowania:

• 5 kwietnia procesor zdecydował się na zmianę humoru, powodując zamieszanie ze znaczącymi incydentami blokowania.

• Zapisy z 7 i 11 kwietnia są równie ciekawymi przypadkami. Drugi z tych dni był świadkiem zasobów zablokowanych na oszałamiające 1 272 sekundy.

Historia blokad i analiza sesji

Zagłębiając się w sedno sprawy i monitorowanie zapytań SQL, odwiedziliśmy zakładkę 'block history’. Służy ona jako nasz wehikuł czasu, oferując wgląd na potyczki z blokadami. Tutaj każdy typ blokady z poszczególnych dni dostaje swoją chwilę pod mikroskopem. Żywy interaktywny wykres przedstawia przypływy i odpływy dramatu bazy danych. Pokazuje nam liczbę sesji blokujących i oczekujących wraz z czasem ich trwania.

Proste kliknięcie na wykresie ujawnia winowajców każdej z blokad. Oddziela inicjatorów (sesje blokujące) od ofiar (sesji oczekujących).

Co ciekawe, nasze dochodzenie ujawniło notorycznegp sprawcę. Ta sama sesja, z różnymi numerami, została złapana na gorącym uczynku, konsekwentnie wykonując zapytanie, które wywołało blokady.

Statystyki zapytań i plany wykonania

Odwiedzając ekran szczegółów SQL, możemy śledzić wybryki zapytania od 11 do 20 kwietnia, odkrywając, że jest to wydajnościowy kameleon. W dniu 11 kwietnia zdecydowano się wypróbować plan wykonania, który, delikatnie mówiąc, nie spieszył się . Jego wykonanie, każdorazowało trwało. To powolne tempo było całkiem niezłym widowiskiem w porównaniu z jego późniejszymi występami.

W jaśniejsze dni nasze zapytanie wybierało szybszy plan wykonania. Przeleciało przez dane w tempie pięciokrotnie szybszym. Ta zmiana tempa nie tylko pokazuje, że zapytanie może zmienić swoje paski. Podkreśla również dramatyczny wpływ wyboru właściwego planu.

Optymalizacja wydajności dzięki strategicznemu indeksowaniu

Porównanie dwóch planów wykonania uwypukliło drogę działania: dodanie indeksu do kolumny Product ID. Ta poprawka okazała się strzałem w dziesiątkę, zwiększając szybkość zapytania i usuwając te nieznośne problemy z blokowaniem. Był to klasyczny przypadek, w którym indeksowanie strategiczne prężyło muskuły w celu zwiększenia wydajności SQL Server.

Ten epizod podkreśla znaczenie czujnego monitorowania i terminowych poprawek – cech charakterystycznych DB Plus Performance Monitor. Takie narzędzia są niezbędne do wykrywania i naprawiania wąskich gardeł wydajności, zapewniając, że SQL Server działa jak dobrze naoliwiona maszyna.