“Die Anwendung ist sooooo langsam!”. Jeder hat sicherlich schon das Jammern und Wehklagen von Softwareanwendern gehört. Dieses subjektive Gefühl der Benutzer, mit einer langsamen Applikation arbeiten zu müssen, sollte sehr ernst genommen werden. Der Aufwand, in komplexen Anwendungen nach den Ursachen für lange Laufzeiten zu forschen, ist jedoch langwierig und sehr mühselig. Oftmals ist es nur eine von vielen hundert Abfragen, die das System ausbremst. Es bedarf daher einer professionellen Unterstützung bei der Suche nach Schwachstellen einer Anwendung.

In Wikipedia kann man nachlesen: “Ein Profiler hilft dem Entwickler durch Analyse und Vergleich von laufenden Programmen die Problembereiche aufzudecken. Daraus kann man Maßnahmen zur strukturellen und algorithmischen Verbesserung des Quellcodes ableiten.” In allen Microsoft SQL-Server Editionen ab Version 2000 wird so ein Profiler mitgeliefert.

Im ersten Abschnitt dieses Beitrags wird gezeigt, wie der Profiler konfiguriert und an eine SQL-Server Tabelle angebunden wird. Im zweiten Teil wird kurz auf die Inhalte der Log-Tabelle eingegangen und das daraus resultierende Analysemodell für DeltaMaster besprochen. Zum Schluss sollen einige Beispielberichte und -analysen das Potential dieser Überwachungsanwendung aufzeigen.

Einrichten des SQL-Server Profilers

Gestartet wird der SQL-Profiler entweder über das Startmenü von Windows oder direkt aus dem Microsoft SQL-Server Managementstudio in der Menüleiste “Extras”. Nach dem Programmaufruf erscheint sofort ein Anmeldedialog. Hier wird angegeben, welcher Server überwacht werden soll.

Achtung: Standardmäßig ist der Servertyp “Datenbankmodul” eingestellt. Das heißt, man würde die Aktivitäten einer relationalen SQL-Server Datenbank aufzeichnen. Es soll hier aber die OLAP-Datenbank überwacht werden, daher ist der Servertyp auf “Analysis Services” umzustellen.

Nach der Anmeldung an den OLAP-Server erscheint der Dialog “Ablaufverfolgungseigenschaften”, in dem einige wichtige Einstellungen vorzunehmen sind. Zunächst wird im Reiter “Ereignisauswahl” nur das Ereignis “Query End” (unter dem Punkt “Queries Events”) ausgewählt (vgl. Abb. 1). Alle anderen Ereignisse müssen deaktiviert werden, weil für die MDX-Überwachung sonst zu viele Logeinträge generiert würden. Auf den Inhalt des “Query End”-Ereignisses wird weiter unten eingegangen.

Abb. 1: Ablaufverfolgungseigenschaft „Query End“ ausgewählt

Hinweis: Wenn man öfter diese Ereignisauswahl benötigt, kann man diese als Vorlage speichern. Dazu gibt es im Menü “Datei” den Unterpunkt “Vorlagen”. Das Anlegen von Vorlagen ist aber nur möglich, solange noch keine Serververbindung ausgewählt wurde.

Zurück zum Reiter “Allgemein” im Ablaufverfolgungseigenschaftendialog. Dort gibt es zwei Möglichkeiten, die protokollierten Messwerte neben der Anzeige auf dem Bildschirm zu speichern. Entweder können die Profiler-Daten als Datei oder direkt in einer SQL-Server Tabelle gespeichert werden, welches hier die viel bessere Variante ist. Dazu sollte man zuerst eine extra Datenbank auf dem Server anlegen oder man verwendet die unten im Blogbeitrag zum Download bereitgestellte SQL-Backupdatei (dort ist dann auch gleich das komplette DMM-Analysemodell mit dabei).

Wählt man “In Tabelle speichern”, erscheint erneut ein Anmeldedialog – diesmal ist der Server für den Ablageort der Tabelle auszuwählen und danach die Datenbank und die Zieltabelle für die Ablaufverfolgung (vgl. Abb. 2).

Abb. 2: Auswahl der Zieltabelle, in der die Ablaufverfolgung geschrieben wird

