Gdy użytkownik lub aplikacja wysyła żądania do bazy danych, zużywa zasoby w tym systemie. Wraz ze wzrostem liczby żądań możesz doświadczyć oczekiwania na zasoby. Te oczekiwania prowadzą do wąskich gardeł wydajności, a w przypadku baz danych w chmurze, dodatkowych kosztów miesięcznych! Podczas diagnozowania wąskich gardeł wydajności pierwszym krokiem jest zrozumienie, które zasoby są dotknięte.
Możliwość zmapowania wąskiego gardła wydajności z powrotem na określone oczekiwanie zasobu, następnie na określony kod, a na koniec na obciążenie określonego użytkownika, umożliwi dotarcie do głównej przyczyny i trwałe rozwiązanie wąskiego gardła.
Na przykład możesz odkryć, że aplikacja działa wolno, ponieważ procesor jest nadmiernie obciążony na serwerze bazy danych, ponieważ Matt z działu zakupów prowadzi raport inwentaryzacji w bazie danych zakładu.
Analizator obciążenia Spotlight Cloud to narzędzie, które umożliwia to dzięki przyjaznej dla użytkownika nawigacji.
Jak korzystać z analizatora obciążenia Spotlight Cloud
Na początek możesz wybrać interesujący Cię przedział czasowy. Spotlight Cloud przechowuje dane z jednego roku, dzięki czemu możesz cofnąć się do dowolnego punktu w czasie lub zakresu czasu z ostatniego roku.
Następnie masz możliwość filtrowania według zasobów. Na przykład, jeśli wiesz, że problem jest związany z procesorem, możesz wybrać zasób procesora. W ten sposób odfiltrowuje się informacje związane ze wszystkimi innymi zasobami, takimi jak wejścia/wyjścia, blokady i pamięć, skutecznie eliminując biały szum i ułatwiając dotarcie do pierwotnej przyczyny.
Domyślna strona analizatora obciążenia
Przeszukuj wymiar baz danych, aby uporządkować najlepsze bazy danych zużywające najwięcej zasobów od wysokiego do niskiego i odpowiednio je zacieniować. Ten mechanizm sortowania jest zachowywany przez każdą iterację drążenia.
Wgłębianie się w wymiar bazy danych
Co więcej, powinieneś zagłębić się w bazę danych sprzedaży, ponieważ ważne jest, aby wiedzieć, jakie zachowania oczekują w szczególności w najbardziej zużywającej się bazie danych. W tym przykładzie wydaje się, że większość obciążenia była obciążona procesorem (45,7 procent) i zasobami we/wy (30,2 procent), a ich stawki są zbliżone do 0,48 s/s i 0,43 s/s.
Wgłębianie się w wymiar bazy danych sprzedaży
Równolegle wybranie procesora spowoduje odfiltrowanie innych zasobów i uzyskanie dostosowanego odczytu tylko dla procesora. Możliwość wyodrębnienia określonego obciążenia jest przydatna, ponieważ wizualnie odfiltrowuje rozpraszające metryki, pozwalając skupić się tylko na tym, co ma pierwszeństwo. Ponadto wskaźniki wydajności mogą być przedstawiane na wykresie jeden na drugim, dzięki czemu można wizualnie zobaczyć korelacje.
Kluczowe wskaźniki wydajności filtrowane tylko dla statystyk procesora
Następnie przejdź do partii T-SQL. Dzięki temu możemy dowiedzieć się, które partie w bazie danych sprzedaży są najbardziej obciążające. 
Wiercenie w partiach T-SQL
Ponieważ ta partia bardzo intensywnie wykorzystuje procesor, ważne jest, aby wiedzieć, które zapytania w tej partii są przyczyną dodatkowych kosztów. Użycie tekstu T-SQL w połączeniu z planem wykonania pokazuje, że winę ponosi operator Sort. Optymalizator SQL prognozuje, że szacowana opłata wynosi 97 procent. Dodanie indeksu może pomóc zoptymalizować wydajność.
Oświadczenia T-SQL
Plan wykonania i analiza kosztów wykonanych operacji
Należy pamiętać, że selektor zasobów można skonfigurować tak, aby wyróżniał zasób, gdy jego wykorzystanie przekroczy wcześniej zdefiniowany próg. Na przykład można ustawić selektor tak, aby podświetlał zasoby we/wy, jeśli czas oczekiwania przekracza 30 procent.
Dostosowywanie konfiguracji selektora zasobów dla zasobów we/wy
Zastosowano zaktualizowane konfiguracje dla selektora zasobów we/wy
