FirebirdSQL logo
 Cryptage des bases de donnéesAutres articles 

Temps mort

Firebird dispose de deux types de timeout :

  • le timeout d’inactivité de la connexion ;

  • le timeout des instructions SQL.

Délai d’attente pour les instructions SQL

Cette fonctionnalité vous permet de mettre automatiquement fin à l’exécution d’une instruction SQL si elle dépasse la valeur de délai d’attente spécifiée.

Cette fonction peut être utile pour :

  • Administrateurs de bases de données. Ils obtiennent un outil permettant de limiter le temps d’exécution des requêtes lourdes qui consomment beaucoup de ressources ;

  • Développeurs d’applications. Ils peuvent utiliser les délais d’exécution des instructions SQL lors de la rédaction et du débogage de requêtes complexes dont le temps d’exécution est inconnu ;

  • Les testeurs, qui peuvent utiliser les délais d’exécution des instructions SQL pour détecter les requêtes longues et fournir un temps d’exécution limité de la suite de tests.

Cette fonctionnalité fonctionne comme suit.Lorsque l’exécution d’une instruction commence (ou qu’un curseur est ouvert), Firebird démarre une minuterie spéciale.Le fait de récupérer les enregistrements ne remet pas le compteur à zéro.La minuterie s’arrête si l’instruction SQL est terminée ou si le dernier enregistrement est récupéré.

Lorsque le délai d’attente expire :

  • Si l’exécution d’une instruction SQL est active, elle s’arrête au moment spécifié.

  • Si la déclaration SQL n’est pas active à ce moment-là (par exemple, entre deux extractions), elle sera marquée comme annulée, l’extraction suivante sera interrompue et une erreur sera renvoyée.

La valeur du délai d’attente peut être définie :

  • Au niveau de la base de données. La valeur du StatementTimeout peut être définie dans firebird.conf (ou databases.conf) par l’administrateur de la base de données. Le champ d’application est constitué de toutes les déclarations dans toutes les connexions. Le paramètre StatementTimeout définit le délai en secondes, après lequel les déclarations SQL seront annulées. Un zéro signifie que le délai d’attente n’est pas défini. La valeur par défaut est 0.

  • Au niveau de la connexion. Peut être défini en utilisant l’API (en millisecondes) ou avec l’opérateur SQL SET STATEMENT TIMEOUT. La portée de la connexion actuelle.

  • Au niveau de l’opérateur. Peut être défini en utilisant l’API (en millisecondes). La portée de l’instruction SQL actuelle.

La valeur effective du délai d’attente de l’opérateur SQL est calculée chaque fois que l’opérateur SQL est lancé (le curseur est ouvert) comme suit

  • si le délai d’attente n’est pas défini au niveau de l’opérateur, la valeur du délai d’attente au niveau de la connexion sera utilisée ;

  • Si le délai d’attente n’est pas défini au niveau de la connexion, la valeur du délai d’attente de la base de données sera utilisée ;

  • La valeur du délai d’attente ne peut pas être supérieure à la valeur du délai d’attente définie au niveau de la base de données. Ainsi, la valeur du délai d’attente peut être remplacée par le développeur d’applications dans les zones inférieures, mais elle ne peut pas dépasser les limites fixées par le DBA dans la configuration.

Un délai d’attente de zéro ne signifie pas qu’il n’y a pas de délai d’attente, mais simplement que la minuterie d’exécution de l’instruction n’est pas lancée.

Bien que le délai d’attente SQL puisse être défini en millisecondes, la précision absolue n’est pas garantie. Elle peut être moins précise en cas de forte charge. La seule garantie que Firebird peut donner est que le délai d’attente ne s’exécutera pas avant le temps spécifié. Une application cliente peut attendre plus longtemps que la valeur du délai d’attente définie si le moteur Firebird doit annuler de nombreuses actions liées à l’annulation de l’opérateur.

Le délai d’attente de l’opérateur est ignoré pour toutes les requêtes internes utilisées par le moteur Firebird. De plus, le délai d’attente est ignoré pour les déclarations DDL.

docnext count = 19

SET STATEMENT TIMEOUT

Destination

Définir un délai d’attente au niveau de la connexion pour l’exécution des instructions SQL.

Disponible en

DSQL

