Wielu administratorów baz danych musi obsługiwać wystąpienia usług SQL Server Reporting Services (SSRS) lub przynajmniej wewnętrzne bazy danych wymagane przez usługi SSRS. Przez lata SSRS był łączony z instalacją SQL Server, co pomogło zwiększyć pewne zamieszanie związane z licencjonowaniem i obsługą produktu, więc począwszy od SSRS 2017, pakiet instalacyjny usług Reporting Services jest pobierany osobno.

W tym artykule omówiono wiele obszarów, o których administratorzy baz danych muszą wiedzieć, aby prawidłowo licencjonować, odzyskać i dostroić instalację Reporting Services. Te tematy dotyczą zarówno usług SQL Server Reporting Services, jak i serwera raportów usługi Power BI.

Licencjonowanie

Instalacja i obsługa SSRS mogą być mylące. Usługę raportowania można zainstalować jako autonomiczną instancję na dedykowanym serwerze, w tym samym wystąpieniu co SQL Server lub we wdrożeniu skalowalnym w poziomie (tylko Enterprise Edition). Każda instancja, w której w środowisku produkcyjnym jest zainstalowany SSRS, wymaga licencji SQL Server, a także licencjonowania instancji SQL Server, w której znajdują się bazy danych ReportServer i ReportServerTempDB.

Sposób, w jaki lubię wyjaśniać, jak licencjonować usługi Reporting Services, to myślenie o usłudze raportowania jako aplikacji, która korzysta z serwera SQL Server na zapleczu. We wczesnych dniach SSRS wymagano również zainstalowania i skonfigurowania internetowych usług informacyjnych (IIS). SSRS 2008 wprowadził ten składnik do modułu usług raportowania. Bardzo często zdarza się, że SSRS i MSSQL są zainstalowane w tej samej instancji ze względu na licencjonowanie i może to działać dobrze w przypadku mniejszych implementacji. W przypadku większych wdrożeń często można zobaczyć dedykowany serwer usług raportowania z serwerami ReportServer i ReportServerTempDB na skonsolidowanym serwerze SQL Server. W przypadku bardzo dużych instalacji wdrożenia skalowalne w poziomie zapewniają równoważenie obciążenia usługi serwera raportowania. We wdrożeniu skalowalnym każda instancja w farmie musi być licencjonowana.

Odzyskiwanie

W każdym z modeli wdrażania rolą administratora bazy danych jest upewnienie się, że usługi SSRS są stabilne, niezawodne i możliwe do odzyskania. Część odzyskiwalna to coś, co powoduje pewne problemy z administratorami baz danych. Baza danych ReportServer jest zaszyfrowana i niektóre operacje wymagają przywrócenia klucza symetrycznego. Jeśli wystąpi awaria i baza danych musi zostać przywrócona na inny serwer, zostanie zmieniona nazwa konta usługi serwera raportów lub hasło, zmieniona zostanie nazwa komputera, nastąpi migracja do innego serwera lub dodanie nowego serwera do skali- konfiguracji, konieczne będzie przywrócenie klucza szyfrowania. Dopóki klucz nie zostanie utworzona kopia zapasowa, żadne chronione dane, takie jak parametry połączenia i hasła, nie mogą zostać odszyfrowane. Odkryłem, że wielu administratorów baz danych nie zdaje sobie z tego sprawy, dopóki nie jest za późno. Kopię zapasową klucza można utworzyć i przywrócić ręcznie za pomocą Menedżera konfiguracji usług Reporting Services, narzędzia rskeymgmt.exe lub programu PowerShell. Z technicznego punktu widzenia wystarczy wykonać kopię zapasową tylko jednej kopii klucza symetrycznego.

Bazy danych ReportServer i ReportServerTempDB są bazami danych SQL Server i powinny być częścią zwykłego procesu tworzenia kopii zapasowych, podobnie jak inne bazy danych użytkowników. ReportServer powinien używać pełnego modelu odzyskiwania, podczas gdy ReportServerTempDB może używać prostego modelu odzyskiwania. Technicznie rzecz biorąc, ReportServerTempDB można odtworzyć za pomocą skryptu w przypadku awarii, jednak Reporting Services nie można uruchomić bez ReportServerTempDB. Administratorzy baz danych są zaznajomieni z przywracaniem baz danych, zamiast szukać skryptu do odtworzenia bazy danych. W przeciwieństwie do systemowej bazy danych tempdb ReportServerTempDB nie jest odtwarzany podczas uruchamiania. Najlepszą praktyką dla administratorów baz danych jest po prostu traktowanie ReportServer i ReportServerTempDB jak każdej innej bazy danych użytkowników.

Istnieją pliki konfiguracyjne, które przechowują ustawienia aplikacji, które również powinny być archiwizowane. Mogą one być objęte kopiami zapasowymi na poziomie systemu operacyjnego; jednak administratorzy baz danych powinni upewnić się, że kopia zapasowa tych plików została utworzona po początkowej konfiguracji i/lub po zastosowaniu niestandardowych rozszerzeń. Te pliki składają się z:

Rsreportserver.config
Rssvrpolicy.config
Rsmgrpolicy.config
Reportingservciesservice.exe.config
Web.config
Machine.config

Rozważenie tworzenia kopii zapasowych plików Projektanta raportów, takich jak; Należy podać pliki .rdl, .rds, .dv, .ds, rptproj i .sln.

Opcje strojenia

Tuning SSRS jest podobny do każdej innej aplikacji. Użytkownicy wykonują raporty z serwera aplikacji, który komunikuje się z bazami danych. Duża różnica polega na tym, że masz serwer aplikacji (Reporting Services) z własnymi bazami danych, ale raport zawiera źródła danych łączące się z innymi bazami danych użytkowników. Administratorzy baz danych muszą dostroić ogólny stan infrastruktury usług raportowania, a także dostroić rzeczywiste raporty.

