Database Reference
In-Depth Information
das jeweilige Latch und sogar das jeweilige Child-Latch ermitteln. Das ist besonders wich-
tig für die Latches, die sich immer noch unter dem Warteereignis „latch free“ verbergen.
Da die Operationen auf den SGA-Strukturen sehr schnell sein sollen, sind die Latches
so konzipiert, dass sie sehr schnell zu erwerben und sehr schnell wieder freizugeben sind.
Aus diesem Grund sind sie so implementiert, dass keine Deadlocks möglich sind. Dafür
benutzt Oracle sogenannte Latch-Levels (s. die View V$LATCH). Wenn das Erwerben der
Latches in einer aufsteigenden Reihenfolge der Latch-Levels erfolgt, besteht keine Gefahr
der Deadlocks, und ein Prozess, der ein nicht freigegebenes Latch zu erwerben versucht,
kann das beliebig lange tun („willing-to-wait“ Modus). Wenn ein Prozess aber ein Latch
des gleichen oder eines niedrigeren Levels zu erwerben versucht (als der maximale Level
der bereits erworbenen Latches), kann er in eine Deadlock-Situation hineinlaufen, wenn
er diese Versuche unendlich wiederholt oder unendlich lange auf die Freigabe des Latch
wartet. Aus diesem Grund versucht Oracle das nur einmal in dem „no-wait“ Modus. Ge-
lingt es, wird die Verarbeitung fortgesetzt. Wenn es nicht gelingt, werden alle bereits er-
worbenen Latches freigegeben, und der Prozess versucht sie erneut zu erwerben.
In [1] und in [2] unterscheidet man 2 Arten von Latches („short-wait“- und „long-
wait“-Latches) in Bezug auf die Methode der Erwerbung der Latches. Wenn es nicht ge-
lingt, ein „short-wait“-Latch sofort zu erwerben, macht Oracle zunächst eine kleine rech-
nerische Schleife (spin), um den jeweiligen CPU nicht loszulassen, und wiederholt danach
den Erwerbsversuch. Die maximale Anzahl solcher Versuche ist mit der Parameterein-
stellung
_
spin
_
count
festgelegt. Ist diese maximale Anzahl erreicht und es hat wieder nicht
gelungen, das jeweilige Latch zu erwerben, wird der CPU losgelassen (mit dem System
Call „yield()“) und der Prozess verfällt in Schlaf (sleep). Die jeweilige Schlafzeit wird sich
bei jedem zweiten Sleep verdoppeln (das exponentielle Backoff ): 1,1, 2, 2, 4, 4, 8, 8, …. Die
maximale Schlafzeit wird in Hundertstelsekunden mit dem Parameter
•
_
max
_
exponential
_
sleep
festgelegt, wenn der jeweiliger Prozess keine Latches hält,
•
_
max
_
sleep
_
holding
_
latch
festgelegt, wenn der jeweilige Prozess bereits mindestens
ein Latch hält.
Bei den „long-wait“-Latches können Prozesse aus dem Schlaf geweckt werden (latch wait
posting), wenn das jeweilige Latch freigegeben wird. In Oracle 8i gab es lediglich 2 „long-
wait“-Latches: „library cache“ und „shared pool“. Beim Lesen von [1] und [2] ist nicht klar,
ob ein Prozess beliebig lange im Schlaf auf die Freigabe dieser Latches warten kann. In [3]
hat man gezeigt, dass Oracle 8i für das Erwerben von „long-wait“-Latches eine Kombina-
tion vom exponentiellen Backoff und „latch wait posting“ verwendet.
In [3] hat man auch experimentell bewiesen, dass die Methode mit dem exponentiellen
Backoff ab Oracle Release 9.2 lediglich für ein einziges Latch „process allocation“ verwen-
det wird. Für die restlichen Latches benutzt Oracle das exponentielle Backoff nicht. Beim
Versuch, diese Latches zu erwerben, setzt man einmal „spins“ ein, gelingt das nicht, so ver-
fält der jeweilige Prozess in Schlaf, solange er bei der Latch-Freigabe nicht geweckt wird.
Das stimmt mit meinen Beobachtungen überein. Ab Oracle 9.2 beobachte ich wesentlich
weniger „latch sleeps“.
