Rajat DBA’S Blog

Dies ist eine Kopie von Metalinks Referenznotiz 22908.1 für diejenigen, die keinen Zugriff darauf haben.

1. Was ist ein Riegel?
   Latches sind Low-Level-Serialisierungsmechanismen, die zum Schutz gemeinsam genutzter Datenstrukturen im SGA verwendet werden. Die Implementierung von Latches ist betriebssystemabhängig, insbesondere im Hinblick darauf, ob und wie lange ein Prozess auf einen Latch wartet.

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. Jedem Latch ist eine Bereinigungsprozedur zugeordnet, die aufgerufen wird, wenn ein Prozess abbricht, während der Latch gehalten wird. Verriegelungen haben eine zugeordnete Ebene, die verwendet wird, um Deadlocks zu verhindern. 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 ).

2.Latches vs. Enqueues

Enqueues sind eine andere Art von Verriegelungsmechanismus, der in Oracle verwendet wird.
Eine Enqueue ist ein ausgefeilterer Mechanismus, der es mehreren gleichzeitigen Prozessen ermöglicht, “bekannte” Ressourcen in unterschiedlichem Maße gemeinsam zu nutzen. Jedes Objekt, das gleichzeitig verwendet werden kann, kann mit Enqueues geschützt werden. Ein gutes Beispiel sind Sperren für Tabellen. Wir ermöglichen unterschiedliche Freigabestufen für Tabellen, z. B. können zwei Prozesse eine Tabelle im Freigabemodus oder im Freigabeupdatemodus usw. sperren. Ein Unterschied besteht darin, dass die Enqueue unter Verwendung eines betriebssystemspezifischen Verriegelungsmechanismus 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 einem Prozess die Sperre nicht erteilt 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 es in Latches keine geordnete Warteschlange von Kellnern wie in Enqueues gibt. Latch-Kellner können entweder Timer verwenden, um aufzuwachen und es erneut zu versuchen, oder sich drehen (nur bei Multiprozessoren). Da alle Kellner gleichzeitig versuchen (abhängig vom Scheduler), kann jeder den Riegel erhalten, und möglicherweise ist der erste, der es versucht, der letzte, der es bekommt.

1. Wann benötigen wir einen Riegel?

Ein Prozess erhält einen Latch, wenn er mit einer Struktur im SGA (System Global Area) arbeitet. Es hält den Riegel weiterhin für die Zeit, in der es mit der Struktur arbeitet. Der Riegel wird fallen gelassen, wenn der Prozess mit der Struktur abgeschlossen ist. Jeder Latch schützt einen anderen Datensatz, der durch den Namen des Latchs identifiziert wird.

Oracle verwendet atomare Anweisungen wie “test and set” für den Betrieb von Latches. 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. Beispiele sind Redo Allocation Latches, Copy Latches, archive Control Latch usw. Die Grundidee besteht darin, den gleichzeitigen Zugriff auf gemeinsam genutzte Datenstrukturen zu blockieren. Da die Anweisungen zum Setzen und Freigeben von Latches atomar sind, garantiert das Betriebssystem, dass nur ein Prozess sie erhält. Da es nur eine Anweisung ist, ist es ziemlich schnell. Verriegelungen werden für kurze Zeit gehalten und bieten einen Mechanismus zur Bereinigung, falls ein Halter beim Halten abnormal stirbt. Diese Reinigung erfolgt mit den Diensten von PMON.

1. Latches Anforderungsmodi?

Latches Anfrage kann in zwei Modi vorgenommen werden: “willing-to-wait” oder “no wait”. Normalerweise werden Latches im “Willing-to-wait” -Modus angefordert. Eine Anforderung im “Willing-to-wait” -Modus
wird eine Schleife durchlaufen, warten und erneut anfordern, bis der Latch erhalten wird. Im “no Wait” -Modus fordert der Prozess den Latch an. Wenn einer nicht verfügbar ist, anstatt zu warten, wird ein anderer angefordert. Nur wenn alle fehlschlagen, muss der Serverprozess warten.

Beispiele für “wartebereite” Latches sind: Shared Pool und library Cache Latches
Ein Beispiel für “no wait” Latches ist der Redo Copy Latch.

