Re: orasrv: server already running: Address already in use

In article <1992Oct1.114352.1_at_us.oracle.com>, sstephen_at_us.oracle.com writes:
> In article <peter.717868592_at_merlin>, peter.steele_at_acadiau.ca (Peter Steele)
 writes:
> > This error occurs when orasrv, the oracle kernel daemon, is
> > shutdown and the restart command is issued to soon after the
> > shutdown. Waiting a couple of minutes usually solves the problem.
> > However, we occasional get a situation where orasrv gets confused
> > and will issue this error indefinitely. The only way we've discovered
> > to clear this error is by rebooting, which isn't desirable on
> > a production machine.
> >
> > Has anyone seen this error, where Oracle gets confused and won't
> > let you restart orasrv?
> > --
> > Peter Steele Unix Services Manager peter.steele_at_acadiau.ca
> > Acadia Univ., Wolfville, NS, Canada B0P 1X0 902-542-2201 Fax: 902-542-4364
>
> Killing the orasrv process seems to fix this problem, especially on ICL and NCR
> ports. It happens less and less in each release. I believe in orasrv 1.2.7,
> this problem is almost non-existent.
>

I missed the initial posting on this topic but I think I know the issue. Please pardon me if it is not, so here goes.

The following situation I am about to describe is for UNIX boxes. If you are unable to restart/shudown your orasrv, there are a number of things you could do.

1. tcpctl stat Find out if there are any active connections? If there are, log them out or kill the unix server connection process . How do you find them?
2. grep oracle /etc/services Get the socket number. This is normally 1525.
3. netstat -A |grep 1525 Get all processes associated with the Oracle socket,1525

PCB      Proto Recv-Q Send-Q  Local Address      Foreign Address (state)
fface20c tcp        0      0  redbaron.1714      biggles.1525    ESTABLISHED
ffa9d60c tcp        0      0  redbaron.1525      biggles.4847    ESTABLISHED
ffa7ae8c tcp        0      0  redbaron.1052      biggles.1525    ESTABLISHED

4. ofiles -n PCB_number

    This is the difficult part. You now need to find out the UNIX     process that is attached to the socket. There is a public domain     program called, ofiles that can do this. Basically it looks at the     protocol control block (PCB) and maps that to a UNIX process. You     will get a PID from ofiles.

5. kill PID

    Once you have the PID, you may kill it.

6. Try using tcpctl again

The problem is normally associated with PC-Client processes that switch off their PC or reboot them while connected a server database. I hope this sheds some light.

-- 
-----------------------------------------------------------------------------
 _____       ________ / ____ |Tony Jambu, Database Administrator
  /_  __       /_ __ /       |Colonial Mutual Life Australia. (ACN 004021809)
 /(_)/ ((_/ \_/(///(/_)/_(   |EMAIL:  TJambu_at_cmutual.com.au