Logi serwera SSAS

Logi serwera SSAS to dzienniki usługi analitycznej SQL Server, rejestrujące przetwarzanie kostek i zapytania.

Rola logów usługi SQL Server Analysis Services

Logi serwera SSAS, czyli SQL Server Analysis Services, rejestrują zdarzenia zachodzące podczas pracy usługi analitycznej SQL Server. Dotyczą między innymi uruchamiania i zatrzymywania instancji, ładowania baz analitycznych, przetwarzania modeli, odczytu danych oraz obsługi zapytań kierowanych do modeli wielowymiarowych i tabelarycznych. Wpisy mogą zawierać informacje diagnostyczne, ostrzeżenia i błędy, dlatego są jednym z podstawowych źródeł danych przy analizie nieudanego przetwarzania albo problemów z odpowiedzią na zapytania.

Podstawowym plikiem dziennika instancji jest msmdsrv.log. Jego lokalizacja zależy od typu instalacji i konfiguracji SQL Server, ale dla instancji Analysis Services znajduje się w katalogu logów danej instancji, w strukturze obejmującej katalog OLAP\Log. Sam plik nie opisuje całego zachowania systemu. Przy bardziej szczegółowej analizie wykorzystuje się także zdarzenia rozszerzone SQL Server Analysis Services, ślady diagnostyczne oraz mechanizmy rejestrowania zapytań skonfigurowane dla konkretnej instancji.

Co można odczytać z pliku msmdsrv.log

Podczas analizy wpisu należy najpierw ustalić czas zdarzenia, nazwę instancji, identyfikator procesu lub operacji oraz poziom komunikatu. Czas w logu pozwala zestawić błąd z działaniem wykonanym w SSMS, harmonogramem przetwarzania albo komunikatem z aplikacji klienckiej. W przypadku błędów ładowania modelu istotne są informacje o nazwie bazy SSAS, obiektu, partycji, tabeli lub wymiaru. W przypadku problemu z zapytaniem należy sprawdzić, czy komunikat dotyczy parsowania języka MDX lub DAX, dostępu do danych, limitu zasobów, blokady, pamięci czy zerwania połączenia.

Log może wskazać, że usługa nie mogła otworzyć pliku modelu, odczytać danych źródłowych albo ukończyć konkretnego etapu przetwarzania. Przy modelach wielowymiarowych analizuje się między innymi błędy związane z kostkami, wymiarami, agregacjami i partycjami. Przy modelach tabelarycznych ważne są nazwy tabel, kolumn, relacji i partycji oraz etap procesu, w którym wystąpiło niepowodzenie. Sam tekst komunikatu nie zawsze identyfikuje przyczynę pierwotną, ponieważ późniejsze wpisy mogą być tylko skutkiem wcześniejszego błędu inicjalizacji lub utraty połączenia ze źródłem.

Śledzenie przetwarzania i zapytań w SSAS

Plik msmdsrv.log służy przede wszystkim do diagnostyki pracy serwera i nie powinien być utożsamiany z pełnym audytem wszystkich zapytań użytkowników. Do obserwowania szczegółowego przebiegu zapytań oraz operacji przetwarzania stosuje się zdarzenia rozszerzone Analysis Services, konfigurowane dla właściwej instancji. W zależności od wersji i trybu pracy można rejestrować zdarzenia dotyczące rozpoczęcia i zakończenia zapytania, błędów, blokad, wykorzystania zasobów oraz etapów przetwarzania. Przy wyborze zdarzeń trzeba uwzględnić koszt zapisu, ponieważ nadmiernie szczegółowy ślad może zwiększyć obciążenie serwera i rozmiar plików.

SSAS posiada również mechanizm Flight Recorder, który utrzymuje ograniczony bufor zdarzeń diagnostycznych przydatny po awarii lub nieoczekiwanym zakończeniu procesu. Jest to materiał pomocniczy, a nie zamiennik zaplanowanego monitorowania. W praktyce warto korelować logi z historią poleceń XMLA, komunikatami klienta oraz czasem rozpoczęcia procesu. Dla zapytań wykonywanych przez aplikacje znaczenie ma także identyfikacja konta usługi lub użytkownika, nazwa bazy oraz rodzaj połączenia. Taka korelacja pomaga odróżnić błąd modelu od problemu po stronie klienta, sterownika albo źródła relacyjnego.

Bezpieczna analiza błędów i przygotowanie diagnostyki

Przed wyciągnięciem wniosku z logu należy zachować oryginalny fragment wraz z kilkoma wpisami poprzedzającymi i następującymi po komunikacie. Pojedynczy wiersz może opisywać tylko końcowy etap operacji, podczas gdy wcześniejszy wpis zawiera przyczynę, na przykład niedostępne źródło danych, niezgodny typ kolumny albo błąd uprawnień. Należy także sprawdzić, czy komunikat występuje cyklicznie, czy pojawił się jednorazowo po restarcie usługi. Powtarzalność, odstęp czasu i powiązanie z konkretną bazą są ważniejsze niż sama liczba wpisów.

Podczas przekazywania logów do analizy trzeba ograniczyć zakres do potrzebnego przedziału czasowego i zachować strukturę komunikatów. Wpisy mogą zawierać nazwy baz, ścieżki, identyfikatory sesji, nazwy kont lub fragmenty poleceń, dlatego materiał diagnostyczny powinien być udostępniany z zachowaniem zasad obowiązujących w danym środowisku. Nie należy usuwać znaczników czasu ani identyfikatorów zdarzeń, ponieważ utrudnia to korelację. Jeżeli problem dotyczy wydajności, sam komunikat błędu może nie wystarczyć; potrzebne są wtedy dane o czasie trwania zapytania, obciążeniu pamięci, współbieżności i przebiegu przetwarzania w tej samej chwili.