Transaktionen

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

In diesem Kapitel werden Transaktionen definiert und die Art und Weise beschrieben, wie die Datenbank Transaktionen verarbeitet.

Einführung in Transaktionen

Eine Transaktion ist eine logische, atomare Arbeitseinheit, die eine oder mehrere SQL-Anweisungen enthält.

Eine Transaktion gruppiert SQL-Anweisungen so, dass sie entweder alle festgeschrieben sind. Das bedeutet, dass sie auf die Datenbank angewendet werden, oder alle zurückgerollt werden. Das bedeutet, dass sie aus der Datenbank rückgängig gemacht werden. Oracle AI Database weist jeder Transaktion eine eindeutige ID zu, die als Transaktions-ID bezeichnet wird.

Alle Oracle-Transaktionen erfüllen die grundlegenden Eigenschaften einer Datenbanktransaktion, die als ACID-Eigenschaften bezeichnet werden. ACID ist ein Akronym für Folgendes:

Die Verwendung von Transaktionen ist eine der wichtigsten Möglichkeiten, wie sich ein Datenbankverwaltungssystem von einem Dateisystem unterscheidet.

Mustertransaktion: Konto - Soll und Haben

Um das Konzept einer Transaktion zu veranschaulichen, betrachten Sie eine Bankdatenbank.

Wenn ein Kunde Geld von einem Sparkonto auf ein Girokonto überweist, muss die Transaktion aus drei separaten Vorgängen bestehen:

Oracle AI Database muss zwei Situationen zulassen. Wenn alle drei SQL-Anweisungen das korrekte Kontostand beibehalten, können die Auswirkungen der Transaktion auf die Datenbank angewendet werden. Wenn jedoch ein Problem wie unzureichende Mittel, ungültige Kontonummer oder ein Hardwarefehler verhindert, dass eine oder zwei der Anweisungen in der Transaktion abgeschlossen werden, muss die Datenbank die gesamte Transaktion zurücksetzen, damit der Saldo aller Konten korrekt ist.

Die folgende Abbildung zeigt eine Banktransaktion. Die erste Erklärung subtrahiert $ 500 vom Sparkonto 3209. Die zweite Erklärung fügt dem Girokonto 3208 $ 500 hinzu. Mit der dritten Anweisung wird ein Datensatz der Übertragung in die Journalbuchungstabelle eingefügt. Die letzte Anweisung schreibt die Transaktion fest.

Abbildung 1: Eine Banktransaktion

Beschreibung der Abbildung cncpt025.gif

Struktur einer Transaktion

Eine Datenbanktransaktion besteht aus einer oder mehreren Anweisungen.

Insbesondere besteht eine Transaktion aus einer der folgenden Komponenten:

Eine Transaktion hat einen Anfang und ein Ende.

Siehe:

Beginn einer Transaktion

Eine Transaktion beginnt, wenn die erste ausführbare SQL-Anweisung gefunden wird.

Eine ausführbare SQL-Anweisung ist eine SQL-Anweisung, die Aufrufe einer Datenbankinstanz generiert, einschließlich DML- und DDL-Anweisungen und der SET TRANSACTION-Anweisung.

Wenn eine Transaktion beginnt, weist Oracle AI Database die Transaktion einem verfügbaren Undo-Datensegment zu, um die Undo-Einträge für die neue Transaktion aufzuzeichnen. Eine Transaktions-ID wird erst zugewiesen, wenn ein Undo-Segment und ein Slot für die Transaktionstabelle zugewiesen werden. Dies geschieht während der ersten DML-Anweisung. Eine Transaktions-ID ist für eine Transaktion eindeutig und stellt die Undo-Segmentnummer, den Slot und die Sequenznummer dar.

Das folgende Beispiel führt eine UPDATE-Anweisung aus, um eine Transaktion zu starten, und fragt V$TRANSACTION nach Details zur Transaktion ab:

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
  2  XIDSQN AS "seq", STATUS AS "txn status"
  3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

Siehe auch: "Segmente rückgängig machen"

Ende einer Transaktion

Eine Transaktion kann unter verschiedenen Umständen enden.

Eine Transaktion endet, wenn eine der folgenden Aktionen ausgeführt wird:

Nach dem Ende einer Transaktion startet die nächste ausführbare SQL-Anweisung automatisch die folgende Transaktion. Im folgenden Beispiel wird eine UPDATE ausgeführt, um eine Transaktion zu starten, die Transaktion mit einer ROLLBACK-Anweisung beendet und dann eine UPDATE ausgeführt, um eine neue Transaktion zu starten (beachten Sie, dass die Transaktions-IDs unterschiedlich sind):

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

Siehe:

Atomarität auf Anweisungsebene

Oracle AI Database unterstützt die Atomizität auf Anweisungsebene. Das bedeutet, dass eine SQL-Anweisung eine atomare Arbeitseinheit ist und entweder vollständig erfolgreich ist oder vollständig ausfällt.

Eine erfolgreiche Anweisung unterscheidet sich von einer festgeschriebenen Transaktion. Eine einzelne SQL-Anweisung wird erfolgreich ausgeführt, wenn die Datenbank sie als atomare Einheit ohne Fehler parst und ausführt, wie wenn alle Zeilen in einer mehrzeiligen Aktualisierung geändert werden.

Wenn eine SQL-Anweisung während der Ausführung einen Fehler verursacht, ist sie nicht erfolgreich, sodass alle Auswirkungen der Anweisung zurückgesetzt werden. Dieser Vorgang ist ein Rollback auf Anweisungsebene. Dieser Vorgang weist folgende Eigenschaften auf:

Ein Beispiel für einen Fehler, der ein Rollback auf Anweisungsebene verursacht, ist der Versuch, einen doppelten Primärschlüssel einzufügen. Einzelne SQL-Anweisungen, die an einem Deadlock beteiligt sind, der Konkurrenz um dieselben Daten ist, können auch ein Rollback auf Anweisungsebene verursachen. Beim Parsen von SQL-Anweisungen erkannte Fehler, wie z.B. ein Syntaxfehler, wurden jedoch noch nicht ausgeführt. Daher wird kein Rollback auf Anweisungsebene ausgelöst.

Siehe:

Systemänderungsnummern (SCNs)

Eine System Change Number (SCN) ist ein logischer, interner Zeitstempel, der von Oracle AI Database verwendet wird.

SCNs ordnen Ereignisse in der Datenbank an, die erforderlich sind, um die ACID-Eigenschaften einer Transaktion zu erfüllen. Oracle AI Database verwendet SCNs, um die SCN zu markieren, vor der alle Änderungen bekanntermaßen auf dem Datenträger gespeichert sind. So vermeidet das Recovery die Anwendung unnötiger Redo Log-Dateien. Die Datenbank verwendet auch SCNs, um den Punkt zu markieren, an dem kein Redo für eine Gruppe von Daten vorhanden ist, damit das Recovery gestoppt werden kann.

SCNs treten in einer monoton zunehmenden Sequenz auf. Oracle AI Database kann eine SCN wie eine Uhr verwenden, da eine beobachtete SCN einen logischen Zeitpunkt angibt und wiederholte Beobachtungen gleiche oder größere Werte zurückgeben. Wenn ein Ereignis eine niedrigere SCN als ein anderes Ereignis aufweist, trat es zu einem früheren Zeitpunkt in der Datenbank auf. Mehrere Ereignisse können dieselbe SCN verwenden, was bedeutet, dass sie gleichzeitig in der Datenbank aufgetreten sind.

Jede Transaktion hat eine SCN. Beispiel: Wenn eine Transaktion eine Zeile aktualisiert, zeichnet die Datenbank die SCN auf, bei der diese Aktualisierung stattgefunden hat. Andere Änderungen in dieser Transaktion haben dieselbe SCN. Wenn eine Transaktion festgeschrieben wird, zeichnet die Datenbank eine SCN für diesen Commit auf.

Oracle AI Database erhöht SCNs in der System Global Area (SGA). Wenn eine Transaktion Daten ändert, schreibt die Datenbank eine neue SCN in das Undo-Datensegment, das der Transaktion zugewiesen ist. Der Log Writer-Prozess schreibt dann den Commit-Datensatz der Transaktion sofort in das Online-Redo-Log. Der Commit-Datensatz hat die eindeutige SCN der Transaktion. Oracle AI Database verwendet SCNs auch als Teil seiner Instanzwiederherstellungs- und Medienwiederherstellungsmechanismen.

Siehe auch: "Instanz-Recovery - Überblick"

Übersicht über die Transaktionskontrolle

Transaktionskontrolle ist die Verwaltung von Änderungen, die von DML-Anweisungen und die Gruppierung von DML-Anweisungen in Transaktionen vorgenommen werden.

Im Allgemeinen befassen sich Anwendungsdesigner mit der Transaktionskontrolle, sodass die Arbeit in logischen Einheiten ausgeführt wird und die Daten konsistent bleiben.

Die Transaktionskontrolle umfasst die Verwendung der folgenden Anweisungen, wie in "Transaktionskontrollanweisungen" beschrieben:

Die Session in Tabelle 13-1 veranschaulicht die grundlegenden Konzepte der Transaktionskontrolle.

Tabelle 1: Transaktionskontrolle

T Session Erläuterung
t0 
COMMIT;
 Diese Anweisung beendet alle vorhandenen Transaktionen in der Session.
t1 
SET TRANSACTION NAME 'sal_update';
 Diese Anweisung beginnt eine Transaktion und nennt sie sal_update.
t2 
UPDATE employees
 SET salary = 7000
  WHERE last_name = 'Banda';
 Mit dieser Anweisung wird das Gehalt für Banda auf 7000 aktualisiert.
t3 
SAVEPOINT after_banda_sal;
 Diese Anweisung erstellt einen Savepoint namens after_banda_sal, sodass Änderungen in dieser Transaktion bis zu diesem Zeitpunkt zurückgesetzt werden können.
t4 
UPDATE employees
 SET salary = 12000
  WHERE last_name = 'Greene';
 Mit dieser Anweisung wird das Gehalt für Greene auf 12000 aktualisiert.
t5 
SAVEPOINT after_greene_sal;
 Diese Anweisung erstellt einen Savepoint namens after_greene_sal, sodass Änderungen in dieser Transaktion bis zu diesem Zeitpunkt zurückgesetzt werden können.
t6 
ROLLBACK TO SAVEPOINT
 after_banda_sal;
 Mit dieser Anweisung wird die Transaktion auf t3 zurückgesetzt, und die Aktualisierung des Gehalts von Greene unter t4 wird rückgängig gemacht. Die Transaktion sal_update wurde nicht beendet.
t7 
UPDATE employees
 SET salary = 11000
  WHERE last_name = 'Greene';
 Mit dieser Anweisung wird das Gehalt für Greene in Transaktion sal_update auf 11000 aktualisiert.
t8 
ROLLBACK;
 Diese Anweisung setzt alle Änderungen in Transaktion sal_update zurück und beendet die Transaktion.
t9 
SET TRANSACTION NAME 'sal_update2';
 Diese Anweisung startet eine neue Transaktion in der Session und benennt sie sal_update2.
t10 
UPDATE employees
 SET salary = 7050
  WHERE last_name = 'Banda';
 Mit dieser Anweisung wird das Gehalt für Banda auf 7050 aktualisiert.
t11 
UPDATE employees
 SET salary = 10950
  WHERE last_name = 'Greene';
 Mit dieser Anweisung wird das Gehalt für Greene auf 10950 aktualisiert.
t12 
COMMIT;
 Diese Anweisung schreibt alle Änderungen fest, die in Transaktion sal_update2 vorgenommen wurden, und beendet die Transaktion. Der Commit stellt sicher, dass die Änderungen in den Online Redo Log-Dateien gespeichert werden.

Transaktionsbezeichnungen

Ein Transaktionsname ist ein optionales, benutzerdefiniertes Tag, das als Erinnerung an die Arbeit dient, die von der Transaktion ausgeführt wird. Sie benennen eine Transaktion mit der SET TRANSACTION ... NAME-Anweisung, die bei Verwendung die erste Anweisung der Transaktion sein muss.

In Tabelle 13-1 wurde die erste Transaktion mit dem Namen sal_update und die zweite mit dem Namen sal_update2 benannt.

Transaktionsnamen bieten die folgenden Vorteile:

Siehe:

Aktive Transaktionen

