Plany wykonania wybierają sposób, w jaki zapytania SQL są wykonywane przez mechanizm bazy danych. Jako takie stanowią różnicę między płynnie działającą bazą danych a taką, która potyka się pod obciążeniem. Zmiany w planie wykonania mają różne powody – często zmieniają się po cichu i bez ostrzeżenia – a dalekosiężne skutki mogą być ogromne.

Najbardziej bezpośrednim skutkiem zmiany planu wykonania jest spadek wydajności zapytań. Zapytanie, które kiedyś działało płynnie i liczone było w milisekundach, może, z powodu zmienionego planu, zacząć pochłaniać sekundy. Ten wzrost czasu zapytania może kaskadowo przełożyć się na dłuższy czas ładowania aplikacji, frustrację użytkowników końcowych i poważne reperkusje finansowe w środowiskach o wysokiej stawce, takich jak finansowe platformy transakcyjne lub usługi danych w czasie rzeczywistym.

Problem potęguje fakt, że właściciele aplikacji często nie zwracają uwagi na te zmiany. Wielu z nich pozostaje w dużej mierze skupionych na wydajności aplikacji na powierzchownym poziomie. Zakładają, że każde spowolnienie lub wąskie gardło jest kwestią oprogramowania, podejmując świadomą decyzję o nie zagłębianiu się w warstwę bazy danych. Niedopatrzenie to jest często straconą okazją do wychwycenia i skorygowania zmian, które później obniżą wydajność aplikacji.

Gdzie standardowe narzędzia do administrowania bazami danych są niewystarczające

Standardowe narzędzia do administracji bazami danych mają szerokie spektrum wskaźników kondycji systemu. Brakuje im jednak głębi wymaganej do skutecznej analizy i interpretacji zmiany w planie wykonania. Narzędzia te mogą ostrzegać administratorów o skokach użycia procesora lub wolniejszych czasach odpowiedzi na zapytania. Nie oferują one jednak bardziej szczegółowego wglądu niezbędnego do wskazania, że problemy te mogą wynikać ze zmiany planu wykonania.

Co więcej, chociaż narzędzia te mogą pokazać, kiedy i gdzie wskaźniki wydajności słabną, rzadko zapewniają analizę danych historycznych niezbędną do śledzenia wydajności planu wykonania w czasie. Zrozumienie trendów w wydajności planu wykonania wymaga widoku wzdłużnego – czegoś, czego wiele gotowych narzędzi nie obsługuje. Bez tej możliwości trudno jest zidentyfikować, czy problem z wydajnością jest jednorazową anomalią, czy też częścią długoterminowego spadku wydajności bazy danych.

Analiza krok po kroku przy użyciu DBPLUS Performance Monitor

1. Rozpoczęcie analizy

Ten wyjściowy interfejs pozwala nam ocenić, w jaki sposób zapytania wchodzą w interakcję z instancją bazy danych i jak wpływają na ogólną wydajność systemu. Tutaj użytkownicy mogą przeglądać kompleksowe zestawienie wykorzystania instancji, które obejmuje zużycie procesora, operacje we / wy i inne, wszystkie wyświetlane za pomocą intuicyjnych wykresów i wykresów.

W tym przypadku analizujemy statystyki bazy danych z ostatnich czterech dni. Ekran SQL Analyzer pokazuje, które zapytania zostały wykonane w tym okresie, ale nie ogranicza się tylko do tego. Podkreśla również te, które miały największy wpływ na użycie procesora.

Wybierając najbardziej widoczne zapytania z tej listy, natychmiast widzimy, które operacje zużywają najwięcej zasobów i kiedy wystąpiły skoki użycia.

Widzimy, że w niektóre dni to konkretne zapytanie odpowiada za 50% obciążenia instancji. Dlaczego?

2. Szczegółowa analiza zapytań

Po zidentyfikowaniu interesujących zapytań na ekranie SQL Analyzer, następnym krokiem jest głębsze zapoznanie się z każdym konkretnym zapytaniem na ekranie SQL Detail.

Na ekranie SQL Detail statystyki mogą być grupowane według różnych przedziałów czasowych – dni, tygodni, a nawet miesięcy – dając administratorom elastyczność w ocenie wydajności zgodnie z potrzebami ich analizy. W tym przypadku grupowanie według dni dla ostatnich czterech dni ujawnia, że zapytanie działało dobrze w dwa z czterech dni, ale w pozostałych nastąpiło znaczne spowolnienie.

Takie trendy sugerują wahania obciążenia bazy danych lub korekty w planach wykonania, które wymagają dalszych badań.

3. Identyfikacja nieefektywności w planach wykonania

Na tym etapie uwaga skupia się na identyfikacji przyczyn leżących u podstaw zaobserwowanych różnic w wydajności. DBPLUS PERFORMANCE MONITOR umożliwia porównanie różnych planów wykonania dla tego samego zapytania, ilustrując, w jaki sposób każdy plan wpływa na wskaźniki wydajności, takie jak czas wykonania i wykorzystanie zasobów.

Widzimy teraz, że w dniach, w których zapytanie wykonuje się wydajniej (po lewej), plan wykonania wykorzystuje operację wyszukiwania indeksu. Jest ona zwykle używana, gdy optymalizator zapytań zdecyduje, że może zlokalizować dane bardziej bezpośrednio i wydajnie. Z tego powodu jest to szybsze, ponieważ lokalizuje i pobiera niezbędne dane bez zbędnego narzutu.

W dni oznaczone obniżoną wydajnością (po prawej), plan wykonania ucieka się do operacji skanowania indeksu, która jest mniej wydajna ze względu na wymagany szerszy zakres danych.

4. Porównanie planów wykonania

Wizualne porównanie dwóch planów wykonania – jednego, który prowadzi do szybszego wykonania i drugiego, który skutkuje wolniejszą wydajnością – zapewnia jasny i przejrzysty widok. Monitor pozwala użytkownikom przeglądać te plany obok siebie, analizując różnice w strategiach optymalizatora bazy danych.

W tym przypadku wolniejszy plan wykonania obejmuje optymalizator MS SQL Server wybierający odczyt całego indeksu. Wszystko z powodu klauzuli ORDER BY, która nie pasuje do używanego indeksu. Optymalizator decyduje, że skanowanie całego indeksu jest konieczne, ponieważ dane muszą zostać posortowane w sposób, którego istniejący indeks nie obsługuje. Takie podejście jest mniej wydajne, ponieważ wymaga odczytu większej ilości danych niż jest to konieczne. Jest to również powód, dla którego wolniejsze zapytanie nie spieszyło się.