error while loading shared libraries: libgdbm.so.2 or libdb-3.3.so

While installing the latest HTTP Server (Oracle HTTP Server (Apache 2.0) (10.1.3.3.0) ) from oracle to take advantage of the modplsql module that is provided.
The installation completed succesfully but still the httpd process could not start because of missing library dependencies.

When opening your $ORACLE_ACACHE_HOME/opmn/logs/HTTP_Server~1.log

you could find the following errors there :

——–
09/10/31 18:28:32 Start process
——–

/u00/oracle/product/10.1.3/apache/ohs/bin/apachectl startssl: execing httpd
/u00/oracle/product/10.1.3/apache/ohs/bin/httpd: error while loading shared libraries: libgdbm.so.2: cannot open shared object file: No such file or directory

——–
09/10/31 18:37:31 Start process
——–
/u00/oracle/product/10.1.3/apache/ohs/bin/apachectl startssl: execing httpd
/u00/oracle/product/10.1.3/apache/ohs/bin/httpd: error while loading shared libraries: libdb-3.3.so: cannot open shared object file: No such file or directory

In the same order you could fix this by creating symbolic links to the current shared library for each missing library.

( execute as root user )
cd /usr/lib

ln -s libgdbm.so.3.0.0 libgdbm.so.2

ln -s libdb-4.3.so libdb-3.3.so

These versions are found on “SUSE Linux Enterprise Server 10 SP2 (i586)” , your symbolic links can be different when the problem is faced on a different version operating system.
Please adjust accordingly.

( execute as root user )
cd /usr/lib

ln -s libgdbm.so.X.0.0 libgdbm.so.2

ln -s libdb-4.X.so libdb-3.3.so

error while loading shared libraries: libaio.so.1: cannot open shared object file

While wanting to preform a disaster recovery using RMAN on a spare server which has an ORACLE_HOME 10.2.0.1 64bits installed on a Red Hat Enterprise Linux AS release 4 Operating System.
I tried the following to read back my controlfile. But before getting to this point i faced this error :

oracle@xxx: $ $ORACLE_HOME/bin/rman target /

Recovery Manager: Release 10.2.0.1.0 – Production on Wed Jul 8 10:32:56 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

oraclewiki: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-12547: TNS:lost contact

Assuming the libaio library was installed i searched and tried to clear this up. As the server is a x86_64 server there should be a 64 bit library of libaio installed :

oracle@xxx: # find / -name libaio.so.1
/local/app/oracle/product/db10g/lib/stubs/libaio.so.1
/local/app/oracle/product/agent10g/lib/stubs/libaio.so.1
/local/app/oracle/product/db10gtest/lib/stubs/libaio.so.1
/local/app/oracle/product/10.2.0/db/lib/stubs/libaio.so.1
/local/app/oracle/product/10.2.0/db/lib32/stubs/libaio.so.1
/usr/lib/libaio.so.1

oracle@xxx: $ ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => not found

As i could see here, this was not the case. Only the 32 bit is availible and therefor not used by the Oracle 64 bits Database software.
The output of the ldd command supports this as there is a dependency problem for the oracle process on libaio.so.1.

After adding the following rpm’s i was able to connect without problems.

root@xxx: # up2date –showall | grep libaio | grep 64
libaio-0.3.105-2.x86_64
libaio-devel-0.3.105-2.x86_64

As you can see now the correct library is found and the dependency problem is solved.

oracle@xxx: $ ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => /usr/lib64/libaio.so.1 (0×0000002a96f40000)

Problems with the BACKSPACE key on Solaris or AIX

Every ran into the problem that the BACKSPACE key does not work ?
Instead you will get “^?” or “^h” on the screen when BACKSPACE is used.
^? will be returned on ksh shell and ^h will be returned when using a bash shell

When you want to lose this behaviour in your session you could execute the following command :

stty erase [BACKSPACE]

After this the BACKSPACE works again ! After logout the setting is gone and should be executed again.

Use ssh-keygen to setup password-less SSH login

Just a quick reminder on how to setup a simple password-less SSH login on your servers.
You might get lost in all documentation that is published on the topic. Here is what i execute to make it work !

Actions for the source server :

oracle@db $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): [LEAVE EMPTY]
Enter same passphrase again: [LEAVE EMPTY]
Your identification has been saved in /home/oracle/.ssh/id_rsa.
Your public key has been saved in /home/oracle/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx oracle@db.example.nl
oracle@db $

Resulting in ;

oracle@db $ ll
total 12
-rw——- 1 oracle oinstall 1675 Jul 3 11:33 id_rsa
-rw-r–r– 1 oracle oinstall 401 Jul 3 11:33 id_rsa.pub
-rw-r–r– 1 oracle oinstall 1138 Jul 3 10:38 known_hosts
oracle@db $

Actions for the remote server :

Now copy the content of the id_rsa.pub file in the authorized_keys on the server( db2 in my case ) you want to connect to. The location of the the file is /home/oracle/.ssh/authorized_keys

That it !

Now we can connect without the use of a password ;

oracle@db $ ssh db2
Last login: Fri Jul 3 11:37:41 2009 from db2.example.nl
oracle@db2$

I use this setup to be able to execute os command’s from within my script on a remote server.

Using SPident to reveal the running SuSE release

To verify the Suse 10 release and its Service Packs you can either consult the /etc/SuSE-release file or execute the following command.

[] xxx:/> SPident -v

