Version imprimable
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.
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:
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
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...
Tout à fait, c'est la méthode propre pour faire les choses : le gestionnaire de ressources.Citation:
Envoyé par CyBeRoN
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) :
Ce qui donnera à l'usage dans une session SCOTT :Code:
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';
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.Code:
2
3
4
5
Le souci, c'est que cette méthode n'est absolument pas viable pour les SELECT qui donnent un gros volume de données.Citation:
Envoyé par ojo77
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.
Merci pour ces informations. Je crois que je vais plutôt abandonner l'idée pour l'instant... :(