Gleichzeitiger Datenzugriff und Konsistenz

Der Skriptcontent auf dieser Seite ist ausschließlich für Navigationszwecke vorgesehen und bewirkt keinerlei Änderung des Contents.

In diesem Kapitel wird erläutert, wie Oracle AI Database konsistente Daten in einer Mehrbenutzer-Datenbankumgebung verwaltet.

Gleichzeitigkeit und Konsistenz von Daten - Einführung

In einer Einzelbenutzerdatenbank kann ein Benutzer Daten ändern, ohne dass andere Benutzer dieselben Daten gleichzeitig ändern müssen. In einer Mehrbenutzerdatenbank können Anweisungen in mehreren gleichzeitigen Transaktionen jedoch dieselben Daten aktualisieren. Transaktionen, die gleichzeitig ausgeführt werden, müssen aussagekräftige und konsistente Ergebnisse liefern.

Eine Mehrbenutzerdatenbank muss Folgendes bereitstellen:

Um ein konsistentes Transaktionsverhalten zu beschreiben, wenn Transaktionen gleichzeitig ausgeführt werden, haben Datenbankforscher ein Transaktionsisolationsmodell namens Serialisierbarkeit definiert. Eine serialisierbare Transaktion wird in einer Umgebung ausgeführt, in der es so aussieht, als würden keine anderen Benutzer Daten in der Datenbank ändern.

Während dieser Grad der Isolation zwischen Transaktionen im Allgemeinen wünschenswert ist, kann die Ausführung vieler Anwendungen im serialisierbaren Modus den Anwendungsdurchsatz erheblich beeinträchtigen. Eine vollständige Isolierung von Transaktionen, die gleichzeitig ausgeführt werden, könnte bedeuten, dass eine Transaktion keine Einfügung in eine Tabelle ausführen kann, die von einer anderen Transaktion abgefragt wird. Kurz gesagt, reale Überlegungen erfordern in der Regel einen Kompromiss zwischen perfekter Transaktionsisolation und Performance.

Oracle AI Database sorgt für Datenkonsistenz, indem ein Multiversionskonsistenzmodell und verschiedene Arten von Sperren und Transaktionen verwendet werden. Auf diese Weise kann die Datenbank mehreren gleichzeitigen Benutzern eine Datenansicht bereitstellen, wobei jede Ansicht zu einem bestimmten Zeitpunkt konsistent ist. Da verschiedene Versionen von Datenblöcken gleichzeitig vorhanden sein können, können Transaktionen die Version der Daten lesen, die zu dem Zeitpunkt festgeschrieben wurden, der für eine Abfrage erforderlich ist, und Ergebnisse zurückgeben, die zu einem einzelnen Zeitpunkt konsistent sind.

Multiversions-Lesekonsistenz

In Oracle AI Database ist Multiversioning die Möglichkeit, mehrere Datenversionen gleichzeitig zu materialisieren. Oracle AI Database sorgt für mehrstufige Lesekonsistenz.

Abfragen einer Oracle-Datenbank weisen folgende Merkmale auf:

Lesekonsistenz auf Auszugsebene

Oracle AI Database setzt immer die Lesekonsistenz auf Anweisungsebene durch, die gewährleistet, dass die von einer einzelnen Abfrage zurückgegebenen Daten für einen einzigen Zeitpunkt festgeschrieben und konsistent sind.

Der Zeitpunkt, zu dem eine einzelne SQL-Anweisung konsistent ist, hängt von der Transaktionsisolationsebene und der Art der Abfrage ab:

Siehe auch: Oracle AI Database Development Guide enthält Informationen zu Flashback Query

Lesekonsistenz auf Transaktionsebene

Oracle AI Database kann auch Lesekonsistenz für alle Abfragen in einer Transaktion bereitstellen, die als Lesekonsistenz auf Transaktionsebene bezeichnet wird.

In diesem Fall werden für jede Anweisung in einer Transaktion Daten vom gleichen Zeitpunkt angezeigt. Dies ist der Zeitpunkt, zu dem die Transaktion begann.

Bei Abfragen, die von einer serialisierbaren Transaktion durchgeführt werden, werden Änderungen angezeigt, die von der Transaktion selbst vorgenommen wurden. Beispiel: Bei einer Transaktion, die employees aktualisiert und dann employees abfragt, werden die Aktualisierungen angezeigt. Die Lesekonsistenz auf Transaktionsebene erzeugt wiederholbare Lesevorgänge und stellt eine Abfrage keinen Phantom-Lesevorgängen zur Verfügung.

Lesekonsistenz und Undo-Segmente

Um das Konsistenzmodell für mehrere Versionen zu verwalten, muss die Datenbank ein lesekonsistentes Datenset erstellen, wenn eine Tabelle gleichzeitig abgefragt und aktualisiert wird.

Oracle AI Database erreicht Lesekonsistenz durch Undo-Daten.

Wenn ein Benutzer Daten ändert, erstellt Oracle AI Database Undo-Einträge, die in Undo-Segmente geschrieben werden. Die Undo-Segmente enthalten die alten Datenwerte, die durch nicht festgeschriebene oder kürzlich festgeschriebene Transaktionen geändert wurden. Somit können mehrere Versionen derselben Daten zu verschiedenen Zeitpunkten in der Datenbank vorhanden sein. Die Datenbank kann Snapshots von Daten zu verschiedenen Zeitpunkten verwenden, um lesekonsistente Ansichten der Daten bereitzustellen und nicht blockierende Abfragen zu ermöglichen.

Die Lesekonsistenz wird in Einzelinstanz- und Oracle Real Application Clusters-(Oracle RAC-)Umgebungen gewährleistet. Oracle RAC verwendet einen Cache-zu-Cache-Blockübertragungsmechanismus, der als Cache Fusion bezeichnet wird, um lesekonsistente Images von Datenblöcken von einer Datenbankinstanz zu einer anderen zu übertragen.

Siehe:

Lesekonsistenz – Beispiel

Dieses Beispiel zeigt eine Abfrage, die Undo-Daten verwendet, um Lesekonsistenz auf Anweisungsebene in der festgeschriebenen Isolationsebene bereitzustellen.

Abbildung 1: Lesekonsistenz in der Read Committed Isolation Level

Beschreibung der Abbildung cncpt069.gif

Während die Datenbank Datenblöcke im Namen einer Abfrage abruft, stellt die Datenbank sicher, dass die Daten in jedem Block den Inhalt des Blocks widerspiegeln, als die Abfrage begann. Die Datenbank setzt Änderungen an dem Block nach Bedarf zurück, um den Block bis zu dem Zeitpunkt zu rekonstruieren, zu dem die Verarbeitung der Abfrage gestartet wurde.

Die Datenbank verwendet einen internen Bestellmechanismus, der als SCN bezeichnet wird, um die Reihenfolge der Transaktionen zu gewährleisten. Wenn die SELECT-Anweisung in die Ausführungsphase eintritt, bestimmt die Datenbank die SCN, die zum Zeitpunkt der Ausführung der Abfrage aufgezeichnet wurde. In Abbildung 12-1 lautet diese SCN 10023. Die Abfrage sieht nur festgeschriebene Daten in Bezug auf die SCN 10023.

In Abbildung 12-1 geben Blöcke mit SCNs nach 10023 geänderte Daten an, wie die beiden Blöcke mit SCN 10024 zeigen. Die SELECT-Anweisung erfordert eine Version des Blocks, die mit festgeschriebenen Änderungen konsistent ist. Die Datenbank kopiert aktuelle Datenblöcke in einen neuen Puffer und wendet Undo-Daten an, um frühere Versionen der Blöcke zu rekonstruieren. Diese rekonstruierten Datenblöcke werden als konsistente Lese-(CR-)Klone bezeichnet.

In Abbildung 12-1 erstellt die Datenbank zwei CR-Klone: einen konsistenten Block für SCN 10006 und den anderen konsistenten Block für SCN 10021. Die Datenbank gibt die rekonstruierten Daten für die Abfrage zurück. Auf diese Weise verhindert Oracle AI Database schmutzige Lesevorgänge.

Siehe auch: "Datenbankpuffercache" und "Systemänderungsnummern (SCNs)"

Lesekonsistenz und Listen interessierter Transaktionen

Der Blockheader jedes Segmentblocks enthält eine Interested Transaction List (ITL).

Die Datenbank bestimmt anhand der ITL, ob eine Transaktion nicht festgeschrieben wurde, als die Datenbank mit der Änderung des Blocks begann.

Die Einträge in der ITL beschreiben, welche Transaktionen Zeilen gesperrt haben und welche Zeilen im Block festgeschriebene und nicht festgeschriebene Änderungen enthalten. Die ITL verweist auf die Transaktionstabelle im Undo-Segment, die Informationen zum Zeitpunkt der Änderungen an der Datenbank liefert.

In gewisser Weise enthält der Block-Header eine aktuelle Transaktionshistorie, die sich auf jede Zeile im Block ausgewirkt hat. Der Parameter INITRANS der Anweisungen CREATE TABLE und ALTER TABLE steuert die Menge der Transaktionshistorie, die beibehalten wird.

Siehe auch: Oracle AI Database SQL Language Reference, um mehr über den Parameter INITRANS zu erfahren

Lesekonsistenz und verzögerte Einfügungen

Ein spezieller Einfügetyp, der als verzögertes Einfügen bezeichnet wird, verwendet nicht das Standardverfahren für die Lesekonsistenz.

Bei einer verzögerten Einfügung wird der Hint MEMOPTIMIZE_WRITE verwendet, um ihn in eine Tabelle einzufügen, die als MEMOPTIMIZE FOR WRITE angegeben ist. Die Datenbank puffert diese Einfügungen im Large Pool und nicht im Puffercache. Die Datenbank verfolgt die Änderungen nicht mit Redo und Undo. Stattdessen schreibt die Datenbank die Änderungen automatisch fest, wenn der Space Management Coordinator (SMCO) den Puffer auf den Datenträger schreibt. Die Änderungen können nicht zurückgesetzt werden.

Verzögerte Einsätze unterscheiden sich von herkömmlichen Einsätzen auf wichtige Weise:

Clientanwendungen, die einen Datenverlust vermeiden müssen, sollten eine lokale Kopie der Daten behalten, nachdem sie in den Large Pool geschrieben wurden. Der Client kann das DBMS_MEMOPTIMIZE-Package verwenden, um die Dauerhaftigkeit der Schreibvorgänge im Speicher zu verfolgen, und das DBMS_MEMOPTIMIZE_ADMIN-Package, um das Schreiben der Datenbank auf den Datenträger zu erzwingen.

Siehe:

Sperrmechanismen

Im Allgemeinen verwenden Mehrbenutzerdatenbanken eine Art Datensperre, um die Probleme im Zusammenhang mit gleichzeitigem Datenzugriff, Konsistenz und Integrität zu lösen.

Ein Sperre ist ein Mechanismus, der destruktive Interaktionen zwischen Transaktionen verhindert, die auf dieselbe Ressource zugreifen.

Siehe auch: "Überblick über den Sperrmechanismus von Oracle AI Database"

ANSI-/ISO-Transaktionsisolationsebenen

Der SQL-Standard, der sowohl von ANSI als auch von ISO/IEC übernommen wurde, definiert vier Ebenen der Transaktionsisolation. Diese Ebenen haben unterschiedliche Auswirkungen auf den Transaktionsverarbeitungsdurchsatz.

Diese Isolationsebenen werden in Bezug auf Phänomene definiert, die zwischen gleichzeitiger Ausführung von Transaktionen verhindert werden müssen. Die vermeidbaren Phänomene sind:

Der SQL-Standard definiert vier Isolationsebenen in Bezug auf die Phänomene, die eine Transaktion auf einer bestimmten Isolationsebene erleben darf. In Tabelle 12-1 sind die Ebenen dargestellt.

Tabelle 1: Vorbeugende Lesephänomene nach Isolationsebene

Isolationsebene Dirty-Read Nicht wiederholbarer Lesevorgang Phantomablesung
Lesen nicht festgeschrieben Möglich Möglich Möglich
Gelesen festgeschrieben Nicht zulässig Möglich Möglich
Wiederholbarer Lesevorgang Nicht zulässig Nicht zulässig Möglich
Serialisierbar Nicht zulässig Nicht zulässig Nicht zulässig

Oracle AI Database bietet die Isolationsebenen "Read committed" (Standard) und "Serializable". Außerdem bietet die Datenbank einen schreibgeschützten Modus.

Siehe:

Transaktionsisolationsebenen in Oracle AI Database - Überblick

Der ANSI-Standard für Transaktionsisolationsebenen wird in Bezug auf die Phänomene definiert, die für jede Isolationsebene entweder zulässig oder verhindert werden.

Oracle AI Database bietet die Transaktionsisolationsebenen:

Siehe:

Festgeschriebene Isolationsebene lesen

In der gelesenen festgeschriebenen Isolationsebene werden bei jeder von einer Transaktion ausgeführten Abfrage nur Daten angezeigt, die vor der Abfrage festgeschrieben wurden, nicht die Transaktion.

Diese Isolationsebene ist der Standardwert. Sie eignet sich für Datenbankumgebungen, in denen wahrscheinlich nur wenige Transaktionen in Konflikt stehen.

Eine Abfrage in einer ausgelesenen festgeschriebenen Transaktion verhindert das Lesen von Daten, die festgeschrieben werden, während die Abfrage ausgeführt wird. Beispiel: Wenn eine Abfrage einen Scan einer Tabelle mit einer Million Zeilen durchläuft und eine andere Transaktion eine Aktualisierung in Zeile 950.000 festschreibt, sieht die Abfrage diese Änderung nicht, wenn sie Zeile 950.000 liest. Da die Datenbank jedoch nicht verhindert, dass andere Transaktionen Daten ändern, die von einer Abfrage gelesen werden, können andere Transaktionen Daten zwischen Abfrageausführungen ändern. Daher können bei einer Transaktion, bei der dieselbe Abfrage zweimal ausgeführt wird, Fuzzy-Lesevorgänge und Phantome auftreten.

Lesekonsistenz auf der Isolationsebene mit Lesezugriff

Die Datenbank stellt für jede Abfrage eine konsistente Ergebnismenge bereit, die Datenkonsistenz garantiert, ohne dass der Benutzer eine Aktion ausführt.

Eine implizite Abfrage, z.B. eine Abfrage, die von einer WHERE-Klausel in einer UPDATE-Anweisung impliziert wird, wird als konsistentes Ergebnisset garantiert. Jede Anweisung in einer impliziten Abfrage sieht jedoch nicht die Änderungen, die von der DML-Anweisung selbst vorgenommen wurden, sondern sieht die Daten so, wie sie vor den Änderungen vorhanden waren.

Wenn eine SELECT-Liste eine PL/SQL-Funktion enthält, wendet die Datenbank die Lesekonsistenz auf Anweisungsebene für SQL an, die im PL/SQL-Funktionscode ausgeführt wird, und nicht auf der übergeordneten SQL-Ebene. Beispiel: Eine Funktion kann auf eine Tabelle zugreifen, deren Daten von einem anderen Benutzer geändert und festgeschrieben werden. Für jede Ausführung von SELECT in der Funktion wird ein neuer lesekonsistenter Snapshot erstellt.

Siehe auch: "Unterabfragen"

Schreibvorgänge in gelesenen festgeschriebenen Transaktionen in Konflikt

In einer ausgelesenen festgeschriebenen Transaktion tritt ein widersprüchlicher Schreibvorgang auf, wenn die Transaktion versucht, eine Zeile zu ändern, die von einer nicht festgeschriebenen nebenläufigen Transaktion aktualisiert wurde.

Die Transaktion, die eine Zeilenänderung verhindert, wird manchmal als blockierende Transaktion bezeichnet. Die ausgelesene festgeschriebene Transaktion wartet, bis die blockierende Transaktion beendet und ihre Zeilensperre freigegeben wird.

Folgende Optionen stehen zur Auswahl:

Die folgende Tabelle zeigt, wie Transaktion 1, die serialisierbar oder gelesen festgeschrieben sein kann, mit der festgeschriebenen gelesenen Transaktion 2 interagiert. Es zeigt eine klassische Situation, die als verlorenes Update bezeichnet wird. Die von Transaktion 1 vorgenommene Aktualisierung ist nicht in der Tabelle enthalten, auch wenn Transaktion 1 sie festgeschrieben hat. Die Entwicklung einer Strategie zur Bewältigung verlorener Updates ist ein wichtiger Bestandteil der Anwendungsentwicklung.

Tabelle 2: Widersprüchliche Schreibvorgänge und verlorene Aktualisierungen in einer READ COMMITTED-Transaktion

