Yes I had read this before.
I still think it is a lame way to handle it since it is really not very
useful to what I suspect is the majority of the people.
-----Original Message-----
From: Paul Murgatroyd
[mailto:oracledba-ezmlmshield-x39795938.[Email address protected]
Sent: Friday, March 31, 2006 9:31 AM
To: LazyDBA Discussion
Subject: Re[2]: Kill idle session automatically
Hi,
If you read up on session profiles in the Oracle Docs you will see that it
is not supposed to kill the sessions.
What happens is this:
1) The user leaves their session idle
2) Oracle sets the status to "sniped" (i.e. session is inactive, waiting on
client)
3) The NEXT attempted operation by the user will result in an ORA- error
telling them the session has been sniped due to exceeding whatever limit has
been exceeded (cpu, idle time etc)
4) Once the message is displayed, the session is terminated and the user
must reconnect (for an idle timeout at least - CPU/call types don't
terminate the session as far as I know)
The problem is that if the user has disconnected before 3) happens, then the
session will stay in "sniped" status forever and must be cleaned up by a DBA
killing off the processes.
We have this problem quite often with one of our clients. Their firewall is
notorious for dropping network connections, so we get hundreds of sessions
being left in "sniped" status (we have a 15 hour idle timeout). We can see
who the sessions belong to, so we can track it easy enough, but we have to
kill the sniped sessions to recover system resources.
Cheers,
Paul
*********** ORIGINAL MESSAGE ***********
On 31/03/2006 at 2:54 PM Chamberlain John wrote:
Fair point! However, my concern is that it MUST be possible to track what
Oracle is doing. If you are getting 10000 sniped sessions a day, don't you
think that there is a problem that should be addressed by other means? Maybe
you are being hacked! For one or two, its not an issue, but you still need
to know its happening. It may be just one (idiot) user, who you can go and
kick periodically!! You can track even a generic account back to its source
by IP or PC name, idiot or otherwise.
-----Original Message-----
From: Dustin Hayden
[mailto:oracledba-ezmlmshield-x25674653.[Email address protected]
Sent: 31 March 2006 14:38
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
Then why time it out in the first place? We are talking inactive sessions
here not running sessions. If you don't want them killed off why set up a
profile to do so in the first place?
Just seems like oracle goes out if its way to complicate things.
First you set up a profile it is going to ignore until you set a system
parameter. Why? If you don't want a profile acted on then don't create it in
the first place.
Then you create a specific profile so you can get rid of inactive sessions
but it still leaves it out there. If you don't want to kill inactive session
willy-nilly why set the profile to do it in the first place?
I can't think of any other software that keeps the session info around if
you set up a timeout on the user.
Why bother even having the option if I still have to run a script to clean
it up. I could just write the cron script to really clean up the session in
the first place.
We have a generic userid that only has read permissions that applications
use to gather reporting data. Developers constantly fail to close their
connections so setting an idle time out seemed the way to go.
-----Original Message-----
From: Chamberlain John
[mailto:oracledba-ezmlmshield-x16066754.[Email address protected]
Sent: Friday, March 31, 2006 8:22 AM
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
Well, I would prefer Oracle to NOT start killing sessions willy-nilly. It is
important to keep a track of these sessions so you know what is going on in
your database.. are you getting one of these every day or ten thousand? It
is not hard to set up a script to kill these off while producing a log....
you would need something like:
Insert into session_log (select * from v$session where status='SNIPED');
Spool /tmp/killem.sql
Select 'alter system kill session '''||sid||','||serial#||''';' from
V$session where status='SNIPED';
Spool off
Commit;
@/tmp/killem.sql
-----Original Message-----
From: Dustin Hayden
[mailto:oracledba-ezmlmshield-x78584123.[Email address protected]
Sent: 31 March 2006 13:54
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
It does not disconnect the session. It changes the status to from INACTIVE
to SNIPED.
I really hate the fact that it does not remove the session. Pretty lame
design.
-----Original Message-----
From: Sreedhar_Bhaskararaju
[mailto:oracledba-ezmlmshield-x99201978.[Email address protected]
Sent: Friday, March 31, 2006 7:26 AM
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
Hi all,
I changed RESOURCE_LIMIT=TRUE
CREATE PROFILE limit_idle_time LIMIT IDLE_TIME 1
/
ALTER USER tdb PROFILE limit_idle_time
/
But the session which is opened by tdb user is not killing up after 1 minute
idle time.
Is there any settings?
Sree
________________________________
From: "Rüdiger J. Schulz" [mailto:[Email address protected]
Sent: Fri 31/03/2006 16:35
To: Sreedhar_Bhaskararaju
Subject: Re: Kill idle session automatically
you need to set set idle-time-parameter in a new profile.
when you've done so you have to
- assign this profile to an user
- set the init-ora-parameter RESOURCE_LIMIT = TRUE
after that all users - which you have assigned to this profile - will
sniped after the time you've set in the profile.
hth
Rüdiger J. Schulz
www.sosys-berlin.de
Sreedhar_Bhaskararaju schrieb:
>Hi All,
>
>How to kill idle/inactive session automatically, based on its idle time?
Which parameter should change?
>
>Regs,
>Sree
>
>
>
>
>
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
-----------------------------------------
Information in this email may be privileged, confidential and is
intended exclusively for the addressee. The views expressed may not
be official policy, but the personal views of the originator. If
you have received it in error, please notify the sender by return
e-mail and delete it from your system. You should not reproduce,
distribute, store, retransmit, use or disclose its contents to
anyone.
Please note we reserve the right to monitor all e-mail
communication through our internal and external networks.
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html
Oracle LazyDBA home page