Eine aktive Transaktion wurde gestartet, aber noch nicht festgeschrieben oder zurückgesetzt.

In Tabelle 13-1 ist die erste Anweisung zum Ändern von Daten in der Transaktion sal_update die Aktualisierung von Bandas Gehalt. Von der erfolgreichen Ausführung dieses Updates bis zum Ende der Transaktion durch die ROLLBACK-Anweisung ist die sal_update-Transaktion aktiv.

Von einer Transaktion vorgenommene Datenänderungen sind temporär, bis die Transaktion festgeschrieben oder zurückgesetzt wird. Bevor die Transaktion endet, ist der Status der Daten wie in der folgenden Tabelle dargestellt.

Tabelle 2: Status der Daten vor dem Ende der Transaktion

Bundesland Beschreibung Weitere Infos
Oracle AI Database hat Undo-Informationen in der SGA generiert. Die Undo-Daten enthalten die alten Datenwerte, die von den SQL-Anweisungen der Transaktion geändert wurden. "Konsistenz beim Lesen der festgeschriebenen Isolationsebene"
Oracle AI Database hat Redo im Online Redo Log-Puffer der SGA generiert. Der Redo Log-Datensatz enthält die Änderung am Datenblock und die Änderung am Undo-Block. "Redo Log-Puffer"
Die Datenbankpuffer der SGA wurden geändert. Die Datenänderungen für eine festgeschriebene Transaktion, die in den Datenbankpuffern der SGA gespeichert sind, werden nicht unbedingt sofort vom Datenbank-Writer (DBW) in die Datendateien geschrieben. Der Datenträger-Schreibvorgang kann vor oder nach dem Commit erfolgen. "Datenbank-Puffercache"
Die von der Datenänderung betroffenen Datensätze sind gesperrt. Andere Benutzer können die Daten in den betroffenen Zeilen weder ändern noch die nicht festgeschriebenen Änderungen sehen. "Sperrverhalten - Übersicht"

Savepoints

Ein Savepoint ist ein vom Benutzer deklarierter Zwischenmarker im Kontext einer Transaktion.

Der Savepoint-Marker wird intern in eine SCN aufgelöst. Savepoints teilen eine lange Transaktion in kleinere Teile auf.

Wenn Sie Savepoints in einer langen Transaktion verwenden, haben Sie die Möglichkeit, später vor dem aktuellen Zeitpunkt in der Transaktion, aber nach einem deklarierten Savepoint in der Transaktion ausgeführte Arbeit zurückzusetzen. Wenn Sie also einen Fehler machen, müssen Sie nicht jede Anweisung erneut weiterleiten. Tabelle 13-1 erstellt Savepoint after_banda_sal, sodass die Aktualisierung des Greene-Gehalts auf diesen Savepoint zurückgesetzt werden kann.

Rollback zu Savepoint

Ein Rollback zu einem Savepoint in einer nicht festgeschriebenen Transaktion bedeutet, dass alle nach dem angegebenen Savepoint vorgenommenen Änderungen rückgängig gemacht werden. Dies bedeutet jedoch kein Rollback der Transaktion selbst.

Wenn ein Rollback einer Transaktion auf einen Savepoint ausgeführt wird, wie wenn die ROLLBACK TO SAVEPOINT after_banda_sal in Tabelle 13-1 ausgeführt wird, geschieht Folgendes:

  1. Oracle AI Database setzt nur die Anweisungen zurück, die nach dem Savepoint ausgeführt werden.

    In Tabelle 13-1 bewirkt die ROLLBACK TO SAVEPOINT, dass UPDATE für Greene zurückgesetzt wird, nicht jedoch UPDATE für Banda.

  2. Oracle AI Database behält den in der ROLLBACK TO SAVEPOINT-Anweisung angegebenen Savepoint bei, alle nachfolgenden Savepoints gehen jedoch verloren.

    In Tabelle 13-1 bewirkt die ROLLBACK TO SAVEPOINT, dass der Savepoint after_greene_sal verloren geht.

  3. Oracle AI Database gibt alle Tabellen- und Zeilensperren frei, die nach dem angegebenen Savepoint erworben wurden, behält jedoch alle vor dem Savepoint erworbenen Datensperren bei.

Die Transaktion bleibt aktiv und kann fortgesetzt werden.

Siehe:

In Queue gestellte Transaktionen

Je nach Szenario werden Transaktionen, die auf zuvor gesperrte Ressourcen warten, nach einem Rollback zum Savepoint möglicherweise weiterhin blockiert.

Wenn eine Transaktion durch eine andere Transaktion blockiert wird, stellt sie die blockierende Transaktion selbst in eine Queue, sodass die gesamte blockierende Transaktion festgeschrieben oder zurückgesetzt werden muss, damit die blockierte Transaktion fortgesetzt werden kann.

Im Szenario in der folgenden Tabelle wird Session 1 zu einem Savepoint zurückgerollt, der erstellt wurde, bevor eine DML-Anweisung ausgeführt wurde. Sitzung 2 ist jedoch weiterhin blockiert, da sie auf den Abschluss der Transaktion für Sitzung 1 wartet.

Tabelle 3: Rollback zu Savepoint - Beispiel

T Session 1 Session 2 Session 3 Erläuterung
t0 
UPDATE employees
  SET salary=7000
  WHERE last_name=
  'Banda';
     In Sitzung 1 wird eine Transaktion gestartet. Die Session setzt eine exklusive Sperre für die Zeile Banda (TX) und eine SX (SubExclusive Table Lock) für die Tabelle.
t1 
SAVEPOINT
  after_banda_sal;
     Session 1 erstellt einen Savepoint namens after_banda_sal.
t2 
UPDATE employees
  SET salary=12000
  WHERE last_name=
  'Greene';
     Session 1 sperrt die Zeile Greene.
t3   
UPDATE employees
  SET salary=14000
  WHERE last_name=
 'Greene';
   Session 2 versucht, die Zeile Greene zu aktualisieren, fordert jedoch keine Sperre an, da Session 1 eine Sperre für diese Zeile aufweist. In Sitzung 2 wurde keine Transaktion begonnen.
t4 
ROLLBACK
 TO SAVEPOINT
  after_banda_sal;
    

Session 1 setzt die Aktualisierung auf das Gehalt für Greene zurück, wodurch die Zeilensperre für Greene aufgehoben wird. Die unter t0 erworbene Tabellensperre wird nicht freigegeben.

