Oracle-Sperren und Tabellensperren:So funktioniert es

Die Oracle-Datenbank ist die in der Industrie weit verbreitete Datenbank. Hier versuche ich,  über Oracle-Sperren und Oracle-Tabellensperren

zu erklären

Inhaltsverzeichnis

Was ist Oracle Enqueue und Sperren

Enqueue sind Oracle-Sperren, die die Operationen in die gemeinsam genutzte Struktur serialisieren. Die gemeinsam genutzte Struktur könnte eine Tabelle, Redo-Threads und Transaktionen sein.

Wenn ein Benutzer A eine Zeile 12 in der Tabelle aktualisiert, erwirbt er die Transaktion Enqueue (Sperre). Dies wird so erfasst, dass jeder Benutzer, den ich versuche, dieselbe Zeile 12 in der Tabelle zu aktualisieren, wartet, bis der Benutzer A die Transaktion festschreibt. Wenn also Benutzer B versucht, dieselbe Zeile zu aktualisieren, wartet er auf die Enqueue.

Sobald der Benutzer A die Transaktion festschreibt, wird die Transaktion von Benutzer B fortgesetzt

Wir haben eine lokale Enqueue in der Einzelinstanzdatenbank, während wir bei Oracle RAC eine lokale Enqueue und eine globale Enqueue haben, um die gemeinsam genutzte Ressource zu verwalten

Was ist eine Enqueue-Kennung

Enqueues werden durch das Format

Ressource kann

TM -> Tabellensperren

MR-> Medienwiederherstellung

TX-> Transaktion

ID1 und ID2 sind Nummern, die für verschiedene Ressourcentypen unterschiedlich sind

Wie für die Tabellensperre (TM) wird sie geschrieben als

TM--0

Wenn ein Benutzer in einem bestimmten Modus Zugriff auf die Ressource anfordert, wird eine Enqueue-ID generiert, die oben erläutert wurde

Enqueue werden in diesem Modus gehalten

SS: Zeilenfreigabemodus

SX:Zeilenexklusiver Modus

S:  Sperren Sie die Tabelle im Freigabemodus

SSX:Sperren Sie die Tabelle im Freigabemodus und die Zeile im exklusiven Modus

X:Die Tabelle im exklusiven Modus sperren

Was ist eine Enqueue-Ressource

Jede Enqueue wird über eine Ressourcenstruktur vom Oracle-Server verwaltet und wie oben erläutert identifiziert. Eine Ressourcenstruktur hat drei Listen

1. Eigentümerliste
2. Warteliste
3. Converter-Liste

Wenn ein Benutzer in einem bestimmten Modus eine Sperre für eine Ressource anfordert, erhält er eine Sperrstruktur und stellt eine Anforderung zum Erwerb der Sperre für eine bestimmte Ressource. Sie wird in diesen Listen der Ressourcenstruktur gemäß der erforderlichen Sperre platziert.

Der Nutzer   fordert diese Ressource also zuerst an, dann wird sie in die Eigentümerliste aufgenommen

Die Ressourcenstruktur wird aus der Ressourcentabelle und die Sperrstruktur aus der Sperrtabelle abgerufen. Sie werden beide in SGA zugewiesen

Die Anzahl der Zeilen in der Ressourcentabelle wird durch den Initialisierungsparameter enqueue_resources definiert. Die verwendeten Werte können in der v$resource-Ansicht eingesehen werden

Die Anzahl der Zeilen in der Sperrstrukturtabelle wird durch den Initialisierungsparameter _enqueue_locks definiert. Die verwendeten Werte können in v$enqueue_lock

Wie erfolgt die Suche in der Ressourcentabelle?

• Die Ressourcentabelle enthält die gesamte Ressourcenstruktur. Ein Hash-Algorithmus wird verwendet, um die Ressourcenstruktur in der Ressourcentabelle zu finden und darauf zuzugreifen.
• Die Ressourcentabelle ist im Hash-Bucket angeordnet. Jeder Hash-Bucket enthält eine Liste der Ressourcenstruktur in Form einer verknüpften Liste.

• Wenn die Ressource gesucht wird, wird ihr Hash mithilfe des Hash-Algorithmus erhalten und dann wird der Latch abgerufen, um den entsprechenden Hash-Bucket zu finden, und dann wird die Ressource in der Liste im Hash-Bucket gesucht. Wenn die Ressource gefunden wird, wird die Sperrstruktur abgerufen und die Anfrage wird gemäß der angegebenen angeforderten Sperrstufe auf der Eigentümer-, Kellner- und Konvertierungsliste platziert

