Pythian has a home-grown monitoring system that we install for customers who are interested in it. The system is written (almost) entirely in Perl, which makes it very portable and easy to install on the various systems our customers are running: from windows to AIX. It also makes it extensible – DBAs can easily write new monitors and plug them in.
One of the requirements of the system is its use of DBD::Oracle to connect to the Oracle database that we are monitoring. This sounds pretty reasonable, except that default Perl installations typically don’t arrive with DBD and we have to compile when installing the monitoring software. When you start compiling perl modules, things are no longer as portable as you want them to be. Especially not modules that need to link against Oracle’s client libraries.
Suppose you have 64 bit OS. You can install on it both 32 bit and 64 bit software. It is highly likely that you’ll want to install 64 bit Oracle. However, the version of Perl that arrived with your system is probably 32 bit (Check this! run “which perl” and then “file <path to perl executable>” and see). If Perl is 32 bit, then any module you compile for it has to be 32 bit. If the module is 32 bit, you can’t dynamically link it with 64 bit libraries. If you try to compile or use 32 bit DBD::Oracle with 64 bit Oracle with specially configuring the library path you’ll get an error saying:“ld: fatal: file /ora/prod/oracle/ORAHIB/product/11.2.0/lib/libclntsh.so: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to blib/arch/auto/DBD/Oracle/Oracle.so”
So how do we link to Oracle’s client libraries?
Until 11gR2, Oracle kindly bundled 32 bit libraries even with 64 bit Oracle software. This is the famous lib32 directory. So to correctly link DBD::Oracle, you just had to set LD_LIBRARY_PATH=$ORACLE_HOME/lib32, the correct libraries will be used and everyone will be happy.
With 11gR2, lib32 directory no longer exists and 32 bit libraries are no longer provided. Which means that there is no way to use 32 bit Perl to connect to Oracle. BTW. This applies to other 32 bit clients as well. I’ve heard that SAP can’t support 11gR2 for a similar reason.
What do we do?
Option 1: Install 32 bit Oracle Client and use it to connect to the 64 bit Oracle Server. Just be careful, because as Martin Bach noted: “this is wonderful-from MOS: “Deinstall 11.2 32-bit Home Inadvertanly Removes 64-bit Homes and Vice Versa” [ID 1271661.1]”
Option 2: Discover that Oracle bundles 64 bit Perl in $ORACLE_HOME/perl. Change your environment to use this Perl (its 5.10) and compile DBD::Oracle to work with this version.
Option 3: Compile Perl 64 bit yourself. Our resident Perl Guru, Yanick, claims its easy: “On the other hand, compiling Perl is next to trivial nowadays.
Enjoy!
5 Comments. Leave new
Sorry, but you’ve heard wrong.
Oracle 11gR2 is fully supported by SAP, on both 32 and 64 Bit client platforms.
With 11g there are other fish to fry with Oracle, but using the 32-Bit client is not one of them.
regards,
Claudio
AFAIK, once you discovered option 2, compiling DBD::Oracle is unnecessary. It’s delivered along with DBI.
@Wolfgang
I’m pretty sure it wasn’t. Oracle’s Perl was pretty bare-bones and I had to install DBI and DBD.
I’ve come to prefer building a perl that is used exclusively for DBA tasks.
That way it is possible to add whatever modules you like, or install newer versions if needed.
Installing or upgrading modules on the system perl or Oracle version of perl is bound to cause problems.
Having a dedicated install of Perl avoids a number of issues.
you can build 32 bit perl with the 11.2 oracle instant client (which comes in both 32 and 64 bit). It’s much lighter than a full client, and can be put underneath the perl subtree so its each to tar up perl to copy to other servers if needed.