Discussion :

[CyBeRoN]

Bonjour à tous.

Un utilisateur m'a fait une reqûete via ODBC (Excel) qui rapatriait plus de 5 millions de records...
J'aimerais instaurer un Query Timeout de x minutes au niveau de la database afin d'éviter cette mésaventure.
Malgré mes recherches, impossible de trouver comment réaliser cela...
Avez-vous une petite idée ?

Merci d'avance.

[ojo77]

Vous pouvez, par exemple, créer une procédure ordonnancée toutes le n minutes qui tue toutes les requêtes dont la durée d'activité est supérieure à x minutes (avec de préférence x > n ).

Pour cela, la colonne last_call_et de la vue v$session vous donne le nombre de secondes depuis lequel la session est dans l'état actuel. L'état pouvant être ACTIVE ou INACTIVE.

Attention tout de même à ne pas tuer les background processes, la colonne type vous aidera à les trier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
SQL> select SID, SERIAL#, STATUS, LAST_CALL_ET, TYPE
  2  from v$session
  3  /
 
       SID    SERIAL# STATUS   LAST_CALL_ET TYPE
---------- ---------- -------- ------------ ----------
         1          1 ACTIVE        5283172 BACKGROUND
         2          1 ACTIVE        5283172 BACKGROUND
         3          1 ACTIVE        5283172 BACKGROUND
         4          1 ACTIVE        5283171 BACKGROUND
         5          1 ACTIVE        5283161 BACKGROUND
         7          1 INACTIVE            6 USER
        60          1 ACTIVE        5283172 BACKGROUND
        61          1 ACTIVE        5283172 BACKGROUND
        62          1 ACTIVE        5283172 BACKGROUND
        63          3 INACTIVE      5283147 USER
        66          1 ACTIVE        5283152 BACKGROUND
        68         23 ACTIVE        5283140 BACKGROUND
       119          1 ACTIVE        5283174 BACKGROUND
       120          1 ACTIVE        5283172 BACKGROUND
       121          1 ACTIVE        5283172 BACKGROUND
       122          1 ACTIVE        5283172 BACKGROUND
       123          3 ACTIVE        5283168 BACKGROUND
       124          1 ACTIVE        5283152 BACKGROUND
       131      15365 ACTIVE            229 BACKGROUND
       179          1 ACTIVE        5283174 BACKGROUND
       180          1 ACTIVE        5283172 BACKGROUND
       181          1 ACTIVE        5283172 BACKGROUND
       184          3 ACTIVE        5283140 BACKGROUND
       237          1 ACTIVE        5283174 BACKGROUND
       238          1 ACTIVE        5283172 BACKGROUND
       239          1 ACTIVE        5283172 BACKGROUND
       243      28305 ACTIVE              0 USER
       244      13323 ACTIVE         756051 BACKGROUND
       248      14593 ACTIVE         148493 BACKGROUND
       296          1 ACTIVE        5283172 BACKGROUND
       297          1 ACTIVE        5283172 BACKGROUND
       299          1 ACTIVE        5283172 BACKGROUND
       300          1 ACTIVE        5283171 BACKGROUND
       302          1 ACTIVE        5283162 BACKGROUND
       304         11 ACTIVE        5283150 BACKGROUND
       355          1 ACTIVE        5283172 BACKGROUND
       356          1 ACTIVE        5283172 BACKGROUND
       358          1 ACTIVE        5283172 BACKGROUND
       359          5 ACTIVE        5282850 BACKGROUND
       360          1 ACTIVE        5283161 BACKGROUND
       362          1 INACTIVE          134 USER
       414          1 ACTIVE        5283172 BACKGROUND
       415          1 ACTIVE        5283172 BACKGROUND
       416          1 ACTIVE        5283172 BACKGROUND
       417          1 ACTIVE        5283171 BACKGROUND
       418          1 ACTIVE        5283161 BACKGROUND
       421          1 INACTIVE          135 USER
 
