SQL Server 2016 – komenda DBCC dla Analysis Services

SQL Server 2016 dostarcza nam zmian i nowości nie tylko w silniku bazodanowym, ale również
w usługach powiązanych takich jak Integration Services, Analysis Services czy też Reporting Services. W ramach niniejszego artykułu zajmiemy się jedną z najbardziej przydatnych funkcjonalności związanych z kostkami analitycznymi Analysis Services – chodzi mianowicie o dostępność komendy DBCC sprawdzającą konsystencję i poprawność struktur wewnętrznych. Tak więc zaczynajmy!

Komenda DBCC CHCECKDB z pewnością jest Wam znana z jej implementacji dla baz danych SQL Server. W wielu przypadkach stała się ona standardem i znajdowała swoje miejsce w cyklicznych planach utrzymaniowych bazy danych. Wielu osobom (w tym również autorowi niniejszego tekstu) komenda ta bardzo pomogła nie tylko wskazując błędy ale również je naprawiając. Niestety komenda ta była dostępna jedynie dla baz transakcyjnych – użytkownicy rozwiązań tabelarycznych oraz kostek musieli obyć się bez niej. Jak można Sytuacja zmienia się wraz z niedawno wydanym SQL Server 2016 gdzie komenda ta staje się dostępna również dla naszych baz analitycznych. Co ciekawe komenda ta nie jest dostarczona jedynie dla promowanego modelu tabelarycznego ale również dla tradycyjnych kostek OLAP (brawo Microsoft!) które mimo, że wiekowe nadal znajdują szerokie zastosowanie .

Przejdźmy do meritum artykułu i pokażmy jak wygląda składnia komendy DBCC dla baz analitycznych. Mamy do dyspozycji dwie komendy, które możemy uruchamiać na bazach w zależności od ustawionego Compatibility Level. Podstawowa składnia opisywanej komendy wygląda następująco:

dla baz w modelu tabelarycznym ( z compatibility level 1200)

<DBCC xmlns="http://schemas.microsoft.com/analysisservices/2014/engine">  
     <DatabaseID></DatabaseID>  
     <TableName> </TableName>  
     <PartitionName></PartitionName>  
</DBCC>

dla baz w modelu wielowymiarowym i tabelarycznym (z comatibility level 1100 i 1103)

<DBCC xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">  
     <Object>  
          <DatabaseID></DatabaseID>  
          <CubeID></CubeID>  
          <MeasureGroupID></MeasureGroupID>  
          <PartitionID></PartitionID>  
     </Object>  
</DBCC>

W przypadku gdy chcemy sprawdzić model tabelaryczny z compatibility level 1100 i 1103 to w sekcji CubeID podajemy identyfikator modelu, a w sekcji MeasureGroupID identyfikator tabeli do sprawdzenia.

Jak można wywnioskować sprawdzenia konsystencji możemy dokonać na poziomie:

Bazy analitycznej
Kostki analitycznej
Grupy miar
Partycji

Oczywiście w momencie gdy chcemy wykonać operację na konkretnym poziomie to usuwamy węzły z niższym poziomem – dla przykładu poniższe polecenie sprawdzi całą bazę analityczną o ID „TEST”.

<DBCC xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">  
     <Object>  
          <DatabaseID>TEST</DatabaseID>  
     </Object>  
</DBCC>

Aby znaleźć identyfikator naszej bazy, kostki czy partycji wystarczy wejść we właściwości i w sekcji ustawień ogólnych takowa informacja się znajduje – tak jak zostało to przedstawione poniżej:

Oczywistym jest fakt, iż aby wykonać komendę DBCC trzeba posiadać wysokie uprawnienia, a mianowicie trzeba być administratorem serwera lub też administratorem bazy analitycznej.

