Leistungsüberwachung für SQL Server Analysis Services (SSAS)

Erste Schritte mit der Leistungsüberwachung für SQL Server Analysis Services (SSAS)

SQL Server Analysis Services (SSAS) ist eine leistungsstarke Analyselösung von Microsoft und hat seit der ursprünglichen analytischen Onlineverarbeitung (Online Analytical Processing, OLAP) große Fortschritte gemacht. SSAS ist eines der wenigen Produkte, die sich für echte End-to-End-Business-Analytics(BI)-Arbeitslasten eignen und ist eines der gefragtesten Aggregationsmodule für Unternehmensdaten. Dieses Produkt wird manchmal auch als „Benutzeroberfläche für Daten“ beschrieben. Mit gut durchdachten Modellen in SSAS können Sie Erkenntnisse in Power BI und SQL Server Reporting Services (SSRS) mühelos hervorheben. Noch nie war es so einfach, Berichterstellung als Self-Service-Modell anzubieten.

Falls Sie für SSAS verantwortlich sind und die Leistung und Verfügbarkeit der Lösung optimieren möchten, dann sollten Sie zunächst eine Erkundungstour unternehmen. Sie müssen herausfinden, wo sich SSAS in Ihrer Umgebung befindet, woher die Daten kommen, welche Benutzer damit arbeiten, welche Version und welchen Modus Sie einsetzen und ob und wann die Daten verarbeitet oder aktualisiert werden.

Wenn Sie nicht mit der Umgebung vertraut sind, in der die Fehler auftreten, ist es manchmal praktisch unmöglich, technische Fehler zu beheben. Details sind entscheidend, wenn es um die SSAS-Leistung geht. Daher sollten Sie Ihre Details aus Protokollen beziehen, und nicht von Menschen. Protokolle lügen normalerweise nicht und liefern spezifische Zeitrahmen, IP-Adressen und Fehlermeldungen. Alles, was Sie brauchen, um Probleme erfolgreich zu beheben ... in den meisten Fällen.

Im vorkonfigurierten Zustand bietet SSAS nicht die erforderliche Protokollierung und Ablaufverfolgung, um die gängigsten Probleme effektiv beheben zu können. Daher müssen Sie bei jedem SSAS-Leistungsproblem zunächst die richtigen Ablaufverfolgungen und Protokolle konfigurieren, um herauszufinden, was in SSAS vor sich geht. Sie müssen herausfinden, ob SSAS Daten verarbeitet hat, als das Problem aufgetreten ist, ob Abfragen gestellt wurden und ggf., welcher Benutzer die Abfragen gestellt hat.

Version und Modus von SSAS ermitteln

Zunächst müssen Sie herausfinden, welche Version und welchen Modus von SSAS Sie verwenden. Dazu haben Sie zahlreiche Optionen zur Auswahl. Der folgende Screenshot zeigt beispielsweise SSAS in SQL Server Management Studio (SSMS) in unserer Beispielumgebung.

Verbinden Sie sich und wählen Sie <Suche fortsetzen> aus. In unserem Beispiel sehen Sie zwei Instanzen auf dem lokalen Computer. Wählen Sie Ihre Standardinstanz aus und wählen Sie anschließend „Verbinden“ aus. An den Buildnummern erkennen Sie, welche Version ausgeführt wird und welche Updates (z. B. Service Packs und kumulative Updates) installiert wurden. Die folgende Liste enthält die Buildnummern für die einzelnen SQL Server-Versionen:

• SQL Server 2017—14.xx.xxxx.xxx

• SQL Server 2016—13.xx.xxxx.xx

• SQL Server 2014—12.xx.xxxx.xx

• SQL Server 2012—11.xx.xxxx.xx

Sie können auch select @@version in SQL Server ausführen (dazu muss allerdings die SQL-Engine ausgeführt werden), eine DMV-Abfrage in SSAS ausführen und sich die DBMS-Version ansehen oder eine XMLA-Abfrage ausführen.

Sobald Sie wissen, welche Version Sie verwenden, können Sie den Modus ermitteln, in dem SSAS ausgeführt wird: mehrdimensional, tabellarisch oder sogar SharePoint. Dazu können Sie sich die Symbole ansehen. Im folgenden Screenshot sehen Sie, dass das Symbol für den tabellarischen Modus einer Tabelle ähnelt, und der mehrdimensionale Modus wird mit einem Würfel dargestellt.

