Re: SQL*Net leaving defunct processes on server

From: Sudhir Giroti <giroti_at_ksr.com>
Date: 1 Sep 1994 19:23:40 GMT
Message-ID: <3459ns$5q4_at_hopscotch.ksr.com>


: Our Oracle 7 server crashed this morning with the message (proc: table is full)
: There were 200 odd defunct processes owned by oracle.
: It would appear that every connection/disconnection from the PC leaves one defunct process.
: Since kill does not work on a defunct process.
: Can anyone tell me how to stop this happening again (other than rebooting the server daily).
 

: I am running Oracle Version 7.0.16.6.0 and orasrv Version 1.2.7.7.1 on a Sparc 10 with SunOS Release 4.1.3_U1 (GENERIC) #2.
: Oracle Forms 4 is being run on half a dozen PC's.

Your orasrv process is not waiting for the death of childs. Essentially in Unix every death of child is reported back to the parent process by the kernel and the parent can then do a sync or asynch wait or waitpid or wait3 etc to get the child status. Unless the parent gets the status the child remains a zombie process. What's happening in your case is that whenever the PC disconnects from the Oracle RDBMS, you essentially also exit the Oracle Process (as expected) and because Oracle instance is a child of your spxsrv process; you therefore have defunct processes as the the orasrv process does not synchronize with the death of child by issuing a wait (or waitpid or wait3 etc).

So once you have defunct processes you cannot kill them until you exist your parent (orasrv) process

So now you have the reason and the solution. Good luck.

--
=========================================================================
Sudhir Giroti                           | Phone:  617-895-3859
                                        | Email:  giroti_at_ksr.com
Member of Technical Staff               | USMail: Kendall Square Research
Commercial Software Development Group   |         170 Tracer Lane, 
                                        |         Waltham, Ma 02154
=========================================================================
Received on Thu Sep 01 1994 - 21:23:40 CEST

Original text of this message