Database Reference
In-Depth Information
• „cursor:pinS“,
• „cursor:pinX“,
• „cursor:pinSwaitonX“,
• „librarycache:mutexS“,
• „librarycache:mutexX“
Sie alle gehören zu der Klasse „Concurrency“ und haben dieselben 3 Parameter.
Parameter1 (idn) - Identifikator des Mutex. Dieser Identifikator ist der Hashwert eines
Objektes im Library Cache, das mit dem jeweiligen Mutex geschützt wird. Nach diesem
Objekt kann man entweder direkt in der internen Tabelle X$KGLOB über das Feld KGL-
NAHSH oder in der View V$DB_OBJECT_CACHE über das Feld HASH_VALUE suchen.
Wenn das jeweilige Objekt ein Cursor ist (im Falle der Mutex-Warteereignisse „cursor“),
kann man auch in der View V$SQL nach diesem Cursor suchen. Da die Spalte P1 für den
Parameter1 in den Views V$SESSION, V$ACTIVE_SESSION_HISTORY, DBA_HIST_
ACTIVE_SESS_HISTORY vorhanden ist, kann man anhand dieser Information die prob-
lematischen Objekte finden.
Parameter2 (value) - Mutex-Wert. Die höherwertigen Bytes enthalten die SID der Ses-
sion, die das Mutex im exklusiven Modus hält. Mit dem folgenden Select kann man diese
SID sowohl für die 32-bit- als auch für die 64-bit-Plattformen ermitteln:
VHOHFWGHFRGHWUXQFS!WUXQFS!
WUXQFS!IURPGXDO
Für das Warteereignis „cursor: pin S“ ist diese SID immer gleich 0, da es keine blockieren-
de Session für dieses Ereignis gibt.
Die niedrigeren Bytes enthalten einen Zähler der Sessions, die das jeweilige Mutex im
„shared“ Modus halten.
Parameter3 (where) - eine Location Id. Die höherwertigen Bytes enthalten eine Loca-
tion Id, die eine Stelle (Funktion) im Code von Oracle identifiziert, wo das jeweilige Mutex
erworben wird.
Bei der Analyse der Probleme mit Mutexes sind die folgenden 2 Views hilfreich:
V$MUTEX_SLEEP und V$MUTEX_SLEEP_HISTORY. Die erste View enthält die kumu-
lativen Statistiken (die Anzahl der „sleeps“ und die gesamte Wartezeit für jeden Mutex-Typ
und Location). Die zweite View enthält historische Statistiken und wird zyklisch über-
schrieben.
In [6] hat man mit dem Mutex „cursor: pin S“ experimentiert und festgestellt, dass
Oracle eine ziemlich aggressive Strategie beim Erwerben des Mutex in Releases 10.2- 11.1
benutzt hat. Beim Erwerben des Mutex hat Oracle ausschließlich „spins“ gemacht und
ab und zu den CPU mit dem System Call yield() losgelassen. Dies führte zu einer hohen
CPU-Auslastung, die Mutex-Wartezeiten waren dabei sehr niedrig.
