Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Reason for having multiple Oracle Listeners
A few weeks back, I posted a question about the reason for having =
multiple Listeners. Well, I found a big one:
On HP-UX, we're preparing to move our 8.1.7.4 DBs to 9.2.0.4/5, so we = installed 9.2.0.4 on a test box. A few days later, we realized that we = could not compile any Java in the DB, nor load it successfully. Even = after copying over a hotback of the 8.1.7.4 DB from production where = Java works fine, we still could not get Java to work. I verified that = the installed 8.1.7.4.0 Oracle software was the same on both boxes.
Before filing a TAR on the issue, I did a little research. The first = thing I noticed is that all DB connections to the 8.1.7.4 DBs were = coming in under the 9.2.0 OS user (I had named the Oracle8 owner's = account as "oracle8" and we opted to go with a generically-named = "oracle" OS account for the 9i DBs and for the future). The 8i DBs had = correctly auto-registered with the new 9i Listener. More importantly, = the *32-bit* 8i DBs had auto-registered with the new *64-bit* 9i = Listener.
Upon using "tusc" (HP-UX equivalent to "truss"), I found that the 64-bit = 9i Java libs were being called to compile the Java because of the = Listener, causing a 64->32-bit "bad magic number" error. Once we = segregated the 8i DBs to an 8i Listener and the 9i DBs to a 9i Listener = and turned off auto-registration, all's well.
I don't know if having separate owners of the ORACLE_HOME code trees, = while sharing a common ORACLE_BASE had anything to do with it, but Java = is definitely happier now. I'm guessing it's more to do with the = SHLIB_PATH variable (LD_LIBRARY_PATH on other Uni) changing between the = 32-bit and 64-bit versions.
I didn't see anything quite like this on MetaLink, so I thought I'd post = here. Maybe someone else's hair can be saved from needless pulling...
I'm Rich Jesse and I approve of this message.
Rich Jesse System/Database Administrator rich.jesse_at_quadtechworld.com QuadTech, Sussex, WI USAPlease see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------