Re: Killed session

  • From: Rajesh.Rao@xxxxxxxxxxxx
  • To: jkstill@xxxxxxxxx
  • Date: Wed, 12 Nov 2008 21:40:23 -0500

Its one of the lessons I learnt from working with some earlier versions of 
Oracle and Solaris, but I use to this day. It might not be relevant 
anymore, but no foul.

Before killing any session, I always note the values for SID, SERIAL#  and 
SPID. 
Then, kill -9 at the OS level, followed by an alter session kill 
immediate.
Do it the other way around, and sometimes it gets harder to find the SPID.





"Jared Still" <jkstill@xxxxxxxxx> 
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
11/12/2008 07:53 PM
Please respond to
jkstill@xxxxxxxxx


To
Mayen.Shah@xxxxxxxxxx
cc
oracle-l@xxxxxxxxxxxxx
Subject
Re: Killed session







On Wed, Nov 12, 2008 at 6:24 AM, <Mayen.Shah@xxxxxxxxxx> wrote:

Oracle 9.2.0.8 on Solaris 9 

In one of my production database session was long running.  Session was 
killed last night. Since then session is marked as KILLED in v$session. 
This killed session is holding locks on few tables and causing further 
problems. 

USED_UBLK in v$transaction is constant at 287 since late last night. 

I identified unix process and killed at os level two hours ago, still 
session would not go away. (os process is gone already) 

What else should I be looking at? How do I get rid of KILLED session? 

When I worked on Solaris (been a few years) we had the same problem 
regularly.

One thing I found was that if you first kill the session in the database, 
you're sunk.
It was necessary to first use kill -9 at the OS level to kill the process.

If we didn't do that, the only way out was to bounce the database.

This is referring only to sessions holding a lock of course.

Things may have changed between versions since the time I worked on
Solaris, but it sounds remarkably similar.

Actually, I had seen that happen earlier on DG/UX, back in 7.x days.
 

I do not have luxury to recycle database. 

Once it gets to that state, and you can verify that there is nothing being
rolled back by PMON, then there's likely nothing else to do.

Jared



-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.

Other related posts: