Pythian Group

Version of 1.28 of DBD::Oracle has been released. You can find it at CPAN DBD::Oracle.

DBD::Oracle is a Perl module that works with the DBI module to provide access to Oracle databases. It is maintained by me, John Scoles, under the auspices of Pythian as Open Source/Free Software.

This is a long overdue maintenance release that fixes a large number of bug and issues which are detailed below in the Changes.
Read the rest of this entry . . .

Here is the latest and greatest DBD::Oracle for your programming pleasure.

You can find the Zip file here

DBD-Oracle-1.28-RC1.zip

This is a long overdue maintenance release that fixes a large number of bug and issues which are detailed below in the Changes.

Don’t worry there are some new goodies in this release namely I have added in 4 new
server side tracing/debugging attributes
Read the rest of this entry . . .

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. Discover http://bit.ly/e5RELx and rejoice!”

Enjoy!

Sorry no funny nick name for version 1.27 but here is the scoop on it anyway

You can find the Zip file here

DBD-Oracle-1.27-RC1.zip

This version removes ‘PERL_POLLUTE’ and adds in PL_ so it will be fully compatible with Perl 5.13.

So in a nutshell 1.27 is a single issue maintenance release.

For those interested in the whole story you can have a look at this thread

Perl 5.13.3+ MAY BREAK COMPILED DRIVERS – Please test DBI 1.613_71

Any an all testing with differing Perls would be much appreciated

Cheers John Scoles

After enjoying the excellent hospitality of our host here in Pisa (6 courses) we were ready for our second day at YAPCEU 2010 here in sunny Pisa.

Larry’s new catch phrase “My Language is a four letter word” was the ‘Buzz word’ for today. We settled down to some very interesting talks, the highlight for me being Tim Bunce’s talk on using Devel::NYTProf to Optimize your code. Tim first gave us a quick and dirty overview of optimization which covered the basics of where to start and what to look for he followed up with real examples of Optimizer output and than wrapped up with a few before and after results on an optimization effort.

The rest of the day was dedicated in my opinion, to the future of DBs in with Nelson Ferraz giving an excellent presentation of his concepts for using Perl as to glue for a Data Warehouse application. Next on my agenda, Martin Berends reports on the present state of Perl 6 and interfaces database. There is progress here as we now have some access to the DBI for MySQL and some others. Also great news is the fact there is a good deal of development work going on.

Martin was quickly followed by Tim Bunce again who presented his proposal for the new Perl 6′s DBDI. Seems
we are going to use the JDBC specification with a little tweaking as our road map for the future. Tim also
showed of some Perl 6 black majik from Jonathan Worthington and he was able to how us DBI with DBD::Pg
running on Perl 6.

Allison Randal finished off today’s formal presentations with her “Migration Strategies” presentation. She
gave us some good insight into migration in that we, as developers, cannot force migration on the community. She also provided two examples of migrations: Apache, which took seven years but has almost full buy-in by users and Python, which was quick and dirty but has not received the same buy-in from the community.

Finally we all enjoyed the lightning talks as our wrap up. A number of neat quick ones such as ‘I speak Perl with a ‘c’ accent’, was a highlight for me.

Seems the videos and most of the slides (including my presentation on XS) may be online tomorrow. I will be sure to post them as soon as I see them.

If you have ever had this message:

Unable to locate an oracle.mk, proc.mk or other suitable *.mk
file in your Oracle installation. (I looked in…)

It can be a very frustrating one to track down.
Read the rest of this entry . . .

I have successfully compiled and installed DBD::Oracle on Windows 2008 Server 64bit operating system today.

I used the latest version of DBD::Oracle 1.24, version 11.2.0.1.0 for 64bit Windows of Oracle’s
Instant Client Package – Basic along with the Instant Client Package – SQL*Plus and finally the Instant Client Package – SDK.

To get it to make and compile correctly I had to download Microsoft’s Visual Studio Ultimate

which should contain all the files you need. It is rather portly at 2+gb so you might want to grab lunch while you are downloading it.

After all the above downloading DBD::Oracle installed right out of the box.

All one has to do is select ‘Start Menu->All Programs->Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio x64 Win64 Command Prompt (2010)’
which will open a good old ‘dos’ window.

At this point CD to the directory where you downloaded DBD::Oracle

     c:\DBD-Oracle

then set your ‘ORACLE_HOME to the Instant Client directory

     c:\DBD-Oracle set ORACLE_HOME=c:\IC_11

you should also set your NLS like this

     c:\DBD-Oracle set NLS_LANG=.WE8ISO8859P15

Once the above setting are done do a

     c:\DBD-Oracle perl Makefile.PL

and then a

     c:\DBD-Oracle nmake install

Which will produce a whole of warnings (these you can ignore, as they do not seem to effect DBD::Oracle at all) and near the end it should output something like this;

     Generating code
     Finished generating code
     if exist blib\arch\auto\DBD\Oracle\Oracle.dll.manifest mt -nologo -manifest blib\arch\auto\DBD\Oracle\Oracle.dll.manifest -outputresource:blib\arch\auto
\DBD\Oracle\Oracle.dll;2
     if exist blib\arch\auto\DBD\Oracle\Oracle.dll.manifest del blib\arch\auto\DBD\Oracle\Oracle.dll.manifest
     C:\Perl64\bin\perl.exe -MExtUtils::Command -e "chmod" -- 755 blib\arch\auto\DBD\Oracle\Oracle.dll
     C:\Perl64\bin\perl.exe -MExtUtils::Command -e "cp" -- Oracle.bs blib\arch\auto\DBD\Oracle\Oracle.bs
     C:\Perl64\bin\perl.exe -MExtUtils::Command -e "chmod" -- 644 blib\arch\auto\DBD\Oracle\Oracle.bs
     C:\Perl64\bin\perl.exe "-Iblib\arch" "-Iblib\lib" ora_explain.PL ora_explain
Extracted ora_explain from ora_explain.PL with variable substitutions.
     C:\Perl64\bin\perl.exe -MExtUtils::Command -e "cp" -- ora_explain blib\script\ora_explain
        pl2bat.bat blib\script\ora_explain

At this point you are all done.

Well almost.

It is important that you test your code before you install but you will have to set a few things up first to get it to fully test correctly.

You will need a TNSNAMES.ORA file that points to a valid DB in the Instant Client Directory

Next you will need to set the ORACLE_USER_ID to a valid user

     c:\DBD-Oracle set ORACLE_USER_ID=system/system@XE

You will have to set up TNS_ADMIN to point to the Instant Client Directory

     c:\DBD-Oracle set TNS_ADMIN=c:\IC_11

Most importantly you will have to add the Instant Client directory to your path like this

     c:\DBD-Oracle path = c:\IC_11;%path%

If you do not do this step you will run into the dreaded

Can’t load ‘C:/Perl/lib/auto/DBD/Oracle/Oracle.dll’ for module DBD::Oracle: load_file:%1 is not a valid Win32 application at C:/Perl/lib/DynaLoader.pm line 202.

Error later on after the compile when you try to use DBD::Oracle.

What is actually going on is that Perl cannot find oci.dll (or one of the other .dlls it needs to run) the

C:/Perl/lib/auto/DBD/Oracle/Oracle.dll’ and the DynaLoader error

is just a false trail as perl is very limited in what it Windows errors it can report on. For more complet info on this sort of error check out this page;

Oracle Troubleshooter HOWTO

by Alexander Foken. It is rather dated but the facts of why perl did not find a dll are still valid.

now you can do this

     c:\DBD-Oracle nmake test

and all the tests should run and it will report.

Finally simply do a

     c:\DBD-Oracle nmake install

and you are all set.

That is about it.

At this point you might want to add the Instant Client directory permanently to your path so you will not run into the Dynaloader error again.

As well you do not need to keep Visual Studio around to use DBD::Oracle so you can uninstall that as well.

The “Beer” version of DBD::Oracle (1.24) has been released. You can find it at CPAN DBD::Oracle.

DBD::Oracle is a Perl module that works with the DBI module to provide access to Oracle databases. It is maintained by me, John Scoles, under the auspices of Pythian as Open Source/Free Software.

This is largely a maintenance release that fixes a number of bugs. New stuff includes some more improvements to embedded types from Charles Jardine.

Timestamps in Embedded Object now use precision to 6 places.

The big enhancement this round is extending the code to allow more than one row to be returned with a single fetch. Those of you who use Rowcache size will now find that your queries will run much faster.

I have also added the ora_ncs_buff_mtpl parameter, so you can now have very fine grain control over the size of the data buffer using for NCHAR conversions of lobs.

One more little note — thanks to my mistake in compressing a file last week, the version number on CPAN is 1.24a, while the internal Version is still 1.24.

Here is the complete change list: Read the rest of this entry . . .

I finally had the opportunity the other day to try and install DBD::Oracle on an IBM AIX 5.1 box, and for once I have some good news to tell.

Anyone who has ever tried this will know of some of the troubles I speak of. When dealing with DBI and any DBD on a AIX box, you either must either be lucky enough to have the same compiler installed that built the version of Perl that comes with the box (I have never seen this happen); or you have to spend a great deal of time downloading and installing your own GCC and the building your own version of Perl.

Fortunately, all the hard work was done for me by other members of my team, and I was only a Johnny-come-lately to the whole process.

In our case, these are the steps that we followed:

1. get a working version of GCC on the box
2. rebuild and install your own version of Perl
3. build and install DBI using your local version of Perl

All of the above worked without a major problem. It was only when we tried to build DBD::Oracle that we ran into a problem:

Read the rest of this entry . . .

Thanks to a patch from Tomas Pokorny, you can now select Oracle user-defined types directly into a Perl object.

User-defined types include Object, Varray, and Table. These have been around in Oracle since 8i but have never really gained any sort of popularity for any number or reasons. The most common reason I have heard from DBAs and modelers is that they break relational integrity. As the objects in Oracle are “Embedded,” I do not see how that is possible. The more practical reason is that the SQL to retrieve and query this sort of object tends to be rather involved, and is sometimes slower than a simple table join; also, this sort of object can be hidden or unavailable to many kinds of modeling software.

With the new functionality of DBD::Oracle, selects of these objects are simple to work with in Perl. Lets take the example below for a web site that has a number of different “user” types. Read the rest of this entry . . .