Über unsMediaKontaktImpressum
Matthias Reimann 21. April 2015

Belastungstest für die Datenbank

Kaum ein Datenbankserver gleicht mehr dem anderen. Die Möglichkeiten der Virtualisierung versetzen uns heute in die Lage, eine immens große Anzahl an Kombinationen von Prozessor (CPU), Speicher und Storage (SAN) für die Datenbank zu verwenden. Dazu kommen noch ständige Updates der Betriebssysteme, Treiber und für die Datenbank. Die Praxis zeigt, dass es etliche Kombinationen gibt, die für die Datenbank nicht performant sind und sogar bei stärkerer Belastung zu Funktionsstörungen führen. Am Beispiel Oracle-Datenbanken soll der folgende Bericht zeigen, wie wichtig Lasttests sind und wie einfach diese durchzuführen sind. Zur Anwendung kommt hier die Software Swingbench.

Eigentlich sollte nur ermittelt werden, wie hoch der maximale Datentransfer vom Storage (SAN) in die Datenbank ist. Beim ersten Versuch dieses festzustellen tauchte ein Bug auf, der die Oracle-Datenbank (11gR1) unter voller Belastung zum Absturz brachte. Damit war ein Grundstein für die Notwendigkeit von Belastungstests für die Datenbanken gelegt. Ein Lasttest einer Oracle-Datenbank ist für alle die Grundlage, die nicht warten wollen bis eine Datenbank bei Ressourcenengpass stehen bleibt.

Die drei Ressourcen, die einer Datenbank zur Verfügung stehen sind CPU, Speicher und Disk I/O. Die Geschwindigkeit einer Datenbank ergibt sich aus der Kombination dieser drei Ressourcen. Hier hat der Datenbankadministrator die Wahl – Mal mehr und Mal weniger. Die Vielfalt verschiedener Hersteller und Geschwindigkeiten hat dabei in den letzten Jahren weiter zugenommen. Mit der Einführung von SSD-Storage ist noch eine weitere Ressource für die Datenbank dazugekommen. Der Einfluss des DBA auf die Ressourcen hat dadurch aber ebenfalls zugenommen: Die Verfügbarkeit und Möglichkeiten der Skalierbarkeit gilt es zu beeinflussen, so gut es geht. Auch das Betriebssystem, welches diese Ressourcen zur Verfügung stellt, spielt dabei eine nicht unwesentliche Rolle.

Die Datenbank hat eine lange Veränderungsgeschichte hinter sich. In den Anfangszeiten waren Datenbanken oft noch klein: Es genügten wenige Ressourcen aus, um eine Datenbank zu betreiben. Nicht selten waren die Datenbank und die Anwendung auf einem Server - auch aus Kostengründen. Ressourcenkontrolle war nicht möglich und auch noch nicht gefragt. Stabilität stand oft im Vordergrund. Größer werdende Datenbanken sorgten später dafür, dass Datenbanken eigene Server bekamen. Damit standen alle Ressourcen der Datenbank zur Verfügung. Da es sich dabei oft immer noch um Hardware mit eingebauter CPU und Festplattencontroller handelte, war der Speicher in Größe und Verwaltung die einzige Ressource, die gemanagt werden musste. Die Arbeit des DBAs in Bezug auf Ressourcenverwaltung war bis dahin eher übersichtlich. Wenn ein System nicht mehr performant war, dann war neue Hardware zu beschaffen und die Datenbank zog um.

Mit der Einführung der Virtualisierung konnten dann die Ressourcen dem Datenbank-Server zugewiesen werden. Alle drei Ressourcen sind seitdem dynamisch und können je nach Betriebssystem und Datenbankversion auch online im laufenden Betrieb geändert werden. Dadurch sind die Aufgaben des DBAs komplexer geworden. Er kann nun die Ressourcen variieren. Wenn eine Datenbank nicht mehr ihre Leistung bringt, dann heißt es, Anforderungen stellen - aber welche? Die Analyse erfolgt meistens auch noch im produktiven Betrieb, wenn die Zeit knapp ist.

Es gilt also, eine Möglichkeit zu schaffen, die Ressourcen einer Datenbank möglichst genau zu disponieren, so dass eine neue Umgebung entsprechend geprüft an den Start geht und der produktive Betrieb so lange wie möglich ohne Änderungen läuft.

Datenbanktest: Performancetest, Benchmark und Lasttest

Die Möglichkeit, eine Datenbank zu testen, kann in drei Bereiche aufgeteilt werden: Performancetest, Benchmark und Lasttest.

  • Ein Performancetest soll meistens zeigen, wie schnell eine Datenbank ist. Hier stehen die Laufzeit bestimmter SQL-Befehle und die Antwortzeit für die Anwendung oft im Vordergrund.
  • Ein Benchmark soll die Leistung eines Datenbanksystems vergleichbar machen. Nicht nur in Bezug auf Ressourcen, sondern auch auf verschiedene Systeme und Hersteller.
  • Mit einem Lasttest soll versucht werden, das Datenbanksystem bis an die Leistungsgrenze zu belasten. Dabei sollen die Grenzen der Belastbarkeit erreicht werden.

Ein Lasttest sollte auf mehrere Fragen - nicht nur für den DBA - Antworten geben, wie zum Beispiel:

  • Wie reagiert der Datenbankserver bei 100%? Ist er dann noch administrierbar?
  • Kann bei solch einer Last die Datenbank noch gesichert werden?
  • Erfüllt der Datenbankserver bei voller Belastung überhaupt noch die Anforderungen?
  • Haben die Aktualisierungen der Systeme (Host, Betriebssystem, Datenbank) die Stabilität beeinträchtigt?

