After moving Shareplex from one server to another, when you try to apply a license on a Shareplex install, it fails. The following is the screen shot:
dbs02(splex:rptf)>>./splex_add_key
ld.so.1: splex_add_key: fatal: libshareplex.so: open failed: No such file or directory
Killed
dbs02(splex:rptf)>>
There may be problems with the soft links from Shareplex installation to Oracle libraries.
First you may want to run "ldd -s" at Unix OS prompt to determine what, if any, are the issues with the libraries required by the program splex_add_key. The "ldd" (List Dynamic Dependencies) utility is useful for finding problems with missing files and incorrect file links when troubleshooting LEI and DECS issues on UNIX systems. In our case it lists out the missing link for libshareplex.so as shown below:
dbs02(splex:rptf)>>ldd -s splex_add_key
find object=libshareplex.so; required by splex_add_key
search path=/var/adm/.splex/V-5.3/lib81 (RPATH from file splex_add_key)
trying path=/var/adm/.splex/V-5.3/lib81/libshareplex.so
search path=/usr/lib (default)
trying path=/usr/lib/libshareplex.so
libshareplex.so => (file not found)
We then went to the path /var/adm/.splex/V-5.3/lib81 and created a symbolic link as follows:
ln -s <proddir>/lib/libshareplex.so libshareplex.so
This recreated the missing symbolic (soft) link. When the binaries are moved around, say, when changing the servers, the soft links are sometimes lost. This can result in Shareplex processes that require the Oracle libraries to error out. Such processes range from sp_cop, sp_ctrl, ora_setup, splex_add_key, etc. In our case the alarm was raised by the program splex_add_key when the customer first tried to apply another permanent license key as a part of the procedure to do server change. But the problem would have been noticed by any one of the Shareplex process that first encountered it when needing the Oracle library.
The links are also missed at times during Oracle upgrade, etc. The solution in that event is also similar.
