FirebirdSQL logo
 SQL-SicherheitZusatzinformationen 

So funktioniert der Verbindungspool

Jeder erfolgreichen Verbindung ist ein Pool zugeordnet, der zwei Listen verwaltet – eine für inaktive Verbindungen und eine für aktive Verbindungen.Wenn eine Verbindung in der “aktiv”-Liste keine aktiven Anfragen und keine aktiven Transaktionen hat, wird sie als “unbenutzt” angenommen.Es wird versucht, die nicht verwendete Verbindung zurückzusetzen, indem eine ALTER SESSION RESET-Anweisung verwendet wird und

  • wenn das Zurücksetzen erfolgreich ist (keine Fehler auftreten), wird die Verbindung in die “Idle”-Liste verschoben;

  • wenn das Zurücksetzen fehlschlägt, wird die Verbindung geschlossen;

  • Wenn der Pool seine maximale Größe erreicht hat, wird die älteste inaktive Verbindung geschlossen.

  • Wenn die Lebensdauer einer inaktiven Verbindung abläuft, wird sie aus dem Pool gelöscht und geschlossen.

Neue Verbindungen

Wenn die Engine aufgefordert wird, eine neue externe Verbindung zu erstellen, sucht der Pool zunächst nach einem Kandidaten in der “idle”-Liste.Die Suche, bei der die Groß-/Kleinschreibung beachtet wird, umfasst vier Parameter:

  1. Verbindungszeichenfolge

  2. Nutzername

  3. Passwort

  4. Rolle

Wenn eine geeignete Verbindung gefunden wird, wird überprüft, ob sie noch am Leben ist.

  • Wenn die Prüfung fehlschlägt, wird sie gelöscht und die Suche wiederholt, ohne dem Kunden einen Fehler zu melden

  • Andernfalls wird die Live-Verbindung von der “Idle”-Liste in die “active”-Liste verschoben und an den Anrufer zurückgegeben

  • Bei mehreren passenden Anschlüssen wird der zuletzt genutzte ausgewählt

  • Wenn keine passende Verbindung vorhanden ist, wird eine neue erstellt und der Liste "aktiv" hinzugefügt.

docnext count = 25

Wer kann den Pool für externe Verbindungen ändern?

Die Anweisung ALTER EXTERNAL CONNECTIONS POOL kann ausgeführt werden durch:

Siehe auch

RDB$GET_CONTEXT

Ändern der aktuellen Rolle

SET ROLE

Benutzt für

Ändern der Rolle der aktuellen Sitzung

Verfügbar in

DSQL

Syntax
SET ROLE {role_name | NONE}
Table 1. SET ROLE-Anweisungsparameter
Parameter Beschreibung

role_name

Der Name der anzuwendenden Rolle role

Die SET ROLE-Anweisung ermöglicht es einem Benutzer, eine andere Rolle anzunehmen;es setzt die Kontextvariable CURRENT_ROLE auf role_name, wenn diese Rolle dem CURRENT_USER gewährt wurde.Für diese Sitzung erhält der Benutzer die von dieser Rolle gewährten Berechtigungen.Alle Rechte, die der vorherigen Rolle gewährt wurden, werden aus der Sitzung entfernt.Verwenden Sie NONE anstelle von role_name, um die CURRENT_ROLE zu löschen.

Wenn die angegebene Rolle nicht existiert oder dem Benutzer nicht explizit zugewiesen wurde, wird der Fehler “Role role_name is invalid or unavailable” ausgegeben.

SET ROLE-Beispiele

  1. Ändern Sie die aktuelle Rolle in MANAGER

    SET ROLE manager;
select current_role from rdb$database;

ROLE
=======================
MANAGER

  2. Löschen Sie die aktuelle Rolle

    SET ROLE NONE;
select current_role from rdb$database;

ROLE
=======================
NONE
Siehe auch

[fblangref40-management-role-set-trusted-de], GRANT

SET TRUSTED ROLE

Verwendet für

Ändert die Rolle der aktuellen Sitzung in die vertrauenswürdige Rolle

Verfügbar in

DSQL

Syntax
SET TRUSTED ROLE

