Management Data Warehouse

Management Data Warehouse to baza SQL Server gromadząca dane wydajnościowe zbierane przez Data Collector.

Rola Management Data Warehouse w SQL Server

Management Data Warehouse, w skrócie MDW, to baza danych SQL Server przeznaczona do przechowywania danych zbieranych przez funkcję Data Collector. Data Collector może gromadzić informacje o wydajności instancji, obciążeniu procesora, wykorzystaniu pamięci, aktywności dysków, czasie wykonywania zapytań oraz innych zdarzeniach istotnych z punktu widzenia monitorowania aparatu bazodanowego. Zebrane informacje nie pozostają wyłącznie w pamięci serwera i nie są ograniczone do bieżącego podglądu. Są zapisywane w centralnym repozytorium, dzięki czemu można analizować zmiany obciążenia w dłuższym okresie.

MDW nie jest osobnym silnikiem baz danych ani niezależnym produktem instalowanym obok SQL Server. Jest zwykłą bazą SQL Server utworzoną i wykorzystywaną przez mechanizmy zarządzania oraz monitorowania tego silnika. Jej struktura zawiera tabele przeznaczone na dane zebrane przez kolektory, obiekty pomocnicze oraz elementy wymagane do raportowania. W praktyce administrator może wskazać jedną bazę MDW jako magazyn dla danych pochodzących z wielu monitorowanych instancji SQL Server, o ile skonfiguruje odpowiednie połączenia i uprawnienia.

Jak dane trafiają do magazynu

Przepływ informacji zaczyna się od konfiguracji Data Collector na instancji SQL Server. Kolektory pobierają dane z liczników wydajności, dynamicznych widoków zarządzania oraz innych źródeł dostępnych dla SQL Server. Następnie dane są przekazywane do mechanizmu ładowania i zapisywane w bazie Management Data Warehouse. Harmonogram zbierania zależy od konfiguracji konkretnego zestawu kolekcji. Częstotliwość próbkowania wpływa na szczegółowość obrazu wydajności, a okres przechowywania decyduje o tym, jak daleko w przeszłość można sięgać podczas analizy.

Za wykonywanie zaplanowanych operacji odpowiada SQL Server Agent. Jeżeli Agent jest zatrzymany, zadania związane z kolekcją lub ładowaniem danych nie wykonują się zgodnie z harmonogramem. Podobny skutek może mieć błędny adres serwera docelowego, niedostępność bazy MDW, brak uprawnień konta używanego przez zadanie albo niezgodność konfiguracji kolektora i magazynu. W efekcie raport może pokazywać przerwę w pomiarach, mimo że sama instancja SQL Server działa. Dlatego ciągłość danych w MDW należy oceniać razem ze stanem zadań SQL Server Agent, historią ich uruchomień oraz komunikatami z dziennika SQL Server.

Podczas projektowania magazynu trzeba uwzględnić rozmiar danych. Kolektory zapisują kolejne próbki, a tabele MDW zwiększają objętość wraz z liczbą monitorowanych instancji, częstotliwością zbierania i długością retencji. Zbyt krótki okres przechowywania utrudnia porównywanie obciążenia między tygodniami lub miesiącami, natomiast brak kontroli rozmiaru bazy może doprowadzić do zapełnienia woluminu. Utrzymanie MDW obejmuje więc również obserwowanie zajętego miejsca, poprawność wykonywania zadań czyszczących oraz sprawdzanie, czy retencja odpowiada potrzebom diagnostycznym.

Odczyt trendów i interpretacja wyników

Najważniejszą cechą MDW jest możliwość porównania bieżących pomiarów z wcześniejszymi okresami. Pojedynczy wysoki odczyt procesora nie przesądza jeszcze o trwałym problemie. Dopiero zestawienie czasu występowania obciążenia z aktywnością zapytań, operacjami wejścia-wyjścia, zużyciem pamięci i czasem odpowiedzi pozwala odróżnić chwilowy wzrost pracy od powtarzalnego przeciążenia. Dane z magazynu mogą wskazać, czy problem pojawia się w określonych godzinach, po uruchomieniu konkretnego zadania, podczas tworzenia kopii zapasowej albo po zmianie obciążenia aplikacji.

Raporty korzystające z MDW powinny być czytane z uwzględnieniem sposobu agregacji danych. Próbki mogą być podsumowywane w przedziałach czasu, dlatego wartość przedstawiona na wykresie nie zawsze oznacza stan dokładnie w jednej sekundzie. Brak danych również jest informacją diagnostyczną, ale nie powinien być automatycznie interpretowany jako zerowe obciążenie. Przerwa może wynikać z zatrzymania kolektora, błędu zapisu, niedostępności SQL Server Agent lub problemu z połączeniem do docelowej bazy. Przy analizie należy sprawdzić, czy okres raportu rzeczywiście zawiera kompletne próbki.

MDW służy przede wszystkim do analizy historycznej i oceny trendów. Nie zastępuje narzędzi obserwujących stan instancji w czasie rzeczywistym ani bezpośredniej analizy planów wykonania zapytań. Jeżeli magazyn pokazuje wzrost czasu oczekiwania lub opóźnienia operacji dyskowych, dalsze ustalenia wymagają sprawdzenia bieżących sesji, zapytań, blokad, konfiguracji baz oraz stanu podsystemu pamięci masowej. Dane historyczne pomagają zawęzić moment i skalę zjawiska, lecz nie zawsze wskazują pojedynczą przyczynę bez dodatkowych pomiarów.

Kontrola konfiguracji i diagnostyka MDW

Podstawowa diagnostyka obejmuje ustalenie, czy baza Management Data Warehouse istnieje i jest dostępna, czy kolektory są włączone oraz czy zadania SQL Server Agent kończą się powodzeniem. Należy również zweryfikować, do której instancji i bazy kierowane są dane, ponieważ pomyłka w nazwie serwera lub bazie może powodować pozornie puste raporty. Warto porównać czas ostatniego poprawnego uruchomienia zadania z czasem pojawienia się luki w danych oraz przeanalizować szczegóły historii zadań, a nie tylko ich bieżący status.

Jeśli ładowanie kończy się błędem, trzeba rozdzielić problem połączenia od problemu zapisu. Niedostępny serwer docelowy, wyłączony protokół sieciowy, błędne poświadczenia lub brak uprawnień generują inny rodzaj awarii niż brak miejsca w bazie, uszkodzenie obiektu albo konflikt schematu. Pomocne są komunikaty z historii SQL Server Agent, dziennik SQL Server, stan bazy docelowej oraz informacje o woluminie przechowującym pliki danych i dziennika. Po usunięciu przyczyny należy sprawdzić, czy kolejne zaplanowane uruchomienia ponownie zapisują dane, ponieważ samo wznowienie usługi nie zawsze uzupełnia wcześniejszą lukę.

W środowisku monitorującym kilka instancji trzeba dodatkowo rozróżnić źródło danych. Raport może łączyć pomiary z wielu serwerów, dlatego analiza powinna uwzględniać nazwę instancji, bazę źródłową, czas pomiaru i rodzaj kolektora. Bez tego można przypisać problem jednej instancji, chociaż faktycznie wystąpił on na innym serwerze albo dotyczył wyłącznie procesu ładowania do wspólnego MDW. Prawidłowo utrzymany magazyn dostarcza wtedy spójnego materiału do oceny wydajności SQL Server, planowania zmian konfiguracyjnych i potwierdzania, czy po wdrożonej korekcie obciążenie rzeczywiście się zmniejszyło.