chnologies www.i2.com
"Trassens,
Christian" To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
Subject:
original-
> De: Tim Onions [SMTP:[EMAIL PROTECTED]]
> Enviado el: martes 6 de marzo de 2001 12:00
> Para: Multiple recipients of list ORACLE-L
> Asunto: RE: Old INACTIVE and KILLED sessions
>
> Indeed I'd forgotten about
To: Multiple recipients of list ORACLE-L
Subject:RE: Old INACTIVE and KILLED sessions
Beware that SNIPED sessions could last forever when you limit the
IDLE_TIME
whether the users couldn't connect through the same connection. F.e.
when
you use sq
L PROTECTED]]
> Enviado el: martes 6 de marzo de 2001 12:00
> Para: Multiple recipients of list ORACLE-L
> Asunto: RE: Old INACTIVE and KILLED sessions
>
> Indeed I'd forgotten about them! However, in my experience this will only
> mark the session as being SNIPED - th
Indeed I'd forgotten about them! However, in my experience this will only
mark the session as being SNIPED - the disconnect will only happen when the
user tries to do somthing after the SNIP has occurred. This can be a pain if
the session is idle due to network failure, application GPF etc. Howeve
You can also use profiles to do this. With profiles you can not only limit
the amount of time connected, but also the ammount of resources the user can
take.
Before you start playing with these, make sure that you set the init
parameter:
RESOURCE_LIMIT = TRUE
Then to create a profile:
create pr
Henry,
I have found that on certain versions of Oracle on NT (specifically 8.1.6)
that expiry time does not work. So if you set this parameter in SQLNET.ORA
and you do not see dead connections being removed then you're probably
experiencing the same bug (acknowledge by Oracle support but they see
Henry,
set the following parameter in the sqlnet.ora on the server and not on the
client.
the unit is minutes. 10 mins shld be enuf. test with ur environment. if set
less then maybe it may hv an impact on SQL*Net performance.
SQLNET.EXPIRE_TIME= 10
-Mandar
> -Original Message-
> Fr
