Few days back, I wanted to remove a instance semaphore as they were not cleared automatically due to abnormal shutdown. As there were few other databases running on the server , so I thought of capturing the semaphore id to remove them manually using “ipcrm” .
For this purpose, we are required to use sysresv utility. Upon execution of the command, I received following errors
$/u01/app/oracle/product/10.2.0/bin>sysresv
sysresv: error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory
Now this was a new installation so I was bit scared if there was something wrong with the installation. Searching the web pointed me to articles which mentioned about using user which is not in correct group.
But in my case it was properly set and part of dba/oinstall group. Further research led me to Puschitz webpage (Very useful site if you are planning to install Database)which described that this problem is caused when environment variable LD_LIBRARY_PATH is not set.
So I set the value of LD_LIBRARY_PATH and then tried again
<strong>$</strong>export LD_LIBRARY_PATH=$ORACLE_HOME/lib <strong>$</strong>sysresv IPC Resources for ORACLE_SID "orcl10" : Shared Memory: ID KEY 131074 0x0291b1b8 Semaphores: ID KEY 229377 0xc116e83c 262146 0xc116e83d 294915 0xc116e83e Oracle Instance alive for sid "orcl10"
This worked !!!
My issue was solved but I must admit that I was not aware of what this variable did. I had seen this Environment variable set in my previous company, but somehow I didn’t give importance to it.
Searching on web, I came across Oracle Forum thread
which stated that
“The LD_LIBRARY_PATH environment variable contains a colon-separated list of directories in which the linker will search for library (.a) files. If you want the linker to search additional libraries, you can add their names to LD_LIBRARY_PATH.”
One more article gave insight into how application looks for library files.
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p4.html
The runtime linker only looks in one default location for dependencies. This location is /usr/lib when processing 32-bit objects, and /usr/lib/64 when processing 64-bit objects. All other directories to be searched must be added to the runtime linker’s search path explicitly.
On searching metalink for further information on this parameter, I came across
Subject: Solaris: Setting LD_LIBRARY_PATH in 10gR1 and higher
Doc ID: Note:271451.1
According to this note, there are two more variables LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64 which can be set to point to 32-Bit and 64-Bit libraries.
Further it mentioned that it is Not Recommended to set LD_LIBRARY_PATH unless application (Oracle or 3rd-party) requires it and recommended using LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64.
This is done so that 32-Bit programs can use the correct libraries and similarly 64-bit programs can use 64-Bit library files.
So next time, you receive some library error, then do not panic 
and see if parameter LD_LIBRARY_PATH or LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 is set.
Note:- In case you are using non-oracle user and see that you are getting same error after setting the variable,then check if the file ibclntsh.so.10.1exists and non-oracle user’s have read/execute permission over it. If no then relink Oracle using relink all command