Dieser Liste könnte man noch etliche weitere Fragen hinzufügen.

Was wird für einen Lasttest benötigt?

Egal womit eine Datenbank belastet wird, diese Belastung muss protokolliert werden. Anwendungen für einen Lasttest sollten daher in der Lage sein, die Lasten und Messwerte in ein Protokoll zu speichern - am besten in Datenreihen pro Sekunde und als Tabelle (z. B. csv, txt). So werden die Messungen auswertbar, lassen sich zusammenfassen und auch für spätere Vergleiche verwenden. Wenn die Datenbanklast messbar ist, kann mit einer Software die Last erzeugt werden. Dazu benötigt man einen passenden Datenbestand. Eine gute Eigenschaft dieses Datenbestandes ist es, wenn dieser frei skalierbar ist und sowohl für kleine (1 GB) aber auch für große (>100 GB) Datenbanken anwendbar ist. Wenn die Belastung dann idealerweise vom Anwendungsprofil nah an die tatsächliche Nutzung der Anwendung angepasst werden kann, dann ist nach einem Lasttest eine zuverlässige Aussage über die Datenbank möglich.

Für Oracle-Datenbanken ist der Einstieg besonders einfach, weil eine kostenlose Software erhältlich ist, die alle zuvor angesprochenen Kriterien erfüllt. Hier ein schneller Einstieg für alle, die schon lange mal wissen wollten, ob ihre Datenbank belastbar ist.

Swingbench für die Erzeugung der Datenbanklast

Der Einstieg:

  1. Von der Website von Dominic Giles [1] kann die Software Swingbench heruntergeladen werden. Es handelt sich um ein auf Java basierendes Programmpaket, welches lediglich entpackt werden muss. Das Betriebssystem kann sowohl Unix/Linux als auch Windows sein.
  2. Als nächstes ist es erforderlich, für die einzelnen Programmteile die richtige Java-Version zur Verfügung zu stellen. Wenn die Programmdatei java automatisch gefunden wird und in passender Version (java-version) vorliegt, muss nichts geändert werden. Wenn ein passendes Java bereitgestellt werden muss, dann können die Startskripte unter ./bin (Windows ./winbin\*.bat) angepasst werden.
  3. Nun kann der Datenbestand für den Lasttest angelegt werden. Zwei Datenbestände stehen zur Verfügung: Einer für OLTP (Schema soe, ./bin/oewizard) und der andere für OLAP (Schema sh, ./bin/shwizard). Zum einen sollten Passwortrichtlinien abgeschaltet sein und es wird der Pfad für die Datendateien der Datenbank benötigt. Wer genau wissen möchte, was hier geschieht: Die SQL-Skripte befinden sich im Ordner ./sql. Swingbench arbeitet mit JDBC.
  4. Vor dem Erzeugen des Datenbestandes wäre ein guter Zeitpunkt, die Aufzeichnung der Belastungsdaten zu startet: Für das Betriebssystem Windows kann beispielsweise der Performance Monitor verwendet werden, bei Linux das Kommando sar.
  5. Wenn der Datenbestand erzeugt ist, dann kann das Tool Swingbench aufgerufen werden. Es wirkt erst einmal ziemlich mächtig, kann aber auch in einer kleinen Version oder als „Einzeiler“ gestartet werden. Um die Parameter zu erkunden und festzulegen, muss die umfangreiche Version verwendet werden. Im Verzeichnis ./config sind für die einzelnen Varianten Templates, denen man für den ersten Start lediglich die Verbindungsdaten und ggf. ein Login für den AWR-Report hinzufügen muss. Dann kann es schon losgehen.

Empfehlungen

Am besten betrachtet man einen Lasttest wie ein physikalisches Experiment und protokolliert es auch so. Im Ordner Swingbench sind schnell alle Logfiles kopiert und dann gezippt, eine kleine Textdatei dokumentiert alle sonstigen Parameter und das Configfile die Einstellungen im Swingbench. So kann ein Test schnell wiederholt oder für vergleichbare Anforderungen wiederverwendet werden.

Für die Aufnahme der Belastungsdaten gibt es auf der Webseite von Swingbench mehrere Tools, aber auch das das Tool "oratop" von Oracle kommt dafür in Frage.

Swingbench bietet eine einfache und verhältnismäßig schnell zu verwendende Methode um eine Oracle-Datenbank mit einem Lasttest zu prüfen, um mit gutem Gewissen diese für einen sicheren Betrieb bereitzustellen. Mit einer OracleXE auf einem Laptop ist ein Lasttest innerhalb von 45 Minuten realisierbar.

Ausblick

Eine Datenbank mit einer definierten Last zu betreiben, das ist für den DBA nicht nur bei der normalen Datenbank sehr nützlich. Ein Lastgenerator ist auch gut verwendbar für den Funktionstest (oder auch Belastungstest) von Oracle Dataguard, Replikationslösungen oder Oracle Real Application Clusters (RAC).

Swingbench bietet auch ein Modell, in dem ein Lasttest mit eigenem Datenbestand programmiert werden kann. In der nächsten Version soll Swingbench auch einen Ergebnisbericht in PDF erstellen können. Wegen der Betriebssystemunabhängigkeit und der Verwendung ohne Installation lässt sich diese Vorgehensweise schnell und einfach einsetzen.

Quellen

[1] dominicgiles.com

Autor

Matthias Reimann

Matthias Reimann ist Oracle Datenbankadministrator und -entwickler. Im Rechenzentrum der GISA GmbH in Halle hat er sich auf Belastungstests, Datawarehouse und Hochverfügbarkeitstechnologien spezialisiert. In der Deutschen Oracle...
>> Weiterlesen
botMessage_toctoc_comments_9210