FirebirdSQL logo
 KontextvariablenSicherheit 
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.