Oracle Locking Mechanism – Latches & Enqueues

X

Datenschutz & Cookies

Diese Seite verwendet Cookies. Indem Sie fortfahren, stimmen Sie deren Verwendung zu. Erfahren Sie mehr, einschließlich der Kontrolle von Cookies.

Verstanden!

Advertisements

Dieser Artikel ist Teil der Oracle Performance Tuning-Serie und wurde erstellt, um den Verriegelungsmechanismus von Oracle zu beschreiben.

Eine Sperre ist eine Ressource, die Sie halten müssen, um Zugriff auf die Ressource zu erhalten. Oracle hat zwei Arten von Schlössern: Enqueues und Latches, wir würden uns jetzt einzeln auf diesen Verriegelungsmechanismus konzentrieren.

Enqueues

Enqueues sind komplexe Sperren zum Verwalten des Zugriffs auf gemeinsam genutzte Ressourcen (wie Tabellen, Zeilen, Jobs, Redo-Threads). Eine Enqueue kann in verschiedenen Ebenen/Modi angefordert werden:

  • Null
  • Row share
  • Row exclusive
  • Share
  • Share row exclusive
  • Exclusive

Wenn eine Sitzung eine Enqueue im Freigabemodus enthält, können andere Sitzungen dann auch die enqueue im Freigabemodus (für die gleiche Ressource). Wenn eine Sitzung eine Enqueue im exklusiven Modus enthält, müssen andere Sitzungen, die sie erhalten möchten – unabhängig davon, in welcher Ebene – warten.

Wenn für eine Sitzung Zugriff erforderlich ist, wird eine Sperrstruktur abgerufen und eine Anforderung zum Abrufen des Zugriffs auf die Ressource auf einer bestimmten Ebene (Modus) gestellt. Die Sperrstruktur befindet sich in einer von drei verknüpften Listen, die von der Ressource abhängen, genannt OWNER (wenn die Enqueue erworben werden könnte), WAITER (wenn die Sitzung darauf wartet, die Enqueue zu erhalten) und CONVERTER (die Sitzung hält die Enqueue in einer Ebene, möchte sie aber in eine andere konvertieren).

Im Folgenden finden Sie einige gängige Arten von Warteschlangen:-

  • TM – Jedes Mal, wenn eine Sitzung eine Tabelle sperren möchte, wird eine TM-Warteschlange angefordert. Wenn eine Sitzung eine Zeile in der übergeordneten Tabelle löscht und eine referenzielle Einschränkung (Fremdschlüssel) ohne Index für die untergeordnete Tabelle erstellt wird oder wenn die Sitzung die Spalten aktualisiert, auf die der Fremdschlüssel verweist, wird eine Freigabesperre für die untergeordnete Tabelle erstellt. Wenn eine andere Sitzung versucht, Änderungen an der untergeordneten Tabelle vorzunehmen, müssen sie warten (da sie die Warteschlange im Zeilenexklusivmodus haben möchten und dies nicht mit dem Freigabemodus kompatibel ist).
  • TX – Sobald eine Transaktion gestartet wird, wird eine TX-Warteschlange benötigt. Eine Transaktion wird eindeutig durch die Rollback-Segmentnummer, die Slot-Nummer in der Transaktionstabelle des Rollback-Segments und die Sequenznummer der Slot-Nummer definiert. Eine Sitzung kann aus mehreren Gründen auf eine TX-Warteschlange warten:
    1. Eine andere Sitzung sperrt die angeforderte Zeile
    2. Wenn zwei Sitzungen versuchen, denselben eindeutigen Schlüssel in eine Tabelle einzufügen (keine von ihnen hat einen COMMIT ausgeführt), wartet die letzte Sitzung darauf, dass die erste festgeschrieben oder zurückgesetzt wird.
    3. Es gibt keine freie ITL (Interested Transaction List) im Blockheader.
  • UL – Eine Sitzung wurde mit DBMS_LOCK gesperrt.ANFRAGE-Funktion.

Latches