Beispiel:TM-575-0-Ressource, die in Bucket 1 gehasht wird. Eine Latch-Enqueue-Hash-Kette wird abgerufen, um auf den Hash-Bucket zuzugreifen, und auf die Liste wird im Bucket zugegriffen, um die Ressourcenstruktur zu erhalten

• Wenn die Ressource nicht in der Bucket-Liste gefunden wird und eine neue Ressourcenstruktur aus der Liste der freien Ressourcen abgerufen und in die Bucket-Liste aufgenommen wird. Dies geschieht unter dem Latch Enqueue. Außerdem wird eine Sperrstruktur zugewiesen

Die Sperranfrage wird in die Eigentümerliste der Ressourcenstruktur gestellt

Wie funktioniert die Enqueue-Operation?

Wenn ein Benutzer eine Sperre für die Ressource anfordert, führt der Oracle-Server die folgenden Schritte aus

• Wenn sie derzeit nicht im Besitz ist, wird die Ressource dem Benutzer gewährt
• Wenn es Eigentum ist und es Kellner und Konverter gibt, dann wird es am Ende der Kellnerwarteschlange platziert
• Wenn es im Besitz ist, aber kein Kellner und Konverter vorhanden sind, dann wird die Anfrage gewährt, wenn es mit der Eigentümersperre kompatibel ist. Wenn es nicht kompatibel ist, wird es auf die Warteliste gesetzt
• Ein Konverter darf fortfahren, wenn die Anforderung weniger restriktiv ist als die derzeit gehaltene Sperre oder der angeforderte Modus mit der Sperre des anderen Eigentümers kompatibel ist
• Ein Kellner darf fortfahren, wenn die Konverterliste leer ist, es keine Kellner vor ihm gibt und die angeforderte Sperre mit der aktuellen Sperre kompatibel ist
• Converter wird immer vor den Kellnern verarbeitet.
• Der Oracle-Server überprüft diese Warteschlangen jedes Mal, wenn die Sperre aufgehoben oder umgewandelt wird.

Wie die Warteschlange überprüft wird, wenn die Oracle-Sperre freigegeben oder konvertiert wird

• Prozesse, die auf die Ressourcen warten, schlafen auf den Semaphoren, und Semaphoren werden als Sleep/Wake-up-Mechanismen verwendet. Nach dem Einreihen in die Warteschlange schläft der anfordernde Prozess auf dem Semaphor unter Verwendung des sync_op-Aufrufs.

sync_op(SYNC_WAIT, SYNCF_BINARY, 300) =1

• Sobald der Prozess, der die Ressource hält, bereit ist, die Ressource freizugeben, sieht er sich die Warteschlange an, die an die Ressourcenstruktur angehängt ist. Befindet sich ein Prozess in der Warteschlange, sendet er mit
ein Semaphor-Signal an den wartenden Prozess

sync_op-Aufruf.

sync_op(0x0005, SYNCF_BINARY, 134491620) =1

• Der wartende Prozess verarbeitet das Signal und wacht auf. Dieser wartende Prozess ändert den Status gemäß den Schritten, die in der Enqueue-Operation angegeben sind

Häufige Arten von Enqueues

JQ – Auftragswarteschlange. Wenn ein Job (übermittelt von DBMS_JOB.SUBMIT) läuft, wird er durch ein JQ-Enqueue geschützt (was bedeutet, dass nur ein SNP-Prozess den Job ausführen kann).

ST – Flächenmanagement-Transaktion . Die ST-Einreihung muss jedes Mal gehalten werden, wenn die Sitzung Extents zuweist/aufhebt (was bedeutet, dass die UET$- und FET$-Wörterbuchtabellen geändert werden sollen), wie z. Wenn die Sitzung beim Anfordern der ST-Einreihung eine Zeitüberschreitung erhält, wird „ORA-1575-Zeitüberschreitung beim Warten auf die Speicherplatzverwaltung“ zurückgegeben.