Summary (using 840 packages)
Product/ServicePack conflict match update (shipped)
SLE-10-x86_64 0 0% 306 36.4% 0 (2754 11.1%)
SLE-10-x86_64-SP1 0 0% 443 52.7% 0 (2938 15.1%)
SLE-10-x86_64-SP2 0 0% 840 100% 0 (2337 35.9%)

CONCLUSION: System is up-to-date!
found SLE-10-x86_64-SP2

[] xxx:/>

runInstaller Segmentation fault

Today i was challanged with an error which suddenly appeared after running multiple installs on the system.

oracle@xxx 1021 $ ./runInstaller
Starting Oracle Universal Installer…

Checking installer requirements…

./runInstaller: line 65: 4245 Segmentation fault $CMDDIR/install/runInstaller -oneclick SHOW_CUSTOM_TREE_PAGE=false $*

when strace is used to find the error occuring i was able to find this ;

oracle@xxx 1021 $ strace ./runInstaller -oneclick SHOW_CUSTOM_TREE_PAGE=false $*

…
…
write(3, “\nChecking operating system versi”…, 44) = 44
write(3, “redhat-Red Hat Enterprise Linux “…, 192) = 192
access(“/etc/redhat-release”, F_OK) = 0
stat64(“/etc/redhat-release”, {st_mode=S_IFREG|0700, st_size=45, …}) = 0
open(“/etc/redhat-release”, O_RDONLY) = -1 EACCES (Permission denied)
— SIGSEGV (Segmentation fault) @ 0 (0) —
+++ killed by SIGSEGV +

As it turned out , someone just changed the security properties on the redhat-release file so that public could not read it anymore.

WRONG
-rw——- 1 root root 56 Apr 11 2007 redhat-release
(chmod 600 )

RIGHT
-rw-r–r– 1 root root 56 Apr 11 2007 redhat-release
(chmod 644)

After changing this back to original chmod 644 , the installer started perfectly

-bash: /bin/rm: Argument list too long

Ever ran into this error ?
Well the solution other then removing the directory and recreating it would be to run a command similar to this from within the directory you want to clean;

find . -name ‘*.trm’ | xargs rm
find . -name ‘*.trc’ | xargs rm

Just a nice to know :)

ORA-01031: insufficient privileges when using EXP

Using an export OS script with a command similar to this:

exp “‘/ AS SYSDBA’” full=y file=export_SID.dmp log=export_SID.log statistics=none

This error suddenly came around.

EXP-00056: ORACLE error 1031 encountered
ORA-01031: insufficient privileges

After researching this error, i found that when the TWO_TASK parameter is set, Oracle tries to connect via Oracle Net.
This then will return an error while connecting using $OPS login of “/” , which is done in my case.

after unset this variable the problem was solved !

unset TWO_TASK

Exception in thread “main” java.lang.InternalError: Can’t connect to X11 window

When running you runInstaller under another user then the current user logged into the X server screen, you might hit this error.
I ran into this error while being logged on to a vnc session running under the root user. While perfoming tasks under root , switched user to oracle and set the display back to the current screen

su – oracle
export DISPLAY=xxx:1

The installer starts but exits with the following error;

Starting Oracle Universal Installer…

….

Exception in thread “main” java.lang.InternalError: Can’t connect to X11 window
server using ‘xxx:1′ as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Unknown Source)
at java.awt.Window.init(Unknown Source)
at java.awt.Window.(Unknown Source)
at java.awt.Frame.(Unknown Source)
at java.awt.Frame.(Unknown Source)
at oracle.ewt.popup.PopupFrame.(Unknown Source)
at oracle.ewt.lwAWT.BufferedFrame.(Unknown Source)
at oracle.sysman.emgc.oneclick.OneClickWizard.getGuiDefaults(OneClickWizard.java:239)
at oracle.sysman.emgc.oneclick.OneClickWizard.(OneClickWizard.java:205)
at oracle.sysman.emgc.oneclick.OneClick.(OneClick.java:236)
at oracle.sysman.emgc.oneclick.OneClickInstaller.(OneClickInstaller.java:116)
at oracle.sysman.emgc.oneclick.OneClickInstaller.process(OneClickInstaller.java:268)
at oracle.sysman.emgc.oneclick.OneStartup.startup(OneStartup.java:383)
at oracle.sysman.emgc.oneclick.OneArgs.main(OneArgs.java:700)
at oracle.sysman.emgc.oneclick.OneStartup.main(OneStartup.java:391)
oracle@xxx:/u00/agent/linux/agent> ./runInstaller

A solution could be to disable access control under the user from which VNC is running , in my case under root.

xxx:/ # xhost +
access control disabled, clients can connect from any host
xxx:/ #

Now the runInstaller will start fine in this setup !

Testing disk speeds on a linux server using hdparm

Getting more info on the throughput of a disk( or partition) on a Linux server, you might want to compare the outcome of this command against another well preforming disk ( or partition) :

xxx:~ # hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 18296 MB in 2.00 seconds = 9154.93 MB/sec
Timing buffered disk reads: 114 MB in 3.03 seconds = 37.58 MB/sec
xxx:~ #

( The -T means to test the cache system (Memory, CPU and buffer cache). The -t means reading data that is not in the cache. )

I did use this to see a difference in disk preformance of a couple of RAID sets where one was configured as WriteThrough and the other was configured as WriteBack. The Write Back option gave us an enormous preformance boost !