Sitzung 2 wird noch von Sitzung 1 blockiert, da Sitzung 2 die Transaktion von Sitzung 1 in eine Queue stellt, die noch nicht abgeschlossen wurde.

t5     
UPDATE employees
  SET salary=11000
 WHERE last_name=
 'Greene';
 Die Zeile Greene ist derzeit entsperrt, sodass Session 3 eine Sperre für ein Update der Zeile Greene erwirbt. Diese Anweisung startet eine Transaktion in Sitzung 3.
t6 
COMMIT;
     Session 1 schreibt fest und beendet die Transaktion. Session 2 wird jetzt für die Aktualisierung der Zeile Greene hinter der Transaktion in Session 3 in die Queue gestellt.

Siehe auch: "Sperrdauer", um mehr darüber zu erfahren, wann Oracle AI Database Sperren freigibt

Rollback von Transaktionen

Bei einem Rollback einer nicht festgeschriebenen Transaktion werden alle Änderungen an Daten rückgängig gemacht, die von SQL-Anweisungen innerhalb der Transaktion ausgeführt wurden.

Nachdem eine Transaktion zurückgesetzt wurde, sind die Auswirkungen der in der Transaktion ausgeführten Arbeit nicht mehr vorhanden. Beim Rollback einer gesamten Transaktion ohne Referenzierung von Savepoints führt Oracle AI Database die folgenden Aktionen aus:

Die Dauer eines Rollbacks ist eine Funktion der geänderten Datenmenge.

Siehe:

Commits von Transaktionen

Ein Commit beendet die aktuelle Transaktion und macht alle in der Transaktion ausgeführten Änderungen dauerhaft.

In Tabelle 13-1 beginnt eine zweite Transaktion mit sal_update2 und endet mit einer expliziten COMMIT-Anweisung. Die Änderungen, die sich aus den beiden UPDATE-Anweisungen ergeben haben, werden jetzt dauerhaft vorgenommen.

Wenn eine Transaktion festgeschrieben wird, geschieht Folgendes:

Nachdem eine Transaktion festgeschrieben wurde, können Benutzer die Änderungen anzeigen.

In der Regel ist ein Commit unabhängig von der Transaktionsgröße ein schneller Vorgang. Die Commit-Geschwindigkeit erhöht sich nicht mit der Größe der in der Transaktion geänderten Daten. Der längste Teil des Commits ist das physische Datenträger-I/O, das von LGWR ausgeführt wird. Die von LGWR aufgewendete Zeit wird jedoch reduziert, da der Inhalt des Redo Log Buffers inkrementell im Hintergrund geschrieben wurde.

Das Default-Verhalten besteht darin, dass LGWR Redo synchron in das Online Redo Log schreibt und dass Transaktionen darauf warten, dass sich das gepufferte Redo auf Platte befindet, bevor sie einen Commit an den Benutzer zurückgeben. Bei einer geringeren Commit-Latenz von Transaktionen können Anwendungsentwickler jedoch angeben, dass Redo asynchron geschrieben werden soll, sodass Transaktionen nicht warten müssen, bis das Redo auf dem Datenträger gespeichert ist, und sofort vom COMMIT-Aufruf zurückkehren können.

Siehe:

Übersicht über in Quarantäne gestellte Transaktionen

Eine quarantäne Transaktion ist eine Transaktion, die isoliert und beim Datenbank-Recovery nicht wiederhergestellt wird. Um das Problem zu beheben, muss der DBA eingreifen, bevor Sperren freigegeben werden können.

Oracle AI Database verwendet Redo und Undo für Datenkonsistenz. Wenn die Datenbank nach einem Absturz geöffnet wird, rollt die Anwendung von Redo die Datenbank weiter, um alle festgeschriebenen Änderungen, die als Cache-Recovery bezeichnet werden, abzurufen. Undo rollt die Änderungen zurück, die von nicht festgeschriebenen und jetzt aufgrund des Absturzes inaktiven Transaktionen vorgenommen wurden. Dies wird als Crash-Recovery bezeichnet. Die geöffnete Datenbank wartet nicht, bis das Undo der nicht festgeschriebenen Transaktionen angewendet wird, um ein schnelleres Hochfahren zu erreichen. Stattdessen wird der Status der Transaktion in der Transaktionstabelle als "inaktiv" markiert, und die Datenbank wird schnell geöffnet. Die Anwendung von Undo für inaktive Transaktionen wird dann asynchron vom System Monitor-(SMON-)Hintergrundprozess ausgeführt und als Transaktions-Recovery bezeichnet.

Das andere Mal, wenn inaktive Transaktionen von SMON wiederhergestellt werden, ist das Instanz-Recovery. Eine Oracle RAC-Instanz kann bei aktiv ausgeführten Transaktionen abstürzen. Diese inaktiven Transaktionen enthalten Rowlocks, die Transaktionen in denselben Zeilen auf den anderen verbleibenden RAC-Instanzen blockieren. Der SMON-Hintergrundprozess auf einer der verbleibenden Instances führt das Instanz-Recovery in zwei Phasen aus: Cache Recovery und Transaktions-Recovery.

Der PMON-Hintergrundprozess kann auch die Arbeit beim Beenden einer großen Transaktion während der nicht erfolgreichen Prozessbereinigung an SMON auslagern.

Der SMON-Prozess führt Aufgaben auf Systemebene aus, wie die Bereinigung nicht verwendeter temporärer Segmente, die Zusammenführung zusammenhängender Extents und vieler anderer Aufgaben. Es handelt sich um einen nicht behebbaren Prozess, was bedeutet, dass ein Absturz in SMON zu einem Absturz der CDB-Instanz führt. Ein SMON-Transaktions-Recovery-Fehler kann aus verschiedenen Gründen auftreten:

Ein Crash stoppt nicht nur das Recovery der Transaktion, die von SMON aktiv wiederhergestellt wird, sondern auch das Recovery für die restlichen inaktiven Transaktionen. Bei einem persistenten Fehler empfiehlt der Oracle-Support, dass Kunden das SMON-Transaktions-Recovery deaktivieren und die Datenbank öffnen, um die Auswirkungen zu reduzieren. Dies führt dazu, dass Zeilensperren länger von inaktiven Transaktionen gehalten werden. Dies wirkt sich stark auf kritische Geschäftsabläufe aus.

