Friday, April 10, 2009

LD_LIBRARY_PATH is not set! in alert_XE.log

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

This morning i discovered the following messages in the alertXE.log, located in the bdump folder of a xubuntu virtual machine:

Fri Apr 10 15:01:15 2009
Starting ORACLE instance (normal)
Cannot determine all dependent dynamic libraries for /proc/self/exe
Unable to find dynamic library libocr10.so in search paths
RPATH = /ade/aime1_build2101/oracle/has/lib/:/ade/aime1_build2101/oracle/lib/:/ade/aime1_build2101/oracle/has/lib/:
LD_LIBRARY_PATH is not set!
The default library directories are /lib and /usr/lib
Unable to find dynamic library libocrb10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =10
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
...
After a quick search on the web, i read this posting from Mohammad, so i concluded i was not the first one to see this error...
He suggests to set the variable LD_LIBRARY_PATH in the .bash_profile or .profile of the oracle user, however i preferred to change the main startup script located in /etc/init.d containing the settings for most of the Oracle variables, as shown in the image:



After fixing oracle-xe, the alert_XE.log file doesn't show anymore the warning messages:
Fri Apr 10 15:06:43 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =10
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
...
Someone may argue that changing the script does not guarantee against future installations (or re-installations), however hopefully Oracle will fix the bug in the meantime, so Oracle 11XE will not be affected by this flaw.

In the end i'd be curious to know which functionality was affected by the bug because this Oracle instance has been running for quite some time without showing any particular problems.

6 comments:

Anonymous said...

Thanks,

that helped me a lot!

with regards,
Chris

Anonymous said...

I'm not sure but could it be possible that Oracle XE would have problems compiling some packages when the variable LD_LIBRARY_PATH is not set?

Byte64 said...

I'd expect that, if what you say is true, certain features would be completely broken.
Is that your case?
I am asking because I found XE 10g to be very solid apart from a few annoying bugs that in some way I managed to mitigate by using a different approach.
What I mean is that I don't know of any package that is completely unusable, but may be I never came across the specific situation, so you may want to shed some more details about the problems you encountered.

Flavio

Anonymous said...

Thanks Byte64,

The problem is that i've got a package that won't compile (it's using utl_tcp)

if I comment out the use of utl_tcp it compiles without an issue, but since i'm a dba and the developer wants to use XE instead of SE or EE it would be nice if this would work. Permissions on the utl_tcp package are set to execute and debug granted to public and the application owner (owns the packages using utl_tcp)

thanks in advance if you would know what could be the cause, im out of search options:-)

Byte64 said...

I am using UTL_TCP on XE without problems.
If I remember correctly, UTL_TCP doesn't come with a PUBLIC synonym, so if your code doesn't compile it can be because you didn't create a public synonym for UTL_TCP or you are not using the SYS.UTL_TCP syntax.

Hope it helps
Flavio

Anonymous said...

Thanks!

The SYS.UTL_TCP syntax did the trick and the package compiles succesfully!

AWESOME!!!

yes you can!

Two great ways to help us out with a minimal effort. Click on the Google Plus +1 button above or...
We appreciate your support!

latest articles