Session marked for kill

From: Alon Ben-Zvi <Alon.Ben-Zvi_at_demantra.com>
Date: Mon, 22 Oct 2001 22:21:39 -0700
Message-ID: <F001.003B1DB9.20011022221517@fatcity.com>

What is the name of the parameter?

Alon

-----Original Message-----

Sent: Friday, October 12, 2001 10:40 PM
To: Multiple recipients of list ORACLE-L

That's not what this parameter controls. It actually is designed to automatically clean up sessions that have lost their client connection. If this parameter is set to ten minutes then SQL*Net/Net8 automatically "pings" all active connections every ten minutes to see if the remote connection responds. If it doesn't then the server process is cleaned up and dropped.

What is a really useful side benefit of this behavior is tricking firewalls so your inactive connections don't get cut. Since the "ping" generates network traffic the firewall thinks that the connection is still active.

Hope this helps.

--Michael

-----Original Message-----

Sent: Friday, October 12, 2001 2:33 PM
To: Multiple recipients of list ORACLE-L

Michael,

I am testing this parameter now. I set it in the SQLNET.ORA file on the server, made a sqlplus connection, but it is not being terminated after the time limit has expired.

Do I need to re-start the listener and try my little test again?

Tom Mercadante
Oracle Certified Professional

-----Original Message-----

Sent: Friday, October 12, 2001 1:35 PM
To: Multiple recipients of list ORACLE-L

Wow, we use it in 8.1.7 with no problems at all. As a matter of fact the entire reason we starting using it was to prevent the firewall folks from killing "idle" connections. They have their timeout set to 50 minutes and we have ours set to ten minutes so the firewall perceives "activity" every ten minutes and leaves them alone. We've also been running this on 8.0.6 and 8.0.4 as well as with Oracle Applications 10.7 SC running server partition 8.0.3/7.3.4 for over two years with no problems. Could you be more specific about the problems you were seeing?

Thanks.

--Michael

-----Original Message-----

Sent: Friday, October 12, 2001 12:05 PM
To: Multiple recipients of list ORACLE-L

We tried using SQLNET.EXPIRE_TIME, but in the end disabled it at OTS recommendation due to it causing other problems. Let's just say that that particular parameter is not yet ready for prime time.

Dick Goulet

____________________Reply Separator____________________
Author: "Jenkins; Michael" <Michael.Jenkins_at_Nextel.com>
Date:       10/12/2001 7:25 AM

Wouldn't it just be easier and much more thorough to use the SQLNET.EXPIRE_TIME setting to "automagically" clean up dead connections?

-----Original Message-----

Sent: Friday, October 12, 2001 10:45 AM
To: Multiple recipients of list ORACLE-L

In my experiences the reason you get the 'session marked for kill' is mainly due
to the background UNIX process having lost contact with the client. In our organization things are still pretty much client/server (robots don't care much
about application servers and the like). Therefore I also have client workstations where people create their own queries via SQL*Plus, VB, etc....

Some of those queries do in fact run away and/or the end user gets tired of waiting (anything more than 30 seconds) and reboots the PC or uses the task manager (if their that smart) to abort the local process. Now you've got a dedicated server process on the UNIX side who has lost the ability to communicate with the workstation and session that spawned it. Hence what should
have been a simple task gets complicated. So, I use the alter database kill session command and if that's the answer I get then it's time to go hunting a
dead UNIX process and an end user.

Dick Goulet

____________________Reply Separator____________________
Author: "Arn Klammer" <Arn.Klammer_at_austrac.gov.au>
Date:       10/11/2001 4:50 PM

Sometimes we get a runaway Oracle process on our development machine. In those
circumstances, I usually issue an alter system kill session command. Sometimes
I get the above message after the kill times out. As I understand it, the process was doing something that couldn't be interrupted, and so when it completes its current command, it will then be killed. Is this correct?

In these instances, the corresponding Unix process is still active, still chewing up a lot of CPU, and to alleviate the impact as soon as possible, I kill
the Unix process as well.

Is this a bad thing? Is there a better way I can handle these runaway processes?

Thanx

-a

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.

This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Arn Klammer
INET: Arn.Klammer_at_austrac.gov.au

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author:
INET: dgoulet_at_vicr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message