5. Was verursacht diese Auseinandersetzung?Wenn ein erforderliches Latch belegt ist, dreht sich der Prozess, der es anfordert, versucht es erneut und wenn es immer noch nicht verfügbar ist, dreht es sich erneut. Die Schleife wird bis zu einer maximalen Anzahl von Malen wiederholt, die durch den Initialisierungsparameter _SPIN_COUNT . Wenn nach dieser gesamten Schleife der Latch immer noch nicht verfügbar ist, muss der Prozess die CPU verlassen und in den Ruhezustand wechseln. Anfangs schläft für eine Zentisekunde. Diese Zeit wird in jedem nachfolgenden Schlaf verdoppelt.

Dies führt zu einer Verlangsamung und zu zusätzlicher CPU-Auslastung, bis ein Latch verfügbar ist. Die CPU-Auslastung ist eine Folge des “Spinnens” des Prozesses. “Spinnen” bedeutet, dass der Prozess nach bestimmten Zeitintervallen, in denen er schläft, weiterhin nach der Verfügbarkeit des Riegels sucht.

1. Wie erkenne ich Konflikte für interne Latches?

Relevante Datenwörterbuchansichten zum Abfragen:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

Jede Zeile in der V$LATCH-Tabelle enthält Statistiken für einen anderen Latchtyp. Die Spalten der Tabelle spiegeln die Aktivität für verschiedene Arten von Latch-Anforderungen wider. Der Unterschied zwischen diesen Arten von Anforderungen besteht darin, ob der anfordernde Prozess weiterhin einen Latch anfordert, wenn er nicht verfügbar ist:

Wartebereitschaft Wenn der mit einer Wartebereitschaft
angeforderte Latch nicht verfügbar ist, wartet der anfordernde Prozess
eine kurze Zeit und fordert den Latch erneut an.
Der Prozess wartet weiter und fordert an, bis
der Latch verfügbar ist.

keine Wartezeit Wenn der mit einer Sofortanforderung angeforderte Latch
nicht verfügbar ist, wartet der anfordernde Prozess nicht
, sondern setzt die Verarbeitung fort.

V$LATCHNAME Schlüsselinformationen:

RUFT die Anzahl der erfolgreichen Wartebereitschaftsanforderungen für
einen Latch ab.

Wie oft eine anfängliche Wartebereitschaftsanforderung
nicht erfolgreich war.

GIBT an, wie oft ein Prozess nach einer anfänglichen Wiling-to-Wait-Anforderung auf einen angeforderten Latch gewartet hat
.

IMMEDIATE_GETS Anzahl der erfolgreichen Sofortanforderungen für jeden Latch.

IMMEDIATE_MISSES Anzahl der erfolglosen Sofortanforderungen für jeden Latch.

Berechnung der Latch-Trefferquote

Um die Trefferquote für Latches zu erhalten, wenden Sie die folgende Formel an:

“bereit zu warten” Trefferquote=(GETS-MISSES)/GETS
“no wait” Trefferquote=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

Diese Zahl sollte nahe bei 1 liegen. Wenn nicht, stimmen Sie entsprechend dem Latch-Namen ab

1. Nützliche SQL-Skripte zum Abrufen von Latch-Informationen

/*
** Anzeige systemweiter Latch-Statistiken.
*/
Spaltenname Format A32 Überschrift “LATCH NAME” abschneiden
Spalte pid Überschrift “HOLDER PID”
auswählen c.name ,a.addr,a.gets,a.misses,a.sleeps,
a.immediate_gets,a.immediate_misses,b.pid
von v$latch a, v$latchholder b, v$latchname c
wobei a.addr = b.laddr(+)
und a.latch# = c.latch#
nach a.latch#;

/*
** Ermitteln Sie bei einer Latch-Adresse den Latch-Namen.
*/
Spaltenname Format a64 Überschrift ‘Name’
auswählen a.name von v$latchname a, v$latch b
wobei b.addr = ‘&addr’
und b.latch#=a.latch#;

/*
** Latch-Statistiken nach Latch-Namen anzeigen.
*/
Spaltenname Format a32 Überschrift ‘LATCH NAME’
Spalte pid Überschrift ‘HOLDER PID’
auswählen c.name ,a.addr,a.gets,a.misses,a.sleeps,
a.immediate_gets,a.immediate_misses,b.pid
von v$latch a, v$latchholder b, v$latchname c
wobei a.addr = b.laddr(+) und a.latch# = c.latch#
und c.name wie ‘&latch_name%’ order von a.latch#;

1. Liste aller Verriegelungen

