Leistungsüberwachung von Datenbanken: Ein umfassender Leitfaden mit ST04

Die Überwachung der Datenbankleistung ist entscheidend für die reibungslose Funktion von IT-Systemen. Das Tool ST04 spielt hierbei eine zentrale Rolle, indem es detaillierte historische Daten und Statistiken liefert, die zur Bewertung der Datenbankleistung und zur Identifizierung von Optimierungspotenzialen dienen. Diese Analyse kann sowohl aus Anwendungs- als auch aus Systemperspektive erfolgen.

Kernindikatoren für Datenbankleistung

Um die Effizienz einer Datenbank zu beurteilen, werden verschiedene Schlüsselmetriken herangezogen:

• Data Buffer Cache: Die Qualität dieses Caches sollte über 95 % liegen. Eine hohe Qualität bedeutet, dass Daten primär aus dem Speicher gelesen werden können, was physische Lesevorgänge von der Festplatte reduziert und die Zugriffszeiten erheblich verkürzt.
• Benutzer-/Rekursionsaufrufe: Ein Verhältnis von Benutzeraufrufen zu Rekursionsaufrufen von mehr als 2 ist wünschenswert. Hohe Rekursionsaufrufe können mit der Zeit zunehmen und die Leistung beeinträchtigen.
• Lesevorgänge/Benutzeraufruf: Dieser Wert sollte unter 30 liegen. Ein Wert darüber deutet auf teure SQL-Anweisungen hin, die optimiert werden müssen.
• Zeit/Benutzeraufruf: Idealerweise sollte dieser Wert unter 15 ms liegen, um eine schnelle Reaktion auf Benutzeranfragen zu gewährleisten.
• Auslastungszeit & CPU-Zeit: Ein Verhältnis von 60:40 zugunsten der Auslastungszeit weist auf eine gute Systemauslastung hin. Ein höheres Verhältnis zur CPU-Zeit kann auf Optimierungsbedarf hindeuten.
• Sortierbereiche: Der Anteil von Sortierungen, die auf der Festplatte durchgeführt werden, sollte weniger als 0,1 % aller Sortierungen betragen. Sortierungen im Hauptspeicher sind deutlich schneller.
• Shared Pool-Statistiken: Die Qualität des DD-Cache (Data Dictionary Cache) sollte über 99 % liegen. Ebenso sollte die Abrufquote (Get Ratio) für SQL-Bereiche hoch sein, um die Wiederverwendung von geparsten SQL-Anweisungen zu maximieren.
• Instanzleistung: Das Verhältnis von Soft- zu Hard-Parses (Soft Parse Ratio) sollte so nah wie möglich an 1 liegen. Ein hoher Wert bedeutet, dass bereits geparste SQL-Anweisungen wiederverwendet werden, was die CPU-Last reduziert.

ST04 Performance Overview

Detaillierte Analyse wichtiger Speicherbereiche

Data Buffer

Der Data Buffer ist ein Speicherbereich, der Datenbankdaten und -blöcke zwischenspeichert, um zukünftige Zugriffe aus dem Speicher zu ermöglichen. Dies ist deutlich schneller als der Zugriff auf die Festplatte.

• Größe (Size): Gibt die konfigurierte Speichergröße an.
• Qualität (Quality / Hit Ratio): Zeigt an, wie oft eine angeforderte Dateneinheit im Speicher gefunden wird (in Prozent). Eine hohe Qualität reduziert physische I/Os.
• Lesevorgänge (Reads): Summe der Speicher- und Festplattenzugriffe seit dem Start der Datenbank.
• Physische Lesevorgänge (Physical Reads): Gesamtzahl der Zugriffe auf die Festplatte.
• Buffer Busy Wait: Tritt auf, wenn eine Sitzung auf einen Datenbankblock zugreifen möchte, dieser aber gerade von einer anderen Sitzung genutzt wird. Dies deutet auf eine hohe gleichzeitige Zugriffsrate auf dieselbe Datentabelle hin.

Für eine optimale Leistung wird eine Pufferqualität von über 95 % empfohlen. Zur Verbesserung sollten teure SQL-Anweisungen analysiert und optimiert oder die Größe des Data Buffers erhöht werden. Hohe Hit Ratios können jedoch auch durch häufig ausgeführte SQL-Abfragen entstehen, die Daten aus dem Puffer beziehen.

Shared Pool

Dieser Speicherbereich dient zur Speicherung von ausführbaren SQL-Code-Versionen und Datenbankobjekten. Sein Ziel ist die Wiederverwendung von geparsten SQL-Anweisungen und die Vermeidung von Festplattenzugriffen für Datenbankobjekte.

• DD-Cache Quality: Misst, wie oft ein angefordertes Datenobjekt im Cache gefunden wird. Der Data Dictionary Cache speichert Informationen über Datenbankobjekte wie Namen und Definitionen. Eine Qualität von über 98 % ist in Produktionssystemen empfehlenswert.
• SQL Area Get/Pin Ratio: Zeigt an, wie oft geparste SQL-Anweisungen im SQL-Bereich des Shared Pools gefunden werden. Eine Quote von über 99 % ist für Produktionssysteme erstrebenswert. Andernfalls sollte eine Erhöhung der Shared Pool-Größe in Betracht gezogen werden.

Log Buffer

Der Log Buffer ist ein zirkulärer Speicherbereich, der Datenbankänderungen aufzeichnet, bevor sie in Log-Dateien geschrieben werden.