Die Anweisung SET TRUSTED ROLE ermöglicht es, die dem Benutzer durch eine Mapping-Regel zugewiesene Rolle einzunehmen (siehe Mapping von Benutzern auf Objekte).Die durch eine Zuordnungsregel zugewiesene Rolle wird beim Verbinden automatisch übernommen, wenn der Benutzer keine explizite Rolle angegeben hat.Die Anweisung SET TRUSTED ROLE ermöglicht es, die zugeordnete (oder trusted`) Rolle zu einem späteren Zeitpunkt oder nach Änderung der aktuellen Rolle mit SET ROLE wieder einzunehmen.

Eine vertrauenswürdige Rolle ist kein bestimmter Rollentyp, sondern kann eine beliebige Rolle sein, die mit CREATE ROLE erstellt wurde, oder eine vordefinierte Systemrolle wie RDB$ADMIN.Ein Anhang (Sitzung) hat eine vertrauenswürdige Rolle, wenn das Sicherheitsobjekt-Mapping-Subsystem eine Übereinstimmung zwischen dem vom Plugin übergebenen Authentifizierungsergebnis und einer lokalen oder globalen Zuordnung zu einer Rolle für die aktuelle Datenbank findet.Die Rolle kann diesem Benutzer nicht explizit zugewiesen werden.

Wenn eine Sitzung keine vertrauenswürdige Rolle hat, wird die Ausführung von SET TRUSTED ROLE den Fehler „Your attachment has no trusted role“ auslösen.

Note

Während die CURRENT_ROLE mit SET ROLE geändert werden kann, ist es nicht immer möglich, mit demselben Befehl zu einer vertrauenswürdigen Rolle zurückzukehren, da SET ROLE prüft, ob die Rolle dem Benutzer zugewiesen wurde.Mit SET TRUSTED ROLE kann die Trusted Rolle auch dann wieder übernommen werden, wenn SET ROLE fehlschlägt.

SET TRUSTED ROLE-Beispiele

  1. Angenommen, eine Zuordnungsregel weist einem Benutzer "ALEX" die Rolle "ROLE1" zu:

    CONNECT 'employee' USER ALEX PASSWORD 'password';
SELECT CURRENT_ROLE FROM RDB$DATABASE;

ROLE
===============================
ROLE1

SET ROLE ROLE2;
SELECT CURRENT_ROLE FROM RDB$DATABASE;

ROLE
===============================
ROLE2

SET TRUSTED ROLE;
SELECT CURRENT_ROLE FROM RDB$DATABASE;

ROLE
===============================
ROLE1
Siehe auch

[fblangref40-management-role-set-de], Zuordnung von Benutzern zu Objekten

Session Timeouts

Statements for management of timeouts of the current connection.

SET SESSION IDLE TIMEOUT

Verwendet für

Ändern des Sitzungsleerlauf-Timeouts

Verfügbar in

DSQL, PSQL

Syntax
SET SESSION IDLE TIMEOUT value [<time-unit>]

<time-unit> ::= MINUTE | HOUR | SECOND
Table 1. SET SESSION IDLE TIMEOUT-Anweisungsparameter
Parameter Beschreibung

value

Die Zeitüberschreitungsdauer, ausgedrückt in time-unit.Ein Wert von '0' verschiebt die Zeitüberschreitung bei Verbindungsleerlauf, die für die Datenbank konfiguriert ist.

time-unit

Zeiteinheit des Timeouts.Standard ist MINUTE.

Das SET SESSION IDLE TIMEOUT setzt ein Leerlauf-Timeout auf Verbindungsebene und wird sofort wirksam.Die Anweisung kann außerhalb der Transaktionssteuerung (ohne aktive Transaktion) ausgeführt werden.

Das Festlegen eines value größer als für die Datenbank konfiguriert ist zulässig, wird aber effektiv ignoriert, siehe auch [fblangref40-management-session-timeout-effective-de].

Das aktuelle Zeitlimit für die Sitzung kann über RDB$GET_CONTEXT, Namespace SYSTEM und Variable SESSION_IDLE_TIMEOUT abgerufen werden.Informationen sind auch von MON$ATTACHMENTS erhältlich:

MON$IDLE_TIMEOUT

Leerlaufzeitüberschreitung auf Verbindungsebene in Sekunden;0 wenn Timeout nicht gesetzt ist.

MON$IDLE_TIMER

Ablaufzeit des Leerlauftimers;enthält NULL, wenn kein Idle-Timeout gesetzt wurde oder kein Timer läuft.

Sowohl RDB$GET_CONTEXT('SYSTEM', 'SESSION_IDLE_TIMEOUT') und MON$ATTACHMENTS.MON$IDLE_TIMEOUT melden die für die Verbindung konfigurierte Leerlaufzeitüberschreitung;sie melden nicht die effektive Leerlaufzeitüberschreitung.

Das Sitzungsleerlauf-Timeout wird zurückgesetzt, wenn [fblangref40-management-session-reset-alter-de] ausgeführt wird.

Zeitüberschreitungen bei untätigen Sitzungen

Ein Timeout für eine Leerlaufsitzung ermöglicht, dass eine Nutzungsverbindung nach einer bestimmten Zeit der Inaktivität automatisch geschlossen wird.Ein Datenbankadministrator kann damit die Schließung alter Verbindungen erzwingen, die inaktiv geworden sind, um unnötigen Ressourcenverbrauch zu reduzieren.Es kann auch von Anwendungs- und Werkzeugentwicklern als Alternative zum Schreiben eigener Module zur Steuerung der Verbindungslebensdauer verwendet werden.

Standardmäßig ist die Leerlaufzeitüberschreitung nicht aktiviert.Es wird keine Mindest- oder Höchstgrenze festgelegt, aber ein angemessen langer Zeitraum – beispielsweise einige Stunden – wird empfohlen.

So funktioniert das Timeout für Leerlaufsitzungen

  • Wenn der Benutzer-API-Aufruf die Engine verlässt (zur aufrufenden Verbindung zurückkehrt), wird ein spezieller Leerlauf-Timer gestartet, der der aktuellen Verbindung zugeordnet ist

  • Wenn ein anderer Benutzer-API-Aufruf von dieser Verbindung in die Engine eingeht, wird der Leerlauf-Timer gestoppt und auf Null zurückgesetzt

  • Bei Überschreitung der maximalen Leerlaufzeit schließt die Engine die Verbindung sofort wie beim asynchronen Verbindungsabbau:

    • alle aktiven Anweisungen und Cursor sind geschlossen

    • alle aktiven Transaktionen werden zurückgesetzt

    • Die Netzwerkverbindung bleibt zu diesem Zeitpunkt geöffnet, sodass die Client-Anwendung den genauen Fehlercode beim nächsten API-Aufruf abrufen kann.Die Netzwerkverbindung wird serverseitig, nach einer Fehlermeldung oder zu gegebener Zeit durch einen Netzwerk-Timeout durch eine clientseitige Trennung geschlossen.

Note

Immer wenn eine Verbindung abgebrochen wird, gibt der nächste Benutzer-API-Aufruf den Fehler isc_att_shutdown mit einem sekundären Fehler zurück, der den genauen Grund angibt.Jetzt haben wir

isc_att_shut_idle

Idle-Timeout abgelaufen

zusätzlich zu

isc_att_shut_killed

Vom Datenbankadministrator getötet

isc_att_shut_db_down

Datenbank wird heruntergefahren

isc_att_shut_engine

Motor wird abgeschaltet
Einstellen des Timeouts für Leerlaufsitzungen
Note

Der Leerlauf-Timer startet nicht, wenn die Timeout-Periode auf Null gesetzt ist.

Ein Timeout für eine Leerlaufsitzung kann eingestellt werden:

  • Auf Datenbankebene kann der Datenbankadministrator den Konfigurationsparameter ConnectionIdleTimeout setzen, einen ganzzahligen Wert in Minuten.Der Standardwert Null bedeutet, dass kein Timeout festgelegt ist.Es ist pro Datenbank konfigurierbar, kann also global in firebird.conf eingestellt und für einzelne Datenbanken in databases.conf nach Bedarf überschrieben werden.

    Der Geltungsbereich dieser Methode umfasst alle Benutzerverbindungen, außer Systemverbindungen (Garbage Collector, Cache Writer usw.).

  • Auf Verbindungsebene wird das Timeout der Leerlaufsitzung sowohl von der Anweisung SET SESSION IDLE TIMEOUT als auch von der API (setIdleTimeout) unterstützt.Der Umfang dieser Methode ist spezifisch für den mitgelieferten Anschluss (Aufsatz).Sein Wert in der API ist in Sekunden.In der SQL-Syntax können es Stunden, Minuten oder Sekunden sein.Der Geltungsbereich dieser Methode ist die Verbindung, auf die sie angewendet wird.

Note

Weitere Informationen zu den API-Aufrufen finden Sie in den Firebird 4.0 Release Notes.
Bestimmen des wirksamen Timeouts

Der effektive Leerlauf-Timeout-Wert wird immer dann bestimmt, wenn ein Benutzer-API-Aufruf die Engine verlässt, wobei zuerst auf Verbindungsebene und dann auf Datenbankebene geprüft wird.Ein Timeout auf Verbindungsebene kann den Wert einer Einstellung auf Datenbankebene außer Kraft setzen, solange der Zeitraum für die Einstellung auf Verbindungsebene nicht länger als ein auf Datenbankebene anwendbares Timeout ungleich Null ist.

Important

Beachten Sie den Unterschied zwischen den Zeiteinheiten auf jeder Ebene.Auf Datenbankebene ist in den Konfigurationsdateien die Einheit für SessionTimeout Minuten.In SQL ist die Standardeinheit Minuten, kann aber explizit in Stunden oder Sekunden ausgedrückt werden.Auf API-Ebene ist die Einheit Sekunden.

Absolute Genauigkeit ist in jedem Fall nicht garantiert, insbesondere bei hoher Systemlast, aber es wird garantiert, dass Timeouts nicht vor dem angegebenen Zeitpunkt ablaufen.

SET STATEMENT TIMEOUT

Verwendet für

Anweisungs-Timeout für eine Verbindung ändern

Verfügbar in

DSQL, PSQL

Syntax
SET STATEMENT TIMEOUT value [<time-unit>]

<time-unit> ::= SECOND | MILLISECOND | MINUTE | HOUR
Table 1. SET STATEMENT TIMEOUT-Anweisungsparameter
Parameter Beschreibung

value

Die Zeitüberschreitungsdauer, ausgedrückt in time-unit.Ein Wert von 0 verschiebt die Zeitüberschreitung der Anweisung, die für die Datenbank konfiguriert ist.

time-unit

Zeiteinheit des Timeouts.Standardmäßig ist SECOND.

Das SET SESSION IDLE TIMEOUT setzt ein Leerlauf-Timeout auf Verbindungsebene und wird sofort wirksam.Die Anweisung kann außerhalb der Transaktionssteuerung (ohne aktive Transaktion) ausgeführt werden.

Das Setzen eines value größer als für die Datenbank konfiguriert ist zulässig, wird aber effektiv ignoriert, siehe auch [fblangref40-management-stmnt-timeout-effective-de].

Das aktuelle Statement-Timeout für die Sitzung kann über RDB$GET_CONTEXT, Namespace SYSTEM und Variable STATEMENT_TIMEOUT abgerufen werden. Informationen sind auch von MON$ATTACHMENTS erhältlich:

MON$STATEMENT_TIMEOUT

Zeitlimit für Anweisung auf Verbindungsebene in Millisekunden;0 wenn Timeout nicht gesetzt ist.

In MON$STATEMENTS:

MON$STATEMENT_TIMEOUT

Anweisungs-Timeout auf Anweisungsebene in Millisekunden;0 wenn Timeout nicht gesetzt ist.

MON$STATEMENT_TIMER

Ablaufzeit des Timeout-Timers;enthält NULL, wenn kein Idle-Timeout gesetzt wurde oder kein Timer läuft.

Sowohl RDB$GET_CONTEXT('SYSTEM', 'SESSION_IDLE_TIMEOUT') und MON$ATTACHMENTS.MON$IDLE_TIMEOUT melden die für die Verbindung konfigurierte Leerlaufzeitüberschreitung und MON$STATEMENTS$STATEMENT_TIMEOUT für die Anweisung;sie melden nicht das effektive Zeitlimit für die Anweisung.

Der Anweisungs-Timeout wird zurückgesetzt, wenn [fblangref40-management-session-reset-alter-de] ausgeführt wird.

Statement-Timeouts

Die Anweisungs-Timeout-Funktion ermöglicht es, die Ausführung einer Anweisung automatisch zu stoppen, wenn sie länger als ein vorgegebener Timeout-Zeitraum ausgeführt wurde.Es gibt dem Datenbankadministrator ein Instrument zur Begrenzung des übermäßigen Ressourcenverbrauchs durch umfangreiche Abfragen.

Anweisungs-Timeouts können auch für Anwendungsentwickler hilfreich sein, wenn sie komplexe Abfragen erstellen und debuggen, ohne die Ausführungszeit im Voraus zu kennen.Tester und andere könnten sie nützlich finden, um Abfragen mit langer Laufzeit zu erkennen und endliche Laufzeiten für Testsuiten festzulegen.

So funktioniert das Anweisungs-Timeout

Wenn die Anweisung mit der Ausführung beginnt oder ein Cursor geöffnet wird, startet die Engine einen speziellen Timer.Sie wird gestoppt, wenn die Ausführung der Anweisung abgeschlossen ist oder der letzte Datensatz vom Cursor abgerufen wurde.

Note

Ein Abruf setzt diesen Timer nicht zurück.

Wenn der Timeout-Punkt erreicht ist:

  • Wenn die Anweisungsausführung aktiv ist, stoppt sie zum nächstmöglichen Zeitpunkt

  • Wenn die Anweisung derzeit nicht aktiv ist (z. B. zwischen Abrufen), wird sie als abgebrochen markiert und der nächste Abruf unterbricht tatsächlich die Ausführung und gibt einen Fehler zurück

Note
Anweisungstypen von Timeouts ausgeschlossen

Anweisungs-Timeouts gelten nicht für einige Anweisungstypen und werden einfach ignoriert:

  • Alle DDL-Anweisungen

  • Alle internen Abfragen, die von der Engine selbst ausgegeben werden
Festlegen eines Anweisungs-Timeouts
Note

Der Timer startet nicht, wenn die Timeout-Periode auf Null gesetzt ist.

Ein Anweisungs-Timeout kann eingestellt werden:

  • auf Datenbankebene durch den Datenbankadministrator durch Setzen des Konfigurationsparameters StatementTimeout in firebird.conf oder databases.conf.StatementTimeout ist eine Ganzzahl, die die Anzahl der Sekunden angibt, nach denen die Ausführung der Anweisung automatisch von der Engine abgebrochen wird.Null bedeutet, dass kein Timeout eingestellt ist.Eine Einstellung ungleich Null wirkt sich auf alle Anweisungen in allen Verbindungen aus.

  • auf Verbindungsebene mit SET STATEMENT TIMEOUT oder der API zum Setzen eines Anweisungs-Timeouts (setStatementTimeout).Eine Einstellung auf Verbindungsebene (über SQL oder die API) wirkt sich auf alle Anweisungen für die angegebene Verbindung aus;Einheiten für die Timeout-Periode auf dieser Ebene können mit beliebiger Granularität von Stunden bis Millisekunden angegeben werden.

  • auf Anweisungsebene unter Verwendung der API in Millisekunden

Bestimmen des gültigen Anweisungs-Timeouts

Der gültige Anweisungs-Timeout-Wert wird immer dann bestimmt, wenn eine Anweisung ausgeführt wird oder ein Cursor geöffnet wird.Bei der Suche nach dem wirksamen Timeout durchläuft die Engine die Ebenen, von der Anweisung bis zur Datenbank- und/oder globalen Ebene, bis sie einen Wert ungleich Null findet.Wenn sich herausstellt, dass der gültige Wert null ist, läuft kein Anweisungstimer und es gilt kein Timeout.

Ein Timeout auf Anweisungs- oder Verbindungsebene kann den Wert einer Einstellung auf Datenbankebene außer Kraft setzen, solange der Zeitraum für die Einstellung auf niedrigerer Ebene nicht länger als ein auf Datenbankebene anwendbares Timeout ungleich Null ist.

Important

Beachten Sie den Unterschied zwischen den Zeiteinheiten auf jeder Ebene.Auf Datenbankebene in der conf-Datei ist die Einheit für StatementTimeout Sekunden.In SQL ist die Standardeinheit Sekunden, kann aber explizit in Stunden, Minuten oder Millisekunden ausgedrückt werden.Auf API-Ebene ist die Einheit Millisekunden.

Absolute Genauigkeit ist in jedem Fall nicht garantiert, insbesondere bei hoher Systemlast, aber es wird garantiert, dass Timeouts nicht vor dem angegebenen Zeitpunkt ablaufen.

Immer wenn eine Anweisung das Zeitlimit überschreitet und abgebrochen wird, gibt der nächste Benutzer-API-Aufruf den Fehler "isc_cancelled" mit einem sekundären Fehler zurück, der den genauen Grund angibt, d. h.

isc_cfg_stmt_timeout

Zeitüberschreitung auf Konfigurationsebene abgelaufen

isc_att_stmt_timeout

Zeitüberschreitung auf Attachmentebene abgelaufen

isc_req_stmt_timeout

Zeitüberschreitung auf Anweisungsebene abgelaufen

Note
Hinweise zu Anweisungs-Timeouts

  1. Eine Client-Anwendung könnte länger warten als durch den Zeitüberschreitungswert festgelegt, wenn die Engine aufgrund des Abbruchs der Anweisung eine große Anzahl von Aktionen rückgängig machen muss

  2. Wenn die Engine eine EXECUTE STATEMENT-Anweisung ausführt, übergibt sie den Rest des derzeit aktiven Timeouts an die neue Anweisung.Wenn die externe (entfernte) Engine keine Anweisungs-Timeouts unterstützt, ignoriert die lokale Engine stillschweigend alle entsprechenden Fehler.

  3. Wenn die Engine eine Sperre vom Sperrenmanager erhält, versucht sie, den Wert des Sperrzeitlimits zu verringern, indem es den Rest des aktuell aktiven Anweisungszeitlimits verwendet, falls möglich.Aufgrund der Interna des Sperrmanagers wird der Rest der Anweisungszeitüberschreitung auf ganze Sekunden aufgerundet.

Zeitzonenverwaltung

Anweisungen zur Verwaltung von Zeitzonenfunktionen der aktuellen Verbindungen.

SET TIME ZONE

Verwendet für

Ändern der Sitzungszeitzone

Verfügbar in

DSQL, PSQL

Syntax
SET TIME ZONE { time_zone_string | LOCAL }

Ändert die Sitzungszeitzone in die angegebene Zeitzone.Die Angabe von LOCAL wird auf die anfängliche Sitzungszeitzone der Sitzung zurückgesetzt (entweder die Standardeinstellung oder wie durch die Verbindungseigenschaft isc_dpb_session_time_zone angegeben).

Die Ausführung von [fblangref40-management-session-reset-alter-de] hat dieselbe Auswirkung auf die Sitzungszeitzone wie SET TIME ZONE LOCAL, setzt aber auch andere Sitzungseigenschaften zurück.

SET TIME ZONE-Beispiele

set time zone '-02:00';
set time zone 'America/Sao_Paulo';
set time zone local;

Sitzungsstatus zurücksetzen

ALTER SESSION RESET

Verwendet für

Sitzungsstatus auf die Anfangswerte zurücksetzen

Verfügbar in

DSQL, PSQL

Syntax
ALTER SESSION RESET

ALTER SESSION RESET setzt die aktuelle Benutzersitzung in ihren Anfangszustand zurück.Dies kann nützlich sein, um die Verbindung durch eine Clientanwendung (z. B. durch einen clientseitigen Verbindungspool) wiederzuverwenden.Wenn diese Anweisung ausgeführt wird, werden alle Benutzerkontextvariablen gelöscht, der Inhalt globaler temporärer Tabellen wird gelöscht und alle Einstellungen auf Sitzungsebene werden auf ihre Anfangswerte zurückgesetzt.

Es ist möglich, ALTER SESSION RESET ohne Transaktion auszuführen.

Die Ausführung von ALTER SESSION RESET führt die folgenden Schritte aus:

  • Der Fehler isc_ses_reset_err (335545206) wird ausgelöst, wenn eine andere Transaktion in der aktuellen Sitzung aktiv ist als die aktuelle Transaktion (diejenige, die ALTER SESSION RESET ausführt) und zweiphasige Transaktionen im vorbereiteten Zustand.

  • Systemvariable RESETTING wird auf TRUE gesetzt.

  • ON DISCONNECT Datenbank-Trigger werden ausgelöst, falls vorhanden und wenn Datenbank-Trigger für die aktuelle Verbindung nicht deaktiviert sind.

  • Die aktuelle Transaktion (diejenige, die ALTER SESSION RESET ausführt), falls vorhanden, wird zurückgesetzt.Eine Warnung wird gemeldet, wenn diese Transaktion Daten vor dem Zurücksetzen der Sitzung geändert hat.

  • Die Sitzungskonfiguration wird auf ihre Anfangswerte zurückgesetzt.Dies beinhaltet, ist aber nicht beschränkt auf:

    • DECFLOAT-Parameter (TRAP und ROUND) und Zurücksetzen auf die Anfangswerte, die mit dem DPB zur Verbindungszeit definiert wurden, oder ansonsten auf den Systemstandard.

    • Sitzungs- und Anweisungs-Timeouts werden auf Null zurückgesetzt.

    • Die aktuelle Rolle wird zum Verbindungszeitpunkt auf den Anfangswert zurückgesetzt, der mit DPB definiert wurde, und - wenn die Rolle geändert wird - wird der Cache der Sicherheitsklassen gelöscht.

    • Die Sitzungszeitzone wird auf den Anfangswert zurückgesetzt, der mit dem DPB zur Verbindungszeit definiert wurde, oder ansonsten auf den Systemstandard.

    • Die Bindungskonfiguration wird auf den Anfangswert zurückgesetzt, der mit dem DPB zur Verbindungszeit definiert wurde, oder ansonsten auf den Datenbank- oder Systemstandard.

    • Im Allgemeinen sollten Konfigurationswerte auf die Werte zurückgesetzt werden, die mit DPB zur Verbindungszeit konfiguriert wurden, oder ansonsten auf den Datenbank- oder Systemstandard.

  • Für den Namespace USER_SESSION definierte Kontextvariablen werden entfernt.

  • Globale temporäre Tabellen, die als ON COMMIT PRESERVE ROWS definiert sind, werden abgeschnitten (ihr Inhalt wird gelöscht).

  • ON CONNECT-Datenbank-Trigger werden ausgelöst, falls vorhanden und wenn Datenbank-Trigger für die aktuelle Verbindung nicht deaktiviert sind.

  • Eine neue Transaktion wird implizit mit denselben Parametern gestartet wie die Transaktion, die zurückgesetzt wurde (sofern eine Transaktion vorhanden war)

  • Die Systemvariable RESETTING wird auf FALSE gesetzt.

Note

  • Die Kontextvariablen CURRENT_USER und CURRENT_CONNECTION werden nicht verändert.

  • Da isql mehrere Transaktionen für eine einzelne Verbindung startet, kann ALTER SESSION RESET in isql nicht ausgeführt werden.

Fehlerbehandlung

Jeder Fehler, der durch ON DISCONNECT-Trigger ausgelöst wird, bricht das Zurücksetzen der Sitzung ab und lässt den Sitzungsstatus unverändert.Solche Fehler werden mit dem primären Fehlercode isc_session_reset_err (335545206) und dem Fehlertext "Cannot reset user session" gemeldet.

Jeder Fehler, der nach ON DISCONNECT-Triggern ausgelöst wird (einschließlich der durch ON CONNECT-Trigger ausgelösten), bricht sowohl das Zurücksetzen der Sitzung als auch die Verbindung selbst ab.Solche Fehler werden mit dem primären Fehlercode isc_ses_reset_failed (335545272) und dem Fehlertext "Reset of user session failed. Connection is shut down." gemeldet.Nachfolgende Operationen auf der Verbindung (außer Trennen) schlagen mit dem Fehler isc_att_shutdown (335544856) fehl.

Debugging

SET DEBUG OPTION

Verwendet für

Setting debug options

Verfügbar in

DSQL, PSQL

Eingeführt in

Firebird 4.0.1

Syntax
SET DEBUG OPTION option-name = value
Table 1. Unterstützte Optionen
Optionsname Datentyp Beschreibung

DSQL_KEEP_BLR

BOOLEAN

Speichert Statement BLR zum Abrufen mit isc_info_sql_exec_path_blr_bytes und isc_info_sql_exec_path_blr_text.
Hinzugefügt in Firebird 4.0.1.

SET DEBUG OPTION konfiguriert Debug-Informationen für die aktuelle Verbindung.

Warning

Debug-Optionen sind eng mit den Engine-Internals verbunden, und von ihrer Verwendung wird abgeraten, wenn Sie nicht genau verstehen, wie diese Internals von Version zu Version geändert werden können.