Session 1 Session 2 Erläuterung 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
  ('Banda', 'Greene',
 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6200
 Greene 9500
Keine Aktion. Sitzung 1 fragt die Gehälter für Banda, Greene und Hintz ab. Kein Mitarbeiter mit dem Namen Hintz gefunden. 
SQL> UPDATE employees
  SET salary = 7000 WHERE
  last_name = 'Banda';
 Keine Aktion. Sitzung 1 beginnt eine Transaktion, indem das Banda-Gehalt aktualisiert wird. Die Standardisolationsebene für Transaktion 1 ist READ COMMITTED.
Keine Aktion. 
SQL> SET TRANSACTION
  ISOLATION LEVEL
  READ COMMITTED;
 Session 2 beginnt Transaktion 2 und setzt die Isolationsebene explizit auf READ COMMITTED.
Keine Aktion. 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
 ('Banda', 'Greene',
 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6200
 Greene 9500
 Transaktion 2 fragt die Gehälter für Banda, Greene und Hintz ab. Oracle AI Database verwendet Lesekonsistenz, um das Gehalt für Banda vor der nicht festgeschriebenen Aktualisierung anzuzeigen, die von Transaktion 1 vorgenommen wurde.
Keine Aktion. 
SQL> UPDATE employees
  SET salary = 9900
  WHERE last_name='Greene';
 Transaktion 2 aktualisiert das Gehalt für Greene erfolgreich, weil Transaktion 1 nur die Banda-Zeile gesperrt hat. 
SQL> INSERT INTO
  employees (employee_id,
  last_name, email,
  hire_date, job_id)
  VALUES (210, 'Hintz',
  'JHINTZ', SYSDATE,
  'SH_CLERK');
 Keine Aktion. Transaktion 1 fügt eine Zeile für den Mitarbeiter Hintz ein, schreibt aber nicht fest.
Keine Aktion. 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
  ('Banda', 'Greene',
 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6200
 Greene 9900

Transaktion 2 fragt die Gehälter der Angestellten Banda, Greene und Hintz ab.

Transaktion 2 sieht eine eigene Gehaltsaktualisierung für Greene. In Transaktion 2 wird die nicht festgeschriebene Gehaltsaktualisierung für Banda oder die Hintz-Einfügung für Transaktion 1 nicht angezeigt.
Keine Aktion. 
SQL> UPDATE employees SET
 salary = 6300 WHERE
  last_name = 'Banda';

  -- prompt does not return
Transaktion 2 versucht, die Zeile für Banda zu aktualisieren, die derzeit von Transaktion 1 gesperrt ist. Dadurch wird ein unvereinbarer Schreibvorgang erstellt. Transaktion 2 wartet, bis Transaktion 1 endet. 
SQL> COMMIT;
 Keine Aktion. Transaktion 1 schreibt seine Arbeit fest und beendet die Transaktion.
Keine Aktion. 
1 row updated.

  SQL>
 Die Sperre für die Banda-Zeile ist jetzt freigegeben, sodass Transaktion 2 mit der Aktualisierung des Gehalts für Banda fortfährt.
Keine Aktion. 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
 ('Banda', 'Greene',
  'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6300
 Greene 9900
 Hintz
 Transaktion 2 fragt die Gehälter der Angestellten Banda, Greene und Hintz ab. Die Hintz-Einfügung, die von Transaktion 1 festgeschrieben wurde, ist jetzt für Transaktion 2 sichtbar. Transaktion 2 sieht eine eigene Aktualisierung des Banda-Gehalts.
Keine Aktion. 
COMMIT;
 Transaktion 2 schreibt seine Arbeit fest und beendet die Transaktion. 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
  ('Banda', 'Greene',
 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6300
 Greene 9900
 Hintz
 Keine Aktion. Session 1 fragt die Zeilen für Banda, Greene und Hintz ab. Das Gehalt für Banda ist 6300, das ist die Aktualisierung von Transaktion 2. Die Aktualisierung von Bandas Gehalt auf 7000, die durch Transaktion 1 vorgenommen wurde, ist jetzt "verloren".

Siehe:

Serialisierbare Isolationsebene

In der serialisierbaren Isolationsebene werden für eine Transaktion nur Änderungen angezeigt, die zum Zeitpunkt der Transaktion festgeschrieben wurden, nicht die Abfrage und Änderungen, die von der Transaktion selbst vorgenommen wurden.

Eine serialisierbare Transaktion wird in einer Umgebung ausgeführt, in der es so aussieht, als würden keine anderen Benutzer Daten in der Datenbank ändern. Serialisierbare Isolierung eignet sich für Umgebungen:

Bei serialisierbarer Isolation erstreckt sich die Lesekonsistenz, die normalerweise auf Anweisungsebene erhalten wird, auf die gesamte Transaktion. Jede Zeile, die von der Transaktion gelesen wird, wird beim erneuten Lesen sicher gleich sein. Jede Abfrage gibt garantiert dieselben Ergebnisse für die Dauer der Transaktion zurück, sodass Änderungen, die von anderen Transaktionen vorgenommen wurden, für die Abfrage nicht sichtbar sind, unabhängig davon, wie lange sie ausgeführt wurde. Bei serialisierbaren Transaktionen werden keine Dirty-Lesevorgänge, Fuzzy-Lesevorgänge oder Phantom-Lesevorgänge ausgeführt.

Mit Oracle AI Database kann eine serialisierbare Transaktion eine Zeile nur ändern, wenn Änderungen an der Zeile, die von anderen Transaktionen vorgenommen wurden, bereits festgeschrieben wurden, als die serialisierbare Transaktion begann. Die Datenbank generiert einen Fehler, wenn eine serialisierbare Transaktion versucht, Daten zu aktualisieren oder zu löschen, die von einer anderen Transaktion geändert wurden, die nach dem Beginn der serialisierbaren Transaktion festgeschrieben wurde:

ORA-08177: Cannot serialize access for this transaction

Wenn eine serialisierbare Transaktion mit dem Fehler ORA-08177 nicht erfolgreich verläuft, kann eine Anwendung mehrere Aktionen ausführen, darunter:

Die folgende Tabelle zeigt, wie eine serialisierbare Transaktion mit anderen Transaktionen interagiert. Wenn die serialisierbare Transaktion nicht versucht, eine Zeile zu ändern, die von einer anderen Transaktion festgeschrieben wurde, nachdem die serialisierbare Transaktion begonnen hat, wird ein serialisiertes Zugriffsproblem vermieden.

Tabelle 3: Serialisierbare Transaktion

Session 1 Session 2 Erläuterung 
SQL> SELECT last_name, salary FROM employees WHERE
  last_name IN ('Banda',
  'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 6200
 Greene 9500
 Keine Aktion. Sitzung 1 fragt die Gehälter für Banda, Greene und Hintz ab. Kein Mitarbeiter mit dem Namen Hintz gefunden. 
SQL> UPDATE employees
  SET salary = 7000
  WHERE last_name='Banda';
 Keine Aktion. Sitzung 1 beginnt Transaktion 1, indem das Banda-Gehalt aktualisiert wird. Die Standardisolationsebene ist READ COMMITTED.
Keine Aktion. 
SQL> SET TRANSACTION
  ISOLATION LEVEL SERIALIZABLE;
 Session 2 startet Transaktion 2 und setzt sie auf die Isolationsebene SERIALIZABLE.
Keine Aktion. 
SQL> SELECT last_name, salary FROM employees
  WHERE last_name IN
  ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------ ----------
 Banda 6200
 Greene 9500
 Transaktion 2 fragt die Gehälter für Banda, Greene und Hintz ab. Oracle AI Database verwendet Lesekonsistenz, um das Gehalt für Banda vor der nicht festgeschriebenen Aktualisierung anzuzeigen, die von Transaktion 1 vorgenommen wurde.
Keine Aktion. 
SQL> UPDATE employees
  SET salary = 9900
  WHERE last_name = 'Greene';
 Transaktion 2 aktualisiert das Greene-Gehalt erfolgreich, weil nur die Banda-Zeile gesperrt ist. 
SQL> INSERT INTO employees
  (employee_id, last_name,
  email, hire_date, job_id)
  VALUES (210, 'Hintz',
  'JHINTZ', SYSDATE,'SH_CLERK');
 Keine Aktion. Transaktion 1 fügt eine Zeile für den Mitarbeiter Hintz ein. 
SQL> COMMIT;
 Keine Aktion. Transaktion 1 schreibt seine Arbeit fest und beendet die Transaktion. 
SQL> SELECT last_name, salary
  FROM employees
  WHERE last_name IN
  ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 7000
 Greene 9500
 Hintz
 
SQL> SELECT last_name, salary FROM employees
  WHERE last_name IN
 ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ---------
 Banda 6200
 Greene 9900

Sitzung 1 fragt die Gehälter der Angestellten Banda, Greene und Hintz ab und sieht Änderungen, die durch Transaktion 1 festgeschrieben wurden. In Sitzung 1 wird das nicht festgeschriebene Greene-Update von Transaktion 2 nicht angezeigt.

Transaktion 2 fragt die Gehälter der Angestellten Banda, Greene und Hintz ab. Durch die Lesekonsistenz von Oracle AI Database wird sichergestellt, dass das von Transaktion 1 festgeschriebene Hintz Insert- und Banda-Update nicht für Transaktion 2 sichtbar ist. Transaktion 2 sieht eine eigene Aktualisierung des Greene-Gehalts.

Keine Aktion. 
COMMIT;
 Transaktion 2 schreibt seine Arbeit fest und beendet die Transaktion. 
SQL> SELECT last_name, salary
  FROM employees
  WHERE last_name IN
  ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 7000
 Greene 9900
 Hintz
 
SQL> SELECT last_name, salary
 FROM employees
  WHERE last_name IN
  ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ---------
 Banda 7000
 Greene 9900
 Hintz
 In beiden Sitzungen werden die Gehälter für Banda, Greene und Hintz abgefragt. In jeder Session werden alle festgeschriebenen Änderungen angezeigt, die von Transaktion 1 und Transaktion 2 vorgenommen wurden. 
SQL> UPDATE employees
  SET salary = 7100
  WHERE last_name = 'Hintz';
 Keine Aktion. Sitzung 1 beginnt Transaktion 3 durch Aktualisierung des Hintz-Gehalts. Die Standardisolationsebene für Transaktion 3 ist READ COMMITTED.
Keine Aktion. 
SQL> SET TRANSACTION
  ISOLATION LEVEL SERIALIZABLE;
 Session 2 startet Transaktion 4 und setzt sie auf die Isolationsebene SERIALIZABLE.
Keine Aktion. 
SQL> UPDATE employees
  SET salary = 7200
  WHERE last_name = 'Hintz';

  -- prompt does not return
 Transaktion 4 versucht, das Gehalt für Hintz zu aktualisieren, ist jedoch blockiert, da Transaktion 3 die Hintz-Zeile gesperrt hat. Transaktions-4-Queues hinter Transaktion 3. 
SQL> COMMIT;
 Keine Aktion. Transaktion 3 schreibt die Aktualisierung des Hintz-Gehalts fest und beendet die Transaktion.
Keine Aktion. 
UPDATE employees
  SET salary = 7200
  WHERE last_name = 'Hintz'
 *
 ERROR at line 1:
  ORA-08177: can't
  serialize access for
  this transaction
 Der Commit, der Transaktion 3 beendet, führt dazu, dass die Hintz-Aktualisierung in Transaktion 4 mit dem Fehler ORA-08177 nicht erfolgreich verläuft. Der Problemfehler tritt auf, weil Transaktion 3 das Hintz-Update nach Transaktion 4 festgeschrieben hat.
Keine Aktion. 
SQL> ROLLBACK;
 Session 2 setzt Transaktion 4 zurück, wodurch die Transaktion beendet wird.
Keine Aktion. 
SQL> SET TRANSACTION
  ISOLATION LEVEL SERIALIZABLE;
 Session 2 startet Transaktion 5 und setzt sie auf die Isolationsebene SERIALIZABLE.
Keine Aktion. 
SQL> SELECT last_name,
  salary FROM employees
  WHERE last_name IN
  ('Banda', 'Greene', 'Hintz');

  LAST_NAME SALARY
 ------------- ----------
 Banda 7000
 Greene 9900
 Hintz 7100
 Transaktion 5 fragt die Gehälter für Banda, Greene und Hintz ab. Die von Transaktion 3 festgeschriebene Hintz-Gehaltsaktualisierung ist sichtbar.
Keine Aktion. 
SQL> UPDATE employees
  SET salary = 7200
  WHERE last_name='Hintz';

  1 row updated.

Transaktion 5 aktualisiert das Hintz-Gehalt auf einen anderen Wert. Da die von Transaktion 3 vorgenommene Hintz-Aktualisierung vor dem Start von Transaktion 5 festgeschrieben wurde, wird das Problem des serialisierten Zugriffs vermieden.

Hinweis: Wenn eine andere Transaktion die Hintz-Zeile aktualisiert und festgeschrieben hat, nachdem Transaktion 5 gestartet wurde, tritt das Problem des serialisierten Zugriffs erneut auf.

Keine Aktion. 
SQL> COMMIT;
Session 2 schreibt das Update ohne Probleme fest und beendet die Transaktion.

Siehe:

Schreibgeschützte Isolationsebene

Die schreibgeschützte Isolationsebene ähnelt der serialisierbaren Isolationsebene. Bei schreibgeschützten Transaktionen können Daten jedoch nur in der Transaktion geändert werden, wenn der Benutzer SYS ist.

Schreibgeschützte Transaktionen sind nicht anfällig für den Fehler ORA-08177. Schreibgeschützte Transaktionen sind nützlich, um Berichte zu generieren, in denen der Inhalt im Hinblick auf den Zeitpunkt des Transaktionsbeginns konsistent sein muss.

Oracle AI Database erreicht Lesekonsistenz, indem Daten nach Bedarf aus den Undo-Segmenten rekonstruiert werden. Da Undo-Segmente zirkulär verwendet werden, kann die Datenbank Undo-Daten überschreiben. Bei Berichten mit langer Ausführungszeit besteht das Risiko, dass Undo-Daten, die für die Lesekonsistenz erforderlich sind, von einer anderen Transaktion wiederverwendet wurden. Dadurch wird ein snapshot too old-Fehler ausgelöst. Wenn Sie einen Undo-Aufbewahrungszeitraum festlegen, der die Mindestdauer ist, während der die Datenbank versucht, alte Undo-Daten vor dem Überschreiben beizubehalten, wird dieses Problem angemessen vermieden.

Siehe:

Oracle AI Database-Sperrmechanismus - Überblick

Ein Sperre ist ein Mechanismus, der destruktive Interaktionen verhindert.

Interaktionen sind destruktiv, wenn sie Daten fälschlicherweise aktualisieren oder zugrunde liegende Datenstrukturen falsch ändern, zwischen Transaktionen, die auf gemeinsame Daten zugreifen. Sperren spielen eine entscheidende Rolle bei der Aufrechterhaltung des gleichzeitigen Datenbankzugriffs und der Konsistenz.

Übersicht über das Sperrverhalten

Die Datenbank verwaltet verschiedene Arten von Sperren, je nachdem, welcher Vorgang die Sperre erhalten hat.

Im Allgemeinen verwendet die Datenbank zwei Arten von Sperren: exklusive Sperren und Freigabesperren. Für eine Ressource wie eine Zeile oder eine Tabelle kann nur eine exklusive Sperre abgerufen werden. Für eine einzelne Ressource können jedoch viele Freigabesperren abgerufen werden.

Sperren wirken sich auf die Interaktion von Lesern und Autoren aus. Ein Reader ist eine Abfrage einer Ressource, während ein Writer eine Anweisung ist, die eine Ressource ändert. Die folgenden Regeln fassen das Sperrverhalten von Oracle AI Database für Reader und Writer zusammen:

Siehe:

Verwendung von Sperren

In einer Einzelbenutzerdatenbank sind keine Sperren erforderlich, da nur ein Benutzer Informationen ändert. Wenn jedoch mehrere Benutzer auf Daten zugreifen und diese ändern, muss die Datenbank eine Möglichkeit bieten, eine gleichzeitige Änderung derselben Daten zu verhindern.

Sperren erfüllen die folgenden wichtigen Datenbankanforderungen:

Oracle AI Database bietet über seine Sperrmechanismen gleichzeitigen Datenzugriff, Konsistenz und Integrität zwischen Transaktionen. Das Sperren erfolgt automatisch und erfordert keine Benutzeraktion.

Die Notwendigkeit von Sperren kann durch eine gleichzeitige Aktualisierung einer einzelnen Zeile veranschaulicht werden. Im folgenden Beispiel stellt eine einfache webbasierte Anwendung dem Endbenutzer eine E-Mail-Adresse und Telefonnummer des Mitarbeiters zur Verfügung. Die Anwendung verwendet eine UPDATE-Anweisung, wie die folgende, um die Daten zu ändern:

UPDATE employees
SET    email = ?, phone_number = ?
WHERE  employee_id = ?
AND    email = ?
AND    phone_number = ?

In der vorherigen UPDATE-Anweisung sind die E-Mail- und Telefonnummernwerte in der WHERE-Klausel die ursprünglichen, unveränderten Werte für den angegebenen Mitarbeiter. Mit dieser Aktualisierung wird sichergestellt, dass die von der Anwendung geänderte Zeile nicht geändert wurde, nachdem die Anwendung zuletzt gelesen und dem Benutzer angezeigt wurde. Auf diese Weise vermeidet die Anwendung das verlorene Updateproblem, bei dem ein Benutzer Änderungen überschreibt, die von einem anderen Benutzer vorgenommen wurden, wodurch die Aktualisierung durch den zweiten Benutzer verloren geht (Tabelle 12-2 zeigt ein Beispiel für eine verlorene Aktualisierung). Tabelle 12-4 zeigt die Reihenfolge der Ereignisse, wenn zwei Sessions versuchen, dieselbe Zeile in der Tabelle employees ungefähr gleichzeitig zu ändern.

Tabelle 4: Beispiel für Zeilensperren

T Session 1 Session 2 Beschreibung
t0 
SELECT employee_id as ID,
  email, phone_number
  FROM hr.employees
  WHERE last_name='Himuro';
ID EMAIL PHONE_NUMBER
 --- ------- ------------
 118 GHIMURO 515.127.4565
   In Sitzung 1 fragt der hr1-Benutzer hr.employees nach dem Himuro-Datensatz ab und zeigt die Attribute employee_id (118), E-Mail (GHIMURO) und Telefonnummer (515.127.4565) an.
t1   
SELECT employee_id as ID,
 email, phone_number
  FROM hr.employees
  WHERE last_name='Himuro';
ID EMAIL PHONE_NUMBER
 --- ------- ------------
 118 GHIMURO 515.127.4565
 In Sitzung 2 fragt der hr2-Benutzer hr.employees nach dem Himuro-Datensatz ab und zeigt die Attribute employee_id (118), E-Mail (GHIMURO) und Telefonnummer (515.127.4565) an.
t2 
UPDATE hr.employees SET
  phone_number='515.555.1234'
 WHERE employee_id=118
 AND email='GHIMURO'
 AND phone_number =
  '515.127.4565';

  1 row updated.
   In Session 1 aktualisiert der Benutzer hr1 die Telefonnummer in der Zeile in 515.555.1234, wodurch eine Sperre für die Zeile GHIMURO angefordert wird.
t3   
UPDATE hr.employees SET
  phone_number='515.555.1235'
 WHERE employee_id=118
 AND email='GHIMURO'
 AND phone_number =
  '515.127.4565';

  -- SQL*Plus does not show
 -- a row updated message or
 -- return the prompt.

In Session 2 versucht der Benutzer hr2, dieselbe Zeile zu aktualisieren, wird jedoch blockiert, weil hr1 die Zeile derzeit verarbeitet.

Das versuchte Update durch hr2 erfolgt fast gleichzeitig mit dem Update hr1.

t4 
COMMIT;

  Commit complete.
  

In Session 1 schreibt der Benutzer hr1 die Transaktion fest.

Der Commit macht die Änderung für Himuro dauerhaft und entsperrt Sitzung 2, die gewartet hat.
t5   
0 rows updated.

In Session 2 erkennt der Benutzer hr2, dass die Zeile GHIMURO so geändert wurde, dass sie nicht mehr mit ihrem Prädikat übereinstimmt.

Da die Prädikate nicht übereinstimmen, werden in Session 2 keine Datensätze aktualisiert.
t6 
UPDATE hr.employees SET
  phone_number='515.555.1235'
 WHERE employee_id=118
 AND email='GHIMURO' AND
  phone_number='515.555.1234';

  1 row updated.
   In Sitzung 1 erkennt der Benutzer hr1, dass er die Zeile GHIMURO mit der falschen Telefonnummer aktualisiert hat. Der Benutzer startet eine neue Transaktion und aktualisiert die Telefonnummer in der Zeile in 515.555.1235, wodurch die Zeile GHIMURO gesperrt wird.
t7   
SELECT employee_id as ID,
  email, phone_number
  FROM hr.employees
  WHERE last_name='Himuro';
ID EMAIL PHONE_NUMBER
 --- ------- ------------
 118 GHIMURO 515.555.1234
 In Sitzung 2 fragt der Benutzer hr2 hr.employees nach dem Himuro-Datensatz ab. Der Datensatz zeigt die von Sitzung 1 festgeschriebene Aktualisierung der Telefonnummer unter t4. Durch die Lesekonsistenz von Oracle AI Database wird sichergestellt, dass die nicht festgeschriebene Änderung in Session 2 unter t6 nicht angezeigt wird.
t8   
UPDATE hr.employees SET
  phone_number='515.555.1235
  WHERE employee_id=118
 AND email='GHIMURO'
 AND phone_number =
 '515.555.1234';

  -- SQL*Plus does not show
 -- a row updated message or
 -- return the prompt.
 In Session 2 versucht der Benutzer hr2, dieselbe Zeile zu aktualisieren, wird jedoch blockiert, weil hr1 die Zeile derzeit verarbeitet.
t9 
ROLLBACK;

  Rollback complete.
   In Session 1 rollt der Benutzer hr1 die Transaktion zurück, wodurch sie beendet wird.
t10   
1 row updated.
 In Sitzung 2 ist die Aktualisierung der Telefonnummer erfolgreich, da das Update für Sitzung 1 zurückgesetzt wurde. Die Zeile GHIMURO stimmt mit ihrem Prädikat überein, sodass die Aktualisierung erfolgreich verläuft.
t11   
COMMIT;

  Commit complete.
 Session 2 schreibt die Aktualisierung fest und beendet die Transaktion.

Bei der Ausführung von SQL-Anweisungen erhält Oracle AI Database automatisch die erforderlichen Sperren. Beispiel: Bevor die Datenbank zulässt, dass eine Session Daten ändert, muss die Session die Daten zunächst sperren. Die Sperre gibt der Session die exklusive Kontrolle über die Daten, sodass keine andere Transaktion die gesperrten Daten ändern kann, bis die Sperre aufgehoben wird.

Da die Sperrmechanismen von Oracle AI Database eng an die Transaktionskontrolle gebunden sind, müssen Anwendungsdesigner Transaktionen nur ordnungsgemäß definieren, und Oracle AI Database verwaltet Sperren automatisch. Benutzer müssen keine Ressourcen explizit sperren, obwohl Benutzer mit Oracle AI Database auch Daten manuell sperren können.

In den folgenden Abschnitten werden Konzepte erläutert, die wichtig sind, um zu verstehen, wie Oracle AI Database den gleichzeitigen Datenzugriff erreicht.

Siehe auch: Oracle AI Database PL/SQL Packages and Types Reference enthält Informationen zum Package OWA_OPT_LOCK, das Unterprogramme enthält, die dazu beitragen können, verlorene Updates zu verhindern.

Sperrmodi

Oracle AI Database verwendet automatisch die niedrigste anwendbare Einschränkungsebene, um den höchsten Grad an gleichzeitigem Datenzugriff bei gesicherter Datenintegration zu gewährleisten.

Je weniger restriktiv die Ebene ist, desto verfügbarer sind die Daten für den Zugriff durch andere Benutzer. Umgekehrt, je restriktiver die Ebene ist, desto begrenzter sind andere Transaktionen in den Arten von Sperren, die sie erwerben können.

Oracle AI Database verwendet zwei Sperrmodi in einer Mehrbenutzerdatenbank:

Angenommen, eine Transaktion verwendet eine SELECT ... FOR UPDATE-Anweisung, um eine einzelne Tabellenzeile auszuwählen. Die Transaktion erwirbt eine exklusive Zeilensperre und eine Tabellensperre für Zeilenfreigaben. Mit der Zeilensperre können andere Sessions Zeilen ändern, außer der gesperrten Zeile, während die Tabellensperre verhindert, dass Sessions die Struktur der Tabelle ändern. Somit kann die Datenbank so viele Anweisungen wie möglich ausführen.

Konvertierung und Eskalation sperren

Oracle AI Database führt bei Bedarf eine Sperrenkonvertierung durch.

Bei der Lock-Konvertierung konvertiert die Datenbank automatisch eine Tabellensperre mit geringerer Einschränkung in eine höhere Einschränkung. Beispiel: Eine Transaktion gibt eine SELECT ... FOR UPDATE für einen Mitarbeiter aus und aktualisiert die gesperrte Zeile später. In diesem Fall konvertiert die Datenbank die Zeilenfreigabetabellensperre automatisch in eine Zeilensperre. Eine Transaktion enthält exklusive Zeilensperren für alle Zeilen, die in die Transaktion eingefügt, aktualisiert oder gelöscht wurden. Da Zeilensperren mit dem höchsten Grad an Einschränkung erfasst werden, ist keine Sperrkonvertierung erforderlich oder erfolgt.

Die Sperrkonvertierung unterscheidet sich von der Sperreskalation, die auftritt, wenn zahlreiche Sperren auf einer Granularitätsebene gehalten werden (z.B. Zeilen) und eine Datenbank die Sperren auf eine höhere Granularitätsebene erhöht (z.B. Tabelle). Wenn eine Session viele Zeilen in einer Tabelle sperrt, eskalieren einige Datenbanken die Zeilensperren automatisch an eine einzelne Tabelle. Die Anzahl der Sperren nimmt ab, aber die Einschränkung dessen, was gesperrt ist, nimmt zu.

Oracle AI Database eskaliert nie Sperren. Lock-Eskalation erhöht die Wahrscheinlichkeit von Deadlocks erheblich. Angenommen, ein System versucht, Sperren im Namen von Transaktion 1 zu eskalieren, dies ist jedoch aufgrund der Sperren von Transaktion 2 nicht möglich. Ein Deadlock wird erstellt, wenn Transaktion 2 auch eine Lock-Eskalation derselben Daten erfordert, bevor sie fortgesetzt werden kann.

Sperrdauer

Oracle AI Database gibt automatisch eine Sperre frei, wenn ein Ereignis eintritt, sodass die Transaktion die Ressource nicht mehr benötigt.

In der Regel enthält die Datenbank Sperren, die von Anweisungen innerhalb einer Transaktion für die Dauer der Transaktion erworben wurden. Diese Sperren verhindern destruktive Störungen wie schmutzige Lesevorgänge, verlorene Updates und destruktive DDL aus gleichzeitigen Transaktionen. Hinweis: Eine Tabellensperre, die für eine untergeordnete Tabelle aufgrund eines nicht indizierten Fremdschlüssels vorgenommen wurde, wird für die Dauer der Anweisung und nicht für die Transaktion gehalten. Darüber hinaus ermöglicht das Package DBMS_LOCK, dass benutzerdefinierte Sperren nach Belieben freigegeben und zugewiesen und sogar über Transaktionsgrenzen hinweg gehalten werden können.

Oracle AI Database gibt alle Sperren frei, die von den Anweisungen innerhalb einer Transaktion erworben wurden, wenn sie festgeschrieben oder zurückgesetzt werden. Oracle AI Database gibt auch Sperren frei, die nach einem Savepoint erworben wurden, wenn ein Rollback zum Savepoint durchgeführt wird. Allerdings können nur Transaktionen, die nicht auf die zuvor gesperrten Ressourcen warten, Sperren für die jetzt verfügbaren Ressourcen anfordern. Wartende Transaktionen warten weiter, bis die ursprüngliche Transaktion festgeschrieben oder vollständig zurückgesetzt wurde.

Siehe:

Sperren und Deadlocks

Ein Deadlock ist eine Situation, in der zwei oder mehr Benutzer auf Daten warten, die voneinander gesperrt sind. Deadlocks verhindern, dass einige Transaktionen weiterarbeiten.

Oracle AI Database erkennt Deadlocks automatisch und löst sie auf, indem eine Anweisung, die am Deadlock beteiligt ist, zurückgesetzt wird und eine Gruppe der widersprüchlichen Zeilensperren freigegeben wird. Die Datenbank gibt eine entsprechende Meldung an die Transaktion zurück, für die ein Rollback auf Anweisungsebene durchgeführt wird. Die zurückgerollte Anweisung gehört zu der Transaktion, die den Deadlock erkennt. Normalerweise sollte die signalisierte Transaktion explizit zurückgerollt werden. Sie kann jedoch die zurückgerollte Anweisung wiederholen, nachdem sie gewartet hat. In Tabelle 12-5 werden zwei Transaktionen in einem Deadlock dargestellt.

Tabelle 5: Transaktionen mit Deadlock

T Session 1 Session 2 Erläuterung
t0 
SQL> UPDATE employees
  SET salary = salary*1.1
 WHERE employee_id = 100;

  1 row updated.
 
SQL> UPDATE employees
 SET salary = salary*1.1
 WHERE employee_id = 200;

  1 row updated.
 Sitzung 1 startet Transaktion 1 und aktualisiert das Gehalt für Mitarbeiter 100. Sitzung 2 startet Transaktion 2 und aktualisiert das Gehalt für Mitarbeiter 200. Kein Problem, da jede Transaktion nur die Zeile sperrt, die aktualisiert werden soll.
t1 
SQL> UPDATE employees
  SET salary = salary*1.1
 WHERE employee_id = 200;

  -- prompt does not return
 
SQL> UPDATE employees
 SET salary = salary*1.1
 WHERE employee_id = 100;

  -- prompt does not return

Transaktion 1 versucht, die Zeile "Mitarbeiter 200" zu aktualisieren, die derzeit durch Transaktion 2 gesperrt ist. Transaktion 2 versucht, die Zeile "Mitarbeiter 100" zu aktualisieren, die derzeit durch Transaktion 1 gesperrt ist.

Ein Deadlock führt dazu, dass keine Transaktion die Ressource abrufen kann, die sie zum Fortfahren oder Beenden benötigt. Unabhängig davon, wie lange jede Transaktion wartet, werden die widersprüchlichen Sperren gehalten.
t2 
UPDATE employees
 *
 ERROR at line 1:
 ORA-00060: deadlock detected
 while waiting for resource

  SQL>
  

Transaktion 1 signalisiert den Deadlock und rollt die unter t1 ausgegebene UPDATE-Anweisung zurück. Das unter t0 vorgenommene Update wird jedoch nicht zurückgesetzt. Die Eingabeaufforderung wird in Sitzung 1 zurückgegeben.

Hinweis: Nur eine Session im Deadlock erhält den Deadlock-Fehler, aber jede Session kann den Fehler erhalten.

t3 
SQL> COMMIT;

  Commit complete.
   Session 1 schreibt die unter t0 vorgenommene Aktualisierung fest und beendet Transaktion 1. Das unter t1 erfolglose Update wurde nicht festgeschrieben.
t4   
1 row updated.

  SQL>
 Das Update unter t1 in Transaktion 2, das von Transaktion 1 blockiert wurde, wird ausgeführt. Die Eingabeaufforderung wird zurückgegeben.
t5   
SQL> COMMIT;

  Commit complete.
 Session 2 schreibt die Aktualisierungen fest, die unter t0 und t1 vorgenommen wurden, wodurch Transaktion 2 beendet wird.

Deadlocks treten am häufigsten auf, wenn Transaktionen die Standardsperre von Oracle AI Database explizit außer Kraft setzen. Da Oracle AI Database keine Sperren eskaliert und keine Lesesperren für Abfragen verwendet, sondern Sperren auf Zeilenebene (und nicht auf Seitenebene) verwendet, treten Deadlocks selten auf.

Siehe:

Automatische Sperren - Überblick

Oracle AI Database sperrt eine Ressource automatisch im Namen einer Transaktion, um zu verhindern, dass andere Transaktionen etwas tun, das exklusiven Zugriff auf dieselbe Ressource erfordert.

Die Datenbank erwirbt automatisch verschiedene Arten von Sperren auf unterschiedlichen Einschränkungsebenen, abhängig von der Ressource und dem ausgeführten Vorgang. Hinweis: Die Datenbank sperrt beim Ausführen einfacher Lesevorgänge keine Zeilen.

Oracle AI Database-Sperren sind in die Kategorien unterteilt, die in der folgenden Tabelle angezeigt werden.

Tabelle 6: Sperrkategorien

Sperren Beschreibung Weitere Infos
DML-Sperren Daten schützen Beispiel: Tabellensperren sperren ganze Tabellen, während Zeilensperren ausgewählte Zeilen sperren. "DML-Sperren"
DDL-Sperren Schützen Sie die Struktur von Schemaobjekten. Beispiel: Dictionary-Definitionen von Tabellen und Views. "DDL-Sperren"
Systemsperren Schützen Sie interne Datenbankstrukturen wie Datendateien. Riegel, Mutexe und interne Schlösser sind vollautomatisch. "Systemsperren"

DML-Sperren

Eine DML-Sperre, die auch als Datensperre bezeichnet wird, garantiert die Integrität von Daten, auf die mehrere Benutzer gleichzeitig zugreifen.

Zum Beispiel verhindert eine DML-Sperre, dass zwei Kunden die letzte Kopie eines Buches kaufen, das von einem Online-Buchhändler verfügbar ist. DML-Sperren verhindern destruktive Interferenzen gleichzeitiger widersprüchlicher DML- oder DDL-Vorgänge.

DML-Anweisungen erfassen automatisch die folgenden Arten von Sperren:

In den folgenden Abschnitten ist das Akronym in Klammern nach jedem Sperr- oder Sperrmodus die Abkürzung, die im Sperrmonitor von Oracle Enterprise Manager (Enterprise Manager) verwendet wird. Enterprise Manager kann TM für eine Tabellensperre anzeigen, anstatt den Modus der Tabellensperre (wie RS oder SRX) anzugeben.

Zeilensperren (TX)

Eine Zeilensperre, die auch als TX-Sperre bezeichnet wird, ist eine Sperre für eine einzelne Tabellenzeile. Eine Transaktion erwirbt eine Zeilensperre für jede Zeile, die von einer INSERT-, UPDATE-, DELETE-, MERGE- oder SELECT ... FOR UPDATE-Anweisung geändert wurde. Die Zeilensperre ist vorhanden, bis die Transaktion festgeschrieben oder zurückgesetzt wird.

Zeilensperren dienen in erster Linie als Queuing-Mechanismus, um zu verhindern, dass zwei Transaktionen dieselbe Zeile ändern. Die Datenbank sperrt eine geänderte Zeile immer im exklusiven Modus, sodass andere Transaktionen die Zeile erst ändern können, wenn die Transaktion mit der Sperre festgeschrieben oder zurückgesetzt wird. Die Zeilensperrung bietet die bestmögliche Kornsperre und bietet so den bestmöglichen gleichzeitigen Zugriff und Durchsatz.

Hinweis: Wenn eine Transaktion aufgrund eines Instanzfehlers der Datenbank beendet wird, stellt das Recovery auf Blockebene eine Zeile zur Verfügung, bevor die gesamte Transaktion wiederhergestellt wird.

Wenn eine Transaktion eine Sperre für eine Zeile erhält, erwirbt die Transaktion auch eine Sperre für die Tabelle, die diese Zeile enthält. Die Tabellensperre verhindert unvereinbare DDL-Vorgänge, die Datenänderungen in einer aktuellen Transaktion außer Kraft setzen würden. In Abbildung 12-2 wird eine Aktualisierung der dritten Zeile in einer Tabelle dargestellt. Oracle AI Database setzt automatisch eine exklusive Sperre für die aktualisierte Zeile und eine subexklusive Sperre für die Tabelle.

Abbildung 2: Zeilen- und Tabellensperren

Beschreibung der Abbildung cncpt265.gif

Zeilensperren und Nebenläufigkeit

Dieses Szenario veranschaulicht, wie Oracle AI Database Zeilensperren für den gleichzeitigen Zugriff verwendet.

Drei Sessions fragen dieselben Zeilen gleichzeitig ab. Session 1 und 2 nehmen weiterhin nicht festgeschriebene Aktualisierungen an verschiedenen Zeilen vor, während Session 3 keine Aktualisierungen vornimmt. Jede Sitzung sieht ihre eigenen nicht festgeschriebenen Aktualisierungen, aber nicht die nicht festgeschriebenen Aktualisierungen einer anderen Sitzung.

Tabelle 7: Gleichzeitiger Datenzugriff - Beispiel

T Session 1 Session 2 Session 3 Erläuterung
t0 
SELECT employee_id,
 salary
 FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 
SELECT employee_id,
 salary
  FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 
SELECT employee_id,
  salary
  FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 Drei verschiedene Sitzungen fragen gleichzeitig die Personalnummer und das Gehalt der Angestellten 100 und 101 ab. Die von jeder Abfrage zurückgegebenen Ergebnisse sind identisch.
t1 
UPDATE hr.employees
 SET salary =
  salary+100
 WHERE
  employee_id=100;
     Sitzung 1 aktualisiert das Gehalt von Mitarbeiter 100, wird jedoch nicht festgeschrieben. Bei der Aktualisierung erwirbt der Writer nur für die aktualisierte Zeile eine Sperre auf Zeilenebene, wodurch andere Writer daran gehindert werden, diese Zeile zu ändern.
t2 
SELECT employee_id,
 salary
  FROM employees
  WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 612
 101 600
 
SELECT employee_id,
 salary
 FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 
SELECT employee_id,
  salary
  FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 Jede Session setzt gleichzeitig die ursprüngliche Abfrage ab. Sitzung 1 zeigt das Gehalt von 612, das sich aus der Aktualisierung t1 ergibt. Die Reader in Session 2 und 3 geben Zeilen sofort zurück und warten nicht, bis Session 1 die Transaktion beendet. Die Datenbank verwendet die Multiversions-Lesekonsistenz, um das Gehalt so anzuzeigen, wie es vor der Aktualisierung in Sitzung 1 vorhanden war.
t3   
UPDATE hr.employee
 SET salary =
 salary+100
 WHERE
  employee_id=101;
   Sitzung 2 aktualisiert das Gehalt von Mitarbeiter 101, schreibt die Transaktion jedoch nicht fest. Bei der Aktualisierung erwirbt der Writer eine Sperre auf Zeilenebene nur für die aktualisierte Zeile, sodass andere Writer diese Zeile nicht ändern können.
t4 
SELECT employee_id,
 salary
  FROM employees
  WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 612
 101 600
 
SELECT employee_id,
 salary
 FROM employees
  WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 700
 
SELECT employee_id,
  salary
  FROM employees
 WHERE employee_id
 IN ( 100, 101 );
EMPLOYEE_ID SALARY
 ----------- ------
 100 512
 101 600
 Jede Session setzt gleichzeitig die ursprüngliche Abfrage ab. Sitzung 1 zeigt das Gehalt von 612, das sich aus der Aktualisierung t1 ergibt, nicht aber die Gehaltsaktualisierung für Mitarbeiter 101, die in Sitzung 2 vorgenommen wurde. Der Leser in Sitzung 2 zeigt die in Sitzung 2 vorgenommene Gehaltsaktualisierung an, nicht jedoch die in Sitzung 1 vorgenommene Gehaltsaktualisierung. Der Reader in Sitzung 3 verwendet Lesekonsistenz, um die Gehälter vor der Änderung durch Sitzung 1 und 2 anzuzeigen.

Siehe:

Speicherung von Zeilensperren

Im Gegensatz zu einigen Datenbanken, die mit einem Lock Manager eine Liste von Sperren im Speicher verwalten, speichert Oracle AI Database Sperrinformationen im Datenblock, der die gesperrte Zeile enthält.

Die Datenbank verwendet einen Queuing-Mechanismus zum Erfassen von Zeilensperren. Wenn für eine Transaktion eine Sperre für eine entsperrte Zeile erforderlich ist, setzt die Transaktion eine Sperre im Datenblock. Jede von dieser Transaktion geänderte Zeile verweist auf eine Kopie der Transaktions-ID, die im Blockheader gespeichert ist.

Wenn eine Transaktion endet, bleibt die Transaktions-ID im Blockheader. Wenn eine andere Transaktion eine Zeile ändern möchte, verwendet sie die Transaktions-ID, um zu bestimmen, ob die Sperre aktiv ist. Wenn die Sperre aktiv ist, fordert die Session Sie auf, benachrichtigt zu werden, wenn die Sperre aufgehoben wird. Andernfalls erwirbt die Transaktion die Sperre.

Siehe:

Tabellensperren (TM)

Eine Tabellensperre, auch TM-Sperre genannt, wird von einer Transaktion angefordert, wenn eine Tabelle durch eine INSERT-, UPDATE-, DELETE-, MERGE-, SELECT- oder LOCK TABLE-Anweisung mit der FOR UPDATE-Klausel geändert wird.

Für DML-Vorgänge sind Tabellensperren erforderlich, um den DML-Zugriff auf die Tabelle im Namen einer Transaktion zu reservieren und DDL-Vorgänge zu verhindern, die mit der Transaktion in Konflikt stehen.

Eine Tabellensperre kann in einem der folgenden Modi gehalten werden:

Siehe:

Sperren und Fremdschlüssel

Oracle AI Database maximiert die Nebenläufigkeitskontrolle übergeordneter Schlüssel in Bezug auf abhängige Fremdschlüssel.

Das Sperrverhalten hängt davon ab, ob Fremdschlüsselspalten indiziert sind. Wenn Fremdschlüssel nicht indiziert sind, wird die untergeordnete Tabelle wahrscheinlich häufiger gesperrt, Deadlocks treten auf, und der gleichzeitige Zugriff wird verringert. Aus diesem Grund sollten Fremdschlüssel fast immer indiziert werden. Die einzige Ausnahme ist, wenn der übereinstimmende eindeutige Schlüssel oder Primärschlüssel nie aktualisiert oder gelöscht wird.

Sperren und nicht indizierte Fremdschlüssel

Die Datenbank erwirbt eine vollständige Tabellensperre für die untergeordnete Tabelle, wenn kein Index für die Fremdschlüsselspalte der untergeordneten Tabelle vorhanden ist. Eine Session ändert einen Primärschlüssel in der übergeordneten Tabelle (z.B. löscht eine Zeile oder ändert Primärschlüsselattribute) oder führt Zeilen in der übergeordneten Tabelle zusammen.

Wenn beide der folgenden Bedingungen zutreffen, erwirbt die Datenbank eine vollständige Tabellensperre für die untergeordnete Tabelle:

Angenommen, die Tabelle hr.departments ist ein übergeordnetes Element von hr.employees, das den nicht indizierten Fremdschlüssel employees.department_id enthält. Die folgende Abbildung zeigt eine Session, in der die Primärschlüsselattribute von Abteilung 60 in der Tabelle departments geändert werden.

Abbildung 3: Sperrmechanismen mit nicht indiziertem Fremdschlüssel

Beschreibung der Abbildung cncpt308.gif

In Abbildung 12-3 erwirbt die Datenbank während der Primärschlüsseländerung von Abteilung 60 eine vollständige Tabellensperre für employees. Mit dieser Sperre können andere Sessions die Tabelle employees abfragen, jedoch nicht aktualisieren. Beispiel: Veranstaltungen können keine Telefonnummern von Mitarbeitern aktualisieren. Die Tabellensperre für employees wird sofort freigegeben, nachdem die Änderung des Primärschlüssels in der Tabelle departments abgeschlossen wurde. Wenn mehrere Zeilen in departments Primärschlüsseländerungen durchlaufen, wird für jede in departments geänderte Zeile eine Tabellensperre für employees abgerufen und einmal freigegeben. Hinweis: DML für eine untergeordnete Tabelle fordert keine Tabellensperre für die übergeordnete Tabelle an.

Sperren und indizierte Fremdschlüssel

Die Datenbank fordert keine vollständige Tabellensperre für die untergeordnete Tabelle an, wenn eine Fremdschlüsselspalte in der untergeordneten Tabelle indiziert wird, und eine Session einen Primärschlüssel in der übergeordneten Tabelle ändert (z.B. eine Zeile löscht oder Primärschlüsselattribute ändert) oder Zeilen in der übergeordneten Tabelle zusammenführt.

Eine Sperre der übergeordneten Tabelle verhindert, dass Transaktionen exklusive Tabellensperren erhalten. DML in der übergeordneten oder untergeordneten Tabelle wird jedoch bei der Änderung des Primärschlüssels nicht verhindert. Diese Situation ist vorzuziehen, wenn Primärschlüsseländerungen in der übergeordneten Tabelle auftreten, während Aktualisierungen in der untergeordneten Tabelle vorgenommen werden. In Abbildung 12-4 ist die untergeordnete Tabelle employees mit einer indizierten Spalte department_id dargestellt. Bei einer Transaktion wird Abteilung 280 aus departments gelöscht. Dieser Löschvorgang führt nicht dazu, dass die Datenbank eine vollständige Tabellensperre für die Tabelle employees anfordert, wie in dem unter Sperren und nicht indizierte Fremdschlüssel beschriebenen Szenario beschrieben.

Abbildung 4: Sperrmechanismen mit indiziertem Fremdschlüssel

Beschreibung der Abbildung cncpt309.gif

Wenn die untergeordnete Tabelle ON DELETE CASCADE angibt, können Löschvorgänge aus der übergeordneten Tabelle zu Löschvorgängen aus der untergeordneten Tabelle führen. Beispiel: Das Löschen von Abteilung 280 kann dazu führen, dass Datensätze für Mitarbeiter in der gelöschten Abteilung aus employees gelöscht werden. In diesem Fall sind Warte- und Sperrregeln identisch mit denen, die Sie nach dem Löschen von Zeilen aus der übergeordneten Tabelle aus der untergeordneten Tabelle gelöscht haben.

Siehe:

DDL-Sperren

Eine DDL-(Data Dictionary-)Sperre schützt die Definition eines Schemaobjekts, während ein fortlaufender DDL-Vorgang das Objekt bearbeitet oder referenziert.

Nur einzelne Schemaobjekte, die geändert oder referenziert werden, werden während DDL-Vorgängen gesperrt. Die Datenbank sperrt nie das gesamte Data Dictionary.

Oracle AI Database erwirbt automatisch eine DDL-Sperre im Namen jeder DDL-Transaktion, die sie benötigt. Benutzer können DDL-Sperren nicht explizit anfordern. Beispiel: Wenn ein Benutzer eine gespeicherte Prozedur erstellt, erwirbt Oracle AI Database automatisch DDL-Sperren für alle Schemaobjekte, die in der Prozedurdefinition referenziert werden. Die DDL-Sperren verhindern, dass diese Objekte geändert oder gelöscht werden, bevor die Kompilierung der Prozedur abgeschlossen ist.

Exklusive DDL-Sperren

Eine exklusive DDL-Sperre verhindert, dass andere Sessions eine DDL- oder DML-Sperre erhalten.

Die meisten DDL-Vorgänge erfordern exklusive DDL-Sperren für eine Ressource, um destruktive Störungen mit anderen DDL-Vorgängen zu verhindern, die dasselbe Schemaobjekt ändern oder referenzieren könnten. Beispiel: DROP TABLE darf eine Tabelle nicht löschen, während ALTER TABLE ihr eine Spalte hinzufügt, und umgekehrt.

Exklusive DDL-Sperren dauern die Dauer der Ausführung von DDL-Anweisungen und des automatischen Commits. Wenn beim Erwerb einer exklusiven DDL-Sperre eine weitere DDL-Sperre für das Schemaobjekt durch einen anderen Vorgang gehalten wird, wartet die Erfassung, bis die ältere DDL-Sperre freigegeben wird, und fährt dann fort.

Siehe auch: "DDL-Sperren freigeben" beschreibt Situationen, in denen exklusive Sperren nicht erforderlich sind, um destruktive Störungen zu verhindern.

DDL-Sperren freigeben

Eine Freigabe-DDL-Sperre für eine Ressource verhindert destruktive Interferenzen mit unvereinbaren DDL-Vorgängen, ermöglicht jedoch den gleichzeitigen Datenzugriff für ähnliche DDL-Vorgänge.

Beispiel: Wenn eine CREATE PROCEDURE-Anweisung ausgeführt wird, erwirbt die enthaltende Transaktion gemeinsame DDL-Sperren für alle referenzierten Tabellen. Andere Transaktionen können gleichzeitig Prozeduren erstellen, die dieselben Tabellen referenzieren und gleichzeitig DDL-Sperren für gemeinsame Nutzung für dieselben Tabellen anfordern. Keine Transaktion kann jedoch eine exklusive DDL-Sperre für eine referenzierte Tabelle anfordern.

Eine Freigabe-DDL-Sperre dauert die Dauer der Ausführung von DDL-Anweisungen und des automatischen Commits. Somit wird eine Transaktion mit einer DDL-Freigabesperre gewährleistet, dass die Definition des referenzierten Schemaobjekts während der Transaktion konstant bleibt.

Aufbrechbare Parse-Sperren

Eine Parse-Sperre wird von einer SQL-Anweisung oder PL/SQL-Programmeinheit für jedes Schemaobjekt gehalten, das sie referenziert.

Parse-Sperren werden angefordert, sodass der zugehörige gemeinsam verwendete SQL-Bereich invalidiert werden kann, wenn ein referenziertes Objekt geändert oder gelöscht wird. Eine Parse-Sperre wird als breakable parse lock bezeichnet, da sie keine DDL-Vorgänge zulässt und unterbrochen werden kann, um widersprüchliche DDL-Vorgänge zuzulassen.

Während der Parse-Phase der Ausführung von SQL-Anweisungen wird im Shared Pool eine Parse-Sperre angefordert. Die Sperre wird gehalten, solange der Shared SQL-Bereich für diese Anweisung im Shared Pool verbleibt.

Siehe auch: "Shared Pool"

Systemsperren

Oracle AI Database verwendet verschiedene Arten von Systemsperren, um interne Datenbank- und Speicherstrukturen zu schützen. Auf diese Mechanismen kann nicht zugegriffen werden, da Benutzer keine Kontrolle über ihr Auftreten oder ihre Dauer haben.

Latches

Ein Latch ist ein einfacher Serialisierungsmechanismus auf niedriger Ebene, der den Mehrbenutzerzugriff auf gemeinsame Datenstrukturen, Objekte und Dateien koordiniert.

Latches schützen Shared Memory-Ressourcen vor Beschädigung, wenn mehrere Prozesse auf sie zugreifen. Insbesondere schützen Latches Datenstrukturen vor den folgenden Situationen:

In der Regel schützt ein einzelner Latch mehrere Objekte in der SGA. Beispiel: Hintergrundprozesse wie DBW und LGWR weisen Speicher aus dem Shared Pool zu, um Datenstrukturen zu erstellen. Um diesen Speicher zuzuweisen, verwenden diese Prozesse einen Shared Pool-Latch, der den Zugriff serialisiert, um zu verhindern, dass zwei Prozesse versuchen, den Shared Pool gleichzeitig zu prüfen oder zu ändern. Nachdem der Speicher zugewiesen wurde, müssen andere Prozesse möglicherweise auf Shared Pool-Bereiche zugreifen, wie den Bibliothekscache, der für das Parsen erforderlich ist. In diesem Fall verriegeln Prozesse nur den Library-Cache, nicht den gesamten Shared Pool.

Im Gegensatz zu Enqueue-Latches wie Zeilensperren lassen Latches keine Sessions in die Queue zu. Wenn ein Latch verfügbar wird, erhält die erste Session, die den Latch anfordert, exklusiven Zugriff darauf. Das Phänomen Latch Spinning tritt auf, wenn ein Prozess wiederholt einen Latch in einer Schleife anfordert, während Latch Sleep auftritt, wenn ein Prozess die CPU freigibt, bevor die Latch-Anforderung erneuert wird.

In der Regel erwirbt ein Oracle-Prozess einen Latch für eine extrem kurze Zeit, während er eine Datenstruktur bearbeitet oder betrachtet. Beispiel: Bei der Verarbeitung einer Gehaltsaktualisierung eines einzelnen Mitarbeiters kann die Datenbank Tausende von Latches abrufen und freigeben. Die Implementierung von Latches ist betriebssystemabhängig, insbesondere in Bezug darauf, ob und wie lange ein Prozess auf einen Latch wartet.

Eine Erhöhung der Verriegelung bedeutet eine Verringerung der Nebenläufigkeit. Beispiel: Bei übermäßigen Hard Parse-Vorgängen wird ein Konflikt für den Library-Cache-Latch erstellt. Die View V$LATCH enthält detaillierte Statistiken zur Latch-Nutzung für jeden Latch, einschließlich der Häufigkeit, mit der jeder Latch angefordert und gewartet wurde.

Siehe:

Mutexe

Ein gegenseitiges Ausschlussobjekt (mutex) ist ein Mechanismus auf niedriger Ebene, der verhindert, dass ein Objekt im Speicher beim Zugriff durch nebenläufige Prozesse veraltet oder beschädigt wird. Ein Mutex ähnelt einem Latch, während ein Latch normalerweise eine Gruppe von Objekten schützt, schützt ein Mutex ein einzelnes Objekt.

Mutexe bieten mehrere Vorteile:

Interne Sperren

Interne Sperren sind komplexere Mechanismen auf höherer Ebene als Verriegelungen und Mutexe und dienen verschiedenen Zwecken.

Die Datenbank verwendet die folgenden Arten von internen Sperren:

Siehe auch: "Data Dictionary-Cache"

Manuelle Datensperren - Überblick

Sie können die standardmäßigen Sperrmechanismen von Oracle AI Database manuell außer Kraft setzen.

Oracle AI Database führt Sperren automatisch durch, um den gleichzeitigen Datenzugriff, die Datenintegrität und die Lesekonsistenz auf Anweisungsebene sicherzustellen. Das Überschreiben der Standardsperre ist jedoch in folgenden Situationen nützlich:

Sie können die automatische Sperre von Oracle AI Database auf Session- oder Transaktionsebene außer Kraft setzen. Auf Sessionebene kann eine Session die erforderliche Transaktionsisolationsebene mit der Anweisung ALTER SESSION festlegen. Auf Transaktionsebene setzen Transaktionen mit den folgenden SQL-Anweisungen die standardmäßige Sperre von Oracle AI Database außer Kraft:

Von den vorherigen Anweisungen erworbene Sperren werden freigegeben, nachdem die Transaktion beendet wurde oder ein Rollback, um Savepoint freizugeben.

Wenn die Oracle AI Database-Standardsperre auf einer beliebigen Ebene außer Kraft gesetzt wird, muss der Datenbankadministrator oder Anwendungsentwickler sicherstellen, dass die außer Kraft gesetzten Sperrverfahren ordnungsgemäß funktionieren. Die Sperrverfahren müssen folgende Kriterien erfüllen: Datenintegrität ist gewährleistet, Datennebenläufigkeit ist akzeptabel und Deadlocks sind nicht möglich oder werden angemessen behandelt.

Siehe:

Benutzerdefinierte Sperren - Überblick

Mit Oracle AI Database Lock Management-Services können Sie eigene Sperren für eine bestimmte Anwendung definieren.

Beispiel: Sie erstellen eine Sperre, um den Zugriff auf ein Meldungsprotokoll im Dateisystem zu serialisieren. Da eine reservierte Benutzersperre mit einer Oracle AI Database-Sperre identisch ist, verfügt sie über alle Oracle AI Database-Sperrfunktionen, einschließlich Deadlock-Erkennung. Benutzersperren stehen nie in Konflikt mit Oracle AI Database-Sperren, da sie mit dem Präfix UL identifiziert werden.

Die Oracle AI Database Lock Management-Services sind über Prozeduren im Package DBMS_LOCK verfügbar. Sie können Anweisungen in PL/SQL-Blöcke aufnehmen, die:

Siehe:

Fußnotenlegende

Fußnote 1:

Bei der Verarbeitung eines verteilten Two-Phase Commits kann die Datenbank den Lesezugriff unter besonderen Umständen kurzzeitig verhindern. Wenn eine Abfrage zwischen der Vorbereitungs- und Commit-Phase beginnt und versucht, die Daten vor dem Commit zu lesen, kann die Datenbank eine Sperre von Zeilenebene auf Blockebene eskalieren, um die Lesekonsistenz zu gewährleisten.