Oracle: TNS:lost contact on 11.11

[Arne Hinrichsen]

I try to install Oracle 7.3.4.x on HP-UX 11.11. Everything works fine during installation, tnslistener starts and keeps running.
But as soon as I call svrmgrl I get the message
ORA-12547: TNS:lost contact

As this Problem exists on 11.0 and can be patched with PHSS_23440 I think it is an HP-UX problem. This behavior also occurs with Oracle 7.3.3 on the same machine.
Related Kernel Parameters are modified for oracle. (This is part of an SAP installation but support from SAP has been discontinued for this Release)
I attached the sqlnet.log of the svrmgrl-session.

TIA

Arne Hinrichsen

[Sridhar Bhaskarla]

Arne,

First check up all the resources on the system while you are doing an svrmgrl such as cpu, memory, swap etc,..

If everything is within it's limit, then relink the listener executable and see if it fixes the problem.

-Sri

[Arne Hinrichsen]

Sridhar,
I remade all the binaries in
rdbms/lib
network/lib
otrace/lib
sqlplus/lib
but the problem persists. A lot of warnings pass by while remaking the binaries though. Mainly because cc is not ANSI Standard. But there are no errors.

[Sanjay_6]

Hi Arne,

Have a look at this thread.

http://technet.oracle.com/doc/server.804/a58312/newch255.htm

Hope this helps.

Thanks

[Jayaprakash_1]

i am sure this problem is just because of the insufficient memory.if possible increase your kernel settings for shared memory or if you have any extra applications running shut it down and try to give svrmgrl if it works then on need add the memory

[Alexander M. Ermes]

Hi there.
Check this one as well pls :

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x9bccd06ed8c8d4118fef0090279cd0f9,00.html

You may find some hints ( i hope ).
Rgds
Alexander M. Ermes

[Volker Borowski]

Arne,

7.3.x let's me assume, you are quite low with the SAP-Release. SAP had a nonstandard setup for the listener in earlier releases.

The SQL-Net files had been set in /usr/sap/trans and to get access to these files, TNS_ADMIN had to be set in the environment. In addition, /usr/sap/trans could very well be NFS-mounted which could cause access problems.

Do a "lsnrctl status" as orasid to see with which files the listener runs, and if these are the ones you need.

If you get them from NFS, keep in mind, that for ease of use, during the installation, this is often done with a -root mount. Later this is changed with access restricted to sidadm now if orasid is not member of the group sapsys, or the group sapsys has a diffrent id on the NFS-source host, it might be possible, that the listener can not read the SQL-NET files.

Hope this helps
Volker

[siddharth_2]

Hi,



I've run into the same problem as Arne did. I went thru the replies in this thread but couldnt get any that finally worked. I'd like to know how this was/(can be) solved..



thanks,

siddharth

[siddharth_2]

Hi,





I've run into the same problem as Arne did. I went thru the replies in this thread but couldnt get any that finally worked. I'd like to know how this was/(can be) solved..





thanks,


siddharth

[siddharth_2]

Hi,







I've run into the same problem as Arne did. I went thru the replies in this thread but couldnt get any that finally worked. I'd like to know how this was/(can be) solved..







thanks,



siddharth

[siddharth_2]

ooops! sorry for the multiple postings. My browser hung and...



Anyways, I'd appreciate any help on the problem.



thanks & apologies,

siddharth

[Anthony deRito]

This is what I found...

# oerr ora 12547

12547, 00000, "TNS:lost contact"
// *Cause: Partner has unexpectedly gone away, usually during process
// startup.
// *Action: Investigate partner application for abnormal termination. On an
// Interchange, this can happen if the machine is overloaded.

I guess you can get a before and after shot at the listener with lsof. Here is a listing I did on my listener:

# lsof -p 3402

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tnslsnr 3402 oracle cwd VDIR 64,0x1 5120 2 /
tnslsnr 3402 oracle txt VREG 64,0x90003 5575936 1780 /opt/ora.8.0.6.2.0 (/dev/vg09/lvol3)
tnslsnr 3402 oracle mem VREG 64,0x5 528384 1391 /usr/lib/libcma.1
tnslsnr 3402 oracle mem VREG 64,0x5 12288 1343 /usr/lib/libdld.1
tnslsnr 3402 oracle mem VREG 64,0x5 1863680 1160 /usr/lib/libc.1
tnslsnr 3402 oracle mem VREG 64,0x5 114688 1342 /usr/lib/dld.sl
tnslsnr 3402 oracle 0r VCHR 3,0x2 0t0 4610 /dev/null
tnslsnr 3402 oracle 1w VREG 64,0x1 146919 606 / (/dev/vg00/lvol1)
tnslsnr 3402 oracle 2w VREG 64,0x1 146919 606 / (/dev/vg00/lvol1)
tnslsnr 3402 oracle 3w VREG 64,0x170002 1504366 6 /opt/orasid (/dev/vg12/lvol2)
tnslsnr 3402 oracle 4r VREG 64,0x90003 11264 1375 /opt/ora.8.0.6.2.0 (/dev/vg09/lvol3)
tnslsnr 3402 oracle 5r PIPE 0x08d99b04 0 2085
tnslsnr 3402 oracle 6u unix 0x08e7ce00 0t0 /tmp/.oracle/sctaimp0
tnslsnr 3402 oracle 7r VREG 64,0x90003 39424 1397 /opt/ora.8.0.6.2.0 (/dev/vg09/lvol3)
tnslsnr 3402 oracle 8w PIPE 0x0890d704 0 2086
tnslsnr 3402 oracle 9u unix 0x08e7cb00 0t0 /tmp/.oracle/s#3402.1
tnslsnr 3402 oracle 10u inet 0x08d15b00 0t0 TCP *:ctaimp0_lsnr (LISTEN)
tnslsnr 3402 oracle 11u inet 0x08e59e00 0t0 UDP *:1253

Check if the process has lost contact with any open files.

After the problem occurs, run lsof again and compare results. Also watch glance at the process level before and after problem occurs.

Tony