Re: Orphan sessions

From: joel garry <joel-garry_at_home.com>
Date: Wed, 22 Jun 2011 13:28:40 -0700 (PDT)
Message-ID: <666fc3cf-940b-4e7f-91d5-bc8a88206106_at_q12g2000prb.googlegroups.com>

On Jun 22, 10:33 am, David Budac <davidbu..._at_gmail.com> wrote:
> I guess I have to figure out why SQLNET.EXPIRE_TIME didn't work. We've
> had this parameter set. The more I read about it, the more I see it
> was supposed to work. The protocol in use is TCP which makes it even
> weirder.
>
> Thanks again

I seem to recall this can happen if the oracle user process has spawned a child, the child dies or gets hung up in a wait (or odd things that put errors in the alert log), and the parent waits forever for the child to respond, ignoring the death signal from the client. Or something like that.

Be careful if someone tells you to use code like this (X and z are obfuscation):

SYS_at_XXXX> SELECT spid FROM v$process WHERE NOT EXISTS ( SELECT 1 FROM v$session WHERE paddr = addr); 2

SPID

---

2029
2031

SYS_at_XXXX> !ps -ef|grep 2029

  oracle  2029     1  0  Jun  5  ?         0:00 ora_d000_XXXX
  oracle 20039 19987  0 13:08:13 pts/0     0:00 grep 2029

SYS_at_XXXX> !ps -ef|grep 2031
  oracle  2031     1  0  Jun  5  ?         0:01 ora_s000_XXXX
 zzzzzzz 12031     1  0 06:35:15 ?         0:20 oracleXXXX
(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
  oracle 20070 19987  1 13:08:30 pts/0     0:00 grep 2031

Note they've been handed off to init, but you can't tell if they are orphans or legitimate (well, you could have excluded background processes by username), and of course it picked up an extra process.

jg

--
_at_home.com is bogus.
http://www.freelists.org/post/oracle-l/IBM-Consulting-info,9

Received on Wed Jun 22 2011 - 15:28:40 CDT