Data Collector

Data Collector to komponent SQL Server umożliwiający zbieranie i przechowywanie danych o wydajności serwera w czasie.

Data Collector w architekturze SQL Server

Data Collector jest funkcją SQL Server przeznaczoną do cyklicznego gromadzenia informacji o pracy instancji oraz jej otoczenia sprzętowego. Mechanizm pozwala rejestrować dane w czasie, dzięki czemu analiza nie ogranicza się do jednorazowego odczytu obciążenia procesora, pamięci, dysków lub zapytań. Dane mogą być później porównywane między okresami, co ułatwia rozpoznanie powtarzających się przeciążeń, zmian wydajności i problemów występujących tylko w określonych godzinach.

Elementem docelowym gromadzonych informacji jest zwykle Management Data Warehouse, czyli baza danych przeznaczona do przechowywania danych historycznych. Data Collector korzysta z kolektorów danych oraz zestawów kolekcji, nazywanych collection sets. Zestaw określa między innymi, jakie informacje są pobierane, jak często odbywa się zbieranie oraz kiedy dane są przekazywane do magazynu. Konfigurację tej funkcji wykonuje się w SQL Server Management Studio, w obszarze zarządzania instancją SQL Server.

Zestawy kolekcji, kolektory i harmonogramy

W SQL Server Data Collector może korzystać z predefiniowanych zestawów kolekcji, takich jak Server Activity, Query Statistics oraz Disk Usage. Server Activity służy do obserwowania ogólnej aktywności serwera, Query Statistics gromadzi informacje przydatne przy analizie wykonywania zapytań, a Disk Usage koncentruje się na wykorzystaniu przestrzeni przez pliki baz danych i dzienniki transakcji. Zakres danych zależy od wersji SQL Server oraz konfiguracji konkretnego zestawu, dlatego sam fakt włączenia Data Collector nie oznacza automatycznego rejestrowania każdej możliwej metryki.

Za wykonywanie zaplanowanych operacji odpowiada SQL Server Agent. Jeżeli Agent jest zatrzymany, wyłączony albo nie może uruchomić wymaganych zadań, zestawy kolekcji nie będą działały zgodnie z harmonogramem. Podczas diagnostyki należy sprawdzić stan usługi, historię zadań agenta, konfigurację harmonogramów oraz ewentualne błędy zapisu do Management Data Warehouse. Istotne jest także rozróżnienie dwóch etapów: pobrania danych ze źródła oraz ich późniejszego przesłania do magazynu. Błąd może pojawić się w jednym z tych etapów, mimo że pozostałe elementy konfiguracji działają poprawnie.

Data Collector może pracować w trybie buforowanym albo bezpośrednim. W trybie buforowanym dane są najpierw zapisywane lokalnie, a następnie przekazywane do magazynu według osobnego harmonogramu. Takie rozdzielenie ogranicza wpływ chwilowej niedostępności magazynu na samo zbieranie informacji, ale może powodować opóźnienie między wystąpieniem zdarzenia a pojawieniem się danych w raportach. W trybie bezpośrednim kolektor próbuje przekazać dane podczas wykonywania operacji zbierania, więc problemy z połączeniem lub uprawnieniami mogą szybciej zatrzymać cały przebieg.

Management Data Warehouse i interpretacja danych historycznych

Management Data Warehouse nie jest kopią produkcyjnych baz danych ani pełnym dziennikiem wszystkich operacji wykonywanych przez użytkowników. Przechowuje tylko te informacje, które zostały objęte aktywnymi kolektorami i mieszczą się w ich zakresie. Z tego powodu brak wpisu w magazynie nie musi oznaczać, że określone zdarzenie nie wystąpiło. Może oznaczać, że odpowiedni zestaw kolekcji był wyłączony, działał z innym interwałem albo nie zdołał przesłać danych.

Podczas analizy należy uwzględnić częstotliwość próbkowania. Krótki, kilkuminutowy skok obciążenia może nie być widoczny w raporcie tworzonym z rzadszych próbek, natomiast dłuższe okresy wysokiego użycia zasobów powinny pozostawić ślad w danych historycznych. Nie wolno też utożsamiać wysokiego użycia procesora z pojedynczą przyczyną problemu. W SQL Server podobny objaw może wynikać z kosztownych zapytań, kompilacji planów, blokad, presji pamięci lub operacji wejścia-wyjścia. Data Collector dostarcza materiału porównawczego, ale interpretacja wymaga zestawienia kilku kategorii danych.

W praktyce warto porównywać czas wykonywania zapytań, liczbę wykonanych operacji, odczyty i zapisy dyskowe, oczekiwania oraz dostępność pamięci. Szczególne znaczenie ma odróżnienie danych bieżących od historycznych: raport z Management Data Warehouse opisuje stan zarejestrowany przez kolektor, a niekoniecznie stan aktualny w chwili otwarcia raportu. Należy również sprawdzić okres przechowywania danych i działanie zadań porządkowych, ponieważ zbyt krótka retencja może usunąć materiał potrzebny do porównania kilku tygodni lub miesięcy.

Diagnostyka awarii zbierania danych w SQL Server

Jeżeli raporty Data Collector pozostają puste, pierwszym krokiem jest ustalenie, czy problem dotyczy konfiguracji, harmonogramu, uprawnień, połączenia czy samego źródła danych. Należy sprawdzić, czy zestaw kolekcji jest uruchomiony, czy SQL Server Agent wykonuje przypisane zadania oraz czy baza Management Data Warehouse istnieje i jest dostępna. Następnie analizuje się historię zadań, komunikaty SQL Server Agent i dziennik błędów SQL Server. Warto zweryfikować również, czy konto wykonujące zadanie ma wymagane uprawnienia do odczytu danych i zapisu wyników.

Problemy mogą wynikać także z niedostępności miejsca na dysku, wzrostu plików magazynu, błędów połączenia z instancją albo niezgodności konfiguracji po przeniesieniu bazy. Zatrzymanie kolektora nie powinno być naprawiane przez samo ręczne uruchomienie raportu, ponieważ nie usuwa ono przyczyny braku danych. Najpierw trzeba ustalić, który krok procesu zakończył się błędem, a dopiero później skorygować harmonogram, uprawnienia, ścieżki plików lub ustawienia magazynu. Po zmianach należy potwierdzić wykonanie kolejnego cyklu i obecność nowych rekordów w Management Data Warehouse.

Przy pracy z komputerem, na którym działa SQL Server, diagnostyka może obejmować także stan dysków, pamięci operacyjnej, systemu plików oraz usług wymaganych przez instancję. Wnioski powinny rozdzielać awarię mechanizmu monitorowania od rzeczywistego problemu wydajnościowego. Naprawa konfiguracji Data Collector przywraca pomiar, ale nie poprawia automatycznie planów zapytań, indeksów, parametrów instancji ani wydajności podsystemu dyskowego. Te obszary wymagają osobnej analizy technicznej.