FirebirdSQL logo
 SQL-SicherheitZusatzinformationen 
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.

docnext count = 14

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.