Transaktionen, die nicht wiederhergestellt werden können, werden unter Quarantäne gestellt und nicht wiederhergestellt, bis der DBA das Problem beheben kann. Der DBA wird über die Quarantäne-Transaktion benachrichtigt und muss sofort Maßnahmen ergreifen, damit die von der Quarantäne-Transaktion gehaltenen Zeilensperren freigegeben werden können.

Der DBA wird auf das Vorhandensein von Transaktionen in Quarantäne in verschiedenen Protokollen und Ansichten hingewiesen, um die Identifizierung von Transaktionen in Quarantäne und den Grund für die Quarantäne zu erleichtern. Der DBA verwendet diese Informationen, um das spezifische Problem zu beheben, damit die Quarantäne gelöscht werden kann.

Wenn Fehler über mehrere Transaktionen hinweg auftreten oder sich über die gesamte PDB erstrecken, wie logische Datenbeschädigung aufgrund eines Codebugs, physische Beschädigung mehrerer Blöcke oder eine PDB-SGA-Beschädigung, kann die Quarantäne des nicht erfolgreichen inaktiven Transaktions-Recoverys helfen oder nicht. Es hängt davon ab, ob die Ursache für diese Fehler gleich ist oder nicht, da bei der Wiederherstellung anderer inaktiver Transaktionen möglicherweise das gleiche Problem auftritt. Das System wird auch nach der Quarantäne einiger Transaktionen weiterhin inkonsistent ausgeführt. Es kann gefährlich sein, wenn der Fehler auf logische Datenbeschädigung zurückzuführen ist, da er sich im Laufe der Zeit verteilt. Um dies zu verhindern, gibt es ein Transaktions-Quarantäne-Limit von drei (3), nach dem die Quarantäne auf Datenbankebene eskaliert wird und die PDB mit shutdown abort beendet wird, wenn das Archiv-Logging für die PDB aktiviert ist und die PDB heruntergefahren werden kann. Das Transaktions-Recovery für die PDB wird automatisch deaktiviert, sodass der DBA Probleme beim nächsten Hochfahren beheben kann. Nachdem die Probleme behoben wurden, muss der DBA das Recovery für das nächste Hochfahren aktivieren.

Hinweis: Da Oracle Data Guard die logische Replikation verwendet, werden Quarantänemetadaten bei Verwendung von Oracle Data Guard nicht auf den Standby-Server repliziert. Daher kann sich der Inhalt von Transaktions-Quarantäne-Views, wie DBA_QUARANTINED_TRANSACTIONS, auf dem Standby-Server von den Einträgen auf dem Primärserver unterscheiden.

Verwandte Themen

Überblick über Transaction Guard

Transaction Guard ist eine API, mit der Anwendungen die Transaktions-IDempotenz bereitstellen können. Dies ist die Möglichkeit der Datenbank, ein garantiertes Commit-Ergebnis beizubehalten, das angibt, ob eine Transaktion festgeschrieben und abgeschlossen wurde. Oracle AI Database bietet die API für JDBC Thin, OCI, OCCI und ODP.Net.

Ein behebbarer Fehler wird durch einen externen Systemfehler verursacht, der unabhängig von der ausgeführten Anwendungssessionlogik ist. Behebbare Fehler treten nach geplanten und ungeplanten Ausfällen von Vordergrundprozessen, Netzwerken, Knoten, Speicher und Datenbanken auf. Wenn bei einem Ausfall die Verbindung zwischen einer Clientanwendung und der Datenbank unterbrochen wird, erhält die Anwendung eine Fehlermeldung zum Trennen der Verbindung. Die Transaktion, die ausgeführt wurde, als die Verbindung unterbrochen wurde, wird als fliegende Transaktion bezeichnet.

Um zu entscheiden, ob die Transaktion erneut weitergeleitet oder das Ergebnis (festgeschrieben oder nicht festgeschrieben) an den Client zurückgegeben werden soll, muss die Anwendung das Ergebnis der laufenden Transaktion bestimmen. Vor Oracle Database 12c waren die an den Client zurückgegebenen Commit-Nachrichten nicht persistent. Die Prüfung einer Transaktion war keine Garantie dafür, dass sie nach der Prüfung nicht festgeschrieben wird, sodass doppelte Transaktionen und andere Formen logischer Beschädigung zulässig sind. Beispiel: Ein Benutzer kann einen Webbrowser aktualisieren, wenn er ein Buch online kauft, und wird zweimal für dasselbe Buch belastet.

Siehe:

Vorteile von Transaction Guard

Transaction Guard stellt Anwendungen ab Oracle Database 12c ein Tool zur Verfügung, mit dem der Status einer laufenden Transaktion nach einem behebbaren Ausfall bestimmt wird.

Mit Transaction Guard kann eine Anwendung sicherstellen, dass eine Transaktion nicht mehr als einmal ausgeführt wird. Beispiel: Wenn eine Online-Buchhandlung feststellt, dass der zuvor weitergeleitete Commit nicht erfolgreich war, kann der Antrag sicher erneut weitergeleitet werden.

Transaction Guard bietet ein Tool für die fast einmalige Ausführung, um zu verhindern, dass die Anwendung doppelte Weiterleitungen ausführt. Transaction Guard bietet ein bekanntes Ergebnis für jede Transaktion.

Transaction Guard ist eine zentrale Oracle AI Database-Funktion. Application Continuity verwendet Transaction Guard bei der Maskierung von Ausfällen von Endbenutzern. Ohne Transaction Guard kann eine Anwendungswiederholung nach einem Fehler dazu führen, dass doppelte Transaktionen festgeschrieben werden.

Siehe:

Funktionsweise von Transaction Guard

In diesem Abschnitt wird das Problem verlorener Commit-Nachrichten erläutert und erläutert, wie Transaction Guard logische Transaktions-IDs verwendet, um das Problem zu lösen.

Verlorene Commit-Nachrichten

Beim Entwerfen für Idempotenz müssen Entwickler das Problem von Kommunikationsfehlern nach der Weiterleitung von Commit-Anweisungen beheben. Commit-Nachrichten werden nicht in der Datenbank gespeichert und können daher nicht nach einem Fehler abgerufen werden.

