Viele Datenbankadministratoren müssen Instanzen von SQL Server Reporting Services (SSRS) oder zumindest die für SSRS erforderlichen Back-End-Datenbanken unterstützen. Jahrelang wurde SSRS mit der Installation von SQL Server gebündelt, was dazu beitrug, die Verwirrung um die Lizenzierung und den Support für das Produkt zu verstärken. Daher ist das Installationspaket für Reporting Services ab SSRS 2017 ein separater Download.

Dieser Artikel behandelt viele Bereiche, die Datenbankadministratoren beachten müssen, um eine Installation von Reporting Services ordnungsgemäß zu lizenzieren, wiederherzustellen und zu optimieren. Diese Themen gelten sowohl für SQL Server Reporting Services als auch für Power BI Report Server.

Lizenzierung

Installation und Support von SSRS können verwirrend sein. Der Berichtsdienst kann als eigenständige Instanz auf einem dedizierten Server, auf derselben Instanz wie SQL Server oder in einer horizontal skalierten Bereitstellung (nur Enterprise Edition) installiert werden. Jede Instanz, in der SSRS in der Produktion installiert ist, erfordert eine SQL Server-Lizenz sowie die Lizenzierung der Instanz von SQL Server, in der sich die Datenbanken ReportServer und ReportServerTempDB befinden.

Ich erkläre gerne, wie Reporting Services lizenziert werden, indem ich den Reporting-Service als eine Anwendung betrachte, die SQL Server am Back-End verwendet. In den frühen Tagen von SSRS war es erforderlich, auch Internetinformationsdienste (IIS) zu installieren und zu konfigurieren. SSRS 2008 brachte diese Komponente in das Meldedienstmodul. Es kommt sehr häufig vor, dass SSRS und MSSQL aufgrund der Lizenzierung auf derselben Instanz installiert sind, und dies kann für kleinere Implementierungen gut funktionieren. Bei größeren Bereitstellungen ist es üblich, einen dedizierten Berichtsdienstserver mit ReportServer und ReportServerTempDB auf einem konsolidierten SQL Server zu sehen. Bei sehr großen Installationen werden Bereitstellungen mit horizontaler Skalierung verwendet, um den Lastenausgleich des Berichtsserverdiensts bereitzustellen. In einer Bereitstellung mit horizontaler Skalierung muss jede Instanz in der Farm lizenziert werden.

Wiederherstellung

In jedem der Bereitstellungsmodelle besteht die Rolle des Datenbankadministrators darin sicherzustellen, dass SSRS stabil, zuverlässig und wiederherstellbar ist. Der wiederherstellbare Teil ist etwas, das einige DBA-Probleme verursacht. Die ReportServer-Datenbank ist verschlüsselt und bestimmte Vorgänge erfordern die Wiederherstellung des symmetrischen Schlüssels. Wenn ein Fehler auftritt und die Datenbank auf einem anderen Server wiederhergestellt werden muss, der Name oder das Kennwort des Windows-Dienstkontos des Berichtsservers geändert wird, der Computername geändert wird, Sie auf einen anderen Server migrieren oder einen neuen Server zu einem Skalierungsserver hinzufügen, out-Konfiguration müssen Sie den Verschlüsselungsschlüssel wiederherstellen. Ohne Sicherung des Schlüssels können geschützte Daten wie Verbindungszeichenfolgen und Passwörter nicht entschlüsselt werden. Ich habe festgestellt, dass viele DBAs sich dessen nicht bewusst sind, bis es zu spät ist. Der Schlüssel kann manuell mit dem Reporting Services-Konfigurations-Manager, mit dem Dienstprogramm „rskeymgmt.exe“ oder mit PowerShell gesichert und wiederhergestellt werden. Technisch gesehen müssen Sie nur eine Kopie des symmetrischen Schlüssels sichern.