Nach Bestätigung der Tabellenauswahl und drücken des “Ausführen”-Knopfes startet sofort die Überwachung und in einem Fenster werden die MDX-Statements, die der Server verarbeitet, sichtbar.

Aufbau der Log-Tabelle

Parallel zu der Anzeige auf dem Bildschirm füllt sich die angegebene Tabelle im Hintergrund. Sie kann ganz einfach über

Select *
From T_MDX_Log

abgefragt werden. Der genaue Aufbau der Tabelle ist hier beschrieben; auf einzelne Besonderheiten soll hier jedoch hingewiesen werden.

Neben den üblichen Protokollspalten wie Abfragedatum und -zeit, Server, Datenbank und Benutzer wird in den Spalten “Duration” und “CPU Time” die Abfragezeit sowie in der Spalte “TextData” der komplette MDX-Befehl mitgeschrieben. Man kann also genau auswerten, welche Abfragen am langsamsten sind.

Doch wie findet man die zu optimierende Abfrage in einer komplexen .das-Datei mit mehreren Berichten und hunderten von Analysewerten wieder? Eine große Hilfestellung beim Auffinden leistet hier DeltaMaster selbst. Durch eine Einstellung in der Registry (Key im Downloadpaket) werden in den MDX-Befehlen, als Kommentar getarnt, noch weitere Informationen dazu geliefert. Folgendes MDX-Beispiel soll dies verdeutlichen.

SELECT /*Profiler_MDX_Analysis.das (30.12.2011 09:01:13)|Report (1)|RNK|Top 
10 aufgerufene Berichte/Sitzung||RNK||View (1)|Alle Jahre*/
    {[Measures].[Anzahl_Sitzungen]} ON AXIS(0),
    {Descendants([Report].[Report].[Alle Reports], [Report].
[Report].Levels(1),LEAVES)} ON AXIS(1)
FROM [Profiler_MDX_Analysis] CELL PROPERTIES VALUE

Man erkennt im Code zwischen den Kommentarzeichen “/*…*/” und durch Pipe-Zeichen (“|”) getrennt folgende Informationen:

• Verwendete .das-Datei mit letztem Speicherdatum,
• ReportID,
• ReportType (z.B. FLX, RNK),
• ReportName,
• CockpitID,
• CockpitType (z.B. PIV, FLX),
• CockpitName,
• ViewID,
• ViewName (Auflistung der kompletten Sichteinstellung).

In der mitgelieferten Datenbank werden diese Informationen in der Sicht “V_S_Split_MDX_For_DeltaMaster_Information” getrennt (vgl. Abb. 3) und stehen damit für die Einzelanalyse zur Verfügung.

Abb. 3: Von DeltaMaster im MDX-Befehl angereicherte Informationen

Hinweis: Wie bereits erwähnt werden diese Zusatzinformationen nur geliefert, wenn ein Registry Key gesetzt wurde und DeltaMaster ab Version 5.5.0 eingesetzt wird.

Beispielberichte und -analysen

Neben dem Hauptgedanken, langsame MDX-Statements in komplexen Flexreports mit mehreren Cockpitquellen zu identifizieren (vgl. Abb. 4), ergeben sich mit der Anwendung noch ganz andere Analysemöglichkeiten. Einige davon sollen mit Screenshots kurz aufgezeigt werden. Sie sind Bestandteil der mitgelieferten Analysesitzung.

Abb. 4: Langsames MDX-Statement; Pivotnavigation, um das Cockpit zu ermitteln

Abb. 5: Rangfolge der am häufigsten aufgerufenen Berichte

Abb. 6: Übersicht über die verwendeten .das-Dateien

Abb. 7: Fehleranalyse

Datei zum Download

Zum guten Schluss finden Sie das Projekt zum Download auf der Blog-Seite. Darin enthalten sind

• SQL-Server Backup der Profiler_MDX_Log-Datenbank
• Analysis Server Backup der Profiler_MDX_Log-Datenbank
• .das-Datei für Auswertung
• Modeler .das-Datei
• DeltaMaster reg-Key für die Freischaltung der erweiterten Log-Protokollierung

P.S.: Das war pünktlich zum Jahreswechsel der 111. Artikel unseres Blogs. Ein gutes neues Jahr!