• Größe (Size): Zeigt die Speichergröße des Log Buffers an.
• Einträge (Entries): Gesamtzahl der Redo-Einträge seit dem Datenbankstart.
• Allocation Retries & Allocation Fault Rate: Zeigen fehlgeschlagene Versuche, freien Speicherplatz im Redo Log Buffer zuzuweisen, und deren Verhältnis.
• Redo Log Wait & Log Files: Informieren über Wartezeiten und die Anzahl der für die Wiederherstellung verwendeten Log-Dateien.

Wenn die Anzahl der fehlgeschlagenen Zuweisungsversuche hoch ist, muss das LOG_BUFFER_WAIT-Ereignis weiter untersucht werden. Mögliche Abhilfemaßnahmen sind die Vergrößerung des Redo Log Buffers und/oder die Optimierung des I/O-Systems.

Datenbankoperationen und Zeitstatistiken

Aufrufe (CALL)

Dieser Abschnitt liefert wichtige Statistiken über den Datenbankbetrieb:

• Aufrufe (Calls): Gesamtzahl der Benutzeraufrufe seit dem Datenbankstart.
• Commits: Gesamtzahl der abgeschlossenen Transaktionen.
• Rollbacks: Anzahl der zurückgerollten Transaktionen.
• Rekursive Aufrufe (Recursive Calls): Anzahl der rekursiven Aufrufe. Das Verhältnis von rekursiven Aufrufen zu Benutzeraufrufen sollte in einer produktiven Umgebung kleiner als 1:5 sein.
• Parses: Gesamtzahl der geparsten SQL-Anweisungen. Die Rate von Parses zu Benutzeraufrufen sollte unter 25 % liegen.
• Lesevorgänge / Benutzeraufrufe (Reads / User Calls): Zeigt die durchschnittliche Anzahl der aus dem Data Buffer gelesenen Oracle-Blöcke zur Beantwortung von Benutzeranfragen. Ein Wert über 30 deutet auf “teure” SQL-Anweisungen hin, die optimiert werden müssen.

Zeitstatistiken (TIME STATISTICS)

Diese Statistiken fassen die Wartezeiten der Datenbank zusammen. Wartezeiten selbst verbrauchen keine Ressourcen, sind aber ein Ergebnis von Ressourcenkonflikten und sollten nach Möglichkeit behoben werden.

• Busy Wait Time: Kumulative Zeit, die durch das Warten auf nicht verfügbare Ressourcen entstanden ist. Hohe Werte erfordern eine detaillierte Analyse mittels Oracle Wait Event Analysis.
• CPU-Zeit (CPU Time): Gesamte CPU-Zeit seit dem Datenbankstart.
• CPU-Auslastung (CPU Usage): Durchschnittliche CPU-Auslastung.

Bei der CPU-Auslastung sind nicht nur die absoluten Werte wichtig, sondern auch die prozentuale Veränderung über die Zeit. Signifikante Änderungen können auf Probleme hindeuten und erfordern eine genauere Untersuchung.

Redo Logging, Tabellenscans und Sortierungen

Redo Logging

Hier finden sich Informationen zur Leistung der Redo-Log-Ausgabe.

Tabellenscans & Fetches

Dieser Abschnitt liefert zusammenfassende Informationen über sequentielle Lesevorgänge und zeilenweise Verarbeitung (z.B. durch Indizes). Sequentielle Lesevorgänge auf langen Tabellen sollten vermieden werden.

• Short Tables: Anzeigt die Gesamtzahl sequentieller Lesevorgänge auf kleinen Tabellen (weniger als 5 Oracle-Datenblöcke).
• Long Tables: Zeigt sequentielle Lesevorgänge auf großen Tabellen (5 oder mehr Oracle-Datenblöcke).
• Fetch By Row ID: Anzahl der Zeilen, die über einen Index oder eine eindeutige ID (ROWID) abgerufen wurden.
• Continued Row: Anzahl der abgerufenen verketteten Zeilen.

Bei einer hohen Anzahl von “Continued Row”-Fetches sollte die Index- und Tabellenfragmentierung analysiert und gegebenenfalls eine Reorganisation durchgeführt werden. Für kurze Tabellen kann ein sequentieller Lesevorgang besser sein als ein Index-Scan. Bei langen Tabellen ist ein Index-Scan in der Regel vorteilhafter, es sei denn, eine sehr große Anzahl von Datensätzen wird benötigt.

Sortierungen (SORTS)

Hier werden die Gesamtzahl der Sortieroperationen im Hauptspeicher und auf der Festplatte angezeigt.

• Memory: Anzahl der Sortierungen im Hauptspeicher (schneller).
• Disk: Anzahl der Sortierungen, die temporär in den Tablespace PSAPTEMP geschrieben wurden (langsamer).

Idealerweise sollten Sortierungen im Hauptspeicher erfolgen. Das Verhältnis von Festplatten- zu Hauptspeichersortierungen sollte unter 5 % liegen. Andernfalls sollte der Oracle-Parameter SORT_AREA_SIZE erhöht werden.

Empfehlung

Die Analyse der Datenbankleistung ist ein vielschichtiger Prozess, der eine kontinuierliche Überwachung und detaillierte Untersuchung verschiedener Metriken erfordert. Die hier vorgestellten Indikatoren und die Nutzung von Tools wie ST04 bieten eine solide Grundlage, um Engpässe zu identifizieren und die Performance Ihrer Datenbanken effektiv zu optimieren.