Oracle-Versionen können sich in der den vorhandenen Verriegelungen zugewiesenen Verriegelungsnummer unterscheiden.
Die folgende Abfrage hilft Ihnen, alle Verriegelungen und die zugewiesene Nummer zu identifizieren.

Spaltenname Format a40 Überschrift ‘LATCH NAME’
Wählen Sie latch#, name aus v$latchname;

1. Liste der Latches, die für einen DBA am wichtigsten sind

• PUFFERCACHE-LATCHES: Es gibt zwei Haupt-Latches, die Datenblöcke im Puffercache schützen. Konflikte für diese beiden Latches treten normalerweise auf, wenn eine Datenbank hohe E / A-Raten aufweist. Wir können Konflikte für diese Latches reduzieren und sie optimieren, indem wir bestimmte init anpassen.ora-Parameter.

Cache-Puffer Ketten Latch:

Dieser Latch wird immer dann erfasst, wenn auf einen Block im Puffer-Cache zugegriffen wird (gepinnt).

Um Konflikte für die Cache-Pufferketten zu reduzieren, müssen normalerweise die logischen E / A-Raten reduziert werden, indem die E / A-Anforderungen des beteiligten SQL optimiert und minimiert werden. Hohe E / A-Raten können ein Zeichen für einen heißen Block sein (dh einen Block mit hohem Zugriff).

Siehe Anmerkung 163424.1 So identifizieren Sie einen Hotblock in der Datenbank, um dieses Problem korrekt zu identifizieren.

Cache-Puffer LRU-Kettenverriegelung:

Der Cache-Puffer LRU-Kettenverriegelung wird erfasst, um einen neuen Block in den Puffercache einzuführen und wenn ein Puffer zurück auf die Festplatte geschrieben wird, insbesondere wenn versucht wird, die LRU-Kette (least recently used) zu scannen, die alle schmutzigen Blöcke im Puffercache enthält.

Es ist möglich, Konflikte für den Cache-Puffer-LRU-Kettenverriegel zu reduzieren, indem die Größe des Puffer-Caches erhöht und dadurch die Rate verringert wird, mit der neue Blöcke in den Puffer-Cache eingeführt werden. Zwei Parameter bestimmen die Größe des Puffercaches, DB_BLOCK_SIZE und DB_BLOCK_BUFFERS. Tatsächlich können nur die DB_BLOCK_BUFFERS geändert werden, ohne die Datenbank neu zu erstellen. Vorsicht: Vermeiden Sie beim Optimieren des Pufferpools die Verwendung zusätzlicher Puffer, die wenig oder gar nichts zur Cache-Trefferquote beitragen. Ein häufiger Fehler besteht darin, den Wert von DB_BLOCK_BUFFERS weiter zu erhöhen. Solche Erhöhungen haben keine Auswirkungen, wenn Sie vollständige Tabellenscans oder andere Vorgänge ausführen, die den Puffercache nicht verwenden. Mehrere Pufferpools können dazu beitragen, Konflikte auf diesem Latch zu reduzieren.Sie können zusätzliche Cache-Puffer-LRU-Kettenlatches erstellen, indem Sie den Konfigurationsparameter DB_BLOCK_LRU_LATCHES anpassen. Möglicherweise können Sie die Belastung der Cache-Pufferkettenverriegelungen verringern, indem Sie den Konfigurationsparameter _DB_BLOCK_HASH_BUCKETS

• REDOLOG-PUFFERVERRIEGELUNGEN erhöhen: Es gibt zwei Redo-Pufferverriegelungen, den Redo Allocation Latch und den Redo Copy Latch. Der Redo allocation Latch muss erfasst werden, um Speicherplatz innerhalb des Puffers zuzuweisen. Wenn der Redo-Protokolleintrag größer als der Konfigurationsparameter LOG_SMALL_ENTRY_MAX_SIZE ist, kann die Sitzung, die den Redo-Zuweisungslatch erfasst, den Eintrag sofort in den Redo-Puffer kopieren, während sie den Zuweisungslatch hält. Wenn der Protokolleintrag größer als LOG_SMALL_ENTRY_MAX_SIZE ist, gibt die Sitzung den Redo Allocation Latch frei und erfasst den Redo Copy Latch, um den Eintrag zu kopieren. Es gibt nur einen Redo-Zuweisungslatch, es können jedoch bis zu LOG_SIMULTANEOUS_COPIES-Zuweisungslatches vorhanden sein.

