Database Reference
In-Depth Information
Ab Oracle Release 10.2 gibt es einen Parameter
_enable_reliable_latch_waits
, mit dem
man das Verfahren der Latch-Erwerbung steuern kann. Ist dieser Parameter auf TRUE
gesetzt (das ist der Vorgabewert), so wird das Verfahren ohne den exponentiellen Backoff
für das Erwerben der Latches eingesetzt. Mit dem Wert FALSE kehrt man auf das alte Ver-
fahren zurück, was generell nicht empfehlenswert ist.
Die Wartezeitstatistik für die einzelnen Latches wurde in Oracle 9i eingeführt. Sie wird
in Millisekunden gemessen und in der Spalte WAIT_TIME abgespeichert (s. die View
V$LATCH). Vor der Oracle Version 9i konnte man die problematischen Latches nur indi-
rekt anhand der anderen Latch-Statistiken ermitteln (z. B. anhand der Anzahl der Sleeps).
3.2.3.8.1 Latch „shared pool“ (latch: shared pool)
Dieses Latch wird benutzt beim Allozieren und beim Deallozieren des Speichers im Sha-
red Pool. Das Allozieren des Speichers erfolgt beispielsweise bei einem harten Parse Call.
Aus diesem Grund hilft die Reduzierung des harten Parsings beis der Reduzierung der
Wartezeit für dieses Latch. Da die harten Parse Calls sehr häufig durch die Literalen in den
SQL-Anweisungen verursacht werden, kann man das Skript top_sql_with_literals102.sql
für die Ermittlung solcher SQL-Anweisungen zwecks Reduzierung der Wartezeit für das
Latch „shared pool“ benutzen (s. den Abschn. 5.2). Bei Oracle, bis einschließlich Release
8.1, gab es ein einziges Latch „shared pool“. Ab Oracle Version 9 gibt es mehrere Subpools
im Shared Pool (maximal 7). Die Anzahl dieser Subpools wird durch die Parameterein-
stellung
_kghdsidx_count
festgelegt. Dieses Feature ist extra für die Reduzierung der Warte-
zeit für das Latch „shared pool“ eingeführt, da jeder Subpool mit einem separaten Latch
„shared pool“ verwaltet wird.
3.2.3.8.2 Latch „library cache“ (latch: library cache)
Dieses Latch hat Oracle in den Versionen vor 11 zum Schützen der Strukturen im Library
Cache benutzt. Die Wartezustände für dieses Latch wurden in der Regel durch die Konkur-
renz um diese Strukturen beim Parsen verursacht. In der Version 11 hat Oracle das Latch
„library cache“ durch die jeweiligen Mutexes ersetzt (Mutexes sind im Abschn. 3.2.3.9 be-
schrieben).
3.2.3.8.3 Latch „cache buffers chains“ (latch: cache buffers chains)
Die Buffer-Headers werden im Buffer Cache in den Listen („hash chains“) verwaltet. Jede
solche Liste hängt an einem so genannten „hash bucket“. Zum Schutz der Buffer-Hea-
ders benutzt Oracle „cache buffers chains“-Latches. Vor Oracle Version 8i war die Anzahl
der „hash buckets“ (oder der „hash chains“) gleich der Anzahl der Latches „hash buffers
chains“. Ein Latch hat also genau eine Liste geschützt. Ab Oracle Version 8i kann ein Latch
mehrere Listen schützen. Oracle hat die Anzahl dieser Latches in der Version 8i reduziert,
aber die Anzahl der „hash buckets“ dafür vergrößert und somit die Längen der Listen
„hash chains“ wesentlich verkleinert. Die Anzahl der Latches „cache buffers chains“ wird
durch den Parameter
_db_block_hash_latches
festgelegt, die Anzahl der „hash buckets“
durch den Parameter
_db_block_hash_buckets
.
