Błąd SSIS

Błąd SSIS sygnalizuje problem z wykonaniem pakietu usług integracyjnych SQL Server Integration Services.

Co oznacza komunikat o błędzie SSIS

Błąd SSIS oznacza, że pakiet SQL Server Integration Services nie został wykonany zgodnie z zaplanowanym przebiegiem. SSIS służy do budowania procesów ETL i innych przepływów danych: pobiera informacje ze źródeł, przekształca je, a następnie zapisuje w miejscach docelowych. Pakiet może zawierać zadania sterujące, przepływy danych, połączenia do baz SQL Server, plików, usług lub innych obsługiwanych źródeł. Samo określenie „błąd SSIS” nie wskazuje jednej przyczyny. Jest ogólną informacją, że co najmniej jeden element pakietu zwrócił stan zakończenia inny niż pomyślny.

Problemy mogą wystąpić podczas inicjalizacji pakietu, nawiązywania połączenia, odczytu danych, konwersji typów, walidacji komponentów, zapisu wyników albo wykonywania skryptu. SSIS może również przerwać działanie z powodu błędu zadania poprzedzającego, przekroczenia limitu czasu, braku uprawnień do zasobu lub niezgodności konfiguracji środowiska uruchomieniowego. Do prawidłowej interpretacji potrzebny jest dokładny komunikat, kod błędu, nazwa zadania lub komponentu oraz informacja, na którym etapie pakiet się zatrzymał.

Najczęstsze źródła niepowodzenia pakietu

Częstą przyczyną błędów są nieprawidłowe lub niedostępne menedżery połączeń. Pakiet może odwoływać się do serwera SQL Server, bazy danych, udziału plikowego albo pliku lokalnego, który nie istnieje w środowisku wykonawczym. Ścieżka dostępna na komputerze autora pakietu może nie być dostępna na serwerze wykonującym zadanie. Podobny problem pojawia się, gdy pakiet korzysta z uwierzytelniania Windows, a konto uruchamiające SQL Server Agent lub inną usługę nie ma praw do wskazanego zasobu. Błąd może także wynikać z wygasłego hasła, zmienionej nazwy serwera, niedostępnego portu albo niezgodnej wartości parametru połączenia.

W przepływie danych często zawodzą kolumny i typy danych. Źródło może zwrócić wartość dłuższą niż rozmiar kolumny docelowej, tekst może zawierać znaki niepasujące do kodowania, a wartość liczbowa lub data może mieć format nieakceptowany przez komponent. Zmiana schematu tabeli, nazwy kolumny albo typu danych po utworzeniu pakietu może spowodować błędy walidacji lub konwersji. Należy też sprawdzić obsługę wartości NULL, kluczy głównych, ograniczeń integralności i duplikatów. Jeżeli komponent otrzyma rekord niespełniający założeń, pakiet może skierować go do wyjścia błędów albo zakończyć całe wykonanie, zależnie od ustawionej konfiguracji.

Niepowodzenia powodują również błędne wyrażenia, skrypty i konfiguracje parametrów. Pakiet może otrzymać pustą wartość, nieprawidłową datę, błędną nazwę pliku lub parametr wskazujący na niewłaściwe środowisko. W przypadku komponentów Script Task i Script Component znaczenie ma zgodność używanych bibliotek oraz środowiska uruchomieniowego. Problem może wystąpić także wtedy, gdy pakiet wymaga dostawcy lub sterownika, którego nie zainstalowano na komputerze wykonującym zadanie. W takiej sytuacji projekt może otwierać się poprawnie w środowisku projektowym, lecz kończyć błędem podczas uruchomienia na serwerze.

Jak odczytać przyczynę w logach SSIS

Diagnostyka powinna rozpoczynać się od najwcześniejszego błędu, a nie od ostatniego komunikatu podsumowującego. Kolejne ostrzeżenia mogą być tylko skutkiem wcześniejszego zerwania połączenia lub odrzucenia danych. W logu warto ustalić nazwę pakietu, nazwę zadania, nazwę przepływu danych, komponent, czas wystąpienia i pełny tekst komunikatu. Istotne są również informacje o źródle i miejscu docelowym, numerze wiersza, kolumnie, wartości parametru oraz operacji wykonywanej w chwili awarii.

Jeżeli pakiety są uruchamiane z katalogu SSISDB, informacje o wykonaniach można analizować w raportach katalogu oraz w widokach zawierających komunikaty operacji i etapów wykonania. Przydatne są między innymi identyfikator wykonania, status pakietu, poziom szczegółowości logowania i komunikaty przypisane do konkretnego komponentu. Sam status „Failed” nie wystarcza do ustalenia przyczyny. Trzeba odszukać komunikat poprzedzający zakończenie oraz sprawdzić, czy błąd pojawił się podczas walidacji, wykonania zadania, transferu danych czy zatwierdzania transakcji.

Warto porównać wykonanie zakończone błędem z ostatnim poprawnym uruchomieniem. Taka analiza może ujawnić zmianę liczby rekordów, struktury danych, lokalizacji pliku, parametrów środowiskowych lub dostępności serwera. Należy również rozdzielić błąd aplikacyjny od problemu infrastrukturalnego. Niedostępna baza, zerwane połączenie sieciowe, brak miejsca na dysku lub restart usługi mogą przerwać prawidłowo skonfigurowany pakiet, ale wymagają innego postępowania niż błąd mapowania kolumny albo niepoprawne zapytanie.

Postępowanie przy przywracaniu wykonania

Po ustaleniu konkretnego komunikatu należy odtworzyć problem w kontrolowanych warunkach i sprawdzić konfigurację używaną przez rzeczywiste zadanie. Nie wystarczy uruchomić pakietu z poziomu środowiska projektowego, ponieważ wartości parametrów, konto użytkownika, katalog roboczy, sterowniki i uprawnienia mogą być inne niż podczas wykonania automatycznego. Trzeba potwierdzić dostęp do wszystkich źródeł i celów, poprawność parametrów, zgodność schematów oraz obecność wymaganych providerów i komponentów.

Jeśli przyczyną jest zmiana danych, należy poprawić mapowanie, regułę konwersji, długość kolumny albo obsługę wartości odrzuconych. Jeśli problem dotyczy połączenia, należy zweryfikować nazwę serwera, bazę, metodę uwierzytelniania, uprawnienia konta wykonującego oraz dostępność zasobu z tej samej maszyny, na której działa pakiet. Przy błędach czasowych trzeba rozważyć limit czasu, blokady w bazie, wydajność zapytania i wielkość przetwarzanego zbioru, ale nie należy zwiększać limitów bez potwierdzenia, że operacja rzeczywiście trwa prawidłowo.

Po wprowadzeniu zmiany wykonanie powinno zostać sprawdzone na danych testowych, a następnie w docelowym harmonogramie. Należy zweryfikować nie tylko status zakończenia pakietu, lecz także liczbę przetworzonych rekordów, liczbę odrzuceń, poprawność danych docelowych i komunikaty zapisane w logu. Jeżeli błąd występuje sporadycznie, pomocne jest porównanie kilku kolejnych wykonań oraz sprawdzenie zależności czasowych, dostępności źródeł i blokad. Powtarzalne logowanie nazwy pakietu, zadania i komponentu ułatwia późniejsze rozróżnienie błędów konfiguracji od awarii środowiska.