Stephen Weblog

Had a chance to do a disco installation on Linux. Had a strange issue when I login to Oracle Applications via disco it said invalid user name and password. Cannot connect to database, all i know is disco uses the .dbc file for connection.. I did copy the .dbc file from apps tier to disco tier, but the file name was in uppercase. Don’t know for what reason I changed the file name to lowercase it started working…

Copy apps dbc file to disco tier under location: $ORACLE_HOME/discoverer/secure/

Here we go, error message as below

libpath libjvm.sl
Library error: Can’t open shared library: libjvm.sl
libpath libjava.sl
Library error: Can’t dlopen() a library containing Thread Local Storage: libjava.sl

How many times we would have come across these type of errors, it screws up sys admins. I have seen this many times and hence I thought of putting it here. When we run any kind of java related process we might hit these type of errors. It’s nothing bug issue one of the process had tried to load the libjava.sl into the memory and it had failed because it dlopen() function call had failed. Actually this type of errors might be platform specific and it most often happens in HP, AIX platforms. So this leads us into two type of questions.

1. Why it fails only on specific operating system and
2. Why it goes through fine on other OS

If we answer the first then we will get the answer for the other as well. On HP, AIX platforms we see this issue because libjava.sl is not preloaded onto the memory, But on some other OS it is loaded into the main memory (JVM) by default. So in this scenario what we need to do is just use one of the OS specific variable LD_PRELOAD. Here the solution will be do a LD_PRELOAD of this shared library, so that when any of the process tries to access this shared library it is loaded in time

export LD_PRELOAD=/opt/java1.4/jre/lib/PA_RISC/libjava.sl

libjava.sl is the one which will call the libjvm.sl, so at times what will happen is we will find a strange error like the below.
Library error: Can’t dlopen() a library containing Thread Local Storage: libjvm.sl

So what we will do is we need to do a LD_PRELOAD of both these sl’s, here we go

export LD_PRELOAD=/opt/java1.4/jre/lib/PA_RISC/libjava.sl:/opt/java1.4/jre/lib/PA_RISC/libjvm.sl

So just in the command line set up these variables and also take a look at LD_LIBRARY_PATH, SHLIB_PATH and LIB_PATH based on the OS being used and try running the process which invokes these shared libraries it will load fine. I myself experienced these type of errors many times and were successfully resolved all of them especially on HP PARISC!!!

Thanks,

At times during patch application we might get into a deadlock situation, In order to remove the blocking session follow the below mentioned steps.

SQL> select process,sid, blocking_session from v$session where blocking_session is not null;

PROCESS SID BLOCKING_SESSION
———— ———- —————-
1234 361 367
1234 367 361

SQL> select SERIAL# from v$session where sid = 361 ;

SERIAL#
———-
42

SQL> alter system kill session ‘361,42′;

System altered.

SQL> select process,sid, blocking_session from v$session where blocking_session is not null;

no rows selected

Just out of interest started to write about my Oracle Apps Experience, so here goes my first blog on Oracle Apps i.e., Rapid Clone of Oracle Applications:

1. Pre-clone Apps Tier and DB Tier in the source system:

• cd <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>
• perl adpreclone.pl dbTier
• cd <COMMON_TOP>/admin/scripts/<CONTEXT_NAME>
• perl adpreclone.pl appsTier


2. Copy the below mentioned directories from source to the target machine:

• rcp -r visappl <<user>>@<<hostname>>:<<target location>>
• rcp -r viscomn <<user>>@<<hostname>>:<<target location>>
• rcp -r visora <<user>>@<<hostname>>:<<target location>>
• rcp -r visdata <<user>>@<<hostname>>:<<target location>>
• rcp -r visdb <<user>>@<<hostname>>:<<target location>>

3. Configure target system:

• cd <RDBMS ORACLE_HOME>/appsutil/clone/bin
• perl adcfgclone.pl dbTier
• cd <COMMON_TOP>/clone/bin
• perl adcfgclone.pl appsTier

4. Post checks

Concurrent Managers might not come up in the cloned instance because some of the CM tables will still hold the source instance details, so to bring up CM run this script and bounce CM.

$FND_TOP/patch/115/sql/afdcm037.sql

Thats it, you are all set with your cloned instance.