MÜNCHEN - Der Praktiker steht häufig vor besonderen Problomen, wenn es gilt, Letstungsmängel bei installierten Datenbanksystemen zu beseitigen. Im folgenden Beitrag gibt Gunter Müller-Ettrich von der IABG aus Ottobrunn Tips und Ratschläge zu einer sinnvollen Vorgehensweise bei diesen Tuningmaßnahmen. Wichtig scheint dem Autor, daß das Tuning auf Leistungsmessungen beruht und in den Zyklen jeweils nur eine Komponente verändert wird, um Wechselwirkungen treffsicher ausschalten zu können. Die Anregungen basieren auf Erfahrungen, die der Münchner mit den Datenbanksystemen IMS/VS. Adabas und UDS gesammelt hat. Ausführlicher sind sie in seinem Buch "Leistungsmessung und Leistungsverbesserung von Datenbanksystemen" Verlagsgesellschaft Rudolf-Müller, Köln-Braunsfeld, beschrieben.

Eine der wichtigsten Vorarbeiten zur Planung und Durchführung von Leistungsmessungen und Leistungsverbesserungen eines Datenbanksystems ist die klare Festlegung der Ziele und Tätigkeiten. Die Vorgehensweise zur Erreichung dieser Ziele können erheblich voneinander abweichen. Die häufigsten beim Einsatz von Datenbanken auftretenden Problemkomplexe sind:

- Indentifizierung und Beseitigung von Leistungsmängeln bei bereits installierten oder neu eingeführten Datenbanksystemen.

- Prüfung, welche Auswirkungen zusätzlich geplante Anwendungen oder Systemänderungen auf ein installiertes Datenbanksystem haben.

- Prüfung, ob spezifizierte Anwendungsanforderungen durch eine geplante Datenbanksystemkonkfiguration erfüllt werden können.

- Quantitativer Vergleich der Auswirkungen einzelner Leistungsfaktoren von Datenbanksystemen.

Hier werden im wesentlichen Verfahren der Leistungsmessung für den ersten und vierten Problemkreis behandelt.

Theoriemangel zwingt zu Pragmatismus

Die heute von den EDV-Herstellern und Softwarefirmen angebotenen Datenbanksysteme stellen überwiegend generalisierte Softwarepakete dar, die für die jeweiligen Anwendungen erst "zugeschnitten" werden müssen. Das geschieht zum einen durch Auswahl der benötigten Teilmoduln und zum anderen durch Festlegung bestimmter Parameter bei der Generierung und beim Aufbau des Systems. Bei entsprechender Komplexität des Datenbanksystems sowie des zugrundeliegenden Betriebsystems ist es in vielen Fällen nicht möglich, die Auswirkungen der Parameterwahl auf die Gesamtleistung genügend genau vorherzusagen. Die quantitativen Auswirkungen zahlreicher Einzelparameter sowie die quantitativen Wechselwirkungen zwischen vielen Einzelparametern sind bei komplexen Datenbanksystemanwendungen nicht hinlänglich bekannt und auch mit mathematischen Methoden wie beispielsweise stochastischen Prozessen nicht genügend realistisch erfaßbar.

Dieser Mangel an Theorie zwingt in diesen Fällen zu einem pragmatischen Vorgehen, dessen Kern gezielte Leistungsmessungen bilden. Diese Leistungsmessungen sind bei komplexen Datenbanksystemen nicht als Notlösung aufgrund von Softwaremängeln zu betrachten, sondern bilden eine unvermeidliche Tätigkeit zur Anpassung der generalisierten Datenbanksoftware an benutzerspezifische Probleme und die gegebene Hardwarekonfiguration

Um erfolgreich Leistungsmessungen für Leistungsverbesserungen und Leistungsvorhersagen durchführen zu können, sind einige allgemeine Richtlinien zu beachten Solche Hilfen sucht man in der überwiegenden Zahl der Veröffentlichungen zur Leistungsmessung und Leistungsverbesserung leider vergeblich. Viele Berichte, vor allem der Anbieter von Hardware- und Softwaremonitoren verwirren häufig durch die Fülle von Detaildaten und helfen wenig bei der Suche nach einer Vorgehensmethodik. Im folgenden werden daher einige Richtlinien zu dieser Problematik zusammengestellt.

Die Messung der Auslastung der zentralen Systembetriebsmittel wie Zentraleinheit, Arbeitsspeicher und Ein-/Ausgabekonfiguration stellt einen wichtigen Bestandteil der Messungen zur Leistungsverbesserung dar. Problematisch ist hier, wie diese gemessenen Werte zu interpretieren sind. Allgemein gibt es für diese Werte keine absolut festen Sollgrößen.

