usr/lib/pa20_64/dld.sl: Unable to find library 'libwtc9.sl'

[Phil Mickolay]

We have done R3copy from a live production system to a test system with a new sid and hostname.

Both the systems have the same version of Oracle(9.2.0.5) and HP-UX (11.11).

We can start/stop the new db on the new target server. However, when we try to start the listener, we get the error usr/lib/pa20_64/dld.sl: Unable to find library 'libwtc9.sl'

I have read other posts at this site describing the need to set the LD_LIBRARY_PATH on the new target server. I have done that and listener now works on this new target server.......HOWEVER..... I went back to the original Production source server and the LD_LIBRARY_PATH is not set. My question is ..HOW IS THE LISTENER WORKING ON THE ORIGINAL PRODUCTION SERVER??? I am confused cause the target server is an exact dupicate of the Source server/db and the source works just fine without a LD_LIBRARY_PATH set, but I need this set on the new Target server??? Your explanation is appreciated.....

Some info from the prod source server are:

uxhq042:orabwp 22> echo $LD_LIBRARY_PATH
LD_LIBRARY_PATH: Undefined variable.
uxhq042:orabwp 23>
uxhq042:orabwp 23>
uxhq042:orabwp 23> env
HOME=/oracle/BWP
PATH=/oracle/BWP/920_64/bin:.:/oracle/BWP:/usr/sap/BWP/SYS/exe/run:/usr/bin:/uss
LOGNAME=orabwp
SHELL=/usr/bin/csh
TERM=vt100
COLUMNS=80
LINES=24
MANPATH=/usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man:/n
TZ=EST5EDT
SAPSYSTEMNAME=BWP
DIR_LIBRARY=/usr/sap/BWP/SYS/exe/run
SHLIB_PATH=/usr/sap/BWP/SYS/exe/run:/usr/sap/BWP/SYS/exe/run:/oracle/BWP/920_642
THREAD=NOPS
dbms_type=ORA
dbs_ora_schema=SAPBWP
ORACLE_PSRV=BWP
ORACLE_SID=BWP
DB_SID=BWP
ORACLE_HOME=/oracle/BWP/920_64
ORACLE_BASE=/oracle
ORA_NLS33=/oracle/BWP/920_64/ocommon/nls/admin/data
NLS_LANG=AMERICAN_AMERICA.WE8DEC
SAPDATA_HOME=/oracle/BWP
JAVA_HOME=/opt/java1.4
uxhq042:orabwp 24>

[Steven E. Protter]

Shalom Phil,

On HP-UX SHLIB_PATH is used instead of $LD_LIBRARY_PATH. Check that this is set correctly and try again.

Check the environment on a working machine with env command.

See that SHLIB_PATH is set correctly in all startup scripts.

SEP

[Phil Mickolay]

Steve, my original post shows the env of the production machine which does show that the SHLIB_PATH is set, so that seems to agree with your response. However the new target server also has the SHLIB_PATH set. On the target server, even with the SHLIB_PATH set, we were still encountering the error when attempting to start the Oracle listener. I could start listener on the target server only when I exported the LD_LIBRARY_PATH. And thats what confuses me. How can the production server be working and the target server not be...even though it is an exact duplicate of the source server. As a note, the application admin could not start the SAP application on the new Target server until he also set the LD_LIBRARY_PATH. Here is the env of the target server which shows the SHLIB_PATH is also set. This is very confusing on why this isn't working on the Target Server. Thank you for your help...

uxhq043:orabwk 22> env
HOME=/oracle/BWK
PATH=/oracle/BWK/920_64/bin:.:/oracle/BWK:/usr/sap/BWK/SYS/exe/run:/usr/bin:/uss
LOGNAME=orabwk
SHELL=/usr/bin/csh
TERM=vt100
COLUMNS=80
LINES=24
MANPATH=/usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man:/n
TZ=EST5EDT
SAPSYSTEMNAME=BWK
DIR_LIBRARY=/usr/sap/BWK/SYS/exe/run
SHLIB_PATH=/usr/sap/BWK/SYS/exe/run:/usr/sap/BWK/SYS/exe/run:/oracle/BWK/920_642
THREAD=NOPS
dbms_type=ORA
dbs_ora_schema=SAPBWP
ORACLE_PSRV=BWK
ORACLE_SID=BWK
DB_SID=BWK
ORACLE_HOME=/oracle/BWK/920_64
ORACLE_BASE=/oracle
ORA_NLS33=/oracle/BWK/920_64/ocommon/nls/admin/data
NLS_LANG=AMERICAN_AMERICA.WE8DEC
SAPDATA_HOME=/oracle/BWK
LD_LIBRARY_PATH=/oracle/BWK/920_64/lib
JAVA_HOME=/opt/java1.4
uxhq043:orabwk 23>
uxhq043:orabwk 23>