Redo allocation Latch:

Dieser Latch steuert die Zuweisung von Speicherplatz für Redo-Einträge im Redo-Protokollpuffer. Es gibt einen Redo Allocation Latch pro Instanz.

Konflikte für diesen Latch in Oracle7 können reduziert werden, indem der Wert von LOG_SMALL_ENTRY_MAX_SIZE auf Multi-CPU-Systemen verringert wird, um die Verwendung des
redo Copy Latch zu erzwingen. In Oracle8i ist dieser Parameter veraltet, daher müssen Sie in Betracht ziehen, die Größe des LOG_BUFFER zu erhöhen oder die Belastung des Protokollpuffers mithilfe von NOLOGGING-Funktionen zu reduzieren, wenn dies möglich ist.

Redo copy latch:

Dieser Latch wird verwendet, um Redo-Datensätze in den Redolog-Puffer zu schreiben. Dieser Latch wird sowohl auf Einzel- als auch auf Multi-CPU-Systemen gewartet.

Auf Multi-CPU-Systemen können Konflikte reduziert werden, indem der Wert von LOG_SIMULTANEOUS_COPIES (in Oracle8i ausgeblendet) und / oder LOG_ENTRY_PREBUILD_THRESHOLD (undokumentiert in Oracle7) erhöht wird.

• BIBLIOTHEKS-CACHE

Bibliotheks-Cache-Latch:

Die Bibliotheks-Cache-Latches schützen die zwischengespeicherten SQL-Anweisungen und Objektdefinitionen, die im Bibliotheks-Cache innerhalb des gemeinsam genutzten Pools gespeichert sind. Der Bibliothekscache-Latch muss erworben werden, um dem Bibliothekscache eine neue Anweisung hinzuzufügen. Während einer Analyse durchsucht Oracle den Bibliothekscache nach einer übereinstimmenden Anweisung. Wenn keine gefunden wird, analysiert Oracle die SQL-Anweisung, ruft den Bibliothekscache-Latch ab und fügt die neue SQL ein.

Die erste Ressource, die Konflikte in diesem Latch reduziert, besteht darin, sicherzustellen, dass die Anwendung die SQL-Anweisungsdarstellung so weit wie möglich wiederverwendet. Verwenden Sie Bind-Variablen, wann immer dies in der Anwendung möglich ist. Fehler in diesem Latch können auch ein Zeichen dafür sein, dass die Anwendung SQL mit einer hohen Rate analysiert und möglicherweise unter zu viel Parse-CPU-Overhead leidet.Wenn die Anwendung bereits optimiert ist, kann die SHARED_POOL_SIZE erhöht werden. Beachten Sie, dass der Konflikt mit einer größeren zu behandelnden Struktur möglicherweise schlimmer ist, wenn die Anwendung den Bibliothekscache nicht ordnungsgemäß verwendet.

Der Parameter _KGL_LATCH_COUNT steuert die Anzahl der Bibliothekscache-Latches. Der Standardwert sollte ausreichend sein, aber wenn Konflikte für den Bibliothekscache-Latch nicht gelöst werden können, kann es ratsam sein, diesen Wert zu erhöhen. Der Standardwert für _KGL_LATCH_COUNT ist die nächste Primzahl nach CPU_COUNT. Dieser Wert darf 66 nicht überschreiten (siehe: ).

Bibliotheks-Cache-Pin-Latch:

Der Bibliotheks-Cache-Pin-Latch muss erfasst werden, wenn eine Anweisung im Bibliotheks-Cache erneut ausgeführt wird. Misses auf diesem Latch auftreten, wenn es sehr hohe Raten SQL-Ausführung.

Es gibt wenig, was getan werden kann, um die Belastung des Bibliothekscache-Pin-Latchs zu reduzieren, obwohl private anstelle von öffentlichen Synonymen oder direkten Objektreferenzen wie OWNER verwendet werden.TABELLE kann helfen.

• GEMEINSAM GENUTZTE POOLBEZOGENE LATCHES

Gemeinsam genutzter Pool-Latch:

Während der Bibliotheks-Cache-Latch Vorgänge innerhalb des Bibliotheks-Cache schützt, wird der gemeinsam genutzte Pool-Latch zum Schutz kritischer Vorgänge beim Zuweisen und Freigeben von Speicher im gemeinsam genutzten Pool verwendet.
Wenn eine Anwendung Literal (unshared) SQL verwendet, kann dies die Skalierbarkeit und den Durchsatz stark einschränken. Die Kosten für das Parsen einer neuen SQL-Anweisung sind sowohl in Bezug auf die CPU-Anforderungen als auch in Bezug auf die Häufigkeit, mit der der Bibliothekscache und die gemeinsam genutzten Pool-Latches möglicherweise erfasst und freigegeben werden müssen, hoch. Vor Oracle9 gab es nur einen solchen Latch für die gesamte Datenbank, um die Speicherzuweisung im Bibliothekscache zu schützen. In Oracle9 wurden mehrere untergeordnete Elemente eingeführt, um Konflikte mit dieser Ressource zu lösen.

Möglichkeiten, die Latch des gemeinsam genutzten Pools zu reduzieren, sind: Vermeiden Sie nach Möglichkeit harte Analysen, analysieren Sie einmal, führen Sie viele aus. Das Eliminieren von Literal SQL ist auch nützlich, um den gemeinsamen Pool-Latch zu vermeiden. Die Größe des shared_pool und die Verwendung von MTS (Shared Server Option) haben ebenfalls großen Einfluss auf den Shared Pool Latch. Anmerkung 62143.1 erläutert, wie Probleme mit dem gemeinsamen Pool und dem gemeinsamen Pool-Latch erkannt und behoben werden.

Row Cache objects latch:

Dieser Latch kommt ins Spiel, wenn Benutzerprozesse versuchen, auf die zwischengespeicherten Datenwörterbuchwerte zuzugreifen.

Es ist nicht üblich, Konflikte in diesem Latch zu haben, und die einzige Möglichkeit, Konflikte für diesen Latch zu reduzieren, besteht darin, die Größe des gemeinsam genutzten Pools zu erhöhen (SHARED_POOL_SIZE).

1. _SPIN_COUNT einstellen (_LATCH_SPIN_COUNT in Oracle7)

SPIN_COUNT steuert, wie oft der Prozess erneut versucht, den Latch zu erhalten, bevor er sich zurückzieht und in den Ruhezustand wechselt. Dies bedeutet im Grunde, dass sich der Prozess in einer engen CPU-Schleife befindet und ständig versucht, den Latch für SPIN_COUNT Versuche SPIN_COUNT . Wenn auf einem einzelnen CPU-System ein Oracle-Prozess versucht, einen Latch zu erhalten, dieser jedoch von einer anderen Person gehalten wird, gibt der Prozess die CPU frei und wechselt für kurze Zeit in den Ruhezustand, bevor er es erneut versucht. Auf einem Multiprozessorsystem (SMP) ist es jedoch möglich, dass der Prozess, der den Latch hält, auf einer der anderen CPUs ausgeführt wird und daher möglicherweise den Latch in den nächsten Anweisungen freigibt (Latches werden normalerweise nur für sehr kurze Zeiträume gehalten).

Die Leistung kann durch Ändern des Werts von SPIN_COUNT angepasst werden. Wenn ein hoher Wert verwendet wird, wird die Verriegelung früher erreicht, als wenn Sie einen niedrigen Wert verwenden. Sie können jedoch mehr CPU-Zeit zum Drehen verwenden, um den Latch zu erhalten, wenn Sie einen hohen Wert für SPIN_COUNT . Sie können diese Wahrscheinlichkeit von Sitzungsausfällen verringern, indem Sie den Wert der Konfigurationsparameter _LATCH_SPIN_COUNT oder SPIN_COUNT erhöhen. Dieser Parameter steuert die Anzahl der Versuche, die die Sitzung vor dem Schlafengehen ausführt, um den Latch abzurufen. Wenn Sie diesen Parameter erhöhen, wird möglicherweise eine Erhöhung der CPU-Gesamtauslastung Ihres Systems angezeigt. Wenn Ihr Computer in der Nähe von 100% CPU ist und Ihre Anwendung eher vom Durchsatz als von der Antwortzeit abhängt, können Sie SPIN_COUNT verringern, um die CPU zu schonen. Das Anpassen von SPIN_COUNT ist Versuch und Irrtum. Erhöhen Sie SPIN_COUNT im Allgemeinen nur, wenn genügend freie CPU-Ressourcen auf dem System verfügbar sind, und verringern Sie es nur, wenn keine freie CPU-Kapazität vorhanden ist.