Diese sind vielmehr je nach Art der Anwendungssysteme und der Benutzeranforderungen verschieden. Liegt die maximale Auslastung eines Kanals bei Systemen mit interaktiven Anwendungen bei etwa 30 Prozent, so kann derselbe Kanal bei reinen Stapelanwendungen bis zu 80 Prozent ausgelastet sein, ohne daß dies leistungsmindernd ist.

Bei bestimmten Anwendungs- und Systemkonfigurationen haben sich jedoch aufgrund zahlreicher Installationen empirische Richtwerte herauskristallisiert, deren Überschreitung in den meisten Fällen zu Leistungsproblemen führt. Hierzu gehört zum Beispiel die Regel, daß eine Demand-Page-In-Rate größer 20/sec bei einer IBM/158 (MVS) negativen Einfluß auf die Antwortzeiten interaktiver Subsysteme hat. Analog gibt es Regeln und Richtwerte für interne Schlüsselwerte bei verschiedenen Datenbanksystemen. Ist dies nicht der Fall, so können Richtwerte durch Messung an leistungsmäßig zufriedenstellenden Systemen ermittelt werden, die dann allerdings zunächst nur für spezielle Installationen gelten.

Neben Richtlinien für die Kenngrößen der zentralen Systembetriebsmittel müssen auch Regeln für die Versorgung der Systemkomponenten des Datenbanksystems mit Betriebsmitteln, die Zeitkomponenten des Lebenslaufs einer Nachricht in einem DB/DC-System sowie die Werte der anwenderspezifischen Komponenten vorliegen. Zu letzteren gehören auch Richtlinien für Datenbankzugriffs- und Verweilzeiten von Nachrichten in Warteschlangen.

Kontinuierliche Auswertung ist wichtig

Bei vielen Datenbanksysteminstallationen ist es üblich, während des Datenbankbetriebs wichtige Leistungsdaten auf Band- oder Plattendateien zu sammeln und zu einem späteren Zeitpunkt im Offline-Status auszuwerten. Ein Nachteil dieser Methode ist, daß Probleme erst nach deren Auftreten analysiert werden können. Das für die Leistungsprobleme zuständige Personal erfährt häufig erst dann von Schwierigkeiten, wenn sich unzufriedene Anwender - meist mit zeitlicher Verzögerung - melden.

Befassen sich die zuständigen Bearbeiter erst zu diesem Zeitpunkt mit der Untersuchung der Leistungsprobleme, dann ist es möglich, daß wichtige Anhaltspunkte, die zur Klärung der Problemursache führen können bereits verschwunden sind oder daß zusätzlich nötige Logvorrichtungen gar nicht rechtzeitig eingeschaltet werden können.

Um dies zu vermeiden, sollte eine kontinuierliche Überwachung und Auswertung vorgenommen werden. Voraussetzung hierfür sind Meßwerkzeuge, die eine ständige Überwachung und Auswertung gestatten. Mit Hilfe einer solchen ständigen Überwachung ist es möglich, drohende Leistungsabfälle rechtzeitig zu erkennen und korrigierend einzugreifen, bevor die den Anwendern zugesicherte Leistung gemindert wird.

Ziel der Leistungsmessung zur Leistungsüberwachung wird zunächst sein, die Ursache für die Leistungsmängel aufzuspüren. Diese Messungen sind zweckmäßigerweise in zwei Stufen durchzuführen. In der ersten Stufe - dem Grobtuning - sind die Hauptfaktoren für die Leistungsmängel zu identifizieren und soweit wie möglich zu beseitigen. Grobe Leistungsmängel haben ihre Ursache häufig in einer Überlastung oder unausgewogenen Auslastung der Systembetriebsmittel wie der Ein-/Ausgabekonfiguration oder einer übermäßigen oder unausgeglichenen Arbeitslast. Erst nach Beseitigung der gröbsten Leistungsmängel kann das System in einer zweiten Stufe - dem Feintuning - durch Anpassung der schwieriger zu erfassenden Faktoren - optimiert werden.

So hat sich bei Untersuchungen ergeben, daß etwa 70 Prozent der Leistungsmängel von DB-Systemen auf eine Überlastung oder eine unausgewogene Auslastung der E/A-Konfiguration zurückzuführen war.

In der Praxis kann man häufig beobachten, daß obige Reihenfolge gerade umgekehrt wird. Hier dreht das Datenbankpersonal zuerst an allen möglichen "Feinschrauben" des Datenbanksystems, ehe es sich mit dem für die Hardware oder dem Betriebssystem zuständigen Personal in Verbindung setzt und dieses die in vielen Fällen nötigen Grobtuningmaßnahmen durchführt.

Diese Gefahr ist um so größer, je mehr Möglichkeiten und Komfort des Tunens das Datenbanksystem bietet.