TM – DML (Table) enqueue. Jedes Mal, wenn eine Sitzung eine Tabelle sperren möchte, wird ein TM-Enqueue angefordert. Wenn eine Sitzung eine Zeile in der übergeordneten Tabelle (DEPT) löscht und eine referenzielle Einschränkung (Fremdschlüssel) ohne einen Index für die untergeordnete Tabelle (EMP) erstellt wird oder wenn die Sitzung die Spalte(n) aktualisiert, die die fremde Schlüsselreferenzen, um dann eine gemeinsame Sperre (Ebene 4) für die untergeordnete Tabelle zu übernehmen. Wenn eine andere Sitzung versucht, Änderungen an der untergeordneten Tabelle vorzunehmen, müssen sie warten (weil sie das Enqueue im zeilenexklusiven Modus wünschen, und das nicht mit dem Share-Modus kompatibel ist). Wenn ein Index für die Fremdschlüsselspalte der untergeordneten Tabelle erstellt wird, ist für die untergeordnete Tabelle keine gemeinsame Sperre erforderlich.

TX – Transaktion. Sobald eine Transaktion gestartet wird, wird ein TX-Enqueue 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-Einreihung 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 ein COMMIT durchgeführt), dann wartet die letzte Sitzung darauf, dass die erste COMMIT oder ROLLBACK durchführt.

3) Es gibt keine freien ITL (Interested Transaction List) im Blockheader (erhöhen Sie INI_TRANS und PCT_FREE für das Segment).

UL – Benutzersperre . Eine Sitzung hat mit der DBMS_LOCK.REQUEST-Funktion eine Sperre erhalten.

Ansichten und Tabelle zum Anzeigen von Oracle-Enqueue und Oracle-Sperren

V$session und v$session_wait

Wenn eine Sitzung auf Enqueue oder Lock wartet, kann dies eine Sitzung von V$session (in 11g und höher) und v$session_wait

Select * from v$session_wait where event like ‘enq%’;

The parameter of the enqueue wait event   has following meaning

P1: resource type and mode wanted

P2:ID1 of the resource

P3: ID2 of the resource

Wir können die folgende Abfrage verwenden, um alle Enqueues im System abzurufen

Select event,p1, p2,p3 from v$session_wait  where wait_time=0 and event like 'enq%';

1. V$lock ist eine weitere nützliche Ansicht, um Enqueues zu überprüfen
2. V$lock listet alle derzeit im System gehaltenen Lock-Strukturen auf
3. Die Spaltentypen ,id1 und id2 stellen die Ressourcentypen ,id1 und id2 der Ressourcenstruktur dar. Sie können also mit V$resource verbunden werden, die die Liste aller Ressourcenstrukturen enthält

• LMODE und Anfrage sagen uns, welche Warteschlange (Eigentümer, Konverter, Kellner) die Sitzung ist

Die folgende Abfrage kann verwendet werden, um Inhaber und Kellner zu finden

SELECT inst_id,DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request
;

Im Fall von RAC könnte die folgende Abfrage verwendet werden, um Blocker und Kellner herauszufinden

SELECT inst_id,DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM GV$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM gV$LOCK WHERE request>0)
ORDER BY id1, request
;

V$locked_object

es ist eine weitere nützliche Ansicht für Oracle-Tabellensperren

Es enthält alle TM-Sperren in der Datenbank. Es gibt den Transaktionsschlitz, den Betriebssystemprozess und die Sitzungs-ID der Sitzung an, die die TM-Sperren hält

Es gibt mehrere Ansichten, die verwendet werden können, um die Sperrinformationen zu finden. Diese Ansichten werden von catblock.sql

Abfrage, um das Warten auf Sitzungen und das Halten von Sitzungen in Oracle herauszufinden 

set linesize 1000
column waiting_session heading 'WAITING|SESSION'
column holding_session heading 'HOLDING|SESSION'
column lock_type format a15
column mode_held format a15
column mode_requested format a15
select
waiting_session,
holding_session,
lock_type,
mode_held,
mode_requested,
lock_id1,
lock_id2
from
dba_waiters
/

Abfrage, um alle gesperrten Objekte herauszufinden