[Phil Mickolay]

One other piece of info....we are a 64 bit shop and I thought the shlib_path was a 32 bit shared library. Again, I feel comfortable adding the LD_LIBRARY_PATH varaible to the new target server, but reamin totally confused how everytrhing is working fine on the original Production box where no LD_LIBRARY_PATH is set......

[Sundar_7]

Phil,

I dont know how R3Copy works, but did you try comparing the chatr output of the binaries ?

# chatr

Compare the output and post the difference here , if any

Sundar.

[Phil Mickolay]

I performed this on both the prod(source) server and the new test(target) server and have copied both into this response....I cd to the oracle binary lib and performed chatr for the listener... Please note that it is showing that it goes to the LD_LIBRARY_PATH first..but my first posting shows no LD_LIBRARY_PATH is set on this production box. SO how is the production box recognizing LD_LIBRARY_PATH as proven when I perform chatr on the binaries???? There are some differences from the output of chatr of Prod server to the new target server, but I am not versed enough to know if these differences have any bearing on my problem???

uxhq042:orabwp 40> echo $LD_LIBARY_PATH
LD_LIBARY_PATH: Undefined variable.
uxhq042:orabwp 41>

uxhq042:orabwp 38> cd $ORACLE_HOME/bin
uxhq042:orabwp 39> chatr lsnrctl
lsnrctl:
64-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /oracle/BWP/920_64/network/lib/:
/oracle/BWP/920_64/lib/:/usr/lib/pa20_64:/opt/langtools/lib/pa20_64:
shared library list:
libclntsh.sl.9.0
libwtc9.sl
libcl.2
librt.2
libpthread.1
libnss_dns.1
libdl.1
libm.2
libc.2
shared library binding:
deferred
global hash table disabled
global hash table size 1103
shared library mapped private disabled
shared library segment merging disabled
shared vtable support disabled
explicit unloading disabled
segments:
index type address flags size
6 text 4000000000000000 z---c- D (default)
7 data 8000000100000000 ---m-- D (default)
executable from stack: D (default)
static branch prediction disabled
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr references disabled
uxhq042:orabwp 40>


******************************************

And for documentation, here is the new target server. We had to manually export the LD_LIBRARY_PATh for listener to work ...

uxhq043:orabwk 27> echo $LD_LIBRARY_PATH
/oracle/BWK/920_64/lib
uxhq043:orabwk 28>
uxhq043:orabwk 28>
uxhq043:orabwk 28>
uxhq043:orabwk 28> chatr lsnrctl
lsnrctl:
64-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /oracle/BWK/920_64/network/lib/:
/oracle/BWK/920_64/lib/:/usr/lib/pa20_64:/opt/langtools/lib/pa20_64:
shared library list:
libclntsh.sl.9.0
libwtc9.sl
libcl.2
librt.2
libpthread.1
libnss_dns.1
libdl.1
libm.2
libc.2
shared library binding:
deferred
global hash table disabled
shared vtable support disabled
segments:
index type address flags size
5 text 4000000000000000 z---c D (default)
6 data 8000000100000000 ---m- D (default)
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
uxhq043:orabwk 29>


Thank you for any assistance that you might be able to provide.......

[Phil Mickolay]

Steve/Sundar....was just checking to see if you might have any explanation, or if my last posting of documentation helped. Still curious how our production system is working when we do Not have a LD_LIBRARY_PATH set in the env. Thank you

[Sanjay Kumar Suri]

Hello Phil

Just check this thread.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=713819

sks

[Mar_4]

In my case it's always fixed after relinking oracle...

Diamanda.