Die Datenbanken ReportServer und ReportServerTempDB sind SQL Server-Datenbanken und sollten wie andere Benutzerdatenbanken Teil eines regelmäßigen Sicherungsprozesses sein. ReportServer sollte das vollständige Wiederherstellungsmodell verwenden, während ReportServerTempDB das einfache Wiederherstellungsmodell verwenden kann. Technisch gesehen kann ReportServerTempDB im Notfall durch ein Skript neu erstellt werden, ohne ReportServerTempDB können Reporting Services jedoch nicht gestartet werden. DBAs sind mit der Wiederherstellung von Datenbanken vertraut, anstatt nach einem Skript zu suchen, um die Datenbank neu zu erstellen. Anders als die Systemdatenbank tempdb wird ReportServerTempDB beim Start nicht neu erstellt. Best Practice für DBAs ist wirklich, ReportServer und ReportServerTempDB einfach wie jede andere Benutzerdatenbank zu behandeln.

Es gibt Konfigurationsdateien, die Anwendungseinstellungen speichern, die ebenfalls gesichert werden sollten. Diese können durch Ihre Sicherungen auf Betriebssystemebene abgedeckt werden; DBAs sollten jedoch sicherstellen, dass diese Dateien nach der Erstkonfiguration und/oder nach dem Anwenden von benutzerdefinierten Erweiterungen gesichert werden. Diese Dateien bestehen aus:

• Rsreportserver.config
• Rssvrpolicy.config
• Rsmgrpolicy.config
• Reportingserviceciesservice.exe.config
• Web.config
• Machine.config

Überlegungen zum Sichern Ihrer Report Designer-Dateien wie z. .rdl-, .rds-, .dv-, .ds-, rptproj- und .sln-Dateien sollten angegeben werden.

Tuning-Optionen

Das Tunen von SSRS ist ähnlich wie jede andere Anwendung. Benutzer führen Berichte von einem Anwendungsserver aus, der mit Datenbanken kommuniziert. Der große Unterschied besteht darin, dass Sie über einen Anwendungsserver (Reporting Services) mit eigenen Datenbanken verfügen, der Bericht jedoch über Datenquellen verfügt, die eine Verbindung zu anderen Benutzerdatenbanken herstellen. DBAs müssen den Gesamtzustand der Reporting Services-Infrastruktur sowie die eigentlichen Berichte optimieren.

Infrastruktur für Reporting Services

Datenträgerlatenz für ReportServer und ReportServerTempDB sind sehr wichtig. Je nach Workload müssen diese Datenbanken möglicherweise auf schnelleren Festplatten platziert werden. Zwischenspeicher von Berichtsergebnissen werden in der ReportServerTempDB-Datenbank gespeichert, und die E/A-Leistung kann hier zu einem Problem werden.

Die Reporting Services-Arbeitslast kann vorschreiben, dass zusätzliche Reporting Services-Instanzen erforderlich sind, um diese Arbeitslast zu bewältigen. Für eine Bereitstellung mit horizontaler Skalierung ist eine Enterprise Edition-Lizenz erforderlich. Zu den Vorteilen einer Scale-out-Bereitstellung gehören Lastenausgleich für Kunden für höheren Durchsatz, hohe Verfügbarkeit sowie die Möglichkeit, die Berichtsserververarbeitung zu segmentieren.

Nutzen Sie Snapshots dort, wo sie sinnvoll sind. Wenn Sie Berichte haben, die tagealte Daten verwenden, ziehen Sie in Betracht, einen Snapshot zu verwenden, damit nachfolgende Ansichten dieses Berichts einen Snapshot verwenden, anstatt den gesamten Bericht erneut generieren zu müssen.

Datengesteuerte Abonnements können verwendet werden, um Berichte auszuführen und die Inhalte basierend auf der Abonnentenbasis und nach einem Zeitplan bereitzustellen. Basierend auf dem Zeitplan können viele dieser Berichte ausgeführt werden, nachdem die Datenverarbeitung abgeschlossen ist, lange bevor Benutzer bei der Arbeit ankommen, in einer weniger ausgelasteten Zeit für die Umgebung.

DBAs sollten mit der Ausführungsprotokollierung vertraut sein, da dies helfen kann, Berichte zu identifizieren, die Kandidaten für das Caching sein könnten, sowie Berichte, die auf der Grundlage der Ausführungsverarbeitung auf Leistungsverbesserungen untersucht werden sollten. Die Ausführungsprotokollierung bietet Einblicke in Dinge wie die Häufigkeit der Ausführung von Berichten, das am häufigsten angeforderte Format und den Prozentsatz der Verarbeitung, der mit einer Phase des Berichtsprozesses verbunden ist. Auf diese Daten kann über die integrierten Ansichten für Ausführungsprotokoll, Ausführungsprotokoll2 und Ausführungsprotokoll3 zugegriffen werden.

