Oracle Datenbank-Tuning - Teil 4

Performance des Redo Log Buffers

Wenn die Datenbank im ARCHIVELOG-Modus läuft, kopiert der Hintergrundprozess ARCH die Online Redo Log-Dateien in ein Archiv. In folgender Abbildung sehen Sie die Architektur des Redo Log-Mechanismus.

Ein Weg zum Messen der Performance des Redo Log Buffers ist, die Häufigkeit und die Länge von Warte-Ereignissen der Server-Prozesse zu ermitteln. Für diese Statistiken stehen die Views V$SYSSTAT und V$SESSION_EVENT zur Verfügung.

In V$SYSSTAT werden alle relevanten Statistiken des Redo Log Buffers aufgezeichnet. Der Wert für redo entries spiegelt die Anzahl von Einträgen in den Redo Log Buffer durch Server-Prozesse seit dem Start der Instanz wider. Die Statistik redo buffer allocation retries ist die Anzahl von Wiederholungen, die der Server-Prozess gestartet hat, um Daten im Redo Log Buffer zu platzieren. Die Abfrage in folgendem Listing ermittelt die Retry Ratio des Redo Log Buffers.

SQL> SELECT a.value/b.value "Retry Ratio"
2 FROM v$sysstat a, v$sysstat b
3 WHERE a.name='redo buffer allocation retries'
4 AND b.name='redo entries';
Retry Ratio
-----------
,00009602

Im Idealfall würde der Server-Prozess nie warten, um Blöcke in den Redo Log Buffer zu schreiben. Ein starkes Anwachsen der Retry Ratio ist ein Indiz dafür, dass der Redo Log Buffer optimiert werden muss.

Die Retry Ratio des Log Buffers sollte weniger als ein % betragen. Ist sie größer, muss der Redo Log Buffer vergrößert werden.

Die Statistik redo log space requests misst, wie oft der LGWR-Prozess auf einen Log Switch warten musste.

SQL> SELECT name, value
2 FROM v$sysstat
3 WHERE name='redo log space requests';
NAME VALUE
-------------------------------------- -----
redo log space requests 6