Awaria SSRS

Awaria SSRS to zdarzenie uniemożliwiające prawidłowe generowanie raportów przez usługę SQL Server Reporting Services.

Na czym polega awaria SQL Server Reporting Services

Awaria SSRS oznacza stan, w którym usługa SQL Server Reporting Services nie może poprawnie realizować jednej lub kilku swoich funkcji: uruchomić serwera raportów, udostępnić portalu internetowego, odnaleźć raportu, połączyć się ze źródłem danych, wykonać zapytania albo wygenerować i dostarczyć wynik w wybranym formacie. SSRS korzysta z kilku współpracujących elementów, dlatego sam komunikat wyświetlony w przeglądarce nie zawsze wskazuje bezpośrednią przyczynę problemu.

W instalacji SSRS istotną rolę odgrywają usługa serwera raportów, baza katalogowa ReportServer, opcjonalna baza ReportServerTempDB, konfiguracja adresów URL oraz źródła danych używane przez poszczególne raporty. Uszkodzenie lub niedostępność dowolnego z tych elementów może objawić się jako błąd generowania raportu. Inny przebieg ma awaria całej instancji SSRS, a inny problem dotyczący pojedynczego raportu, jego zapytania, poświadczeń albo parametrów.

Objawy widoczne w portalu i przy generowaniu raportu

Jednym z podstawowych objawów jest brak dostępu do Report Server Web Service lub Report Managera, czyli interfejsu webowego służącego do przeglądania i zarządzania raportami. Przeglądarka może zwracać błąd połączenia, kod HTTP albo stronę wskazującą na niepoprawną konfigurację adresu URL. Jeżeli usługa działa, lecz nie można otworzyć konkretnego raportu, przyczyną może być błąd w zapytaniu, brak uprawnień do danych, niedostępność serwera bazy danych lub nieprawidłowe dane uwierzytelniające.

Raport może otworzyć się w portalu, ale zakończyć błędem dopiero po podaniu parametrów. Taki przypadek często wskazuje na problem z walidacją parametrów, zależnościami między parametrami albo zapytaniem wykorzystującym otrzymane wartości. Awaria może również dotyczyć eksportu do PDF, Excela lub innego formatu, gdy sam proces renderowania napotyka błąd. Przy raportach subskrybowanych osobnym objawem jest brak wysyłki lub zapisania wyniku mimo prawidłowego działania portalu.

Rozdzielenie problemu usługi, katalogu i źródła danych

Diagnostykę rozpoczyna się od ustalenia zakresu awarii. Jeżeli nie działa cały portal, należy sprawdzić stan usługi SSRS, dostępność skonfigurowanego adresu URL, rezerwację portu oraz możliwość połączenia z bazami katalogowymi. Baza ReportServer przechowuje między innymi definicje raportów, foldery, uprawnienia i ustawienia, natomiast ReportServerTempDB jest używana do danych tymczasowych potrzebnych podczas pracy serwera raportów. Niedostępność katalogu może uniemożliwić uruchomienie usługi albo odczytanie konfiguracji raportów.

Jeżeli problem występuje tylko w wybranych raportach, trzeba porównać ich wspólne cechy: źródło danych, typ połączenia, używane zapytania, parametry i sposób uwierzytelniania. Należy odróżnić poświadczenia zapisane w konfiguracji źródła danych od poświadczeń użytkownika uruchamiającego raport. Pomyślne logowanie do portalu nie oznacza automatycznie, że konto ma dostęp do tabel, widoków lub procedur wykorzystywanych przez zapytanie. W przypadku raportów opartych na zewnętrznych źródłach znaczenie ma także dostępność serwera danych i poprawność sieciowej nazwy hosta.

Najbardziej użyteczne informacje znajdują się w logach SSRS oraz w Dzienniku zdarzeń systemu Windows. Wpisy należy korelować z dokładnym czasem wystąpienia błędu, nazwą raportu i operacją wykonywaną przez użytkownika. Warto sprawdzić, czy błąd powtarza się dla każdego raportu, tylko dla konkretnego zestawu parametrów albo wyłącznie podczas eksportu. Takie rozdzielenie ogranicza ryzyko błędnej naprawy konfiguracji całej instancji, gdy rzeczywistą przyczyną jest pojedyncze zapytanie lub utracone połączenie ze źródłem danych.

Bezpieczne przywracanie generowania raportów

Naprawa powinna wynikać z potwierdzonej przyczyny. Przy problemie z usługą sprawdza się konfigurację instancji, adresy URL, certyfikat używany przez połączenie HTTPS, dostęp do baz katalogowych oraz zależności systemowe. Przy błędzie źródła danych weryfikuje się nazwę serwera, dostępność bazy, uprawnienia konta i działanie zapytania poza samym raportem. Zmiana hasła lub sposobu uwierzytelniania bez ustalenia, który komponent zgłasza błąd, może tylko utrudnić dalszą analizę.

Nie należy usuwać baz ReportServer ani ReportServerTempDB w celu „odświeżenia” instalacji. Baza ReportServer zawiera konfigurację i zawartość katalogu raportów, dlatego jej utrata może oznaczać utratę definicji raportów, folderów, subskrypcji oraz ustawień. Przed zmianami w konfiguracji warto zabezpieczyć kopię baz i plików konfiguracyjnych, a następnie wykonać test obejmujący logowanie do portalu, otwarcie raportu, uruchomienie z parametrami i eksport do używanego formatu.

Jeżeli awaria powstała po zmianie sterownika, certyfikatu, konta usługi, struktury bazy albo definicji raportu, należy uwzględnić tę zmianę w analizie zależności czasowych. Sam restart usługi może chwilowo usunąć objaw związany z blokadą lub wyczerpaniem zasobów, ale nie rozwiąże błędnego zapytania, braku uprawnień ani niepoprawnej konfiguracji adresu URL. Trwałe przywrócenie działania wymaga potwierdzenia przyczyny w logach i ponownego sprawdzenia całego przepływu od żądania raportu do wygenerowania wyniku.