DBD::Oracle gotcha

when only the 'best' will do, ie. Oracle & Solaris: you have install the Perl DBD::Oracle module but whenever you try to load it (or run 'make test' etc) libnnz10.so is not found.

Go and check Oracle.so - this is the library created by the DBD::Oracle compile:

ldd -s Oracle.so | grep libnnz

This is one of the Oracle libs that was installed with instant client - in the location that should be your Oracle Home. You will see from the ldd output that it's expected to be found somewhere like /usr/lib. So even though you've defined $ORACLE_HOME & $LD_LIBRARY_PATH - that's not where the shared lib is looking for a dependency.

just make a symlink:

ln -s $ORACLE_HOME/libnnz10.so /usr/lib/libnnz10.so - or whatever the paths that will make it visible to the Oracle.so.

Oracle client-only on unix systems

I've seen DBAs grab & run the full Oracle installer on *nix systems just to get the client components. This is unecessary.

Go to the Oracle download site for the client components coresponding to the database verison you want to access. Install basic libs, sdk (probably optional) & sqlplus off the web.

* say you have installed all this in /opt/instantclient
then:
* set an ORACLE_HOME environment variable to /opt/instantclient
* add ORACLE_HOME to your PATH
* add ORACLE_HOME to your LD_LIBRARY_PATH
* set ORACLE_SID to the name of the database you usually want to connect to...

add a .tnsnames.ora file to your home dotfiles (I still do not know how to specify a default system-wide tnsnames file on unix).

Now, when you (or a script running in your environment) execute SQLPLus, it can find it's libraries etc. Likewise things such as DBD::Oracle will also work.

You CAN also dispense with a tnsnames file completely for SQLPLus - specifying host, port & datasource explicitly but this is a very long command line & requires escaping brackets etc.

EDIT (Jan 2010) - there are some systems where you will NEVER be able to get sqlplus to work - even if you follow the installation instructions. I suspect that there are just broken library paths compiled into the oracle binary. The attitude on the forums is the same as you will meet when dealing with most oracle admins: it's your fault, check everything that you've already checked etc. it's a problem with your OS, blah.

Such is the lot of the middleware guy. I'm just glad I won't have to do this shit for much longer...

Perl - read a bunch of files

# read in a directory trying to ignore non-image files

#!/usr/bin/perl

use Image::Magick;

my $image = Image::Magick->new;
$image->Set(bordercolor=>'#FFFFFF');

# args to the script:
my $argc = $#ARGV+1;

my @imageFilenames, my $target;
my @imageInfo;
my $inPath = $ARGV[0] . '/';
my $outPath = $ARGV[1] . '/';

opendir DIR, $inPath or die "cannot access $path\n";
@imageFilenames = grep{$_ ne '.' && $_ ne '..'} readdir DIR;
closedir DIR;

# process all the filenames
my $j = 0;
foreach $imageFilename (@imageFilenames) {
$target = join("", ($inPath, $imageFilename));
# test if the file returns width in pixels at least 1 - meaning that
# imagemagick can truly read it
@imageInfo=$image->ping($target);
if($imageInfo[1]<1) {
next; # ie. skip this iteration
}
status =" $image-">Read($target);
warn "error reading: $status\n" if $status;
print "reading $target\n";
}

undef $image;
exit;

maxim #1

don't tell me it's mission critical. Just tell me what you want me to do.

comment #1

...you're not deep, you're just an ass