Raporty systemowe SSMS

Raporty systemowe SSMS obejmują gotowe zestawienia o aktywności, wydajności i konfiguracji instancji.

Zakres i przeznaczenie raportów systemowych SSMS

Raporty systemowe SSMS to gotowe raporty dostępne w SQL Server Management Studio, służące do przeglądania informacji o instancji Microsoft SQL Server, bazach danych oraz bieżącej aktywności serwera. Nie są one osobnym mechanizmem monitorującym działającym niezależnie od silnika bazy danych. SSMS uruchamia raport i pobiera dane z połączonej instancji, korzystając między innymi z widoków katalogowych, dynamicznych widoków zarządzania oraz procedur systemowych. Zakres prezentowanych informacji zależy więc od wersji SSMS, wersji silnika SQL Server, konfiguracji instancji i uprawnień konta wykonującego raport.

Raporty mogą przedstawiać między innymi stan i konfigurację serwera, wykorzystanie zasobów, właściwości baz danych, informacje o połączeniach, blokadach, transakcjach, zadaniach oraz wydajności zapytań. Ich zadaniem jest szybkie uporządkowanie danych administracyjnych w tabelach, wykresach i sekcjach tematycznych. Raport systemowy nie zastępuje jednak pełnej analizy wydajności. Wynik pokazuje stan danych w chwili wykonania lub zakres wynikający z przechowywanych liczników i historii, dlatego przy diagnozie problemu trzeba uwzględnić czas wystąpienia zdarzenia, obciążenie oraz konfigurację monitorowanej instancji.

Gdzie uruchamia się raporty i jakie dane mogą zawierać

Standardowe raporty są dostępne w interfejsie SSMS po nawiązaniu połączenia z serwerem. W Eksploratorze obiektów można otworzyć menu kontekstowe odpowiedniego węzła, a następnie wybrać pozycję Reports i Standard Reports. Raport wybrany dla instancji może dotyczyć całego serwera, natomiast raport uruchomiony dla konkretnej bazy danych odnosi się do obiektu wskazanego w Eksploratorze obiektów. Dokładna lista raportów oraz ich parametry może różnić się między wydaniami SSMS i obsługiwanymi wersjami SQL Server.

Przykładowe raporty dotyczące aktywności pokazują sesje, żądania, transakcje lub blokowanie. Raporty wydajnościowe mogą prezentować obciążenie procesora, operacje wejścia-wyjścia, oczekiwania, wykorzystanie pamięci albo charakterystykę wykonywanych zapytań, jeżeli wymagane dane są dostępne. Raporty bazodanowe mogą zawierać informacje o rozmiarze plików danych i dziennika, wykorzystaniu przestrzeni, tabelach, indeksach lub właściwościach bazy. Raporty konfiguracyjne odczytują ustawienia instancji i bazy, takie jak wybrane opcje, parametry plików, konfiguracja zabezpieczeń dostępna dla danego raportu oraz informacje o funkcjach włączonych na serwerze.

Raporty są zwykle dostarczane jako definicje raportów RDL, które SSMS przechowuje lokalnie i interpretuje podczas uruchamiania. Oznacza to, że samo posiadanie raportu w instalacji narzędzia nie gwarantuje dostępu do wszystkich danych. Użytkownik musi mieć odpowiednie uprawnienia do odczytu metadanych i informacji diagnostycznych. Przy ograniczonych uprawnieniach raport może zwrócić niepełne dane, komunikat o braku dostępu albo błąd wykonania zapytania używanego przez raport.

Wykorzystanie raportów w diagnostyce SQL Server

Raporty systemowe SSMS pomagają rozpocząć analizę sytuacji, w której baza działa wolno, występują blokady albo rośnie zużycie zasobów. Podczas badania blokowania można sprawdzić, które sesje wykonują żądania, które transakcje oczekują oraz jaki łańcuch zależności powstał między procesami. Taki raport wskazuje stan chwilowy, więc przy krótkotrwałym problemie warto wykonać go kilkukrotnie i porównać wyniki z czasem rozpoczęcia oczekiwania. Sam fakt wykrycia blokady nie oznacza jeszcze błędu silnika; blokada może być normalnym skutkiem izolacji transakcji, ale długie przetrzymywanie blokady może wskazywać na niezatwierdzoną transakcję, nieoptymalne zapytanie lub niewłaściwy zakres operacji.

W analizie wydajności raporty można zestawić z planami wykonania zapytań, statystykami oczekiwań, komunikatami z dziennika oraz obserwacją systemu operacyjnego. Jeżeli raport wskazuje wysokie operacje odczytu, należy sprawdzić, czy wynik wynika z pełnych skanów, niewystarczających indeksów, dużego zakresu danych czy normalnego obciążenia aplikacji. Wysokie użycie procesora również nie określa samoistnie przyczyny, ponieważ może być skutkiem wielu krótkich zapytań, pojedynczego kosztownego zapytania, kompilacji planów albo operacji konserwacyjnych. Raport jest punktem wyjścia do weryfikacji hipotezy, a nie automatyczną rekomendacją zmiany konfiguracji.

Warto zapisywać wyniki raportów wraz z datą, nazwą instancji, nazwą bazy i opisem obserwowanego problemu. Porównanie raportów wykonanych przed zmianą i po zmianie ułatwia ocenę wpływu modyfikacji indeksu, parametrów instancji lub zapytania. Niektóre raporty wymagają funkcji i danych, które mogą być wyłączone albo niegromadzone w danej konfiguracji, dlatego brak wpisu nie zawsze oznacza brak zdarzenia. Przy interpretacji trzeba także rozróżnić dane bieżące od wartości agregowanych w czasie.

Raporty standardowe, własne i ograniczenia interpretacji

Standardowe raporty SSMS są przygotowane do powtarzalnych kontroli administracyjnych, lecz nie obejmują każdej potrzeby diagnostycznej. Administrator może korzystać z raportów własnych, o ile środowisko i używana wersja narzędzia obsługują taką formę rozszerzenia. Raport własny powinien jasno określać źródło danych, zakres czasowy, wymagane uprawnienia, sposób filtrowania oraz znaczenie prezentowanych wartości. Zapytania raportu należy testować na właściwej wersji SQL Server, ponieważ dostępność kolumn, widoków zarządzania i liczników może zależeć od wersji silnika lub użytej edycji produktu.

Raporty uruchamiane z SSMS nie powinny być traktowane jako dowód, że problem został usunięty. Przed wyciągnięciem wniosku trzeba sprawdzić, czy raport został wykonany na właściwej instancji i bazie, czy nie użyto innego konta, czy dane nie są filtrowane oraz czy czas obserwacji obejmuje moment wystąpienia awarii. Szczególną ostrożność należy zachować przy licznikach, rozmiarach i wartościach procentowych: pojedynczy odczyt może nie pokazywać trendu, a wartości zagregowane mogą zależeć od momentu uruchomienia usługi lub wyzerowania statystyk. W praktyce raport systemowy SSMS najlepiej łączyć z kontrolą konfiguracji, analizą zapytań i powtarzalnymi pomiarami.

Przy serwisowaniu laptopa lub komputera PC raporty SSMS mogą być przydatne wtedy, gdy na urządzeniu działa lokalna instancja SQL Server wykorzystywana przez program użytkownika. Wnioski z raportu powinny jednak uwzględniać także stan sprzętu, sterowników, systemu Windows i aplikacji korzystającej z bazy.