Mit Oracle 8i hat die Datenbankfirma einen wichtigen Schritt getan, um ihr Flaggschiff Internet-ready zu machen. Doch sobald eine Oracle-Datenbank in den Einsatz für Internet-Dienste geht, zeigt es sich, ob auch Entwickler und Administratoren ihr Handwerk gut genug verstehen, um ausreichende Geschwindigkeit auf Dauer zu gewährleisten.
Ein nahezu alltäglicher Fall: Bei einer Internetfirma X.COM erstellt die Programmiererin Paula eine Webseite basierend auf einer Oracle-Datenbank. Nachdem sie ihren SQL-Code und das Skript drumherum entwickelt hat, stellt sie mit Befriedigung fest, dass ihre Seite in nur 0,1 Sekunden aufgebaut ist, und meldet stolz die Fertigstellung. Die Anwendung geht online, aber nach nur drei Stunden melden sich enttäuschte Benutzer bei X.COM, dass die Seite unsagbar langsam aufgebaut wird. Was war passiert?
Paula hatte nicht damit gerechnet, dass wirklich 20 Benutzer pro Sekunde ihre Webseite besuchen und dass durch das stetige Füllen der Datenbank mit Benutzerdaten die einzelnen Operationen immer länger dauern.
Was lernen wir daraus? Datenbankanwendungen für das Internet müssen hoch performant sein und das eintretende Wachstum verkraften können. Damit Ihnen als Oracle-Programmierer oder -Administrator nicht das Gleiche passiert, möchte ich Ihnen einige Kochrezepte für das Orac-le-Performance-Tuning an die Hand geben. In der Tat sind die vorgestellten Techniken zum Teil auch auf andere Datenbanksysteme übertragbar, aber naturgemäß ist das High-End-Tuning von Datenbankanwendungen stark vom entsprechenden Produkt geprägt.
Abbildung 1: Die verschiedenen Tuning-Möglichkeiten sind unterschiedlich effizient.
Performance hat bei Servern immer zwei Aspekte: erstens die Antwortzeit - das ist die Zeit, die vergeht, bis ein einzelner Endanwender das vollständige Ergebnis einer Datenbankinteraktion zurückerhält, bis sich also eine Webseite oder eine Maske mit Daten gefüllt hat. Zweiter Aspekt ist der Durchsatz, der sich als Summe von Operationen pro Zeiteinheit über alle Benutzer versteht. Obwohl wir Fälle konstruieren können, in denen beide Ziele entgegengesetzte Maßnahmen erfordern, gilt doch in den meisten Fällen, dass eine gute Antwortzeit vieler Einzeloperationen gleichbedeutend mit einem hohen Gesamtdurchsatz ist. Ziel dieses Artikels ist es daher, Tuningmaßnahmen vorzuschlagen, die beide Aspekte der Datenbankperformance berücksichtigen.
Welche Faktoren bestimmen die Performance einer Datenbank mit all ihren Anwendungen? Wie so oft in der EDV wird auch bei Datenbankanwendungen die Gesamtleistung durch mehrere logische Schichten bestimmt:
Die Praxis zeigt allerdings, dass diese vier Schichten ein stark unterschiedliches Verhältnis von Tuning-Effekt zu Tuning-Aufwand haben (Abbildung 1). Während wir durch optimale Betriebssystem- und Hardwareparameter oft nur Prozente an Leistung erzielen können, ist es möglich, durch wenige Regeln im Anwendungsdesign Faktoren von mehreren Größenordnungen in der Performance zu erzielen. Ich schlage deshalb vor, das Datenbanktuning immer in der obigen Reihenfolge durchzuführen, und gliedere so auch diesen Beitrag.
Die Beschleunigung von Programmen wird dadurch erreicht, dass der so genannte Ausführungspfad von Operationen verkürzt wird. Doch wie sieht der Ausführungspfad einer SQL-Operation im Client-Server-Umfeld aus? Einen Überblick über die Schritte liefert dazu Abbildung 2 anhand eines einfachen »UPDATE«-Befehls, der von der Applikation abgesetzt wird:
1. Marshalling: Die Client-Bibliothek packt den SQL-Code mit Bind-Variablen und einer Reihe von Hilfsgrößen in eine Plattform-, Architektur- und Versions-unabhängige Form.
2. Dieses Datenpaket wird über einen Systemaufruf (»write()« oder Ähnliches) dem Betriebssystem zum Transport zum Server übergeben. Über die entsprechenden Protokollstapel und die Netzwerkhardware erreicht das Päckchen letztlich den zugeordneten Serverprozess.
3. Nach einem analogen De-Marshalling fängt aber erst die eigentliche Arbeit des Servers an:
4. Der SQL-Code wird auf syntaktische Richtigkeit geprüft. Das kann einige Zeit in Anspruch nehmen, bedenkt man die Größe der Syntaxgraphen moderner Oracle-Versionen.
5. Die Datenbank überprüft anhand des Repositorys, ob der angemeldete Benutzer diesen Code ausführen darf.
6. In der SQL-Area wird dann nachgeschaut, ob ein Ausführungsplan zu exakt diesem SQL-Statement bereits vorliegt. Wenn das nicht der Fall ist, muss der Optimierer (Optimizer) aus seinen verfügbaren Hintergrundinformationen einen neuen, den vermeintlich günstigsten Ausführungspfad berechnen.
7. Der Ausführungspfad wird abgearbeitet, das heißt, aus Tabellen und Indexen werden Datensätze geladen, modifiziert, in das Rollback-Segment geschrieben, alle Änderungen im Redo-Log manifestiert und ein Antwortpaket erzeugt.
8. Dieses Päckchen nimmt den umgekehrten Weg durch alle Instanzen zurück zur Client-Logik, wo lapidar festgestellt wird: »UPDATE« hat geklappt.
Abbildung 2: Der Weg der Information durch die verschiedenen Schichten der Datenbank.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
