Performance-Analyse von Datenbanken

Die Optimierung von Datenbanken zählt oftmals nicht zu den Lieblingsaufgaben der Datenbank-Administratoren. Allerdings können sich derartige Optimierungs-Arbeiten durchaus auszahlen, und dabei zum Vorteil für Anwender, Administratoren und die Unternehmen gereichen. Für den Fall, dass die betroffenen Datenbanken (DBs) im Unternehmenseigenen Rechenzentrum (RZ) betrieben werden, wirkt sich ein solches „Performance-Tuning“ in der Regel nur auf die verbrauchte Strommenge aus. In seltenen Fällen sorgen nicht optimierte DB dafür, dass neue, leistungsfähigere Hardware beschafft wird – um die entsprechenden Anwendungen zu beschleunigen.

Im Cloud-Umfeld werden die Unternehmen meist direkt proportional zum „Ressourcen-Verbrauch“ – sprich der in Anspruch genommenen CPU-, DRAM-Leistungen und des Massenspeicherverbrauchs – zur Kasse gebeten. An dieser Stelle kann es für die Unternehmen wichtig werden, leistungshungrige DBs und die darauf zugreifenden Applikationen möglichst zu optimieren, und die vom Cloud-Anbieter bezogenen „Leistung“ möglichst gering zu halten. Dies soll am Beispiel einer SQL-Installation, die innerhalb einer Amazon EC2-Instanz betrieben wird, genauer erläutert werden:

Bei den Amazon EC2-Instanzen handelt es sich um dedizierte VMs, die in unterschiedlichen Leistungsklassen verfügbar sind. Diese unterscheiden sich anhand der zur Verfügung gestellten CPU-Leistung, des vorhandenen DRAM-Ausbaus, sowie den Massenspeichermedien. Instanzen mit besserer CPU-Leistung und höheren DRAM- sowie Massenspeicher erzeugen dabei höhere Kosten. Eine Optimierung der jeweiligen Software-Komponenten, Datenbanken und Applikationen kann sich folglich in „barer Münze“ auswirken. Zudem sorgt eine geschwindigkeitsoptimierte DB für schnellere Antwortzeiten, sprich die Anwender profitieren ebenfalls, wenn Anfragen mit einer möglichst geringen Latenz beantwortet werden. Um nun den CPU-Leistungsverbrauch eine SQL-DB zu verringern, sind unterschiedliche Methoden verfügbar. Unter anderem können sich die Administratoren auf die folgenden drei Methoden konzentrieren:

• Dynamic Management Views
• Time Statistics
• SQL Server Management Studio Client Statistics

Um die passende Methode zu selektieren, die für die jeweilige Umgebung möglichst passend ist, sollten die Systembetreuer. Dazu kommt eine SQL-Kopie der „Wide World Importeurs“ zum Einsatz. Hier wurde bewusst eine Funktion mit „schlechter Performance“ gewählt, damit die einzelnen Optimierungsschritte gut sichtbar werden.

CREATE PROCEDURE pOption1 AS

BEGIN

SELECT RecordedWhen, A.Temperature

FROM dbo.Temps AS A

WHERE A.Temperature < dbo.OptimalValue(ColdRoomSensorNumber)

AND A.ColdRoomSensorNumber = 1

END

GO

Um zunächst möglichst aussagekräftige Messwerte des Grundzustands zu erzeugen, müssen im ersten Schritt die Baselines ermittelt werden. Sprich mit welcher Performance (etwa Antwortzeit in Millisekunden) ein bestimmter Task abläuft. Danach können Optimierungen vorgenommen werden, und die Antwortzeit neu ermittelt, und mit den Baseline-Werten verglichen werden.

Dynamic Management Views

Es sind unterschiedliche DMVs (Dynamic Management Views beziehungsweise Dynamische Verwaltungsansichten) vorhanden, um den „CPU-Verbrauch“ zu messen. Dabei sind vor die Funktion sys.dm_exec_query_stats sowie Aufruf von sys.dm_exec_procedure_stats zu nennen. Der erstgenannte Aufruf liefert Rückmeldung über aktuelle (laufende) Anfragen, während der letztgenannte Aufruf Informationen zu älteren Anfragen, die bereits abgearbeitet wurden, enthält. Dabei ähneln sich die beiden Funktionen, denn beide liefern detaillierte Informationen, etwa den minimalen/durchschnittlichen/maximalen Antwortzeiten, IOPS (Input Output Operation per Second) oder der CPU-Belastung. Folgender Aufruf liefert beispielsweise die gewünschten Informationen:

SELECT OBJECT_NAME(ePS.object_id,ePS.database_id)

 

, ePS.execution_count, ePS.last_worker_time / 1000.0 AS last_worker_time_ms

 

, ePS.last_elapsed_time / 1000.0 AS last_elapsed_time_ms

 

FROM sys.dm_exec_procedure_stats AS ePS

 

WHERE OBJECT_NAME(ePS.object_id, ePS.database_id) = 'pOption1';

Dabei ist anzumerken, dass die jeweiligen Detailinformationen beim Ausführen von SQL-Operationen automatisch mit angelegt und gecached werden. Somit lassen sich Performance-Werte auch bequem nachträglich in Erfahrung bringen, und müssen nicht zwangsläufig erstellt werden.

Time Statistics

Die Möglichkeit, entsprechende Statistiken abzurufen, lässt sich im SSMS (SQL Server Management Studio) aktivieren. Dazu Nutzen die Systembetreuer den entsprechenden Button auf der rechten Seite der SSMS-Toolbar (siehe Bild). Alternativ ist die Funktion auch über die Tastenkombination „SHIFT+ALT+S“ erreichbar. Alternativ kann der folgende Befehl ausgeführt werden:

SET STATISTICS IO (ON|OFF)

 

The information is displayed on the Messages Tab that is generated when a query is executed in SSMS:

 

SET STATISTICS TIME ON

 

EXEC dbo.pOption1;

Bei dieser Methode sollte auf einige Nachteile hingewiesen werden. So werden die Ergebnisse nur anhand der Ausführungszeit ermittelt. Somit müssen die einzelnen Zeitabschnitte dokumentiert werden.

Show Client Statistics

Zudem ist es möglich, Messungen über das SQL Management Studio anzeigen zu lassen. Dazu navigieren die Systembetreuer im Management Studio auf die entsprechende Schaltfläche in der Menüleiste. Diese Funktion ist auch mit dem passenden Shortcut (Shift+Alt+S) erreichbar. Hier finden die Administratoren detaillierte Informationen abrufen, und Abfrage- sowie Laufzeiten der SQL-Datenbanken in Erfahrung bringen.

Florian Huttenloher