Die folgende Grafik stellt eine allgemeine Darstellung einer Interaktion zwischen einer Clientanwendung und einer Datenbank dar.

Abbildung 2: Nachricht "Verlorener Commit"

Beschreibung der Abbildung cncpt356.png

Im Standard-Commit-Fall schreibt die Datenbank eine Transaktion fest und gibt eine Erfolgsmeldung an den Client zurück. In Abbildung 13-2 leitet der Client eine Commit-Anweisung weiter und erhält eine Meldung, in der angegeben wird, dass die Kommunikation fehlgeschlagen ist. Diese Art von Fehler kann aus verschiedenen Gründen auftreten, z. B. aus einem Ausfall der Datenbankinstanz oder einem Netzwerkausfall. In diesem Szenario kennt der Client den Status der Transaktion nicht.

Nach einem Kommunikationsfehler führt die Datenbank die Weiterleitung möglicherweise noch aus und weiß nicht, dass der Client die Verbindung getrennt hat. Die Prüfung des Transaktionsstatus garantiert nicht, dass eine aktive Transaktion nach der Prüfung nicht festgeschrieben wird. Wenn der Client den Commit aufgrund dieser veralteten Informationen erneut sendet, kann die Datenbank die Transaktion wiederholen, was zu einer logischen Beschädigung führt.

Logische Transaktions-ID

Oracle AI Database löst den Kommunikationsfehler mit einer global eindeutigen ID, der als logische Transaktions-ID bezeichnet wird.

Diese ID enthält die logische Sessionnummer, die zugewiesen wird, wenn sich eine Session zum ersten Mal anmeldet, und eine laufende Commit-Nummer, die jedes Mal aktualisiert wird, wenn die Session festschreibt oder rollt back.Foot 1 Aus Anwendungsperspektive identifiziert die logische Transaktions-ID eindeutig die letzte Datenbanktransaktion, die in der nicht erfolgreichen Session weitergeleitet wurde.

Für jede Roundtrip-Transaktion vom Client, in der eine oder mehrere Transaktionen festgeschrieben werden, speichert die Datenbank eine logische Transaktions-ID. Diese ID kann Transaktions-Idempotenz für Interaktionen zwischen der Anwendung und der Datenbank für jede Rundreise bereitstellen, die Daten festschreibt.

Das Fast-Once-Protokoll ermöglicht den Zugriff auf das Commit-Ergebnis, indem die Datenbank Folgendes ausführen muss:

Während eine Transaktion ausgeführt wird, enthalten sowohl die Datenbank als auch der Client die logische Transaktions-ID. Die Datenbank gibt dem Client bei der Authentifizierung, beim Ausleihen aus einem Connection Pool und bei jeder Roundtrip aus dem Clienttreiber, der einen oder mehrere Commit-Vorgänge ausführt, eine logische Transaktions-ID.

Bevor die Anwendung das Ergebnis der letzten Transaktion nach einem behebbaren Fehler ermitteln kann, ruft die Anwendung die logische Transaktions-ID ab, die auf dem Client mit Java-, OCI-, OCCI- oder ODP.Net-APIs gespeichert ist. Die Anwendung ruft dann die PL/SQL-Prozedur DBMS_APP_CONT.GET_LTXID_OUTCOME mit der logischen Transaktions-ID auf, um das Ergebnis der letzten Weiterleitung zu bestimmen: Festgeschrieben (true oder false) und Benutzeraufruf abgeschlossen (true oder false).

Wenn Transaction Guard verwendet wird, kann die Anwendung Transaktionen wiedergeben, wenn der Fehler behoben werden kann und die letzte Transaktion in der Session nicht festgeschrieben wurde. Die Anwendung kann fortgesetzt werden, wenn die letzte Transaktion festgeschrieben und der Benutzeraufruf abgeschlossen wurde. Die Anwendung kann Transaction Guard verwenden, um das bekannte Ergebnis an den Client zurückzugeben, damit der Client die nächste auszuführende Aktion auswählen kann.

Siehe:

Transaction Guard – Beispiel

In diesem Szenario geht die Commit-Nachricht aufgrund eines behebbaren Fehlers verloren.

Transaction Guard verwendet die logische Transaktions-ID, um das Ergebnis der COMMIT-Anweisung beizubehalten und sicherzustellen, dass ein bekanntes Ergebnis für die Transaktion vorliegt.

Abbildung 3: Prüfung des logischen Transaktionsstatus

Beschreibung der Abbildung cncpt365.png

In Abbildung 13-3 informiert die Datenbank die Anwendung darüber, ob die Transaktion festgeschrieben wurde und ob der letzte Benutzeraufruf abgeschlossen wurde. Die Anwendung kann dann das Ergebnis an den Endbenutzer zurückgeben. Die Möglichkeiten sind:

Siehe auch: Oracle AI Database Development Guide enthält Informationen zur Verwendung von Transaction Guard

Übersicht über Application Continuity

Application Continuity versucht, Ausfälle aus Anwendungen zu maskieren, indem unvollständige Anwendungsanforderungen nach ungeplanten und geplanten Ausfällen wiedergegeben werden. In diesem Zusammenhang ist eine Anforderung eine Arbeitseinheit der Anwendung.

In der Regel entspricht eine Anforderung den DML-Anweisungen und anderen Datenbankaufrufen einer einzelnen Webanforderung für eine einzelne Datenbankverbindung. Im Allgemeinen wird eine Anforderung durch die Aufrufe abgegrenzt, die zwischen dem Auschecken und Einchecken einer Datenbankverbindung aus einem Verbindungspool ausgeführt werden.

Der vorliegende Abschnitt umfasst die folgenden Themen:

Vorteile von Application Continuity

Ein grundlegendes Problem für Entwickler ist, wie eine verlorene Datenbanksession von Endbenutzern maskiert wird.

Application Continuity versucht, das verlorene Sessionproblem zu lösen, indem die Datenbanksession wiederhergestellt wird, wenn eine Komponente die Unterhaltung zwischen Datenbank und Client unterbricht. Die wiederhergestellte Datenbanksession enthält alle Status, Cursor, Variablen und die letzte Transaktion, sofern vorhanden.

Anwendungsfall für Application Continuity