Syntaxe:
SET STATEMENT TIMEOUT value [HOUR | MINUTE | SECOND | MILLISECOND]
Table 1. Paramètres de l’opérateur SET STATEMENT TIMEOUT
Paramètre Description

value

La valeur du délai d’exécution des instructions SQL dans les unités de temps spécifiées. Si aucune unité de temps n’est spécifiée, la valeur par défaut du délai d’exécution est mesurée en secondes.

Définit la valeur du délai d’exécution des instructions SQL au niveau de la connexion actuelle. Si aucune unité de temps n’est spécifiée, le délai par défaut sera compté en secondes.

Note

Cette instruction SQL fonctionne en dehors du mécanisme de contrôle des transactions et prend effet immédiatement.
Example 1. Définition d’un délai d’attente pour les instructions SQL
SET STATEMENT TIMEOUT 2 MINUTE
Note

L’outil interactif isql prend également en charge la commande :

SET LOCAL_TIMEOUT int

Cette commande vous permet de définir un délai d’attente (en millisecondes) pour l’instruction suivante. Une fois l’instruction SQL exécutée, il est automatiquement remis à zéro.

Délai d’inactivité de la connexion

Cette fonctionnalité permet de fermer automatiquement les connexions des utilisateurs après une période d’inactivité.Il peut être utilisé par les administrateurs de bases de données pour fermer de force les anciennes connexions inactives et libérer les ressources associées.Les applications et les outils de développement peuvent l’utiliser comme substitut au contrôle maison de la durée de vie des connexions.

Il est recommandé (mais pas obligatoire) de définir le délai d’inactivité à une valeur raisonnablement élevée, par exemple quelques heures.Par défaut, cette fonction est désactivée.

Cette fonctionnalité fonctionne comme suit.Lorsqu’un appel de l’utilisateur à l’API quitte le moteur, une minuterie spéciale est lancée et est associée à la connexion actuelle.Dès que l’appel de l’utilisateur entre dans le moteur, la minuterie de ralenti est arrêtée.Si le délai d’inactivité expire, le moteur ferme la connexion comme si une annulation asynchrone avait eu lieu :

  • toutes les déclarations et curseurs actifs sont fermés ;

  • toutes les transactions actives sont annulées ;

  • toutes les connexions réseau ne sont pas fermées pour le moment. Cela permet à l’application cliente d’obtenir le code d’erreur exact pour le prochain appel de l’API. La connexion réseau sera fermée du côté serveur après que l’erreur a été signalée, ou si le côté client se déconnecte lorsque le délai d’attente du réseau expire.

Le délai d’inactivité de la connexion peut être défini :

  • Au niveau de la base de données. La valeur du ConnectionIdleTimeout peut être définie dans firebird.conf (ou databases.conf) par l’administrateur de la base de données. La portée est l’ensemble des connexions de l’utilisateur, à l’exclusion des connexions du système (garbage collector, cache writer, etc.). Le paramètre ConnectionIdleTimeout définit le délai en minutes, après lequel une connexion inactive sera terminée par le moteur. Zéro signifie qu’aucun délai n’est défini. La valeur par défaut est 0.

  • Au niveau de la connexion. Peut être défini en utilisant l’API (en secondes) ou avec l’opérateur SQL SET SESSION IDLE TIMEOUT. Le champ d’application est constitué de tous les opérateurs de la connexion en cours.

La valeur effective du délai d’inactivité est calculée chaque fois qu’un appel API utilisateur quitte le moteur comme suit :

  • si le délai d’attente n’est pas défini au niveau de la connexion, la valeur au niveau de la base de données sera utilisée ;

  • La valeur du délai d’attente ne peut pas être supérieure à la valeur définie au niveau de la base de données. Ainsi, la valeur du délai d’inactivité peut être modifiée par le développeur de l’application pour une connexion donnée, mais elle ne peut pas dépasser la limite fixée par le DBA dans la configuration.

Un délai d’attente nul ne signifie pas qu’il n’y a pas de délai d’attente, mais simplement que le temporisateur de délai d’attente n’est pas lancé.

Bien que le délai d’inactivité puisse être défini en secondes, une précision absolue n’est pas garantie.Il peut être moins précis dans des conditions de charge élevée.La seule garantie que Firebird peut donner est que le timeout ne sera pas déclenché avant le temps spécifié.