Sowohl bei Grobtuning als auch beim Feintuning handelt es sich um iterative Prozesse. In beiden Fällen werden Meßergebnisse analysiert, und aufgrund der Kenntnisse über das Datenbanksystem, die Systemumgebung und die Anwendung werden Hypothesen über eine Verbesserung der Meßergebnisse durch Veränderungen von Leistungsfaktoren aufgestellt. Daraufhin werden die Leistungsfaktoren verändert und wieder Messungen durchgeführt. Dieser Zyklus muß solange wiederholt werden, bis ein befriedigendes Systemverhalten erreicht ist oder keine wesentliche Verbesserung mehr erreicht werden kann.

Dieses iterative Vorgehen stellt aufgrund des bereits erwähnten Mangels an Theorie den einzig praktisch gangbaren Weg zur Lösung von Systemproblemen bei komplexen Datenbanksystemen dar. Die Veränderung der Leistungsfaktoren in einem Tuningzyklus darf freilich kein ungeregeltes Probieren sein. Die Entscheidung über die Auswahl, Reihenfolge und Größe der in einem Tuningzyklus zu verändernden Leistungsfaktoren erfordert immer gute Systemkenntnisse sowie Informationen über die Anwendung und die Systemumgebung des Datenbanksystems.

Over-Tuning ist gefährlich

In diesem Zusammenhang muß noch auf die Gefahr des "Over-Tuning" hingewiesen werden, bei dem nur marginale Veränderungen bei überproportional steigendem Aufwand erzielt werden können. Hier muß der Verantwortliche aufgrund seiner Erfahrungen und Systemkenntnisse entscheiden, wann die Kette der iterativen Tuningprozesse abzubrechen ist.

Werden in einem Tuningzyklus mehrere Leistungsfaktoren gleichzeitig geändert, so können häufig Wechselwirkungen der verschiedenen Leistungsänderungen nicht mehr auseinandergehalten werden, und es besteht die Gefahr von Fehlinterpretationen. In einem Tuningzyklus sollte daher nur ein einziger Leistungsfaktor oder nur eine Gruppe unmittelbar zusammenhängender Leistungsfaktoren (wie Blocklänge und zugehörige Puffergröße) geändert werden.

Exakte Vergleichsmessungen der Auswirkungen einzelner Leistungsfaktoren setzen voraus, daß alle anderen Systembedingungen wie der Hintergrundverkehr auf dem Rechnersystem während dieser Messungen annähernd konstant gehalten werden. Diese Forderung muß speziell bei Feintuning erfüllt sein, da sonst wegen der zahlreichen unkontrollierbaren Einflußfaktoren keine objektiven Vergleiche mehr möglich sind. In der Praxis bedeutet dies meist, daß für solche Messungen entweder eine eigene Testmaschine zur Verfügung stehen muß, oder aber daß die Messungen in einer Schicht außerhalb des Produktionsbetriebes vorgenommen werden müssen.

Meßwerkzeuge können Ergebnisse verfälschen

Alle eingesetzten Meßprogramme beanspruchen Betriebsmittel des Systems, da während der Meßperiode Zeiten gemessen, Aktivitäten gezählt und diese Werte häufig in Dateien protokolliert werden. Je nach Beanspruchung der Betriebsmittel können dadurch die Meßergebnisse erheblich verfälscht werden.

Grundsätzlich sollte stets versucht werden, Daten voll auszuwerten, die vom System, unabhängig von den Tuningaktivitäten, fortgeschrieben werden. Ein Beispiel dafür ist das bei vielen Online-Datenbanksystemen obligate Logband, das dem Wiederanlauf nach einem System- oder Programmabsturz dient. Damit können zum Beispiel Leistungsdaten über Datenbankzugriffe oder Nachrichtenaktivitäten gewonnen werden. Leider bieten aber nur wenige Datenbankhersteller hierfür entsprechende Auswertungssoftware an.

Eine sinnvoll aufgebaute Checkliste zur Überprüfung der Leistungsdaten eines Datenbanksystems kann viel dazu beitragen, den Leistungsverbesserungsprozeß effektiver zu gestalten. Bei sorgfältiger Planung kann eine Checkliste sowohl eine Konzentration auf die wesentlichen Leistungsdaten als auch die Einhaltung einer sinnvollen Meßreihenfolge (Grobtuning, Feintuning) bewirken. Dies trifft insbesondere auf die Leistungsmessungen des DB/DC-Teils eines Datenbanksystems zu. Eine solche Checkliste sollte zunächst die zentralen Systembetriebsmittel enthalten und hier wiederum zunächst die Auslastung der E/A-Konfiguration, da hier unseren Erfahrungen nach der überwiegende Teil echter Leistungsengpässe (Kanalbelegung, Auslastung der Steuer-und Direktzugriffseinheiten) zu suchen ist.

