Monitorowanie SQL Server z poziomu Windows opiera się na licznikach wydajności systemu oraz dzienniku zdarzeń.
Zakres monitorowania instancji SQL Server w systemie Windows
Monitorowanie SQL Server z poziomu Windows obejmuje obserwację zarówno procesu silnika bazy danych, jak i zasobów systemu operacyjnego, z których ten silnik korzysta. Podstawowym narzędziem jest Monitor wydajności systemu Windows, uruchamiany jako Performance Monitor lub poleceniem perfmon.exe. Pozwala on zbierać dane z liczników wydajności w określonych odstępach czasu, zapisywać je w zestawach modułu zbierającego dane i porównywać obciążenie w czasie. Taki pomiar powinien obejmować procesor, pamięć operacyjną, podsystem dyskowy, sieć oraz liczniki udostępniane przez poszczególne komponenty SQL Server.
W przypadku silnika relacyjnego SQL Server istotne są między innymi obiekty liczników SQLServer:SQL Statistics, SQLServer:Buffer Manager, SQLServer:Databases, SQLServer:Access Methods i SQLServer:Wait Statistics, jeżeli dana wersja i konfiguracja udostępniają konkretny obiekt. Nazwy instancji mogą być prezentowane z oznaczeniem instancji nazwanej, dlatego przed zapisaniem konfiguracji warto sprawdzić listę dostępnych obiektów w lokalnym Monitorze wydajności. Sam wysoki poziom pojedynczego licznika nie przesądza jeszcze o błędzie. Znaczenie ma jego korelacja z czasem trwania operacji, typem obciążenia oraz objawami widocznymi w zapytaniach i dziennikach.
Liczniki procesora, pamięci i operacji wejścia-wyjścia
Po stronie systemu Windows często analizuje się licznik Processor(_Total)\% Processor Time, a także czas procesora dla procesu sqlservr.exe. Długotrwałe wysokie użycie procesora może wskazywać na kosztowne zapytania, kompilowanie planów wykonania, sortowanie, agregacje albo nieefektywne przetwarzanie danych, lecz nie identyfikuje samoistnie przyczyny. Przydatne jest zestawienie tego pomiaru z licznikami SQL Server dotyczącymi kompilacji i ponownego użycia planów oraz z informacjami o oczekiwaniach sesji.
Dla pamięci systemowej sprawdza się między innymi Memory\Available MBytes, Memory\Pages/sec oraz użycie pamięci przez proces sqlservr.exe. W samym SQL Server można porównać te dane z informacjami DMV, takimi jak sys.dm_os_process_memory i sys.dm_os_sys_memory. Wysoka aktywność stronicowania systemowego może oznaczać presję na pamięć, ale licznik Pages/sec obejmuje różne operacje pamięci i wymaga interpretacji w szerszym kontekście.
Podsystem dyskowy ocenia się z użyciem liczników takich jak LogicalDisk(*)\Avg. Disk sec/Read, LogicalDisk(*)\Avg. Disk sec/Write, LogicalDisk(*)\Disk Reads/sec, LogicalDisk(*)\Disk Writes/sec oraz LogicalDisk(*)\Current Disk Queue Length. W SQL Server ważne jest rozróżnienie plików danych, plików dziennika transakcji i pliku tempdb, ponieważ każdy z tych obszarów może mieć inny profil operacji. Obiekt SQLServer:Databases dostarcza między innymi liczników związanych z aktywnością transakcji i dziennika, natomiast oczekiwania typu PAGEIOLATCH_* mogą wskazywać, że sesje czekają na odczyt stron danych z dysku.
Dzienniki zdarzeń, DMV i ślady diagnostyczne
Podgląd zdarzeń Windows, dostępny przez eventvwr.msc, umożliwia sprawdzenie wpisów z dziennika aplikacji oraz dziennika systemowego. Błędy SQL Server są jednak przede wszystkim zapisywane w dzienniku błędów samego silnika. Lokalizację aktywnego pliku można odczytać z konfiguracji instancji albo sprawdzić w SQL Server Management Studio w sekcji zarządzania dziennikami. Przy analizie należy zwracać uwagę na powtarzające się komunikaty o nieudanych operacjach wejścia-wyjścia, problemach z uruchomieniem usługi, braku dostępu do pliku, błędach logowania, przerwanych połączeniach oraz nieudanych operacjach odtwarzania lub zapisu dziennika.
Do kontroli stanu działającej instancji służą dynamiczne widoki zarządzania, czyli DMV. Widok sys.dm_exec_requests pokazuje aktualnie wykonywane żądania, ich czas, stan, polecenie i oczekiwanie. sys.dm_os_waiting_tasks pomaga ustalić, na co czekają zadania, a sys.dm_exec_sessions i sys.dm_exec_connections dostarczają informacji o sesjach oraz połączeniach. Historię kosztownych zapytań można analizować przez sys.dm_exec_query_stats wraz z funkcjami sys.dm_exec_sql_text i sys.dm_exec_query_plan. Dane z tych widoków są związane z okresem życia planów i pamięci podręcznej, dlatego nie zastępują długookresowego systemu zbierania danych.
Do rejestrowania szczegółowych zdarzeń SQL Server stosuje się Extended Events. Sesja tego mechanizmu może rejestrować na przykład zakończenia zapytań, błędy, blokowania, deadlocki lub długie oczekiwania, a następnie zapisywać wyniki do pliku .xel. W przeciwieństwie do przypadkowego uruchamiania rozbudowanego śledzenia konfigurację należy dopasować do konkretnego problemu, ponieważ zbyt szeroki zakres zdarzeń zwiększa ilość danych i utrudnia analizę. Deadlocki można rejestrować przez zdarzenie xml_deadlock_report, którego dane zawierają graficzny opis konfliktu blokad w formacie XML.
Łączenie pomiarów w diagnozie problemu
Wiarygodna diagnoza wymaga zestawienia pomiarów z tego samego przedziału czasu. Przykładowo, wzrost czasu odpowiedzi zapytań należy porównać z użyciem procesora, opóźnieniem odczytów i zapisów dyskowych, presją pamięci, długością blokad oraz typami oczekiwań. Jeżeli w tym samym czasie rosną opóźnienia plików danych i oczekiwania PAGEIOLATCH_*, hipoteza o ograniczeniu wejścia-wyjścia jest bardziej uzasadniona niż wniosek oparty wyłącznie na wysokim użyciu procesora. Z kolei oczekiwania LCK_M_* wskazują na czekanie związane z blokadami, a nie bezpośrednio na awarię dysku.
Przygotowany zestaw monitorowania powinien określać częstotliwość próbkowania, czas przechowywania danych oraz sposób oznaczania okresów awarii. Warto rejestrować wersję SQL Server, nazwę instancji, role monitorowanych plików i moment wystąpienia objawu. Dzięki temu można odróżnić stałe przeciążenie od krótkiego skoku aktywności. Nie należy traktować progów liczbowych jako uniwersalnych dla każdej instalacji, ponieważ ich interpretacja zależy od rozmiaru bazy, rodzaju zapytań, szybkości magazynu i oczekiwanego obciążenia. Diagnostyka techniczna może obejmować sprawdzenie usługi SQL Server, poprawności dostępu do plików, stanu systemu Windows, dzienników oraz wyników DMV, bez wyciągania wniosków z pojedynczego komunikatu.
W praktyce raport z monitorowania powinien rozdzielać objaw, obserwację i potwierdzoną przyczynę. Przykładowo: „wystąpił wzrost czasu oczekiwania” jest obserwacją, „sesje oczekiwały na blokadę” jest wynikiem analizy DMV, a „konkretna transakcja utrzymywała blokadę przez określony okres” wymaga dodatkowego potwierdzenia w danych Extended Events lub historii zapytań. Takie rozróżnienie ogranicza ryzyko błędnej interpretacji i ułatwia zaplanowanie dalszych czynności diagnostycznych przy instancji SQL Server działającej w środowisku Windows.
