RE: Killing "Killed" Users

That's interesting Jared... I had always heard terrible stories about what could happen to you if you killed the system process first (plague, locusts, hung sessions, etc.) Has anyone else had similar experiences to Jared's? Perhaps the stuff I have heard is all "fluff". I'm certainly inclined to believe Jared.

My question is this: When Oracle kills the session, what is it killing *exactly*?

John Dailey
Consultant
Concept Solutions, LLC

Concept Solutions, LLC
*Your Business Intelligence Partner*
www.concept-solutions.com

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Jared Still Sent: Monday, November 13, 2000 11:26 AM To: Multiple recipients of list ORACLE-L Subject: Re:Killing "Killed" Users

I've found that the best method for killing session is to kill the system process *first*, then kill the Oracle session.

PMON seems to do a better job of cleaning up sessions that way. Dunno why, but several years of anecdotal evidence and being required to bounce the DB when I didn't kill the process first have convinced me.

Jared

On Mon, 13 Nov 2000 dgoulet_at_vicr.com wrote:

> Lee,
>
> Killing a killed user has been a problem, at least around here, for
quite
> some time & has generated several TAR's. My problem is the end user who
> launches the update from HELL and then power cycles their PC. Oracle does
a
> fine job of rolling back the transaction, but since it no longer can
communicate
> with the originating session it hang almost indefinitely. Now this is not
in
> and of itself bad, except for good old Oracle's Read Consistent View
mechanism.
> Since the transaction was started as a particular SCN on a particular
table(s)
> then our good old buddy hangs onto all rollback data on that table(s)
until you
> finally run out of rollback space. At this point you've only one resort,
bounce
> the DB which many times requires the use of "shutdown abort". Now I
understand
> Oracle's take on the matter. PMON and SMON are after all background tasks
& the
> first job of the DB is to process data for active users, but I think in
this
> case a second look at what is happening is required. Basically I think
they
> need to code something into the database that basically says, "I give up,
you're
> out of here".
>
> BTW: Dead connect detect was suppose to do that. Too bad it had terminal
> problems of it's own.
>
> Dick Goulet
> --
> 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
> 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).
>

Jared Still
Certified Oracle DBA and Part Time Perl Evangelist ;-) Regence BlueCross BlueShield of Oregon
jkstill_at_bcbso.com - Work - preferred address jkstill_at_teleport.com - private

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jared Still
  INET: jkstill_at_bcbso.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
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