SET SESSION IDLE TIMEOUT

Destination

Définir le délai de connexion au niveau de la connexion.

Disponible en

DSQL.

Syntaxe
SET SESSION IDLE TIMEOUT value [HOUR | MINUTE | SECOND]
Table 1. Paramètres de l’opérateur SET SESSION IDLE TIMEOUT.
Paramètre Description

value

La valeur du délai d’inactivité dans l’unité de temps spécifiée. Si aucune unité de temps n’est spécifiée, la valeur du délai par défaut est mesurée en minutes.

Définit la valeur du délai d’inactivité au niveau de la connexion actuelle. Si aucune unité de temps n’est spécifiée, le délai par défaut sera compté en minutes.

Note

Cette instruction SQL fonctionne en dehors du mécanisme de gestion des transactions et prend effet immédiatement.
Example 1. Définition d’un délai d’inactivité de la connexion
SET SESSION IDLE TIMEOUT 8 HOUR

Pool de connexion externe

Chaque connexion externe (créée par l’opérateur EXECUTE STATEMENT …​ ON EXTERNAL) est associée à un pool de connexion à sa création (voir External Connection Pooling pour plus de détails).

Ce groupe d’opérateurs permet de gérer le pool de connexion externe. Dans sa préparation, ils sont décrits comme des opérateurs DDL, mais ont un effet immédiat : c’est-à-dire qu’ils sont exécutés immédiatement et complètement, sans attendre un commit de la transaction.

Les changements sont appliqués à l’instance de pool en mémoire dans le processus Firebird actuel. Par conséquent, un changement dans un processus classique n’affecte pas les autres processus classiques. Les changements ne sont pas permanents, et après le redémarrage de Firebird, les paramètres de pool de firebird.conf seront utilisés.

Le privilège système MODIFY_EXT_CONN_POOL est requis pour exécuter ce groupe d’opérateurs. [fblangref-security-roles-create].

ALTER EXTERNAL CONNECTIONS POOL SET SIZE

Destination

Définit le nombre maximum de connexions inactives.

Syntaxe
ALTER EXTERNAL CONNECTIONS POOL SET SIZE size
Table 1. Paramètres de l’opérateur ALTER EXTERNAL CONNECTIONS POOL SET SIZE
Paramètre Description

size

Taille du pool de connexion externe. Valeurs valides de 0 à 1000.

L’instruction ALTER EXTERNAL CONNECTIONS POOL SET SIZE définit le nombre maximum de connexions inactives dans le pool de connexions externes. Les valeurs valides vont de 0 à 1000.

Une valeur nulle indique que le pool est désactivé. La valeur par défaut est définie dans firebird.conf (paramètre ExtConnPoolSize).

ALTER EXTERNAL CONNECTIONS POOL SET LIFETIME

Destination

Définit la durée de vie des connexions inactives.

Syntaxe
ALTER EXTERNAL CONNECTIONS POOL SET LIFETIME value <time_part>

<time_part> ::= SECOND | MINUTE | HOUR
Table 1. Paramètres de l’opérateur ALTER EXTERNAL CONNECTIONS POOL SET LIFETIME
Paramètre Description

value

Durée de vie des connexions inactives.

L’instruction ALTER EXTERNAL CONNECTIONS POOL SET LIFETIME définit la durée de vie des connexions inactives dans le pool de connexions externes.

Les valeurs valides vont de 1 seconde à 24 heures. La valeur par défaut est définie dans firebird.conf (paramètre ExtConnPoolLifeTime en secondes).

ALTER EXTERNAL CONNECTIONS POOL CLEAR ALL

Destination

Ferme toutes les connexions inactives.

Syntaxe
ALTER EXTERNAL CONNECTIONS POOL CLEAR ALL

L’opérateur ALTER EXTERNAL CONNECTIONS POOL CLEAR ALL ferme toutes les connexions inactives dans le pool de connexions externes. Toutes les connexions actives seront déconnectées du pool (ces connexions seront fermées immédiatement si elles ne sont pas utilisées).

ALTER EXTERNAL CONNECTIONS POOL CLEAR OLDEST

Destination

Ferme les connexions inactives qui ont expiré.

Syntaxe
ALTER EXTERNAL CONNECTIONS POOL CLEAR OLDEST