Warto również pamiętać, iż komenda ta podobnie jak jej odpowiednik w bazach transakcyjnych dosyć mocno obciąża zasoby naszego serwera. Podczas wykonywania komendy budowane są tymczasowe indeksy dla każdej z partycji i porównywane z istniejącymi indeksami. W związku z tym działaniem wszystkie dane muszą być przeczytane z dysku aby porównać je z tymczasowymi indeksami – wiąże się to ze zwiększonym użyciem pamięci oraz IO.

Wykonajmy więc komendę i sprawdźmy rezultat – posłużymy się poniższą komendą:

<DBCC xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
	<Object>
		<DatabaseID>SSAS_CHECKDB</DatabaseID>
	</Object>
</DBCC>

Niestety dla mniejszych baz danych zarówno rezultat jak i sekcja Messages nie musi przedstawiać pełnej informacji o przebiegu działania komendy. Jeżeli chcemy zobaczyć pełny rezultat to możemy uruchomić np. SQL Server Profiler gdzie możemy zobaczyć wydarzenie oznaczone w EventSubclass jako 32 DBCC oraz 64 – Check tabular data structure:

Jak zostało przedstawione powyżej możemy Profiler dostarcza nam pełnej informacji co zostało sprawdzone.

Jak wiemy Profiler jest jednak narzędziem, które będzie stopniowo wycofywane, warto więc przestawić się na Extended Events (które w Analysis Services 2016 otrzymały graficzny interfejs użytkownika). Skonfigurujmy sobie naszą sesję klikając prawym przyciskiem myszy na węzeł sessions w SSMS i wybierając New Session. W pierwszym oknie wybierzmy pusty szablon i nazwijmy naszą sesję DBCC.

Kolejnym krokiem jest wybranie wydarzeń jakie chcemy rejestrować – na potrzeby niniejszej prezentacji wybierzmy wszystkie zdarzenia Progress tak jak zostało to przedstawione poniżej:

Następnie w sekcji Data Storage wybierzmy w jaki sposób dane będą przechowywane. Dla nas odpowiednie będzie ustawienie event stream.

Potwierdźmy przyciskiem OK i użyjmy polecenia DBCC. W rezultacie otrzymamy szczegółowe zestawienie wraz z informacjami co zostało sprawdzone.

W przypadku modeli tabelarycznych konsystencja jest sprawdzana w momencie ładowania danych do bazy analitycznej niejako automatycznie. Działanie to oczywiście można wyłączyć i ręcznie obsłużyć komendą DBCC (chociaż Microsoft zaznacza to działanie jako nierekomendowane i nie sposób z tym polemizować). Aby mimo wszystko wyłączyć automatyczne sprawdzanie należy zmodyfikować plik msmdsrv.ini, a konkretnie sekcję:

<ConfigurationSettings>  
     <Vertipaq />  
          <DisableConsistencyChecks />

W istniejących plikach nie znajdziemy tego zapisu i musimy dodać go ręcznie. DisableConsistencyChecks według Books Online przyjmuje następujące wartości:

-2 (wartość domyślna) – gdzie silnik po napotkaniu błędu konsystencji postara się go naprawić automatycznie.
-1 – konsystencja jest sprawdzana podczas operacji RESTORE
0 – konsystencja jest sprawdzana podczas operacji RESTORE, IMAGELOAD, LOCALCUBELOAD oraz ATTACH
1 DBCC jest całkowicie wyłączone

Więcej informacji o komendzie DBCC dla Analysis Services znajdziecie tutaj (https://msdn.microsoft.com/en-us/library/mt156975.aspx)

Jak widać nowość ta jest niezwykle ważna i użyteczna. Błędy wewnętrzne Analysis Services (szczególnie modelu wielowymiarowego) będą mogły być w łatwiejszy sposób sprawdzane i naprawiane. Z tej funkcjonalności na pewno ucieszą się również administratorzy rozwiązań analitycznych, którzy do swojego zasobnika narzędzi będą mogli dodać kolejną, ważną komendę. Mam nadzieję, że również dla Was ta nowość okaże się użyteczna i zwiększy kontrolę jaką macie nad swoimi projektami.