47 rows selected.

[CyBeRoN]

Merci pour ta réponse mais n'y a-t-il pas moyen de faire ça via un paramètre ?
Je ne suis pas trop spécialiste Oracle et cette solution me parait pas facile à mettre en oeuvre.
Mes recherches m'ont vaguement mené à un paramètre MAX_ESTIMATED_EXEC_TIME mais pas moyen de savoir où il se trouve...

[Pomalaix]

Mes recherches m'ont vaguement mené à un paramètre MAX_ESTIMATED_EXEC_TIME mais pas moyen de savoir où il se trouve...

Tout à fait, c'est la méthode propre pour faire les choses : le gestionnaire de ressources.
Ca exige d'être en édition Entreprise.
Et malheureusement ça n'est pas un simple paramètre à activer, c'est toute une mécanique.

Paramétrage du gestionnaire de ressources (c'est le minimum syndical) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
-- création du groupe de consommateurs dont SCOTT fera partie
BEGIN
	dbms_resource_manager.clear_pending_area();
	dbms_resource_manager.create_pending_area();
	dbms_resource_manager.create_consumer_group(consumer_group => 'G1', comment => '', mgmt_mth => 'ROUND-ROBIN');
	dbms_resource_manager.submit_pending_area();

	dbms_resource_manager_privs.grant_switch_consumer_group('SCOTT', 'G1', false);

END;
/

-- Association de SCOTT à ce groupe
BEGIN
	dbms_resource_manager.clear_pending_area();
	dbms_resource_manager.create_pending_area();
	dbms_resource_manager.set_consumer_group_mapping(
		dbms_resource_manager.oracle_user,
		'SCOTT',
		'G1');
	dbms_resource_manager.submit_pending_area();
END;
/

-- création d'un plan de ressources PLANDEMO
BEGIN
	dbms_resource_manager.clear_pending_area();
	dbms_resource_manager.create_pending_area();
	dbms_resource_manager.create_plan( 'PLANDEMO', '');
	dbms_resource_manager.create_plan_directive(
		plan => 'PLANDEMO',
		group_or_subplan => 'G1',
		comment => '',
		max_est_exec_time => 30);
	
	dbms_resource_manager.create_plan_directive(
		plan => 'PLANDEMO',
		group_or_subplan => 'OTHER_GROUPS',
		comment => '');
	dbms_resource_manager.submit_pending_area();
END;
/


-- activation du plan ( --> remplacer le SID par le nom de la base)
exec dbms_resource_manager.switch_plan( plan_name => 'PLANDEMO', sid => 'DEMO' );

-- ouvrir par ailleurs une session SCOTT, puis vérifs sous SYSTEM
show parameter resource_manager plan
select username, resource_consumer_group from v$session where username='SCOTT';

Ce qui donnera à l'usage dans une session SCOTT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SCOTT@DEMO>select count(*) from dba_objects, dba_objects;
select count(*) from dba_objects, dba_objects
                     *
ERREUR à la ligne 1 :
ORA-07455: temps d'exécution prévu (209017 sec.) hors limites (30 sec.)

Le SELECT n'a même pas démarré car sa durée estimée est supérieure au seuil de 30 secondes que j'ai défini.

[Pomalaix]

...
Pour cela, la colonne last_call_et de la vue v$session vous donne le nombre de secondes depuis lequel la session est dans l'état actuel. L'état pouvant être ACTIVE ou INACTIVE

Le souci, c'est que cette méthode n'est absolument pas viable pour les SELECT qui donnent un gros volume de données.

Voir ceci : http://www.developpez.net/forums/d96...s/#post5397675

Je viens encore de faire un test en échantillonnant toutes les 10 millisecondes lors d'un long SELECT : dans plus de 95% des cas, le statut ramené est INACTIVE, et LAST_CALL_ET est 0.

[CyBeRoN]

Merci pour ces informations. Je crois que je vais plutôt abandonner l'idée pour l'instant...