L’opérateur ALTER EXTERNAL CONNECTIONS POOL CLEAR OLDEST ferme les connexions inactives du pool dont la durée de vie a expiré.

Changer le rôle actuel

SET ROLE

Destination

Changer le rôle actuel.

Disponible en

DSQL.

Syntaxe
SET ROLE rolename
Table 1. Paramètres de l’opérateur SET ROLE.
Paramètre Description

rolename

Le nom du rôle à installer.

Selon la norme SQL-2008, l’instruction SET ROLE permet de définir la variable de contexte CURRENT_ROLE sur l’un des rôles assignés à l’utilisateur CURRENT_USER ou sur le rôle obtenu par authentification de confiance (dans ce cas, l’instruction prend la forme SET TRUSTED ROLE).

Example 1. Changer le rôle actuel
SET ROLE manager;
SELECT current_role FROM rdb$database;
ROLE
=======================
MANAGER

SET TRUSTED ROLE

Destination

Définir un rôle de confiance.

Disponible en

DSQL

Syntaxe
SET TRUSTED ROLE

L’instruction SET TRUSTED ROLE permet l’accès à un rôle de confiance, à condition que le CURRENT_USER soit obtenu par une authentification de confiance et que le rôle soit disponible.

L’idée derrière la commande distincte SET TRUSTED ROLE est que lors de la connexion d’un utilisateur de confiance sans spécifier d’informations supplémentaires sur le rôle, SET TRUSTED ROLE fait du rôle de confiance (s’il y en a un) le rôle courant sans l’activité supplémentaire de définir les paramètres DBP.

Un rôle de confiance n’est pas un type de rôle spécial, il peut être n’importe quel rôle créé avec l’instruction CREATE ROLE ou le rôle système prédéfini RDB$ADMIN.Il devient un rôle de connexion de confiance lorsque le sous-système de mappage des objets de sécurité fait correspondre le résultat de l’authentification renvoyé par le plugin avec le mappage local ou global de la base de données actuelle.Le rôle peut même être un rôle qui n’est pas explicitement accordé à cet utilisateur de confiance.

Note

Le rôle de confiance n’est pas attribué par défaut dans la connexion. Vous pouvez modifier ce comportement en utilisant le plugin d’authentification approprié et les opérateurs {CREATE | ALTER} MAPPING.

Un exemple d’utilisation d’un rôle de confiance est l’attribution du rôle système RDB$ADMIN aux administrateurs Windows lorsque l’authentification Windows de confiance est utilisée.

Gestion du fuseau horaire d’une session

SET TIME ZONE

Destination

Changer le fuseau horaire d’une session.

Syntaxe
SET TIME ZONE { <time-zone-string> | LOCAL }

<time-zone-string> ::=
    '<time-zone>'

<time-zone> ::=
    <time-zone-region>
  | [+/-] <hour-displacement> [: <minute-displacement>]

Change immédiatement le fuseau horaire de la session (la connexion actuelle).

Si vous spécifiez LOCAL, vous reviendrez au fuseau horaire initial de la session (soit celui par défaut, soit celui spécifié dans la propriété de connexion isc_dpb_session_time_zone).

Vous pouvez obtenir le fuseau horaire actuel de la session en utilisant la fonction RDB$GET_CONTEXT avec les arguments 'SYSTEM' pour l’espace de noms et 'SESSION_TIMEZONE' comme nom de variable.

Note

L’exécution de ALTER SESSION RESET a le même effet sur le fuseau horaire de la session que SET TIME ZONE LOCAL, mais réinitialise également d’autres propriétés de la session.
Example 1. Changer le fuseau horaire d’une session
set time zone '-02:00';
select rdb$get_context('SYSTEM', 'SESSION_TIMEZONE') from rdb$database;
-- returns -02:00

set time zone 'America/Sao_Paulo';
select rdb$get_context('SYSTEM', 'SESSION_TIMEZONE') from rdb$database;
-- returns America/Sao_Paulo

set time zone local;

Réinitialisation de l’état de la session

ALTER SESSION RESET

Destination

Réinitialisation de l’environnement de la session.

Disponible en

DSQL

Syntaxe
ALTER SESSION RESET

Réinitialise l’environnement de session (connexions) à l’état initial.Cette fonctionnalité est utile si la session est réutilisée au lieu de se déconnecter/connecter.

