Problème de gestion de ressource

Version imprimable

15/01/2006, 09h50
Isabella

Problème de gestion de ressource

Bonjour

j'ai créé un profil PROF1, parmi les paramètres de ce profil,

CONNECT_time 5
ce qui veut dire (à ma connaissance ) pas plus de 5 minutes de connexion à l'utilisateur

j'ai affecté le profil PROF1 à un utilisateur U1 de ma base, puis j'ai lancé une session
de l'utilisateur U1, pour voir l'effet du paramètre CONNECT_TIME 5
finalement rien a signalé ! , l'utilisateur U1 est resté connecté bien au dela de 5 minutes

bien sur j'ai d'abord mis le paramètre RESOURCE_LIMIT à TRUE
via la commande ALTER SYSTEM

par contre , j'ai fais l'essai avec le paramètre IDLE_TIME, les choses on l'air de bien fonctionner, je constaté que le système déconnecte bien automtiquement l'utilisateur après un certain temps d'inactivité

quelqu'un pourrait il m'orienter

merci à tous

Le testcase suivant fonctionne dans mon cas avec une legere inapproximation concenant la detection de la limite par le noyau (en 9.2.0.1 en tout cas). Il faut effectivement veiller a initializer une nouvelle session:

Code:

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
 
CONNECT system/manager
DROP USER pl
/
DROP PROFILE PROF
/
CREATE PROFILE PROF
LIMIT CONNECT_TIME 1
/
CREATE USER PL IDENTIFIED BY PL
/
ALTER USER PL
PROFILE PROF
/
GRANT CONNECT TO PL
/
ALTER SYSTEM SET RESOURCE_LIMIT=TRUE
/
CONNECT sys/manager AS SYSDBA
GRANT EXECUTE ON dbms_lock   TO pl
/
GRANT ALL     ON v_$parameter TO pl
/
CONNECT PL/PL
SELECT TO_CHAR(sysdate,'DD MON YYYY HH24:MI:SS')
FROM   sys.dual
/
SELECT value 
FROM   V$PARAMETER 
WHERE  name = 'resource_limit'
/
execute dbms_lock.sleep(120);
SELECT TO_CHAR(sysdate,'DD MON YYYY HH24:MI:SS')
FROM   sys.dual
/
/
/

Code:

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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 
Connected to:
Personal Oracle9i Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
 
Connected.
 
User dropped.
 
 
Profile dropped.
 
 
Profile created.
 
 
User created.
 
 
User altered.
 
 
Grant succeeded.
 
 
System altered.
 
Connected.
 
Grant succeeded.
 
 
Grant succeeded.
 
Connected.
 
TO_CHAR(SYSDATE,'DDM
--------------------
15 JAN 2006 09:49:34
 
 
VALUE
--------------------------------------------------------------------------------
 
TRUE
 
 
PL/SQL procedure successfully completed.
 
 
TO_CHAR(SYSDATE,'DDM
--------------------
15 JAN 2006 09:51:37
 
SQL> /
 
TO_CHAR(SYSDATE,'DDM
--------------------
15 JAN 2006 09:51:44
 
SQL> /
 
TO_CHAR(SYSDATE,'DDM
--------------------
15 JAN 2006 09:51:45
 
SQL>
SQL> /
SELECT TO_CHAR(sysdate,'DD MON YYYY HH24:MI:SS')
*
ERROR at line 1:
ORA-02399: exceeded maximum connect time, you are being logged off

16/01/2006, 09h00
Isabella

merci PLABREVO
je vais tester cela à mon niveau

en tous cas pour moi aussi, j'ai continué à faire des tests et il s'avère que la limitation du CONNECT_TIME se manifeste bien quand je fais des transactions, par contre si je me limite à une succession de SELECT comme dans ton exemple , il n'y a jamais rien à signaler tout en dépassant largement le délai de connexion.
16/01/2006, 13h30
Isabella

re .. PLABREVO

je viens d'essayer ton script, ça marche mais quand tu dis "légère inaproximation", elle n'est pas vraiment légère pour moi !

et puis aussi j'aimerais savoir pourquoi tu utilises la fonction dbms_lock.sleep(120)
puisque de toutes façons je suis sur une session qui occupe des ressources quelqu'en soit l'activité, je veux dire le temps de connexion est comptabilisé y compris pour les minutes où je ne fais rien durant la session

Merci
16/01/2006, 16h33
plabrevo

Il semble que le noyau, pour des raisons de performance, n'effectue pas un constant monitoring des sessions concernant leurs limites d'utilisation.
Au contraire, le noyau effectuera leurs verification par interval de quelques minutes. Il n'est dont pas anormale que cette limite doit exceeder de quelques minutes avant que le noyau ne procede a des actions de deconnexions.

Extrait du concept manual (8i):
Oracle does not constantly monitor the elapsed idle time or elapsed connection time. Doing so would reduce system performance. Instead, it checks every few minutes. Therefore, a session can exceed this limit slightly (for example, by five minutes) before Oracle enforces the limit and aborts the session.

PS: J'avais utilise dbms_lock.sleep pour simuler une attente de 2 minutes.
18/01/2006, 09h20
Isabella

Merci Plabervo.