Przenoszenie Analysis Services

Przenoszenie Analysis Services obejmuje migrację modeli i kostek do nowej instancji SSAS.

Przenoszenie Analysis Services – zakres i znaczenie procesu

Przenoszenie Analysis Services oznacza zaplanowane przeniesienie środowiska analitycznego Microsoft SQL Server Analysis Services do innej instancji, serwera, centrum danych albo platformy przygotowanej do dalszej pracy. Zakres takiej operacji może obejmować modele tabelaryczne, modele wielowymiarowe, kostki, wymiary, miary, role bezpieczeństwa, źródła danych, harmonogramy przetwarzania oraz ustawienia wymagane do prawidłowego odświeżania danych. Nie chodzi więc wyłącznie o skopiowanie plików. Konieczne jest odtworzenie zależności pomiędzy modelem, bazą źródłową, kontami użytkowników i narzędziami, które korzystają z gotowych danych analitycznych.

W praktyce przed rozpoczęciem prac ustala się, co ma zostać przeniesione, jaki jest obecny typ modelu oraz w jaki sposób użytkownicy uzyskują dostęp do raportów. Znaczenie ma również wersja Analysis Services, tryb uwierzytelniania, sposób przechowywania danych oraz rozmiar i częstotliwość przetwarzania. Dobrze przygotowana migracja powinna zachować logikę biznesową, nazwy obiektów, relacje, obliczenia i uprawnienia w takim zakresie, w jakim pozwala na to środowisko docelowe.

Przed zmianą zaleca się sporządzenie inwentaryzacji baz i modeli. Warto zapisać nazwy baz, tabel, partycji, perspektyw, hierarchii, miar kalkulowanych, reguł bezpieczeństwa oraz połączeń używanych przez raporty. Taka lista ułatwia późniejsze porównanie starego i nowego środowiska, a także pozwala szybciej rozpoznać element, który nie został odtworzony albo wymaga ręcznej korekty.

Przenoszenie Analysis Services a modele tabelaryczne i wielowymiarowe

Model tabelaryczny i model wielowymiarowy wykorzystują odmienne struktury, dlatego sposób migracji powinien zostać dobrany do konkretnej architektury. W modelu tabelarycznym szczególnej uwagi wymagają relacje, kolumny obliczeniowe, miary zapisane w języku DAX, partycje i ustawienia pamięci. Przy modelu wielowymiarowym sprawdzenia wymagają kostki, grupy miar, wymiary, poziomy hierarchii, perspektywy, agregacje, kalkulacje MDX i mechanizmy przetwarzania.

Można wyróżnić kilka scenariuszy. Przy przeniesieniu na zgodną wersję oprogramowania możliwe jest odtworzenie bazy z zachowaniem większości obiektów, a następnie ponowne podłączenie źródeł danych i wykonanie testowego przetwarzania. Przy zmianie wersji albo trybu działania potrzebna bywa konwersja modelu. Wtedy należy uwzględnić różnice w obsłudze wyrażeń, właściwościach obiektów, poziomie zgodności i sposobie zarządzania połączeniami.

Ważne jest rozróżnienie pomiędzy metadanymi modelu a danymi zapisanymi w strukturach przetwarzanych przez Analysis Services. Samo odtworzenie definicji może nie przywrócić gotowych wyników zapytań ani agregacji. Z tego powodu po migracji zwykle planuje się pełne albo częściowe przetworzenie danych. Przy większych modelach można rozważyć przetwarzanie partycjami, aby ograniczyć czas niedostępności i ułatwić kontrolę nad kolejnymi etapami.

W przypadku zmiany nazwy instancji lub punktu połączenia trzeba sprawdzić wszystkie raporty, pulpity, skoroszyty i skrypty korzystające z dotychczasowej lokalizacji. Czasami wystarczy aktualizacja parametrów połączenia, jednak w innych sytuacjach konieczne jest dostosowanie nazw baz, katalogów, kont usługowych albo sposobu logowania. Każdą zmianę warto dokumentować, ponieważ ułatwia to późniejsze utrzymanie i odtworzenie środowiska po awarii.

Przenoszenie Analysis Services – typowe problemy podczas migracji

Jednym z częstszych problemów jest brak dostępu nowej instancji do źródłowej bazy danych. Może to wynikać z nieprawidłowego konta usługi, braku uprawnień, zmienionego adresu źródła albo odmiennego sposobu uwierzytelniania. Model może zostać odtworzony poprawnie, lecz przetwarzanie zakończy się błędem, ponieważ środowisko docelowe nie może pobrać danych.

