FirebirdSQL logo
 KontextvariablenSicherheit 
SNAPSHOT TABLE STABILITY-Isolationsstufe

Die Isolationsstufe SNAPSHOT TABLE STABILITY oder SNAPSHOT TABLE — ist die restriktivste.Wie in `SNAPSHOT sieht eine Transaktion in der SNAPSHOT TABLE STABILITY-Isolation nur die Änderungen, die vor dem Start der aktuellen Transaktion festgeschrieben wurden.Nachdem eine SNAPSHOT TABLE STABILITY gestartet wurde, können keine anderen Transaktionen Änderungen an Tabellen in der Datenbank vornehmen, deren Änderungen für diese Transaktion anstehen.Andere Transaktionen können andere Daten lesen, aber jeder Versuch des Einfügens, Aktualisierens oder Löschens durch einen parallelen Prozess führt zu Konfliktausnahmen.

Die RESERVING-Klausel kann verwendet werden, um anderen Transaktionen zu erlauben, Daten in einigen Tabellen zu ändern.

Wenn bei einer anderen Transaktion eine nicht festgeschriebene Änderung von Daten in einer Datenbanktabelle ansteht, bevor eine Transaktion mit der Isolationsstufe SNAPSHOT TABLE STABILITY gestartet wird, führt der Versuch, eine SNAPSHOT TABLE STABILITY-Transaktion zu starten, zu einer Ausnahme.

Die Isolationsstufe SNAPSHOT TABLE STABILITY wird auch als “consistency” bezeichnet.

READ COMMITTED-Isolationsstufe

Die Isolationsstufe READ COMMITTED ermöglicht, dass alle Datenänderungen, die andere Transaktionen seit ihrem Beginn festgeschrieben haben, sofort von der nicht festgeschriebenen aktuellen Transaktion gesehen werden.Nicht festgeschriebene Änderungen sind für eine 'READ COMMITTED'-Transaktion nicht sichtbar.

Um die aktualisierte Liste der Zeilen in der Tabelle, an der Sie interessiert sind - “aktualisiert” - abzurufen, muss nur die SELECT-Anweisung erneut angefordert werden, während sie sich noch in der nicht festgeschriebenen Transaktion READ COMMITTED befindet.

docnext count = 16

Varianten von READ COMMITTED

Für READ COMMITTED-Transaktionen kann je nach Art der gewünschten Konfliktlösung einer von zwei modifizierenden Parametern angegeben werden: RECORD_VERSION und NO RECORD_VERSION.Wie die Namen vermuten, schließen sie sich gegenseitig aus.

  • NO RECORD_VERSION (der Standardwert) ist eine Art Zwei-Phasen-Sperrmechanismus: Er macht die Transaktion nicht in der Lage, in eine Zeile zu schreiben, für die eine Aktualisierung von einer anderen Transaktion aussteht.

    • Wenn NO WAIT die angegebene Lock-Resolution-Strategie ist, wird sofort ein Lock-Konflikt-Fehler ausgegeben

    • Wenn WAIT angegeben ist, wird gewartet, bis die andere Transaktion entweder festgeschrieben oder zurückgesetzt wird.Wenn die andere Transaktion zurückgesetzt oder festgeschrieben wird und ihre Transaktions-ID älter ist als die ID der aktuellen Transaktion, ist die Änderung der aktuellen Transaktion zulässig.Ein Sperrkonfliktfehler wird zurückgegeben, wenn die andere Transaktion festgeschrieben wurde und ihre ID neuer war als die der aktuellen Transaktion.

  • Wenn RECORD_VERSION angegeben ist, liest die Transaktion die letzte festgeschriebene Version der Zeile, unabhängig von anderen ausstehenden Versionen der Zeile.Die Lock-Resolution-Strategie (WAIT oder NO WAIT) beeinflusst das Verhalten der Transaktion beim Start in keiner Weise.

  • Bei Angabe von READ CONSISTENCY (oder ReadConsistency = 1) erhält die Ausführung einer Anweisung einen Snapshot der Datenbank, um ein konsistentes Lesen auf Anweisungsebene der Transaktionen sicherzustellen, die beim Start der Ausführung festgeschrieben wurden.

    Die anderen beiden Varianten können zu inkonsistenten Lesevorgängen auf Anweisungsebene führen, da sie möglicherweise einige, aber nicht alle Änderungen einer gleichzeitigen Transaktion lesen, wenn diese Transaktion während der Anweisungsausführung festgeschrieben wird.Beispielsweise könnte ein SELECT COUNT(*) einige, aber nicht alle eingefügten Datensätze einer anderen Transaktion lesen, wenn der Commit dieser Transaktion erfolgt, während die Anweisung Datensätze liest.

    Diese Momentaufnahme auf Anweisungsebene wird für die Ausführung einer Anweisung der obersten Ebene abgerufen, verschachtelte Anweisungen (Trigger, gespeicherte Prozeduren und Funktionen, dynamische Anweisungen usw.) verwenden die Momentaufnahme auf Anweisungsebene, die für die Anweisung der obersten Ebene erstellt wurde.

Note

Einen Snapshot für READ CONSISTENCY zu erhalten ist eine sehr billige Aktion.
Caution

Die Einstellung ReadConsistency ist in der firebird.conf standardmäßig auf 1 gesetzt.
Behandlung von Aktualisierungskonflikten mit READ CONSISTENCY

Wenn eine Anweisung in einer READ COMMITTED READ CONSISTENCY-Transaktion ausgeführt wird, wird ihre Datenbankansicht ähnlich wie bei einer SNAPSHOT-Transaktion beibehalten.Dies macht es sinnlos, auf das Festschreiben der gleichzeitigen Transaktion zu warten, in der Hoffnung, die neu festgeschriebene Datensatzversion lesen zu können.Wenn also eine READ COMMITTED READ CONSISTENCY-Transaktion Daten liest, verhält sie sich ähnlich wie die READ COMMITTED RECORD VERSION-Transaktion: sie durchläuft die Rückwärtsversionskette und sucht nach einer Datensatzversion, die für den aktuellen Snapshot sichtbar ist.

Wenn ein Aktualisierungskonflikt auftritt, unterscheidet sich das Verhalten einer Transaktion READ COMMITTED READ CONSISTENCY von dem einer Transaktion in READ COMMITTED RECORD VERSION.Folgende Aktionen werden ausgeführt:

  1. Der Transaktionsisolationsmodus wird vorübergehend auf READ COMMITTED NO RECORD VERSION umgeschaltet.

  2. Für den widersprüchlichen Datensatz wird eine Schreibsperre verwendet.

  3. Verbleibende Datensätze des aktuellen UPDATE/DELETE-Cursors werden verarbeitet und sind ebenfalls schreibgeschützt.

  4. Sobald der Cursor geholt wird, werden alle Änderungen, die seit dem Start der Anweisung der obersten Ebene durchgeführt wurden, rückgängig gemacht, bereits genommene Schreibsperren für jeden aktualisierten/gelöschten/gesperrten Datensatz bleiben erhalten, alle eingefügten Datensätze werden entfernt.

  5. Der Transaktionsisolationsmodus wird auf READ COMMITTED READ CONSISTENCY wiederhergestellt, ein neuer Snapshot auf Anweisungsebene wird erstellt und die Anweisung der obersten Ebene wird erneut gestartet.

Dieser Algorithmus stellt sicher, dass bereits aktualisierte Datensätze nach dem Neustart gesperrt bleiben, für den neuen Snapshot sichtbar sind und ohne weitere Konflikte erneut aktualisiert werden können.Aufgrund der Natur von READ CONSISTENCY bleibt der geänderte Datensatz konsistent.

Note

  • Dieser Neustartalgorithmus wird auf die Anweisungen UPDATE, DELETE, SELECT WITH LOCK und MERGE mit oder ohne die RETURNING-Klausel angewendet, die direkt von einer Client-Anwendung oder innerhalb eines PSQL-Objekts (gespeicherte Prozedur/ Funktion, Trigger, BLOCK AUSFÜHREN usw.).

  • Wenn eine UPDATE/DELETE-Anweisung auf einem expliziten Cursor positioniert wird (unter Verwendung der WHERE CURRENT OF-Klausel), dann wird der obige Schritt (3) übersprungen, d. h. die verbleibenden Cursor-Datensätze werden nicht abgerufen und schreibgeschützt.

  • Wenn die Anweisung der obersten Ebene auswählbar ist und ein Aktualisierungskonflikt auftritt, nachdem ein oder mehrere Datensätze an die Clientseite zurückgegeben wurden, wird wie üblich ein Aktualisierungskonfliktfehler gemeldet und kein Neustart eingeleitet.

  • Es erfolgt kein Neustart für Anweisungen, die innerhalb autonomer Blöcke ausgeführt werden (IN AUTONOMOUS TRANSACTION DO …​).

  • Nach 10 erfolglosen Versuchen wird der Neustartalgorithmus abgebrochen, alle Schreibsperren werden aufgehoben, der Transaktionsisolationsmodus wird auf READ COMMITTED READ CONSISTENCY zurückgesetzt und ein Aktualisierungskonfliktfehler wird ausgelöst.

  • Jeder Fehler, der in Schritt (3) oben nicht behandelt wurde, bricht den Neustartalgorithmus ab und die Ausführung der Anweisung wird normal fortgesetzt.

  • UPDATE/DELETE Trigger werden mehrmals für denselben Datensatz ausgelöst, wenn die Anweisungsausführung neu gestartet wurde und der Datensatz erneut aktualisiert/gelöscht wird.

  • Der Anweisungsneustart ist normalerweise für Clientanwendungen vollständig transparent und Entwickler sollten keine besonderen Maßnahmen ergreifen, um ihn in irgendeiner Weise zu behandeln.Die einzige Ausnahme ist der Code mit Nebenwirkungen, die außerhalb der Transaktionskontrolle liegen, zum Beispiel:

    • Verwendung externer Tabellen, Sequenzen oder Kontextvariablen

    • Versenden von E-Mails mit UDF

    • Nutzung autonomer Transaktionen oder externer Abfragen

    und so weiter.Beachten Sie, dass ein solcher Code mehr als einmal ausgeführt werden kann, wenn ein Aktualisierungskonflikt auftritt.

  • Es gibt keine Möglichkeit zu erkennen, ob ein Neustart stattgefunden hat, aber er könnte manuell mit Code mit Nebenwirkungen wie oben beschrieben durchgeführt werden, beispielsweise mithilfe einer Kontextvariablen.

  • Aus historischen Gründen wird der Fehler isc_update_conflict als sekundärer Fehlercode gemeldet, wobei der primäre Fehlercode isc_deadlock ist.
NO AUTO UNDO

Die Option NO AUTO UNDO beeinflusst die Behandlung von Datensatzversionen (Garbage), die von der Transaktion im Fall eines Rollbacks erzeugt werden.Wenn NO AUTO UNDO markiert ist, markiert die ROLLBACK-Anweisung die Transaktion nur als Rollback, ohne die in der Transaktion erstellten Datensatzversionen zu löschen.Sie werden später von der Müllabfuhr weggewischt.

NO AUTO UNDO kann nützlich sein, wenn viele separate Anweisungen ausgeführt werden, die Daten unter Bedingungen ändern, bei denen die Transaktion wahrscheinlich die meiste Zeit erfolgreich festgeschrieben wird.

Die Option NO AUTO UNDO wird bei Transaktionen ignoriert, bei denen keine Änderungen vorgenommen werden.

RESTART REQUESTS

Laut den Firebird-Quellen wird dies

Alle Anfragen der aktuellen Verbindungen (Attachment) neustarten, um die übergebene Transaktion zu verwenden.

— src/jrd/tra.cpp

Die genaue Semantik und die Auswirkungen dieser Klausel sind nicht klar, und wir empfehlen, diese Klausel nicht zu verwenden.

AUTO COMMIT

Die Angabe von AUTO COMMIT aktiviert den Auto-Commit-Modus für die Transaktion.Im Auto-Commit-Modus führt Firebird intern nach jeder Anweisungsausführung das Äquivalent von COMMIT RETAIN aus.

Caution

Dies ist kein allgemein nützlicher Auto-Commit-Modus;derselbe Transaktionskontext wird beibehalten, bis die Transaktion durch einen Commit oder Rollback beendet wird.Mit anderen Worten, wenn Sie SNAPSHOT oder SNAPSHOT TABLE STABILITY verwenden, ändert dieser Auto-Commit die Sichtbarkeit des Datensatzes nicht (die Auswirkungen von Transaktionen, die nach dem Start dieser Transaktion festgeschrieben wurden, sind nicht sichtbar).

Für READ COMMITTED gelten die gleichen Warnungen wie für das Beibehalten von Commit: Die längere Verwendung einer einzelnen Transaktion im Auto-Commit-Modus kann die Garbage Collection verhindern und die Leistung beeinträchtigen.
IGNORE LIMBO

Dieses Flag wird verwendet, um zu signalisieren, dass Datensätze, die von Limbo-Transaktionen erstellt wurden, ignoriert werden sollen.Transaktionen bleiben “in der Schwebe”, wenn die zweite Stufe eines zweiphasigen Commits fehlschlägt.

Note
Historischer Hinweis

IGNORE LIMBO liefert den TPB-Parameter isc_tpb_ignore_limbo, der seit InterBase-Zeiten in der API verfügbar ist und hauptsächlich von gfix verwendet wird.
RESERVING

Die RESERVING-Klausel in der SET TRANSACTION-Anweisung reserviert Tabellen, die in der Tabellenliste angegeben sind.Das Reservieren einer Tabelle verhindert, dass andere Transaktionen Änderungen daran vornehmen oder sogar unter Einbeziehung bestimmter Parameter Daten aus ihnen lesen, während diese Transaktion läuft.

Eine RESERVING-Klausel kann auch verwendet werden, um eine Liste von Tabellen anzugeben, die von anderen Transaktionen geändert werden können, selbst wenn die Transaktion mit der Isolationsstufe SNAPSHOT TABLE STABILITY gestartet wird.

Eine RESERVING-Klausel wird verwendet, um beliebig viele reservierte Tabellen anzugeben.

Optionen für die RESERVING-Klausel

Wird eines der Schlüsselwörter SHARED oder PROTECTED weggelassen, wird SHARED angenommen.Wenn die gesamte FOR-Klausel weggelassen wird, wird FOR SHARED READ angenommen.Die Namen und die Kompatibilität der vier Zugriffsoptionen zum Reservieren von Tabellen sind nicht offensichtlich.

Table 1. Kompatibilität der Zugriffsoptionen für RESERVING

 

SHARED READ

SHARED WRITE

PROTECTED READ

PROTECTED WRITE

SHARED READ

Ja

Ja

Ja

Ja

SHARED WRITE

Ja

Ja

Nein

Nein

PROTECTED READ

Ja

Nein

Ja

Nein

PROTECTED WRITE

Ja

Nein

Nein

Nein

Die Kombinationen dieser RESERVING-Klausel-Flags für den gleichzeitigen Zugriff hängen von den Isolationsstufen der gleichzeitigen Transaktionen ab:

  • SNAPSHOT-Isolierung

    • Gleichzeitige SNAPSHOT-Transaktionen mit SHARED READ haben keinen Einfluss auf den Zugriff des anderen

    • Eine gleichzeitige Mischung aus SNAPSHOT- und READ COMMITTED-Transaktionen mit SHARED WRITE hat keinen Einfluss auf den gegenseitigen Zugriff, aber sie blockieren Transaktionen mit der SNAPSHOT TABLE STABILITY-Isolation entweder vom Lesen aus oder Schreiben in die angegebene(n) Tabelle(n). )

    • Gleichzeitige Transaktionen mit beliebiger Isolationsstufe und PROTECTED READ können nur Daten aus den reservierten Tabellen lesen.Jeder Versuch, auf sie zu schreiben, führt zu einer Ausnahme

    • Mit PROTECTED WRITE können gleichzeitige Transaktionen mit SNAPSHOT und READ COMMITTED Isolation nicht in die angegebenen Tabellen schreiben.Transaktionen mit SNAPSHOT TABLE STABILITY-Isolation können überhaupt nicht aus den reservierten Tabellen lesen oder in sie schreiben.

  • Isolierung "SNAPSHOT TABLE STABILITY"

    • Alle gleichzeitigen Transaktionen mit SHARED READ können unabhängig von ihrer Isolationsstufe aus den reservierten Tabellen lesen oder schreiben (wenn im READ WRITE Modus)

    • Gleichzeitige Transaktionen mit den Isolationsstufen SNAPSHOT und READ COMMITTED und SHARED WRITE können Daten aus den angegebenen Tabellen lesen und schreiben (wenn im READ WRITE-Modus) aber gleichzeitig auf diese Tabellen von Transaktionen mit SNAPSHOT . zugreifen TABLE STABILITY ist komplett gesperrt, während diese Transaktionen aktiv sind

    • Gleichzeitige Transaktionen mit beliebiger Isolationsstufe und PROTECTED READ können nur aus den reservierten Tabellen lesen

    • Mit PROTECTED WRITE können gleichzeitige SNAPSHOT- und READ COMMITTED-Transaktionen aus den reservierten Tabellen lesen, aber nicht in sie schreiben.Der Zugriff durch Transaktionen mit der Isolationsstufe SNAPSHOT TABLE STABILITY wird vollständig blockiert.

  • Isolation "READ COMMITTED"

    • Mit SHARED READ können alle gleichzeitigen Transaktionen mit beliebiger Isolationsstufe sowohl von den reservierten Tabellen lesen als auch schreiben (wenn im READ WRITE Modus)

    • SHARED WRITE erlaubt allen Transaktionen in der SNAPSHOT- und READ COMMITTED-Isolation das Lesen und Schreiben (wenn im READ WRITE-Modus) in die angegebenen Tabellen und blockiert den Zugriff vollständig von Transaktionen mit der SNAPSHOT TABLE STABILITY-Isolation

    • Mit PROTECTED READ können gleichzeitige Transaktionen mit beliebiger Isolationsstufe nur aus den reservierten Tabellen lesen

    • Mit PROTECTED WRITE können gleichzeitige Transaktionen in SNAPSHOT und READ COMMITTED Isolation aus den angegebenen Tabellen lesen, aber nicht in sie schreiben.Der Zugriff von Transaktionen in der Isolation SNAPSHOT TABLE STABILITY wird vollständig blockiert.

Note

In Embedded SQL kann die USING-Klausel verwendet werden, um Systemressourcen zu schonen, indemBegrenzung der Anzahl der Datenbanken, auf die eine Transaktion zugreifen kann.USING schließt sich mit RESERVING gegenseitig aus.Eine USING-Klausel in der SET TRANSACTION-Syntax wird in DSQL nicht unterstützt.
Siehe auch

[fblangref40-transacs-commit-de], [fblangref40-transacs-rollback-de]

COMMIT

Verwendet für

Bestätigen einer Transaktion

Verfügbar in

DSQL, ESQL

Syntax
COMMIT [TRANSACTION tr_name] [WORK]
  [RETAIN [SNAPSHOT] | RELEASE];
Table 1. COMMIT-Anweisungsparameter
Parameter Beschreibung

tr_name

Transaktionsname.Nur in ESQL verfügbar

Die COMMIT-Anweisung verpflichtet alle Arbeiten, die im Rahmen dieser Transaktion ausgeführt werden (Einfügungen, Aktualisierungen, Löschungen, Auswahlen, Ausführen von Prozeduren).Neue Datensatzversionen werden für andere Transaktionen verfügbar, und wenn die 'RETAIN'-Klausel nicht verwendet wird, werden alle Serverressourcen, die seiner Arbeit zugewiesen sind, freigegeben.

Wenn während des Festschreibens der Transaktion Konflikte oder andere Fehler in der Datenbank auftreten, wird die Transaktion nicht festgeschrieben und die Gründe werden zur Bearbeitung an die Benutzeranwendung zurückgesendet, und die Möglichkeit, einen weiteren Festschreibungsversuch oder ein Rollback der Transaktion zu versuchen .

Die Klauseln TRANSACTION und RELEASE sind nur in ESQL gültig.

COMMIT-Optionen

  • Die optionale TRANSACTION tr_name-Klausel, die nur in Embedded SQL verfügbar ist, gibt den Namen der Transaktion an, die festgeschrieben werden soll.Ohne TRANSACTION-Klausel wird COMMIT auf die Standardtransaktion angewendet.

    Note

    In ESQL-Anwendungen ermöglichen benannte Transaktionen, dass mehrere Transaktionen gleichzeitig in einer Anwendung aktiv sind.Wenn benannte Transaktionen verwendet werden, muss für jede benannte Transaktion eine Hostsprachenvariable mit demselben Namen deklariert und initialisiert werden.Dies ist eine Einschränkung, die eine dynamische Angabe von Transaktionsnamen verhindert und somit eine Transaktionsbenennung in DSQL ausschließt.

  • Das optionale Schlüsselwort WORK wird nur aus Kompatibilitätsgründen mit anderen relationalen Datenbankverwaltungssystemen unterstützt, die es erfordern.

  • Das Schlüsselwort RELEASE ist nur in Embedded SQL verfügbar und ermöglicht die Trennung von allen Datenbanken, nachdem die Transaktion festgeschrieben wurde.RELEASE wird in Firebird nur aus Kompatibilitätsgründen mit älteren Versionen von InterBase beibehalten.Es wurde in ESQL durch die DISCONNECT-Anweisung ersetzt.

  • Die RETAIN [SNAPSHOT]-Klausel wird für das “soft”-Commit verwendet, das unter Hostsprachen und ihren Praktikern verschiedentlich als COMMIT WITH RETAIN, “CommitRetaining”, “warm commit”, etc. bezeichnet wird.Die Transaktion wird festgeschrieben, aber einige Serverressourcen werden beibehalten und eine neue Transaktion wird transparent mit derselben Transaktions-ID neu gestartet.Der Zustand von Zeilencaches und Cursors wird so beibehalten, wie er vor dem Soft Commit war.

    Bei Transaktionen mit Soft-Committed, deren Isolationsstufe SNAPSHOT oder SNAPSHOT TABLE STABILITY ist, wird die Ansicht des Datenbankstatus nicht aktualisiert, um Änderungen durch andere Transaktionen widerzuspiegeln, und der Benutzer der Anwendungsinstanz hat weiterhin dieselbe Ansicht wie beim Transaktion wurde ursprünglich gestartet.Änderungen, die während der Laufzeit der einbehaltenen Transaktion vorgenommen wurden, sind natürlich für diese Transaktion sichtbar.

Note
Empfehlung

Die Verwendung der COMMIT-Anweisung anstelle von ROLLBACK wird empfohlen, um Transaktionen zu beenden, die nur Daten aus der Datenbank lesen, da COMMIT weniger Serverressourcen verbraucht und hilft, die Leistung nachfolgender Transaktionen zu optimieren.
Siehe auch

[fblangref40-transacs-settransac-de], [fblangref40-transacs-rollback-de]

ROLLBACK

Verwendet für

Rollback einer Transaktion

Verfügbar in

DSQL, ESQL

Syntax
  ROLLBACK [TRANSACTION tr_name] [WORK]
    [RETAIN [SNAPSHOT] | RELEASE]
| ROLLBACK [WORK] TO [SAVEPOINT] sp_name
Table 1. ROLLBACK-Anweisungsparameter
Parameter Beschreibung

tr_name

Transaktionsname.Nur in ESQL verfügbar

sp_name

Name des Sicherungspunkts.Nur in SQL verfügbar

Die ROLLBACK-Anweisung macht alle im Kontext dieser Transaktion ausgeführten Arbeiten (inserts, update, deletes, selects, Ausführung von Prozeduren) rückgängig.ROLLBACK schlägt nie fehl und verursacht daher keine Ausnahmen.Sofern die 'RETAIN'-Klausel nicht verwendet wird, werden alle der Arbeit der Transaktion zugeordneten Serverressourcen freigegeben.

Die Klauseln TRANSACTION und RELEASE sind nur in ESQL gültig.Die Anweisung ROLLBACK TO SAVEPOINT ist in ESQL nicht verfügbar.

ROLLBACK Options

  • Die optionale TRANSACTION tr_name-Klausel, die nur in Embedded SQL verfügbar ist, gibt den Namen der Transaktion an, die festgeschrieben werden soll.Ohne TRANSACTION-Klausel wird ROLLBACK auf die Standardtransaktion angewendet.

    Note

    In ESQL-Anwendungen ermöglichen benannte Transaktionen, dass mehrere Transaktionen gleichzeitig in einer Anwendung aktiv sind.Wenn benannte Transaktionen verwendet werden, muss für jede benannte Transaktion eine Hostsprachenvariable mit demselben Namen deklariert und initialisiert werden.Dies ist eine Einschränkung, die eine dynamische Angabe von Transaktionsnamen verhindert und somit eine Transaktionsbenennung in DSQL ausschließt.

  • Das optionale Schlüsselwort WORK wird nur aus Kompatibilitätsgründen mit anderen relationalen Datenbankverwaltungssystemen unterstützt, die es benötigen.

  • Das Schlüsselwort RETAIN gibt an, dass der Transaktionskontext beibehalten werden soll, obwohl die gesamte Arbeit der Transaktion rückgängig gemacht werden soll.Einige Serverressourcen werden beibehalten und die Transaktion wird transparent mit derselben Transaktions-ID neu gestartet.Der Zustand von Zeilencaches und Cursors wird so beibehalten, wie er vor dem “sanften” Rollback war.

    Bei Transaktionen, deren Isolationsstufe SNAPSHOT oder SNAPSHOT TABLE STABILITY ist, wird die Ansicht des Datenbankstatus durch das weiche Rollback nicht aktualisiert, um Änderungen durch andere Transaktionen widerzuspiegeln.Der Benutzer der Anwendungsinstanz hat weiterhin dieselbe Ansicht wie beim ursprünglichen Start der Transaktion.Änderungen, die während der Laufzeit der einbehaltenen Transaktion vorgenommen und mit einem Soft-Commit versehen wurden, sind natürlich für diese Transaktion sichtbar.

Siehe auch

[fblangref40-transacs-settransac-de], [fblangref40-transacs-commit-de]

ROLLBACK TO SAVEPOINT

Die alternative Anweisung ROLLBACK TO SAVEPOINT gibt den Namen eines Sicherungspunkts an, an dem Änderungen rückgängig gemacht werden sollen.Der Effekt besteht darin, alle innerhalb der Transaktion vorgenommenen Änderungen rückgängig zu machen, vom angegebenen Sicherungspunkt vorwärts bis zu dem Punkt, an dem ROLLBACK TO SAVEPOINT angefordert wird.

ROLLBACK TO SAVEPOINT führt die folgenden Operationen aus:

  • Alle Datenbankmutationen, die seit der Erstellung des Sicherungspunkts durchgeführt wurden, werden rückgängig gemacht.Mit RDB$SET_CONTEXT() gesetzte Benutzervariablen bleiben unverändert.

  • Alle Sicherungspunkte, die nach dem benannten erstellt wurden, werden zerstört.Savepoints vor dem benannten werden zusammen mit dem benannten Savepoint selbst beibehalten.Wiederholte Rollbacks auf denselben Sicherungspunkt sind somit zulässig.

  • Alle impliziten und expliziten Datensatzsperren, die seit dem Sicherungspunkt erworben wurden, werden aufgehoben.Andere Transaktionen, die Zugriff auf nach dem Sicherungspunkt gesperrte Zeilen angefordert haben, müssen weiterhin warten, bis die Transaktion festgeschrieben oder zurückgesetzt wird.Andere Transaktionen, die die Zeilen noch nicht angefordert haben, können die entsperrten Zeilen sofort anfordern und darauf zugreifen.

Siehe auch

[fblangref40-transacs-savepoint-de], [fblangref40-transacs-releasesp-de]

SAVEPOINT

Verwendet für

Erstellen eines Sicherungspunkts

Verfügbar in

DSQL

Syntax
SAVEPOINT sp_name
Table 1. SAVEPOINT-Anweisungsparameter
Parameter Beschreibung

sp_name

Name des Sicherungspunkts.Nur in SQL verfügbar

Die SAVEPOINT-Anweisung erstellt einen SQL:99-konformen Savepoint, der als Marker im „Stack“ von Datenaktivitäten innerhalb einer Transaktion fungiert.Anschließend können die im “Stack” ausgeführten Aufgaben bis zu diesem Sicherungspunkt rückgängig gemacht werden, wobei die frühere Arbeit und ältere Sicherungspunkte unberührt bleiben.Savepoint-Mechanismen werden manchmal als “veschachtelte Transaktionen” bezeichnet.

Wenn bereits ein Sicherungspunkt mit demselben Namen wie dem für den neuen angegebenen Sicherungspunkt vorhanden ist, wird der vorhandene Sicherungspunkt freigegeben und ein neuer mit dem angegebenen Namen erstellt.

Um Änderungen zum Savepoint zurückzurollen, wird die Anweisung ROLLBACK TO SAVEPOINT verwendet.

Note
Erwägungen zum Speicher

Der interne Mechanismus unter Sicherungspunkten kann viel Speicher beanspruchen, insbesondere wenn dieselben Zeilen mehrere Aktualisierungen in einer Transaktion erhalten.Wenn ein Sicherungspunkt nicht mehr benötigt wird, die Transaktion aber noch Arbeit zu erledigen hat, wird er durch eine [fblangref40-transacs-releasesp-de]-Anweisung gelöscht und somit die Ressourcen freigegeben.
Beispiel-DSQL-Sitzung mit Sicherungspunkten
CREATE TABLE TEST (ID INTEGER);
COMMIT;
INSERT INTO TEST VALUES (1);
COMMIT;
INSERT INTO TEST VALUES (2);
SAVEPOINT Y;
DELETE FROM TEST;
SELECT * FROM TEST; -- returns no rows
ROLLBACK TO Y;
SELECT * FROM TEST; -- returns two rows
ROLLBACK;
SELECT * FROM TEST; -- returns one row
Siehe auch

[fblangref40-transacs-rollback-tosavepoint-de], [fblangref40-transacs-releasesp-de]

RELEASE SAVEPOINT

Verwendet für

Speicherpunkt löschen

Verfügbar in

DSQL

Syntax
RELEASE SAVEPOINT sp_name [ONLY]
Table 1. RELEASE SAVEPOINT Statement Parameter
Parameter Beschreibung

sp_name

Name des Sicherungspunkts.Nur in SQL verfügbar

Die Anweisung RELEASE SAVEPOINT löscht einen benannten Savepoint und gibt alle darin enthaltenen Ressourcen frei.Standardmäßig werden alle Sicherungspunkte, die nach dem benannten Sicherungspunkt erstellt wurden, ebenfalls freigegeben.Der Qualifier ONLY weist die Engine an, nur den benannten Savepoint freizugeben.

Siehe auch

[fblangref40-transacs-savepoint-de]

Interne Sicherungspunkte

Standardmäßig verwendet die Engine einen automatischen Sicherungspunkt auf Transaktionsebene, um ein Transaktions-Rollback durchzuführen.Wenn eine ROLLBACK-Anweisung ausgegeben wird, werden alle in dieser Transaktion durchgeführten Änderungen über einen Sicherungspunkt auf Transaktionsebene zurückgesetzt und die Transaktion wird dann festgeschrieben.Diese Logik reduziert die Menge der durch Rollback-Transaktionen verursachten Garbage Collection.

Wenn das Volumen der Änderungen, die unter einem Sicherungspunkt auf Transaktionsebene durchgeführt werden, groß wird (~50000 betroffene Datensätze), gibt die Engine den Sicherungspunkt auf Transaktionsebene frei und verwendet die Transaktionsbestandsseite (TIP) als Mechanismus, um die Transaktion bei Bedarf zurückzusetzen.

Tip

Wenn Sie erwarten, dass das Volumen der Änderungen in Ihrer Transaktion groß ist, können Sie die Option NO AUTO UNDO in Ihrer SET TRANSACTION-Anweisung angeben, um die Erstellung des Sicherungspunkts auf Transaktionsebene zu blockieren.Wenn Sie stattdessen die API verwenden, würden Sie das TPB-Flag isc_tpb_no_auto_undo setzen.

Savepoints und PSQL

Anweisungen zur Transaktionssteuerung sind in PSQL nicht zulässig, da dies die Atomarität der Anweisung, die die Prozedur aufruft, zerstören würde.Firebird unterstützt jedoch das Auslösen und Behandeln von Ausnahmen in PSQL, sodass Aktionen, die in gespeicherten Prozeduren und Triggern ausgeführt werden, selektiv rückgängig gemacht werden können, ohne dass die gesamte Prozedur fehlschlägt.

Intern werden automatische Sicherungspunkte verwendet, um:

  • alle Aktionen im BEGIN…​END Block rückgängig machen, bei denen eine Ausnahme auftritt

  • alle von der Prozedur oder dem Trigger ausgeführten Aktionen rückgängig machen oder, in einer wählbaren Prozedur, alle Aktionen, die seit dem letzten SUSPEND ausgeführt wurden, wenn die Ausführung aufgrund eines nicht abgefangenen Fehlers oder einer Ausnahme vorzeitig beendet wird

Jeder PSQL-Ausnahmebehandlungsblock ist außerdem durch automatische Systemsicherungspunkte begrenzt.

Note

Ein BEGIN…​END-Block erzeugt selbst keinen automatischen Sicherungspunkt.Ein Sicherungspunkt wird nur in Blöcken erstellt, die die WHEN-Anweisung zur Behandlung von Ausnahmen enthalten.