Der mehrdimensionale Modus ist schon seit einiger Zeit verfügbar und ist nicht ganz einfach zu verstehen. Der tabellarische Modus wurde in SQL Server 2012 eingeführt und verwendet relationale Modellierungskonstrukte und Begriffe.

Zu den verschiedenen Modi und Modellierungstypen gibt es jede Menge Ressourcen. Weitere Informationen finden Sie unter „Vergleichen von tabellarischen und mehrdimensionalen Projektmappen“.

Welche Arbeitslasten werden in SSAS ausgeführt?

Sobald Sie wissen, welche Version und welchen Modus von SSAS Sie verwenden, können Sie sich mit der Integrität und Leistung der Lösung auseinandersetzen. Dazu müssen Sie die Überwachung einrichten und herausfinden, was genau in Ihrem SSAS-Server vor sich geht.

SSAS verwendet einen Prozess mit dem passenden Namen „Verarbeitung“, um Daten aus Datenspeichern abzurufen und in einem stark optimierten Modell zu codieren, zu komprimieren und zu aggregieren. Diese Verarbeitung kann sich auf die Abfrageleistung auswirken, und Abfragen können die Verarbeitung beeinträchtigen. Daher müssen Sie wissen, wann und wie viele Daten verarbeitet werden. Außerdem müssen Sie wissen, wann, von wem und wie oft die Daten abgefragt werden.

Falls Power BI oder Tableau Ad-Hoc-Berichte erstellen, sollten Sie sich mit den Auswirkungen dieser Berichte auf SSAS vertraut machen. Ad-Hoc-Berichterstellungstools erstellen manchmal schlecht optimierte Abfragen, die die Leistung von SSAS beeinträchtigen können. Sie können dies in den meisten Fällen verhindern, indem Sie Ihre Modelle an diese Berichte anpassen (Schlüsselspalten ausblenden, Synonyme in Power BI verwenden, korrekte Hierarchien, passende Datentypen, Standardaggregationen usw.).

Das häufigste Problem im Zusammenhang mit der Verarbeitung und mit Abfragen tritt auf, wenn die Verarbeitung erfolgt, während eine Abfrage ausgeführt wird. Daher sollten Sie Maßnahmen ergreifen, um die Auswirkungen der Verarbeitung auf Ihre Abfragen zu beschränken. Um herauszufinden, welche Arbeitslasten in SSAS ausgeführt werden, müssen Sie Ablaufverfolgungen oder Leistungsindikatoren einrichten oder ein Produkt installieren, das diese Informationen für Sie sammelt (z. B. SentryOne BI Sentry).

Ablaufverfolgungen und Perfmon-Leistungsindikatoren erfassen

Wenn ein SSAS-Leistungsproblem gemeldet wird, starten Sie eine ressourcenschonende Ablaufverfolgung und ein Leistungsmonitor-Protokoll (Perfmon) für bestimmte Leistungsindikatoren. Sie können diese Komponenten und die Erfassung der Informationen selbst einrichten, müssen Sie jedoch in einem Repository erfassen, das Sie ganz einfach abfragen können. Außerdem müssen Sie in der Lage sein, Ihre Perfmon-Leistungsindikatoren mit Ihren Ablaufverfolgungsdaten zu synchronisieren. Es gibt verschiedene Whitepaper und GitHub-Beispiele, die Ihnen den Einstieg erleichtern.

Eine sehr einfache Möglichkeit besteht beispielsweise darin, BI Sentry zu installieren und SSAS als Ziel hinzuzufügen. Daraufhin werden alle relevanten Ablaufverfolgungen und Perfmon-Leistungsindikatoren in Ihrem SentryOne-Repository in SQL Server erfasst. Seien Sie beim Erstellen von Ablaufverfolgungen und Protokollen vorsichtig, um nicht zu viele Informationen zu sammeln und das Problem noch zu verschlimmern. Die SentryOne-Plattform wurde über die Jahre weiterentwickelt und erfasst sämtliche erforderlichen Informationen auf möglichst ressourcenschonende Art und Weise. Die SentryOne-Plattform installiert keinen Agent auf Ihrem SSAS-Computer, und unser Team aus MVPs hat die Leistung unseres Repositorys drastisch optimiert.

Beispielszenario