Problemy mogą dotyczyć również ról i zabezpieczeń na poziomie wierszy. Po migracji należy potwierdzić, czy użytkownicy widzą właściwy zakres danych, czy grupy zostały odwzorowane oraz czy zastosowano odpowiedni sposób uwierzytelniania. Szczególnej kontroli wymagają konta techniczne, uprawnienia do źródeł, reguły zapór oraz zasady dostępu do raportów. Zbyt szerokie uprawnienia tworzą ryzyko niezamierzonego ujawnienia danych, natomiast zbyt wąskie mogą zatrzymać odświeżanie.

Inną grupę trudności stanowią różnice wydajnościowe. Ten sam model może odpowiadać na zapytania inaczej po zmianie wersji oprogramowania, parametrów pamięci, układu dysków lub ustawień przetwarzania. Należy porównać czas ładowania, czas odpowiedzi na typowe zapytania, wielkość struktur oraz obciążenie podczas odświeżania. Nie powinno się oceniać powodzenia migracji wyłącznie na podstawie tego, czy baza została otwarta bez komunikatu o błędzie.

Do często pomijanych elementów należą zadania automatyzujące, skrypty wdrożeniowe, połączenia zapisane w raportach oraz zależności od lokalnych ścieżek. Jeżeli harmonogram przetwarzania nie został odtworzony, dane mogą pozostać aktualne tylko do momentu migracji. Jeżeli nie zaktualizowano połączeń raportowych, użytkownicy mogą otrzymywać błędy mimo prawidłowego działania samego modelu.

Praktyczne przygotowanie do przenoszenia Analysis Services

Prace dobrze rozpocząć od kopii zapasowej baz, definicji modeli i konfiguracji. Kopia powinna być przechowywana w miejscu niezależnym od środowiska, które jest migrowane. Następnie warto przygotować plan obejmujący kolejność działań, osoby odpowiedzialne za akceptację, przewidywany czas testów oraz sposób powrotu do poprzedniego rozwiązania, gdyby wynik kontroli był niezadowalający.

Bezpieczny przebieg można podzielić na etapy: rozpoznanie, przygotowanie środowiska docelowego, odtworzenie modeli, podłączenie źródeł, konfigurację uprawnień, przetworzenie danych, testy i przełączenie użytkowników. Każdy etap powinien mieć jasno określone kryterium poprawności. Należy sprawdzić nie tylko możliwość otwarcia modelu, lecz także wartości kluczowych miar, kompletność danych, działanie filtrów, hierarchii, perspektyw i zabezpieczeń.

Dobrym rozwiązaniem jest przeprowadzenie próby na kopii albo środowisku testowym. Pozwala to ustalić, ile trwa odtworzenie, jakie błędy pojawiają się przy przetwarzaniu i czy raporty wymagają zmian. Warto zebrać przykładowe zapytania biznesowe oraz wyniki ze starego środowiska, a następnie porównać je z rezultatami po migracji. Różnica w wyniku nie zawsze oznacza błąd techniczny, ale powinna zostać wyjaśniona.

Przed przełączeniem należy ustalić moment zatrzymania zmian w źródłach i modelach. Jeżeli w trakcie kopiowania definicje albo dane nadal są modyfikowane, środowisko docelowe może nie odpowiadać stanowi bieżącemu. Po przełączeniu przydatny jest okres wzmożonej obserwacji, podczas którego sprawdza się odświeżanie, logi, obciążenie oraz zgłoszenia użytkowników. Dokumentacja powinna zawierać finalne nazwy, połączenia, role, harmonogramy i czynności potrzebne przy kolejnym odtworzeniu.

Kiedy zgłosić przenoszenie Analysis Services do serwisu

Wsparcie techniczne przy przenoszeniu Analysis Services może być potrzebne, gdy środowisko zawiera wiele modeli, zależności od różnych źródeł albo rozbudowane reguły dostępu. Zgłoszenie warto rozważyć również wtedy, gdy brakuje aktualnej dokumentacji, migracja ma zostać wykonana w krótkim oknie serwisowym, a działanie raportów ma pozostać nieprzerwane. Przed rozpoczęciem prac przydatne jest przygotowanie listy modeli, wersji oprogramowania, źródeł danych, kont technicznych i raportów, które muszą działać po zmianie.

W przypadku problemów ze stacją roboczą używaną do zarządzania środowiskiem, narzędziami administracyjnymi albo lokalnymi plikami konfiguracyjnymi można skorzystać z pomocy Warszawskiego Pogotowia Komputerowego 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu dobrze opisać objawy, moment pojawienia się błędu oraz wykonane dotychczas czynności, ponieważ ułatwia to ocenę zakresu prac i przygotowanie bezpiecznego rozwiązania.