Well, I don't use it.. I prefer to get the problem fixed at source rather
than applying and re-applying a band-aid to the symptom. The problem you
have is "Developers constantly fail to close their connections" (as you
said). Fix this and the problem will disappear. I have been round this loop
with developers. Eventually they will do what you ask as there code will
repeatedly fail in testing otherwise... (set processes on the test/dev
database to a much lower number than live to make your point).
-----Original Message-----
From: Dustin Hayden
[mailto:oracledba-ezmlmshield-x55236941.[Email address protected]
Sent: 31 March 2006 15:23
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
Again if that is your concern why set it up in the first place?
We are talking idle sessions here. NOT ACTIVE.
If someone is hacking you it would be an active session. Hackers don't tend
to be inclined to leave open sessions around that could be traced back.
Not to mention your network should be monitoring for intrusions.
If you have thousands of sessions coming at you over your network then you
have a serious network breech.
If hacker session has been idle for an hour before being timed out you are a
little late for the party anyway.
Hell many OS systems have a preset idle time out.
At the very least Oracle should give you the option to either leave the
session info or clean it up.
I would be willing to wager that far more people would rather the session be
cleaned up to make viewing what is actually running on a busy system easier
to monitor than go through dozens to thousands of sessions that have been
idle for god knows how long.
-----Original Message-----
From: Chamberlain John
[mailto:oracledba-ezmlmshield-x30609721.[Email address protected]
Sent: Friday, March 31, 2006 8:54 AM
To: LazyDBA Discussion
Subject: RE: Kill idle session automatically
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