In diesem Szenario verwenden wir BI Sentry als Repository für die Leistungsüberwachung. Ein DBA mit geringen SSAS-Kenntnissen wurde dazu verdonnert, SSAS zu verwalten und zu überwachen. Die SSAS-Datenbank wurde von einem Auftragnehmer entwickelt und anschließend an das Datenteam übergeben. Die ersten Monate nach der Bereitstellung verliefen ereignislos, aber in letzter Zeit wurden dem Datenteam immer wieder Zeitüberschreitungen bei Berichten gemeldet. In dieser Umgebung wurde ein Berichterstellungs-Dashboard eingerichtet, mit dem Endbenutzer und bestimmte Führungskräfte Berichte aus der SSAS-Datenbank erstellen und ausführen können. Die Berichte sind eine Kombination aus Power BI-Berichten und einigen vorab erstellten und Ad-Hoc-Berichten, die die Benutzer erstellt haben, um die Daten zu analysieren.

Sie sehen sich in SSMS um und stellen fest, dass Sie eine SQL Server 2017-Implementierung im tabellarischen SSAS-Modus verwenden. Seitdem die Probleme zum ersten Mal aufgetreten sind, hat die IT-Abteilung die Berichte analysiert und festgestellt, dass die problematischen Berichte allesamt das tabellarische SSAS-Modell abfragen. Daraufhin wurde BI Sentry installiert und für die Überwachung der SSAS-Datenbank konfiguriert.

Der folgende Screenshot zeigt das Leistungs-Dashboard in SentryOne. Im Dashboard sehen Sie zwei Dinge, die einen möglichen Hinweis auf die Problemursache liefern.

1. Sie erkennen sofort, dass das SSAS-Modell verarbeitet wird (der Spitzenwert bei den übertragenen Zeilen).

2. Außerdem sehen Sie eine hohe Speicherauslastung (SSAS-Arbeitsspeicher überschreitet den roten Grenzwert). Dadurch wird SSAS gezwungen, Caches zu leeren, wodurch nachfolgende Abfragen verlangsamt werden.

Nachdem Sie die Ursache der Leistungsprobleme ermittelt haben, müssen Sie herausfinden, wodurch der Spitzenwert bei der Speicherauslastung verursacht wird, und ermitteln, welche Abfragen zu diesem Zeitpunkt ausgeführt werden. Dies lässt sich mühelos erreichen, indem Sie den Spitzenwert im Leistungs-Dashboard hervorheben und zum Kalender springen.

In der Kalenderansicht sehen Sie, dass der Verarbeitungsbefehl zu einem Zeitpunkt ausgelöst wird, an dem mehrere Power BI-Berichte ausgeführt werden. Bei näherer Betrachtung der Abfragen stellen Sie fest, dass die Berichte viele Felder mit hoher Kardinalität verwenden, die eigentlich ausgeblendet sein sollten. Viele Felder mit Schlüsselwerten sind sichtbar und werden in einigen der Berichte eingebunden. Für die meisten Berichte ist keine Kunden-ID oder Produkt-ID erforderlich, da die Berichtersteller kaum mit diesen IDs arbeiten werden. Daher sollten Sie diese Arten von Spalten für die Berichterstellungstools ausblenden und nur relevante Spalten für die Berichte sichtbar machen. Dies lässt sich ohne großen Aufwand erreichen und kann sich spürbar auf die Leistung auswirken.

Anschließend können Sie die Verarbeitungsbefehle so anpassen, dass sie mitten in der Nacht ausgeführt werden, wenn niemand die Datenbank abfragt.

Wenn Sie diese beiden einfachen Änderungen implementieren, stören Ihre Verarbeitungs- und Abfragearbeitslasten einander nicht mehr gegenseitig, und die generierten Abfragen verbrauchen viel weniger Arbeitsspeicher, da die Felder mit Schlüsselwerten nicht mehr angezeigt werden.

Testdaten

Für dieses Beispielszenario haben wir Testdaten mit TPC-DS generiert. Hier finden Sie eine kurze Übersicht über das entsprechende Verfahren:

1. Laden Sie die TPC-DS-Tools herunter.

2. Erstellen Sie TPC-DS und führen Sie die Software aus, um Daten zu generieren.

3. Verbinden Sie sich mit SQL Server und führen Sie tpcds.sql aus, um die Data Warehouse-Tabellen zu erstellen.

4. Führen Sie tpcds_source.sql aus, um die Quell- und Stagingtabellen zu erstellen.

5. Verwenden Sie die .sql-Skripts, um Daten zu erstellen bzw. zu laden (in den Tools finden Sie eine .docx-Datei mit einer Anleitung).