In einem typischen Fall hat ein Client eine Anforderung an die Datenbank weitergeleitet, die sowohl den Transaktions- als auch den nicht transaktionsfähigen Status aufgebaut hat.

Der Status auf dem Client bleibt aktuell, möglicherweise mit eingegebenen Daten, zurückgegebenen Daten sowie zwischengespeicherten Daten und Variablen. Der Sessionzustand der Datenbank, in dem die Anwendung arbeiten muss, geht jedoch verloren.

Wenn die Clientanforderung eine oder mehrere Transaktionen initiiert hat, stehen der Anwendung die folgenden Möglichkeiten zur Verfügung:

Wenn die Wiedergabe erfolgreich ist, wird der Datenbankbenutzerservice für geplante und ungeplante Ausfälle nicht unterbrochen. Wenn die Datenbank Änderungen an den Daten erkennt, die von der Anwendung angezeigt und möglicherweise bearbeitet wurden, wird die Wiedergabe abgelehnt. Die Wiedergabe wird nicht versucht, wenn die zulässige Zeit für das Starten der Wiedergabe überschritten wird, die Anwendung einen eingeschränkten Aufruf verwendet oder die Anwendung die Wiedergabe mit der Methode disableReplay explizit deaktiviert hat.

Siehe auch: Oracle Real Application Clusters Administration and Deployment Guide, um mehr darüber zu erfahren, wie Application Continuity für Datenbanksessions funktioniert

Anwendungskontinuität für geplante Wartung

Application Continuity für geplante Ausfälle ermöglicht es Anwendungen, Vorgänge für Datenbanksessions fortzusetzen, die zuverlässig entwässert oder migriert werden können.

Die geplante Wartung muss die Anwendungsarbeit nicht unterbrechen. Application Continuity gibt aktive Arbeitszeit für das Drain von seinem aktuellen Standort an einen neuen Standort, der derzeit von der Wartung nicht betroffen ist. Am Ende des Drain-Intervalls können Sessions auf der Datenbankinstanz verbleiben, in der die Wartung geplant ist. Anstatt diese Sessions zwangsweise zu trennen, kann Application Continuity ein Failover dieser Sessions auf eine verbleibende Site ausführen und laufende Transaktionen erneut weiterleiten.

Wenn Application Continuity aktiviert ist, kann die Datenbank Folgendes ausführen:

Steuern Sie das Drain-Verhalten während der geplanten Wartung mithilfe der Serviceattribute drain_timeout und stop_option des Utilitys SRVCTL, des Global Data Services Control Utilitys (GDSCTL) und des Oracle Data Guard-Brokers. Das Package DBMS_SERVICE stellt die zugrunde liegende Infrastruktur bereit.

Siehe:

Application Continuity-Architektur

Die wichtigsten Komponenten von Application Continuity sind Laufzeit, erneute Verbindung und Wiedergabe.

Die Phasen sind wie folgt:

  1. Normale Laufzeit

    In dieser Phase führt Application Continuity die folgenden Aufgaben aus:

    • Identifiziert Datenbankanforderungen

    • Legt fest, ob lokale und Datenbankaufrufe wiedergegeben werden können

    • Erstellt Proxyobjekte, um die Wiedergabe zu ermöglichen und Queues zu verwalten

    • Speichert ursprüngliche Aufrufe und die Validierung dieser Aufrufe, bis das Ende der Datenbankanforderung oder -wiedergabe deaktiviert ist

  2. Erneute Verbindung

    Diese Phase wird durch einen behebbaren Fehler ausgelöst. Application Continuity führt die folgenden Aufgaben aus:

    • Stellt sicher, dass die Wiedergabe für die Datenbankanforderungen aktiviert ist

    • Verwaltet Timeouts

    • Ruft eine neue Verbindung zur Datenbank ab und validiert dann, ob es sich um ein gültiges Datenbankziel handelt

    • Bestimmt mit Transaction Guard, ob die letzte Transaktion erfolgreich festgeschrieben wurde (festgeschriebene Transaktionen werden nicht erneut weitergeleitet)

  3. Wiedergabe

    Application Continuity führt die folgenden Aufgaben aus:

    • Wiederholt Anrufe, die in der Warteschlange gehalten werden

    • Deaktiviert die Wiedergabe, wenn vom Benutzer sichtbare Änderungen der Ergebnisse während der Wiedergabe angezeigt werden

    • lässt keinen Commit zu, lässt aber zu, dass der letzte Rückruf (der den Fehler ermittelt hat) festgeschrieben wird

Nach einer erfolgreichen Wiedergabe wird die Anforderung ab dem Zeitpunkt des Fehlers fortgesetzt.

Siehe:

Überblick über autonome Transaktionen

Eine autonome Transaktion ist eine unabhängige Transaktion, die von einer anderen Transaktion aufgerufen werden kann, der Haupttransaktion. Sie können die aufrufende Transaktion unterbrechen, SQL-Vorgänge ausführen und sie in der autonomen Transaktion festschreiben oder rückgängig machen und dann die aufrufende Transaktion fortsetzen.

Autonome Transaktionen sind nützlich für Aktionen, die unabhängig voneinander ausgeführt werden müssen, unabhängig davon, ob die aufrufende Transaktion festgeschrieben oder zurückgesetzt wird. Beispiel: In einer Aktienkauftransaktion möchten Sie Kundendaten speichern, unabhängig davon, ob der gesamte Aktienkauf durchläuft. Darüber hinaus möchten Sie Fehlermeldungen in einer Debug-Tabelle protokollieren, auch wenn die gesamte Transaktion zurückgerollt wird.

Autonome Transaktionen weisen folgende Merkmale auf:

In PL/SQL wird eine autonome Transaktion in einem autonomen Geltungsbereich ausgeführt. Dies ist eine Routine, die mit dem Pragma AUTONOMOUS_TRANSACTION gekennzeichnet ist. In diesem Kontext umfassen Routinen anonyme PL/SQL-Blöcke der obersten Ebene sowie PL/SQL-Unterprogramme und -Trigger. Eine pragma-Anweisung weist den Compiler an, eine Kompilierungsoption auszuführen. Das Pragma AUTONOMOUS_TRANSACTION weist die Datenbank an, dass diese Prozedur, wenn sie ausgeführt wird, als neue autonome Transaktion ausgeführt werden soll, die von der übergeordneten Transaktion unabhängig ist.