Cette déclaration fait ce qui suit :

  • une erreur (isc_ses_reset_err) est générée s’il existe une transaction ouverte dans la connexion courante autre que la transaction courante et les transactions 2PC préparées qui sont autorisées et ignorées par cette vérification ;

  • La variable système RESETTING est définie à TRUE ;

  • Les déclencheurs de base de données pour l’événement ON DISCONNECT sont lancés s’ils sont présents et autorisés pour la connexion actuelle ;

  • La transaction de l’utilisateur en cours est annulée (ROLLBACK) si elle est présente. Un avertissement sera émis si des modifications ont été apportées à la transaction actuellement active ;

  • Remet les paramètres DECFLOAT (BIND, TRAP et ROUND) aux valeurs par défaut ;

  • réinitialise les délais d’attente de la session et de l’opérateur à 0 ;

  • supprime toutes les variables de contexte de l’espace de nom USER_SESSION ;

  • Réinitialise le rôle à la valeur transmise au DPB (spécifiée lors de la connexion) et efface le cache des préférences (si le rôle a été modifié avec l’instruction SET ROLE) ;

  • Efface le contenu de toutes les tables globales de niveau connexion utilisées (GLOBAL TEMPORARY TABLE …​ ON COMMIT PRESERVE ROWS) ;

  • déclenche des déclencheurs de base de données sur l’événement ON CONNECT s’ils sont présents et autorisés pour la connexion actuelle ;

  • lance une nouvelle transaction avec les mêmes propriétés que la transaction annulée (si la transaction était présente avant la réinitialisation) ;

  • La variable système RESETTING a la valeur FALSE.

Traitement des erreurs

Une erreur survenant dans le déclencheur ON DISCONNECT interrompt la réinitialisation de la session et laisse l’état de la session inchangé.De telles erreurs sont signalées avec le code d’erreur principal isc_session_reset_err et le texte d’erreur“Canot reset user session”.

Les erreurs survenant après l’exécution des déclencheurs ON DISCONNECT interrompent l’instruction de réinitialisation de la session et la connexion elle-même.Ces erreurs étaient signalées avec le code d’erreur principal isc_session_reset_failed et le texte d’erreur“Reset of user session failed. Connection is shut down”.Les opérations de connexion ultérieures (sauf la déconnexion) se termineront par l’erreur isc_att_shutdown.

Gestion de l’optimiseur

SET OPTIMIZE

Affectation

Changer la stratégie de l’optimiseur.

Disponible en

DSQL

Syntaxe
SET OPTIMIZE <optimize-mode>

<optimize-mode> ::=
    FOR {FIRST | ALL} ROWS
  | TO DEFAULT

L’instruction SET OPTIMIZE vous permet de changer la stratégie de l’optimiseur au niveau de la session actuelle.

Il existe deux stratégies d’optimisation des requêtes :

  • FIRST ROWS - l’optimiseur construit le plan de requête pour récupérer seulement les premières lignes de la requête aussi vite que possible ;

  • ALL ROWS - l’optimiseur construit le plan de requête pour récupérer toutes les chaînes de la requête aussi rapidement que possible.

Par défaut, la stratégie d’optimisation spécifiée dans le paramètre OptimizeForFirstRows du fichier de configuration est utiliséefirebird.conf ou database.conf. OptimiseForFirstRows = false correspond à la stratégie ALL ROWS,OptimiseForFirstRows = true correspond à la stratégie First ROWS.

La stratégie d’optimisation peut être modifiée au niveau de l’instruction SQL à l’aide de la phrase OPTIMIZE FOR.

Débogage

SET DEBUG OPTION

Configure les options de débogage.

Syntaxe
SET DEBUG OPTION option-name = value
Table 1. Options prises en charge
Nom de l’option Type de valeur Description

DSQL_KEEP_BLR

BOOLEAN

Sauvegarde le BLR de l’instruction qui sera récupéré par les fonctionsisc_info_sql_sql_exec_path_blr_bytes et isc_info_sql_exec_path_blr_text.

L’instruction SET DEBUG OPTION configure les informations de débogage pour la connexion courante.

Warning

Les options de débogage sont étroitement liées aux éléments internes du moteur, et leur utilisation n’est pas recommandée si vous ne comprenez pas comment ces éléments internes peuvent changer d’une version à l’autre.