Database Reference
In-Depth Information
Datenbankstatistiken aus der View V$SYSSTAT seit dem letzten Instanz-Start berechnen.
Es ist auch möglich, die Dauer eines Log-Write anhand der Datenbankstatistiken aus dem
AWR oder aus dem Statspack-Repository für ein bestimmtes Zeitintervall zu schätzen.
Wenn der Log-Writer performant ist, hat das System normalerweise keine gravierenden
Wartezeiten auf „log file sync“.
3.2.3.6 log file switch (checkpoint incomplete)
Der Logwriter wechselt auf das neue Redolog, muss aber warten, da der Checkpoint für
dieses Redolog noch nicht fertig ist. Weil das Schreiben der geänderten (dirty) Datenblöcke
aus dem Buffer Cache bei den Checkpoints vom DB-Writer gemacht wird, kann es theore-
tisch auch ein Zeichen für die unzureichende Performanz der DB-Writer sein. In der Praxis
ist dieses Problem normalerweise wegen des häufigen Wechsels der Redologs passiert, so
dass der DB-Writer nicht ausreichend Zeit für die Durchführung der Checkpoints hat. Mit
dem Skript redolog_switch_history_html8i.sql kann man die Anzahl der Log-Switches pro
Stunde ermitteln. Wenn diese Anzahl hoch ist, muss man die Redologs vergrößern.
3.2.3.7 Enqueues
Oracle verwendet Enqueues (oder Locks) um die Zugriffe zu den verschiedenen Ressour-
cen zu steuern. Im Vergleich zu den Latches werden die Enqueues normalerweise länger
gehalten. Die Enqueues können mehrere Modi haben. Wenn eine Session ein Enqueue für
eine Ressource hält und die andere versucht, diese Ressource in einem nicht kompatiblen
Modus zu bekommen, muss sie auf die Freigabe des Enqueue in der ersten Session warten
(diese Freigabe erfolgt nach dem Beenden der jeweiligen Transaktion). Es gibt ziemlich
viele Typen von Enqueues bei Oracle. Ich beschreibe hier kurz nur einige davon, mit denen
man häufig bei Performance Tuning zu tun hat.
3.2.3.7.1 TX - row lock contention
Dieses Enqueue verwendet Oracle bei DML-Operationen (DML bedeutet „data manipula-
tion langugage“). Ändert eine Session beispielsweise einen Tabellensatz, so wird dieser Satz
gesperrt, und eine andere Session muss auf die Freigabe dieser Sperre warten, wenn sie
denselben Satz auch zu ändern versucht. Diese Sperre wird entweder mit einem Commit
oder mit einem Rollback aufgehoben. Es wird dabei dabei auf „enq: TX - row lock con-
tention“ gewartet. Normalerweise sind die Wartezustände für dieses Warteereignis anwen-
dungsbedingt. Es ist aber auch möglich, dass solche Wartezustände durch inperformante
SQL-Anweisungen verursacht werden: in diesem Fall dauern die jeweiligen Transaktionen
länger (dementsprechend länger werden die in diesen Transaktionen erworbenen En-
queues nicht freigegeben).
3.2.3.7.2 TX - allocate ITL entry
Jede Transaktion macht einen Eintrag in die ITL (interested transaction list) bei einer
Datenänderung. Diese ITL befindet sich im Block-Header des jeweiligen Datenblocks. Die
Anfangsgröße der ITL für ein Segment bestimmt der Parameter INITRANS. Wenn dieser
Search WWH ::




Custom Search