Allgemeine Stimmung

Für die Benutzerdatenbanken, die von den Berichten verwendet werden, und die Instanz, die ReportServer und ReportServerTempDB enthält, möchten Sie die Leistung nachverfolgen und Baselines erstellen. Sie müssen die Speicher-/Datenträger-/CPU-Auslastung, Netzwerk-E/A, tempdb-Auslastung, Wartezeiten und andere Leistungsindikatoren überwachen, um zu wissen, was für die Gesamtarbeitslast dieser Systeme normal ist. Wenn Benutzer anfangen, Probleme zu melden, müssen Sie wissen, ob die aktuelle Auslastung normal ist oder nicht. Wenn Sie es nicht überwachen, wie können Sie es messen?

Zusätzlich zu Überwachung und Baselining sollten branchenweit akzeptierte Best Practices für die Instanz vorhanden sein. Ich habe Speichereinstellungen, Indexverwaltung, Statistiken, MAXDOP und Kostenschwellenwerte für Parallelität in einem früheren Artikel, Häufige Pannen bei SQL Server, behandelt.

Die wahre Magie, um Berichte schneller auszuführen, besteht darin, für diesen Bericht zu optimieren. Ein Bericht ist im Wesentlichen nur eine weitere Abfrage. Das Optimieren für einen langsamen Bericht bedeutet normalerweise, dass Sie Indizes für diesen bestimmten Bericht erstellen oder den Code innerhalb des Berichts optimieren müssen. Wenn es sich um Berichte handelt, die die OLTP-Datenbank treffen, kann das Erstellen von Indizes für Berichte das OLTP-System beeinträchtigen, indem mehr Speicherplatz verbraucht wird, zusätzliche E/A für Aktualisierungen, Einfügungen und Löschungen generiert werden und zusätzlicher Aufwand für die Verwaltung dieser Indizes entsteht. Sie müssen das Risiko gegen die Belohnung abwägen. Einige Kunden können die Berichtsdatenbank von der OLTP trennen, indem sie die Transaktionsreplikation verwenden, und dies ermöglicht die Indexierung der Berichtsdatenbank, ohne die OTLP-Datenbank zu beeinträchtigen.

Obwohl Sie die Verwendung von Berichten mithilfe des Ausführungsprotokolls verfolgen können, müssen Sie auch die Benutzerdatenbankinstanz nach hohen Kosten und lang andauernden Abfragen für Optimierungsmöglichkeiten durchsuchen. DMVs und Query Store sind ebenfalls eine große Hilfe, aber ein Überwachungstool wie SQL Sentry kann viel leistungsfähiger und flexibler sein. SQL Sentry verfügt per se nicht über ein „Reporting Services-Dashboard“, aber Sie können Kalenderansichten von SSRS-Ereignissen erstellen, integrierte Metriken und Berichte einfach filtern, um sich auf die SSRS-Aktivität zu konzentrieren, und robuste Beratungsbedingungen erstellen, um die genauen Aspekte von zu überwachen Reporting Services, die Ihnen wichtig sind (und nichts von dem Lärm, den Sie nicht interessieren). Selbst wenn Sie SSRS nicht auf einem SQL Server-Rechner ausführen, können Sie Win Sentry verwenden, um umfassende Einblicke in die Leistung aktueller und historischer Aktivitäten auf Prozess- und Dienstebene zu erhalten.

Schlussfolgerung

Optimieren SQL Server Reporting Services weist mehrere einzigartige Eigenschaften auf, jedoch ist die standardmäßige Leistungsoptimierung weiterhin anwendbar, um Berichte zu optimieren und die ReportServer- und ReportServerTempDB-Datenbanken zu überwachen. Das Sichern des Verschlüsselungsschlüssels ist für alle Notfallwiederherstellungs- oder Migrationsbemühungen erforderlich. Um die Verwendung von Berichten besser zu verstehen, sollten DBAs damit beginnen, das ExecutionLog zu verwenden.