Latches bieten einen Low-Level-Serialisierungsmechanismus, der gemeinsam genutzte Datenstrukturen im SGA schützt. Ein Riegel ist eine Art Schloss, das sehr schnell erworben und freigegeben werden kann. Latches werden normalerweise verwendet, um zu verhindern, dass mehr als ein Prozess denselben Code zu einem bestimmten Zeitpunkt ausführt. Wenn ein Latch erfasst wird, wird er auf einer bestimmten Ebene erfasst, um Deadlocks zu vermeiden. Sobald ein Prozess einen Latch auf einer bestimmten Ebene erfasst, kann er anschließend keinen Latch auf einer Ebene erfassen, die gleich oder kleiner als diese Ebene ist (es sei denn, er erfasst ihn nowait ). Jedem Latch ist eine Bereinigungsprozedur zugeordnet, die aufgerufen wird, wenn ein Prozess abbricht, während der Latch gehalten wird. Diese Reinigung erfolgt mit den Diensten von PMON. Die zugrunde liegende Implementierung von Latches ist betriebssystemabhängig, insbesondere im Hinblick darauf, ob und wie lange ein Prozess auf einen Latch wartet.

Das Ziel von Latches besteht darin, den gleichzeitigen Zugriff auf gemeinsam genutzte Datenstrukturen so zu verwalten, dass jeweils nur ein Prozess auf die Struktur zugreifen kann. Blockierte Prozesse (Prozesse, die darauf warten, einen Teil des Codes auszuführen, für den bereits ein Latch von einem anderen Prozess abgerufen wurde) warten, bis der Latch freigegeben wird. Oracle verwendet atomare Anweisungen wie „test and set“ für den Betrieb von Latches. Da die Anweisungen zum Setzen und Freigeben von Latches atomar sind, garantiert das Betriebssystem, dass nur ein Prozess sie erhält, und da es sich nur um eine einzige Anweisung handelt, ist sie ziemlich schnell.

Latch-Anfragen können in zwei Modi gestellt werden:

  • willing-to-wait : Eine „Willing-to-wait“ -Modusanforderung wird wiederholt, gewartet und erneut angefordert, bis der Latch erhalten wird.
  • no wait : Im Modus „no wait“ fordert der Prozess den Latch an, und wenn er nicht verfügbar ist, wird anstelle des Wartens ein anderer Latch angefordert. Nur wenn alle fehlschlagen, muss der Serverprozess warten.

Unterschied zwischen Riegeln & Enqueues

Ein Unterschied zwischen einem Riegel und einer Enqueue besteht darin, dass die Enqueue unter Verwendung eines betriebssystemspezifischen Verriegelungsmechanismus erhalten wird, während ein Riegel unabhängig vom Betriebssystem erhalten wird. Eine Enqueue ermöglicht es dem Benutzer, einen Wert in der Sperre zu speichern (dh den Modus, in dem wir ihn anfordern). Der OS Lock Manager verfolgt die gesperrten Ressourcen. Wenn ein Prozess der Sperre nicht gewährt werden kann, weil er mit dem angeforderten Modus nicht kompatibel ist und die Sperre mit wait angefordert wird, stellt das Betriebssystem den anfordernden Prozess in eine Warteschlange, die im FIFO bedient wird.

Ein weiterer Unterschied zwischen Latches und Enqueues besteht darin, dass Enqueues die Warteschlange der Kellner pflegen und ordnen, während Latches dies nicht tun. Alle Prozesse, die gleichzeitig auf einen Latch warten, versuchen es erneut (abhängig vom Scheduler). Dies bedeutet, dass jeder der Kellner die Verriegelung erhalten könnte und möglicherweise der erste, der versucht, die Verriegelung zu erhalten, der letzte sein könnte, der sie tatsächlich erhält. Latch-Kellner können entweder Timer verwenden, um aufzuwachen und es erneut zu versuchen, oder sie können sich drehen (nur in Multiprozessoren), indem sie sich auf einem Latch drehen (Halten der CPU und Warten in Erwartung, dass dieser Latch in kurzer Zeit freigegeben wird).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.