Infrastruktura usług raportowania

Opóźnienia dysku dla ReportServer i ReportServerTempDB są bardzo ważne. W zależności od obciążenia te bazy danych mogą wymagać umieszczenia na szybszych dyskach. Pamięć podręczna wyników raportów jest przechowywana w bazie danych ReportServerTempDB i wydajność we/wy może tutaj stanowić problem.

Obciążenie usług Reporting Services może dyktować, że do obsługi tego obciążenia potrzebne są dodatkowe wystąpienia usług Reporting Services. Wdrożenie skalowalne w poziomie wymaga licencji Enterprise Edition. Korzyści z wdrożenia skalowanego w poziomie obejmują zapewnienie klientom równoważenia obciążenia w celu uzyskania wyższej przepustowości, wysokiej dostępności, a także możliwość segmentacji przetwarzania serwera raportów.

Korzystaj z migawek tam, gdzie mają sens. Jeśli masz raporty korzystające z danych sprzed jednego dnia, rozważ użycie migawki, aby kolejne widoki tego raportu korzystały z migawki zamiast ponownego generowania całego raportu.

Subskrypcje oparte na danych mogą być wykorzystywane do generowania raportów i dostarczania treści w oparciu o bazę subskrybentów i zgodnie z harmonogramem. Zgodnie z harmonogramem wiele z tych raportów można uruchomić po zakończeniu przetwarzania danych, na długo przed przybyciem użytkowników do pracy, w mniej napiętym dla środowiska czasie.

Administratorzy baz danych powinni być zaznajomieni z rejestrowaniem wykonywania, ponieważ może to pomóc w identyfikacji raportów, które mogą być kandydatami do buforowania, a także raportów, na które należy zwrócić uwagę w celu poprawy wydajności w oparciu o przetwarzanie wykonywania. Rejestrowanie wykonania zapewnia wgląd w takie rzeczy, jak częstotliwość uruchamiania raportów, najbardziej pożądany format i procent przetwarzania powiązany z fazą procesu raportowania. Dostęp do tych danych można uzyskać za pomocą wbudowanych widoków ExecutionLog, ExecutionLog2 i ExecutionLog3.

Ogólne strojenie

W przypadku baz danych użytkowników używanych przez raporty i instancji przechowującej ReportServer i ReportServerTempDB chcesz śledzić i bazową wydajność. Musisz monitorować wykorzystanie pamięci/dysku/procesora, sieciowe operacje we/wy, użycie bazy danych tempdb, oczekiwania i inne liczniki, aby wiedzieć, co jest normalne dla ogólnego obciążenia tych systemów. Jeśli użytkownicy zaczną zgłaszać problemy, musisz wiedzieć, czy bieżące wykorzystanie jest normalne, czy nie. Jeśli go nie monitorujesz, jak możesz to zmierzyć?

Oprócz monitorowania i tworzenia punktów odniesienia, na przykład powinny istnieć przyjęte w branży najlepsze praktyki. Omówiłem ustawienia pamięci, konserwację indeksu, statystyki, MAXDOP i próg kosztów dla równoległości w poprzednim artykule, Common SQL Server Mishaps.

Prawdziwą magią przyspieszania raportów jest optymalizacja pod kątem tego raportu. Raport to w zasadzie tylko kolejne zapytanie. Aby dostroić się do powolnego raportu, zwykle oznacza to, że musisz utworzyć indeksy dla tego konkretnego raportu lub dostroić kod w raporcie. Jeśli są to raporty, które trafiają do bazy danych OLTP, tworzenie indeksów dla raportów może wpłynąć na system OLTP, wykorzystując więcej miejsca, generując dodatkowe operacje we/wy na potrzeby aktualizacji, wstawiania i usuwania oraz ponosząc dodatkowe koszty utrzymania tych indeksów. Musisz zrównoważyć ryzyko i nagrodę. Niektórzy klienci mogą oddzielić bazę danych raportowania od OLTP za pomocą replikacji transakcyjnej, co pozwala na indeksowanie bazy danych raportowania bez wpływu na bazę danych OTLP.

Chociaż możesz śledzić użycie raportu za pomocą ExecutionLog, musisz zbadać instancję bazy danych użytkownika pod kątem wysokich kosztów i długotrwałych zapytań, aby również dostroić możliwości. DMV i Query Store również są bardzo pomocne, ale narzędzie do monitorowania, takie jak SQL Sentry, może być znacznie wydajniejsze i bardziej elastyczne. SQL Sentry nie ma „pulpitu nawigacyjnego usług raportowania”, ale można tworzyć widoki kalendarza zdarzeń SSRS, łatwo filtrować wbudowane metryki i raporty, aby skoncentrować się na aktywności SSRS, a także tworzyć niezawodne warunki doradcze w celu monitorowania dokładnych aspektów Usługi raportowania, na których Ci zależy (i żaden hałas, którego nie lubisz). Nawet jeśli nie korzystasz z usług SSRS na maszynie SQL Server, nadal możesz użyć Win Sentry, aby uzyskać szczegółowe informacje o wydajności w bieżących i historycznych działaniach na poziomie procesów i usług.

Wniosek

Dostrajanie usług SQL Server Reporting Services ma kilka unikalnych cech, jednak standardowe dostrajanie wydajności nadal ma zastosowanie do optymalizacji raportów i monitorowania baz danych ReportServer i ReportServerTempDB. Tworzenie kopii zapasowej klucza szyfrowania jest niezbędne do wszelkich działań związanych z odzyskiwaniem po awarii lub migracją. Aby lepiej zrozumieć wykorzystanie raportów, administratorzy baz danych powinni zacząć korzystać z ExcecutionLog.