set term on;
set lines 130;
column sid_ser format a12 heading 'session,|serial#';
column username format a12 heading 'os user/|db user';
column process format a9 heading 'os|process';
column spid format a7 heading 'trace|number';
column owner_object format a35 heading 'owner.object';
column locked_mode format a13 heading 'locked|mode';
column status format a8 heading 'status';
select
substr(to_char(l.session_id)||','||to_char(s.serial#),1,12) sid_ser,
substr(l.os_user_name||'/'||l.oracle_username,1,12) username,
l.process,
p.spid,
substr(o.owner||'.'||o.object_name,1,35) owner_object,
decode(l.locked_mode,
1,'No Lock',
2,'Row Share',
3,'Row Exclusive',
4,'Share',
5,'Share Row Excl',
6,'Exclusive',null) locked_mode,
substr(s.status,1,8) status
from
v$locked_object l,
all_objects     o,
v$session       s,
v$process       p
where
l.object_id = o.object_id
and l.session_id = s.sid
and s.paddr      = p.addr
and s.status != 'KILLED'
/

Wie die DML-Sperren auf dem Oracle-Server gehandhabt werden

Wenn ein update, inserts, deletes oder select for update auf der Oracle-Tabelle ausgeführt wird, übernimmt Oracle diese beiden Sperren

• DML-Tabellensperre:Um die Konsistenz der Objektdefinition für die Dauer der Transaktion sicherzustellen. Dadurch wird verhindert, dass DDL-Operationen ausgeführt werden, während eine DML ausgeführt wird.
• DML-Zeilensperre:Damit soll die Konsistenz der Daten während der Ausführung der Transaktion sichergestellt werden. Wir können dies umformulieren wie:Dies erhält eine Sperre für die jeweilige Zeile, die berührt wird, und jede andere Transaktion, die versucht, dieselbe Zeile zu ändern, wird blockiert, bis diejenige, die sie bereits besitzt, beendet ist

Wie Oracle-Tabellensperren implementiert werden

Die Infrastruktur von Enqueue haben wir bereits im vorigen Abschnitt erklärt. Oracle Table-Sperren sind als TM Enqueue implementiert

Die Enqueue-Struktur wäre also

TM- -0

Modi sind

RS:Zeilenanteil

RX:Zeile exklusiv

S:teilen

SRX:Zeile exklusiv teilen

X:exklusiv

Jeder Cursor verwaltet eine Liste der Tabellensperrstruktur, die während des Analysierens der Anweisung erstellt wird. Bei der ersten Ausführung erfolgt ein Funktionsaufruf, um alle Tabellen in der Liste zu sperren. Die Sperren werden aufgehoben, wenn die Transaktion festgeschrieben oder zurückgesetzt wird.

Die Möglichkeit des Rollbacks, insbesondere des Rollbacks zu einem Sicherungspunkt, fügt der Wörterbuchsperre eine weitere Dimension der Komplexität hinzu. Wenn nämlich eine Transaktion über den Punkt hinaus zurückgesetzt wird, an dem eine Sperre aktualisiert wurde, muss die Sperre als Teil des Rollback-Vorgangs entsprechend herabgestuft werden, um das Risiko künstlicher Deadlocks zu verringern.

Die Anforderungen des Wörterbuch-Sperrens für Transaktionen und insbesondere das Führen einer Historie von Sperrkonvertierungen werden durch DML-Sperren in Verbindung mit TM-Enqueue bereitgestellt. Jede Transaktion, die eine DML-Sperre hält, hält auch eine TM-Enqueue-Sperre. Die grundlegende Sperrfunktionalität wird durch die Enqueue bereitgestellt, und die DML-Sperre fügt die Pflege der Konvertierungshistorie hinzu.

Die Größe des festen Arrays von DML-Sperrstrukturen wird durch den DML_LOCKS-Parameter bestimmt. Seine freie Liste ist durch den dml-Sperrzuweisungsriegel geschützt, und die aktiven Slots sind in V$LOCKED_OBJECT .

Um die DML_LOCKs zu setzen, überprüfen Sie die Auslastung in v$resource_limit. Wir können es großzügig einstellen, da es sehr wenig Platz benötigt

Wie deaktiviere ich die Tabellensperren?

• DML-Sperren und die zugehörigen TM-Enqueue-Sperren können entweder vollständig oder nur für bestimmte Tabellen deaktiviert werden.
• Um diese Sperren vollständig zu deaktivieren, muss der DML_LOCKS-Parameter auf Null gesetzt werden. In einer Parallelserver-Datenbank muss es in allen Instanzen auf Null gesetzt werden.
• Um solche Sperren für eine bestimmte Tabelle zu deaktivieren, muss die DISABLE TABLE LOCKS-Klausel der ALTER TABLE-Anweisung verwendet werden.
• Wenn Sperren für eine Tabelle deaktiviert sind, können DML-Anweisungen weiterhin die Blöcke der Tabelle ändern, und Sperren auf Zeilenebene werden weiterhin gehalten. Die Tabellensperren im sub-shared Modus, die normalerweise Abfragen zugeordnet sind, und die Tabellensperren im sub-exklusiven Modus, die normalerweise DML zugeordnet sind, werden jedoch nicht genommen. Stattdessen werden Transaktionen für die Tabelle vor widersprüchlichen DDL geschützt, indem einfach alle Versuche verboten werden, eine Sperre für die gesamte Tabelle und damit alle DDL für die Tabelle zu nehmen.
• Das Deaktivieren der Tabellensperren kann die Leistung steigern, da der Overhead für die Sperrenerfassung reduziert wird. Dies ist besonders wichtig im Fall von RAC, wo dieser Overhead ziemlich hoch ist.
• Das Deaktivieren der Tabellensperren verhindert auch das Erstellen von Fremdschlüsselindizes. Als Fremdschlüssel muss indiziert werden, um eine Tabellensperre der untergeordneten Tabelle zu vermeiden, während die Zeilen in der übergeordneten Tabelle manipuliert werden. Wenn wir also die Tabellensperre insgesamt deaktivieren, sind Indizes nicht erforderlich
• Es ist vorzuziehen, alter table zu verwenden, um die Tabellensperren für einige Tabellen zu deaktivieren, anstatt sie auf die Tabelle dml_locks zu setzen. Als ob dml_locks auf Null gesetzt wäre, müssen wir die Instanz zurückweisen, um sie erneut zu setzen
• Bei Direct-Load-Insert nimmt eine Sitzung die TM-Einreihung in den „X“-Modus. Dadurch wird verhindert, dass während des direkten Ladens andere DML ausgeführt werden, zusätzlich zum Blockieren aller DDL

Wie DML-Zeilensperren implementiert werden

DML-Zeilensperren werden als Kombination der folgenden zwei Dinge implementiert

1. Sperre auf Zeilenebene:Sie wird als Sperrbyte in jedem Zeilenheader und als ITL (Liste der interessanten Transaktionen) in jedem Daten- oder Indexblock implementiert. Diese werden nirgendwo zwischengespeichert und da sie im Block selbst gespeichert sind, nicht in SGA, das begrenzt ist, ist dieser Mechanismus von Locking by Oracle massiv skalierbar
2. Transaktionssperren:Diese werden als TX Enqueue implementiert

Das Sperrbyte zeigt auf den ITL-Eintrag im Block und Alle ITL-Einträge für die Transaktion zeigen auf die TX-Einreihung, die letztendlich bestimmt, ob die Transaktion festgeschrieben oder zurückgesetzt wird. Die Kellner warten auf die Transaktionssperre

Beispiel

• Eine Transaktion A möchte die Zeilen 2 und 3 im Block aktualisieren. Es wird eine ITL (interessierte Transaktionsliste) zugewiesen. Die Transaktion greift auf die Zeilen 2 und 3 zu und sieht das Sperrbyte. Wenn das Sperrbyte null ist, ist es nicht gesperrt. Die Transaktion aktualisiert die Zeile 3 ,3
• Nun startet eine Transaktion B   und möchte die Zeilen aktualisieren 1 . Es wird eine ITL (interessierte Transaktionsliste) zugewiesen. Die Transaktion greift auf die Zeile 1 zu und sieht das Sperrbyte. Wenn das Sperrbyte null ist, ist es nicht gesperrt. Die Transaktion aktualisiert die Zeile 1
• Nun möchte die Transaktion die Zeile 2 aktualisieren. Sie greift auf die Zeile zu und stellt fest, dass sie gesperrt ist, da das Sperrbyte nicht Null ist. Es wird in der ITL nachgesehen, die die Sperre enthält. Es führt eine ITL-Bereinigung durch, um herauszufinden, ob die Transaktion aktiv oder nicht aktiv ist. In diesem Fall findet es Transaktion A aktiv. Transaktion B muss also warten, bis Transaktion A zurückgesetzt oder festgeschrieben wird. Die Transaktion B wartet auf die Anforderung des TX Enqueue, das die Transaktion A im exklusiven Modus hält

Liste der interessierten Transaktionen (ITL)

Wenn eine Sitzung einen Block modifizieren möchte, muss sie dem Block eine ITL zuweisen. ITL ist die Datenstruktur im Blockheader, die viele Slots enthält, die von der Transaktion belegt werden. Sie wird beim Anlegen der Tabelle durch die Parameter INITRANS und MAXTRANS definiert. Anfangszahlen von Slots werden gemäß INITTRANS erstellt und wachsen dynamisch bis zum Maximum von MAXTRANS

Was ist Transaktion?

Wenn eine Sitzung aktualisiert / gelöscht / eingefügt wird, wird eine Transaktion gestartet. Es ist abgeschlossen, wenn das Commit oder Rollback stattgefunden hat. Eine Transaktion wird durch die Transaktions-ID (XID) identifiziert. Die Transaktionsidentifikation besteht aus drei Teilen

1. Segmentnummer zurücksetzen oder rückgängig machen
2. Slot-Nummer der Transaktionstabelle
3. Sequenz- oder Wrap-Nr.

XID=usn#.slot#.wrap#

Jede Block-ITL enthält die XID

Eine ITL-Bereinigung bedeutet, nach der XID in der ITL zu suchen und basierend darauf die Rollback-Segmente zu durchsuchen und nach der Transaktionstabelle und der Wrap-Nummer zu suchen, um die Transaktionsaktivität zu überprüfen.

Wir können den folgenden Befehl verwenden, um jedes Rollback-Segment zu sichern

Ändern Sie den Rückgängig-Header des System-Dumps ;

Jede aktive Transaktion kann in der v$transaction-Tabelle eingesehen werden

select addr, xidusn, xidslot, xidsqn
from v$transaction;
ADDR         XIDUSN    XIDSLOT     XIDSQN
-------- ---------- ---------- ----------
3C485875         50         5      3000

Der Transaction Identifier (XID) kann auch in der eigenen Session mit

select dbms_transaction.local_transaction_id from dual;

Das Warten auf TX enq wird in v$session_wait

P1:Name|Modus

P2:rbs3|Umbruch#

P3:Steckplatz#

Um die DML-Zeilensperren zusammenzufassen

Die erste DML in einer Sitzung, in der noch keine Transaktion vorhanden ist, erstellt implizit eine Transaktion.

• Eine Undo-Segmentnummer, ein Slot und ein Umbruch werden zugewiesen
• TX-Enqueue wird instanziiert

Wenn eine zu ändernde Zeile identifiziert wird, nimmt die Sitzung einen Eintrag in der ITL des Datenblocks und weist ihn der Transaktion zu

• USN/SLOT/WRAP werden in den ITL-Slot geschrieben, wobei dieser Slot für die aktuelle Transaktion reserviert wird
• Die Zeile wird gesperrt, indem das Sperrbyte im Zeilenverzeichnis so gesetzt wird, dass es auf den ITL-Slot der aktuellen Transaktion zeigt

Sowohl TM als auch TX Enqueue sind in V$lock zu sehen

• Typ identifiziert TM oder TX
• ID1 und ID2 können zusätzliche Informationen enthalten, sind jedoch kontextsensitiv in Bezug auf den Enqueue-TYPE
• Bei TM-Enqueue ist ID1 die OBJECT_ID des zu sperrenden Objekts, auf das in DBA_OBJECTS verwiesen werden kann, und ID2 ist immer 0
• Für TX Enqueue enthalten ID1 und ID2 die Undo-Segmentnummer, die Slot-Nummer und den Wrap

Detailliertes Beispiel zur Erläuterung der Funktionsweise von Orakelsperren

• Erstellen Sie die Dummy-Tabelle

Create table from j as select * from dba_objects where rownum < 3;

Table created

 Create table from j1 as select * from dba_objects where rownum < 3;

Table created

• Sitzung A

Select * from j for update;

Mal sehen, was in v$lock

SQL> select distinct sid from v$mystat;

 SID
----------
2125

SQL> select * from v$lock where sid=2125;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
00000006B5D9D0D0 00000006B5D9D148       2125 TX    2883613   16425600          6

0         44          0
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2125 TM   21488781          0          3

0         44          0

So sehen wir hier

DML-Oracle-Tabellensperre wird erstellt

TX (Transaktionssperre) wird erstellt

• Lassen Sie uns Sitzung B starten

SQL>Select * from j1 for update;

SQL > select distinct sid from v$mystat;

 SID
----------
2302
SQL> select * from v$lock where sid=2302;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
00000006AF7FF910 00000006AF7FF988       2302 TX    2949148   16884039          6

0         10          0
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM      33544          0          3

0         10          0

00000006DC289D60 00000006DC289DB8       2302 AE   15062272          0          4

0        106          0

So sehen wir hier

DML-Tabellensperre wird erstellt

TX (Transaktionssperre) wird erstellt

Versuchen wir es jetzt

Select * from j for update;

Dies wird hängen

• Starten Sie eine weitere Sitzung, um das Problem zu analysieren

Wenn Sie die SID =2032-Details der Sitzung in V$lock

select * from v$lock where sid=2302;
ADDR             KADDR                   SID TY        ID1        ID2      LMODE
---------------- ---------------- ---------- -- ---------- ---------- ----------
REQUEST      CTIME      BLOCK
---------- ---------- ----------
FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM      33544          0          3
0         47          0

00000006DC289D60 00000006DC289DB8       2302 AE   15062272          0          4
0        143          0

00000006DC289808 00000006DC289860       2302 TX    2883613   16425600          0
         6          7          0

FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM   21488781          0          3
0          7          0

Die fettgedruckte Zeile ist Anfrage 6 (exklusive Sperre) bei einigen TX-enq

Jetzt können wir die folgende Abfrage verwenden, um die blockierende Sitzung zu finden

select l1.sid, ' IS BLOCKING ', l2.sid
from v$lock l1, v$lock l2
where l1.block =1 and l2.request > 0
and l1.id1=l2.id1
and l1.id2=l2.id2
SID 'ISBLOCKING'         SID
---------- ------------- ----------
2125  IS BLOCKING        2302

Jetzt können wir die Sitzung 2125 festschreiben oder rückgängig machen, damit die Transaktion B fortfahren kann. Wir können die Sitzung 2125 mit dem folgenden Befehl beenden, auch um die Sperre aufzuheben

Alter system kill session ‘2125,<serial>’;

Weitere zusätzliche Informationen

Die TX-Sperren in v$lock teilen den Zeileninformationen nicht mit, wo der Konflikt vorhanden ist. Wir können diese Dinge mit den Abfragen anzeigen

Die folgende Abfrage muss von der wartenden Sitzung aus ausgeführt werden

SQL> select row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#

from v$session where sid=2302

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
------------- -------------- --------------- -------------
21488781            461           81063             0

 

select do.object_name,
row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
from v$session s, dba_objects do
where sid=2302
and s.ROW_WAIT_OBJ# = do.OBJECT_ID ;  
OBJECT_NAME  ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# DBMS_ROWID.ROWID_C
------------- -------------- --------------- ------------- ------------------

J
21488781            461           81063             0 ABR+SNAHNAAATynAAA

 

SQL> Select * from j where rowid=’ ABR+SNAHNAAATynAAA’;

Verwandte Artikel

Funktionsweise der Oracle-Sperre
So finden Sie Sitzungsdetails in der Oracle-Datenbank
Wichtiger Datenbank-Zustandscheck
Oracle-Apps-DBA-Interviewfragen
Abfragen zum Überprüfen von Sperren in der Oracle-Datenbank
Oracle-DBA Interviewfragen

Empfohlene Kurse

Im Folgenden finden Sie einige der empfohlenen Kurse, die Sie kaufen können, wenn Sie einen Schritt weiterkommen möchten

Unten finden Sie die Links zu einigen der Kurse

Oracle DBA 11g/12c – Datenbankverwaltung für Junior DBA :Dieser Kurs eignet sich für Personen, die als Junior DBA beginnen oder Oracle DBA werden möchten. Dies vermittelt ein gutes Verständnis von Backup &Recovery und allgemeinen Verwaltungsaufgaben
Oracle Database:Oracle 12C R2 RAC Administration :Dieser Kurs behandelt die Installation und Verwaltung von Oracle RAC. Ein guter Kurs für Oracle DBA, der seine Fähigkeiten für Oracle RAC verbessern möchte
Oracle Data Guard:Datenbankverwaltung für Oracle 12C R2 :Dieser Kurs behandelt die Installation und Verwaltung von Oracle Dataguard. Ein guter Kurs für Oracle DBA, der seine Fähigkeiten für Oracle Dataguard verbessern möchte