Cryptage des bases de donnéesAutres articles

`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é.

docnext count = 17

`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 fonctions`isc_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.