Im folgenden Beispiel nun wird gezeigt, wie ein interaktiver Leistungsverbesserungsprozeß von Datenbank-und Anwendungskomponenten eines IMS/VS-Systems nach Beseitigung der Leistungsmängel neutraler Systembetriebsmittel aussehen kann. Zur besseren Veranschaulichung werden nur die Zeitkomponenten "Warten der Nachricht in einer Eingabewarteschlange" (4), "Bereitstellen der IMS Betriebsmittel zur Nachrichtenverarbeitung durch ein Programm" (5), "Bereitstellen des Anwendungsprogramms zur Nachrichtenverarbeitung" (6) und "Verweilzeiten des Anwenderprogrammes zur Verarbeitung der Nachricht" (7) aus Abbildung 1 betrachtet. Alle anderen Zeitkomponenten bleiben unberücksichtigt. Die Prozentangaben beziehen sich nur auf diese vier Komponenten.

Wir gehen von einer Ausgangssituation aus, die durch die unten angegebenen Messungen charakterisiert ist. Anschließend stellen wir eine Theorie darüber auf, welche Einflußgrößen zu verändern sind, um die Zeitkomponenten zu verkleinern. Diese Änderungen werden durchgeführt, die Ergebnisse gemessen und analysiert, und es wird wiederum eine Theorie über die Verkürzung der Zeitkomponenten aufgestellt. Dieser iterative Leistungsverbesserungsprozeß wird solange fortgeführt, bis sich keine nennenswerten Verbesserungen mehr erzielen lassen.

(a) Ausgangssituation

- Messung der Zeitkomponenten (Ablaufzeiten, in Klammern: Prozent)

Komponente 4: 1988 ms (51,7)

Komponente 5: 17 ms ( 0,4)

Komponente 6: 31 ms ( 0 8)

Komponente ö7: 1810 ms (47,1)

Total: 3846 ms

- Analyse

Die beiden dominierenden Zeitkomponenten (mit 98 Prozent der Ablaufzeit) sind 4 und 7. Es soll zunächst versucht werden, die auffallend hohe Zeit für das Warten einer Nachricht in der Eingabewarteschlange zu reduzieren (Komponente 4).

- Theorie

Die Eingabenachrichten stehen deshalb so lange in der Warteschlange, weil sie nicht schnell genug von den Nachrichtenverarbeitungsprogrammen abgeholt werden können. Es wird deshalb eine zusätzliche OS-Regelung für die Nachrichtenverarbeitungsprogramme zur Verfügung gestellt.

(b) Lauf 1 (nach Durchführung obiger Änderung)

- Komponente 4: 620 ms (21,8)

Komponente 5: 20 ms ( 0,7)

Komponente 6: 51 ms ( 1,8)

Komponente 7: 2150 ms (75,8)

Total: 2841 ms

- Analyse

Die Zeitkomponente 4 wurde um 1,4 Sekunden verringert. Sie ist mit jetzt 21,8 Prozent nicht mehr so dominierend wie vorher. Die Zeitkomponenten 6 und 7 sind jedoch etwas größer geworden. Die Ursache liegt vermutlich darin daß sich eine weitere OS-Region um Betriebsmittelzuweisung bemüht und damit der Verwaltungsaufwand höher wird,

Als nächstes soll versucht werden, die Ablaufzeit für die Zeitkomponente 7 zu verringern.

- Theorie

Ein Blick auf die Datenbankpufferstatistik zeigt, daß sehr viele externe E/A-Zugriffe durchgeführt werden. Es ist zu vermuten, daß diese Zahl durch Vergrößerung der Datenbankpuffer verringert werden kann.

(c) Lauf 2

- Komponente 4: 620 ms(27,3)

Komponente 5: 20 ms(09)

Komponente 6: 51 ms(2,2)

Komponente 7:1590 ms(69,6)

Total: 2271 ms

- Analyse

Durch die Verringerung der Zahl der externen E/A-Zugriffe wurde die Ablaufzeit der Komponente 7 um 1,6 Sekunden verkleinert.

Mit Lauf 2 soll die Demonstration der iterativen Vorgehensweise zur Leistungsverbesserung in unserem Beispiel beendet werden.

Bei zahlreichen Problemen der Praxis werden, abweichend von unserem Beispiel, mehr Testläufe zur Leistungsverbesserung notwendig sein. Wichtig ist, daß eine effektive Leistungsverbesserung des Gesamtsystems nur durch eine Verkürzung der Verweilzeiten solcher Transaktionen erzielt werden kann, die häufig vorkommen und deren Zeitkomponenten kritische Werte übersteigen.