Die folgende Grafik zeigt, wie die Steuerung von der Hauptroutine (MT) zu einer autonomen Routine und wieder zurück fließt. Die Hauptroutine ist proc1 und die autonome Routine ist proc2. Die autonome Routine kann mehrere Transaktionen (AT1 und AT2) festschreiben, bevor die Kontrolle zur Hauptroutine zurückkehrt.

Abbildung 4: Ablauf der Transaktionskontrolle

Beschreibung der Abbildung cncpt288.gif

Wenn Sie den ausführbaren Bereich einer autonomen Routine eingeben, wird die Hauptroutine unterbrochen. Wenn Sie die autonome Routine beenden, wird die Hauptroutine fortgesetzt.

In Abbildung 13-4 macht COMMIT innerhalb von proc1 nicht nur seine eigene Arbeit, sondern auch alle herausragenden Arbeiten, die in seiner Session ausgeführt werden, dauerhaft. Eine COMMIT in proc2 macht jedoch nur die in der proc2-Transaktion ausgeführte Arbeit dauerhaft. Daher haben die COMMIT-Anweisungen in den Transaktionen AT1 und AT2 keine Auswirkungen auf die MT-Transaktion.

Siehe auch: Oracle AI Database Development Guide und Oracle AI Database PL/SQL Language Reference, um zu erfahren, wie autonome Transaktionen verwendet werden

Übersicht über aufgeteilte Transaktionen

Eine verteilte Transaktion ist eine Transaktion, die eine oder mehrere Anweisungen enthält, die Daten auf zwei oder mehreren eindeutigen Knoten einer verteilten Datenbank aktualisieren. Dabei wird ein Schemaobjekt verwendet, das als Datenbanklink bezeichnet wird.

Eine verteilte Datenbank ist eine Gruppe von Datenbanken in einem verteilten System, die Anwendungen als einzelne Datenquelle angezeigt werden können. Ein Datenbanklink beschreibt, wie sich eine Datenbankinstanz bei einer anderen Datenbankinstanz anmelden kann.

Im Gegensatz zu einer Transaktion in einer lokalen Datenbank ändert eine verteilte Transaktion Daten in mehreren Datenbanken. Folglich ist die verteilte Transaktionsverarbeitung komplizierter, da die Datenbank das Festschreiben oder Zurückrollen der Änderungen in einer Transaktion als atomare Einheit koordinieren muss. Die gesamte Transaktion muss festgeschrieben oder zurückgesetzt werden. Oracle AI Database muss die Transaktionskontrolle über ein Netzwerk koordinieren und die Datenkonsistenz aufrechterhalten, selbst wenn ein Netzwerk- oder Systemfehler auftritt.

Zwei-Phasen-Commit

Der Zwei-Phasen-Commit-Mechanismus garantiert, dass alle Datenbanken, die an einer verteilten Transaktion teilnehmen, entweder alle Commit-Anweisungen oder alle Anweisungen in der Transaktion rückgängig machen. Der Mechanismus schützt auch implizites DML, das durch Integritäts-Constraints, Remote-Prozeduraufrufe und Trigger ausgeführt wird.

Bei einem Two-Phase Commit zwischen mehreren Datenbanken koordiniert eine Datenbank die verteilte Transaktion. Der initiierende Knoten wird als globaler Koordinator bezeichnet. Der Koordinator fragt die anderen Datenbanken, ob sie bereit sind, festzuschreiben. Wenn eine Datenbank mit einem Nein antwortet, wird die gesamte Transaktion zurückgesetzt. Wenn alle Datenbanken mit "Ja" stimmen, sendet der Koordinator eine Nachricht, damit der Commit in jeder Datenbank dauerhaft ist.

Der Zwei-Phasen-Commit-Mechanismus ist für Benutzer transparent, die verteilte Transaktionen ausgeben. Tatsächlich müssen die Benutzer nicht einmal wissen, dass die Transaktion verteilt wird. Eine COMMIT-Anweisung, die das Ende einer Transaktion angibt, löst automatisch den Two-Phase Commit-Mechanismus aus. Es ist keine Codierung oder komplexe Anweisungssyntax erforderlich, um verteilte Transaktionen in den Hauptteil einer Datenbankanwendung aufzunehmen.

Siehe:

Offene, verteilte Transaktionen

Eine in-doubt verteilte Transaktion tritt auf, wenn ein Two-Phase Commit durch einen System- oder Netzwerkfehler unterbrochen wurde.

Beispiel: Zwei Datenbanken berichten an die koordinierende Datenbank, die sie festschreiben wollten. Die koordinierende Datenbankinstanz ist jedoch sofort nach Erhalt der Nachrichten nicht erfolgreich. Die beiden Datenbanken, die bereit sind, festzuschreiben, hängen jetzt, während sie auf die Benachrichtigung des Ergebnisses warten.

Der Recovery-Hintergrundprozess (RECO) löst automatisch das Ergebnis verteilter zweifelhafter Transaktionen auf. Nachdem der Fehler behoben und die Kommunikation wiederhergestellt wurde, schreibt der RECO-Prozess jeder lokalen Oracle-Datenbank automatisch verteilte unverbindliche Transaktionen konsistent auf allen beteiligten Knoten fest oder setzt sie zurück.

Bei einem langfristigen Fehler ermöglicht Oracle AI Database jedem lokalen Administrator, verteilte Transaktionen, die aufgrund des Fehlers in Zweifel geraten sind, manuell festzuschreiben oder rückgängig zu machen. Mit dieser Option kann der lokale Datenbankadministrator gesperrte Ressourcen freigeben, die aufgrund des langfristigen Fehlers unbegrenzt gehalten werden.

Wenn eine Datenbank auf einen früheren Zeitpunkt wiederhergestellt werden muss, ermöglichen Datenbank-Recovery-Funktionen Datenbankadministratoren an anderen Standorten, ihre Datenbanken auf den früheren Zeitpunkt zurückzugeben. Dieser Vorgang stellt sicher, dass die globale Datenbank konsistent bleibt.

Siehe:

Fußnotenlegende

Fußnote 1:

Bei Oracle Real Application Clusters (Oracle RAC) enthält die logische Transaktions-ID die Datenbankinstanznummer als Präfix.