DBD::Oracle::Troubleshooting - Tips and Hints to Troubleshoot DBD::Oracle
If you are reading this it is assumed that you have successfully installed DBD::Oracle and you are having some problems connecting to Oracle.
First off you will have to tell DBD::Oracle where the binaries reside for the Oracle client it was compiled against. This is the case when you encounter a
DBI connect('','system',...) failed: ERROR OCIEnvNlsCreate.
error in Linux or in Windows when you get
OCI.DLL not found
The solution to this problem in the case of Linux is to ensure your 'ORACLE_HOME' (or LD_LIBRARY_PATH for InstantClient) environment variable points to the correct directory.
For Windows the solution is to add this value to you PATH
If you get past this stage and get a
ORA-12154: TNS:could not resolve the connect identifier specified
error then the most likely cause is DBD::ORACLE cannot find your .ORA (TNSNAMES.ORA, LISTENER.ORA, SQLNET.ORA) files. This can be solved by setting the TNS_ADMIN environment variable to the directory where these files can be found.
If you get to this stage and you have either one of the following errors;
ORA-12560: TNS:protocol adapter error ORA-12162: TNS:net service name is incorrectly specified
usually means that DBD::Oracle can find the listener but the it cannot connect to the DB because the listener cannot find the DB you asked for.
If you are still having problems connecting then the Oracle adapters utility may offer some help. Run these two commands:
$ORACLE_HOME/bin/adapters $ORACLE_HOME/bin/adapters $ORACLE_HOME/bin/sqlplus
and check the output. The "Protocol Adapters" should include at least "IPC Protocol Adapter" and "TCP/IP Protocol Adapter".
If it generates any errors which look relevant then please talk to your Oracle technical support (and not the dbi-users mailing list).
If you are using a bequeather to connect to a server on the same host as the client, you might have to add
bequeath_detach = yes
to your sqlnet.ora file or you won't be able to safely use fork/system functions in Perl.
See the discussion at http://www.nntp.perl.org/group/perl.dbi.dev/2012/02/msg6837.html and http://www.nntp.perl.org/group/perl.dbi.users/2009/06/msg34023.html for more gory details.
Some examples related to the use of LONG types are available in the
examples/ directory of the distribution.
libclntsh.so is the shared library composed of all the other Oracle libs you used to have to statically link. libclntsh.so should be in $ORACLE_HOME/lib. If it's missing, try running $ORACLE_HOME/lib/genclntsh.sh and it should create it.
Never copy libclntsh.so to a different machine or Oracle version. If DBD::Oracle was built on a machine with a different path to libclntsh.so then you'll need to set set an environment variable, typically LD_LIBRARY_PATH, to include the directory containing libclntsh.so.
LD_LIBRARY_PATH is typically ignored if the script is running set-uid (which is common in some httpd/CGI configurations). In this case either rebuild with LD_RUN_PATH set to include the path to libclntsh or create a symbolic link so that libclntsh is available via the same path as it was when the module was built. (On Solaris the command "ldd -s Oracle.so" can be used to see how the linker is searching for it.)
See RT 72989 (https://rt.cpan.org/Ticket/Display.html?id=72989)
Apache2 MPM Prefork with mod_perl2 will crash if Module::Runtime is loaded, and an Oracle connection is opened through PerlRequire (before forking).
It looks like this was fixed in 0.012 of Module::Runtime.
See RT 71819 (https://rt.cpan.org/Ticket/Display.html?id=71819)
It seems that in some older versions of Oracle Instant Client (certainly 10.2.0.4.0) when output parameters are bound with lengths greater than 3584 the output parameters can be returned in the wrong placeholders.
It is reported fixed in Instant Client 184.108.40.206.0.
This software is copyright (c) 1994 by Tim Bunce.