Re: Killing "Killed" Users

If it's a pre-Oracle 8i, setting the init parameter cleanup_rollback_entries to a decently high number helps a lot in the cleanup.

The pre-Oracle 8i, pmon wakes up, winds down killed sessions' locks and latches, cleans up to 5 (or some other low number of) blocks of rollback for each session needing it, then goes back to sleep.

Increasing the cleanup_rollback_entries parameter increases the number of rollback blocks pmon processes per session.

In Oracle 8i, pmon does the same thing a few times. If there's still a lot of rollback, it increases the amount it processes each time it wakes up. It also does the rollback in parallel

• Original Message ----- From: John Dailey <John.Dailey_at_concept-solutions.com> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Sent: Monday, November 13, 2000 11:02 AM Subject: 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-----
> Sent: Monday, November 13, 2000 11:26 AM
> To: Multiple recipients of list ORACLE-L
>
>
>
> 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
> also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: John Dailey
> INET: John.Dailey_at_concept-solutions.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
Received on Wed Dec 13 2000 - 15:10:15 CST