KevinSchoenmayer/GseTDDUebungKCLR
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial Commit

Browse Source
This commit is contained in:
Riley Schneider
2025-12-03 16:38:10 +01:00
parent c5e26bf594
commit b732d8d4b5
17680 changed files with 5977495 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

291
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Aix.pod vendored Normal file
View File

@@ -0,0 +1,291 @@
#PODNAME: DBD::Oracle::Troubleshooting::Aix
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on AIX
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Aix - Tips and Hints to Troubleshoot DBD::Oracle on AIX
=head1 VERSION
version 1.80
=head1 Using Visual Age 7 C Compiler
Oracle 9i is only certified as a 64-bit application on AIX 5L (5.1,5.2,5.3) with 32-bit support;
in other words, there is no 9i "32-bit" Oracle client
Oracle 10g is certified as both a 64-bit application and a 32-bit Oracle client
This information only pertains to deploying:
the DBI (version 1.48)
and DBD-Oracle (version 1.16):
on AIX 5.3
using Oracle 9i (9.2.0.1/9.2.0.5)
using the existing Perl 5.8.2 (no custom-built Perl) which is 32-bit
using Visual Age 7.0 C/C++ compiler
Install the DBI (required for the DBD-Oracle install - no issues here)
Untar the DBD-Oracle bundle
Run Makefile.PL
$ perl Makefile.PL
Edit Makefile with following commands:
1,$s?/lib/ ?/lib32/ ?g
1,$s?-q64??g
1,$s?/lib/sysliblist?/lib32/sysliblist?g
Now perform normal commands to perform the testing/making:
$ make
$ make test
$ make install
I've tested the basics of the DBD-Oracle and it seems fully functional.
Stephen de Vries
=head1 Using gcc C Compiler
DBD::Oracle with gcc and Oracle Instant Client on AIX
--------------------------------------------------------------------------------------
Nathan Vonnahme Dec 15 2005, 4:28 pm Newsgroups: perl.dbi.users
See: http://groups.google.com/group/perl.dbi.users/msg/0bd9097f80f2c8a9
[ with updates 1/31/2006 - DBD::Oracle 1.17 doesn't need makefile hacking
to work with instantclient on AIX ]
Yes! It eluded me last year but I finally got DBD::Oracle working on an
AIX machine using gcc. Here's the short version:
First I had to recompile perl with gcc, using
sh Configure -de -Dcc=gcc
This apparently built a 32 bit perl, someday I will try getting it to go
64 bit.
I was then able to install and build DBI 1.50 with the CPAN shell.
I downloaded the base and sdk packages of the Oracle Instant Client for
AIX -- first I tried the 64 bit but that didn't work with my 32 bit perl
-- the 32 bit version (still at 10.1.0.3) did the trick. I unzipped
them and moved the dir to /usr/local/oracle/instantclient10_1 and made a
symlink without the version at /usr/local/oracle/instantclient , then
set:
export ORACLE_HOME=/usr/local/oracle/instantclient
export LIBPATH=$ORACLE_HOME
Oracle wasn't providing the sqlplus package for 32 bit AIX so I
explicitly told Makefile.PL the version:
perl Makefile.PL -V 10.1
make
My test databases were on other machines so I set these environment variables
to get the tests to run:
export ORACLE_DSN=DBI:Oracle://host/dbinstance
export ORACLE_USERID="user/password"
make test
make install
NOTE: I have an older full version of Oracle on this machine, and the
ORACLE_HOME environment variable is normally set to point to that, so
my perl scripts that use DBD::Oracle have to make sure to first set
$ENV{ORACLE_HOME}='/usr/local/oracle/instantclient';
--------------------------------------------------------------------------------------
The following setup worked to build on AIX 5.2:
gcc-3.3.2 (32-bit) (configure opts [ --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as])
Oracle-9.2.0 ( full install w/32bit support)
perl-5.8.3 (built with above gcc/latest stable as of March 2004)
Followed the directions from Rafael's email below, only set ORACLE_HOME, (and
the appropriate test environmentals).
1) build perl-5.8.3 with gcc
2) install DBI
3) ORACLE_HOME="your oracle home"
ORACLE_USERID..
ORACLE_SID ..
(I ignored ORACCENV, didn't use it.)
4) install DBD::Oracle, after perl Makefile.PL, edit the created Makefile,
changing references to Oracle's ../lib to ../lib32. and change crt0_64.o to
crt0_r.o. Remove the -q32 and/or -q64 options from the list of libraries to
link with.
5) make should be clean, make test should pass.
This setup worked with 8.1.7 w/32 bit support, and with 9.2.0 w/ 32-bit support.
--Adrian Terranova
=head1 Using xlc_r C Compiler
From: Rafael Caceres
Date: 22 Jul 2003 10:05:20 -0500
The following sequence worked for me on AIX 5.1:
-use Perl 5.8.0 (the latest stable from CPAN)
-use the xlc_r version of IBM's compiler and build a 32 bit Perl
(which xlc_r will do by default). All tests should be successful.
-get and install DBI
-get DBD::Oracle. Edit the Makefile.PL or Makefile for DBD::Oracle,
changing references to Oracle's ../lib to ../lib32. and change crt0_64.o
to crt0_r.o. Remove the -q32 and/or -q64 options from the list of
libraries to link with. Do the make and make test.
-Set up the environment for making DBD::Oracle:
ORACLE_HOME="your oracle home"
ORACCENV = "xlc_r"
ORACLE_USERID..
ORACLE_SID ..
-Run make, all tests should be successful -against Oracle 9.x at least.
You should have no problems with Oracle 8.1.7, but accessing Oracle 7.x
or previous is not possible (you'll core dump, or simply hang). The same
goes for a Linux build or a Digital build, regarding access of different
Oracle versions.
Rafael Caceres
> I don't believe I compiled Oracle. During the installation it was linked
> but I am not sure it was compiled
>
> I used a xlc compiler to compile PERL.
> Got this message in the Perl Makefile.PL output
>
> Warning: You will may need to rebuild perl using the xlc_r compiler.
> You may also need do: ORACCENV='cc=xlc_r'; export ORACCENV
> Also see the README about the -p option
>
> this probably means I need to rebuild PERL with xlc_r??
>
> thanx
>
> Mike Paladino
> Database Administrator
From: Rafael Caceres
>
> Make sure you use the same compiler to build Oracle and Perl. We have
> used xlc_r on Aix 5.1 with no problems. Your Perl build is 32 bit, so
> when building DBD::Oracle, you should use the 32bit libraries (change
> references to .../oracle/lib to .../oracle/lib32 in your Makefile).
> Remove the references to the -q64 or -q32 parameters for ld in Makefile,
> as they shouldn't be there.
>
> Rafael Caceres
From: "cartman ltd"
Subject: Tip for DBI and DBD::Oracle on AIX 5.1 and Oracle 9.2
Date: Mon, 11 Aug 2003 18:15:38 +0000
Message-ID: <BAY1-F58Temqpg2ItZe00032a0f@hotmail.com>
Here is a tip for compiling DBD::Oracle as a 32 bit application on AIX 5.1
64 bit and Oracle 9.2 64 bit without editing any makefiles. I hope people
find this useful:
First, the versions of products I used:
DBI version 1.32
DBD::Oracle version 1.14
Oracle 9.2.0.2 - default 64 bit application with 32 bit libraries
AIX 5.1 ML03 - 64 bit kernel - ships with Perl as a 32 bit application.
VisualAge C/C++ 5.0.2
Basically DBD must be compiled as 32 bit to link with Perl's 32 bit
libraries.
gunzip -c DBD-Oracle-1.14.tar.gz | tar xvf 
cd DBD-Oracle-1.14
perl Makefile.PL -m $ORACLE_HOME/rdbms/demo/demo_rdbms32.mk
make
NB: I think there is a bug in the Oracle 9.2.0.3 file
$ORACLE_HOME/rdbms/lib/env_rdbms.mk
I corrected this (before running the above commands) by replacing the
invalid linker option
LDFLAGS32=-q32
with
LDFLAGS32=-b32
Have fun: KC.
--------------------------------------------------------------------------------------
Date: Wed, 30 Jun 2004 23:34:24 -0500
From: "SCHULTZ, DARYLE (SBCSI)"
Got it to work. Using dbd 1.16
Perl 5.8.4 built like this, with Visual Age 6.0:
config_args='-Dcc=xlc_r -Dusenm -Dprefix=/appl/datasync/work/perl5
-Dusethreads -Duse64bitall -des'
==============================================
Used DBI 1.42
=============================================
Added this to top of Oracle.h:
#define A_OSF
#include <oratypes.h>
=======================
Set LIBPATH to point to 64bit Oracle libs first.
export LIBPATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32:/usr/lib
Use: perl Makefile.PL -nob
Change all references in Makefile of LD_RUN_PATH to be LIBPATH.
Change nothing else, left all flags in Makefile, including -q64.
Passed make, and all tests.
--------------------------------------------------------------------------------------
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

112
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Cygwin.pod vendored Normal file
View File

@@ -0,0 +1,112 @@
#PODNAME: DBD::Oracle::Troubleshooting::Cygwin
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Cygwin
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Cygwin - Tips and Hints to Troubleshoot DBD::Oracle on Cygwin
=head1 VERSION
version 1.80
=head1 General Info
Makefile.PL should find and make use of OCI include
files, but you have to build an import library for
OCI.DLL and put it somewhere in library search path.
one of the possible ways to do this is issuing command
dlltool --input-def oci.def --output-lib liboci.a
in the directory where you unpacked DBD::Oracle distribution
archive. this will create import library for Oracle 8.0.4.
Note: make clean removes '*.a' files, so put a copy in a safe place.
=head1 Compiling DBD::Oracle using the Oracle Instant Client, Cygwin Perl and gcc
=over
=item 1
Download these two packages from Oracle's Instant Client for
Windows site
(http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winsoft.html):
Instant Client Package - Basic: All files required to run OCI,
OCCI, and JDBC-OCI applications
Instant Client Package - SDK: Additional header files and an
example makefile for developing Oracle applications with Instant Client
(I usually just use the latest version of the client)
=item 2
Unpack both into C:\oracle\instantclient_11_1
=item 3
Download and unpack DBD::Oracle from CPAN to some place with no
spaces in the path (I used /tmp/DBD-Oracle) and cd to it.
=item 4
Set up some environment variables (it didn't work until I got the
DSN right):
ORACLE_DSN=DBI:Oracle:host=oraclehost;sid=oracledb1
ORACLE_USERID=username/password
=item 5
perl Makefile.PL
make
make test
make install
=back
Note, the TNS Names stuff doesn't always seem to work with the instant
client so Perl scripts need to explicitly use host/sid in the DSN, like
this:
my $dbh = DBI->connect('dbi:Oracle:host=oraclehost;sid=oracledb1',
'username', 'password');
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

954
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Hpux.pod vendored Normal file
View File

@@ -0,0 +1,954 @@
#PODNAME: DBD::Oracle::Troubleshooting::Hpux
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on HP-UX
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Hpux - Tips and Hints to Troubleshoot DBD::Oracle on HP-UX
=head1 VERSION
version 1.80
=head1 INTRODUCTION
Building a working dynamically linked version of the Oracle DBD driver
on HP-UX (11.00) has been a challenge for many. For months after taking
a new job, where HP-UX was the standard database server environment, I
had only been able to build a statically linked version of Perl and the
DBD-Oracle module on HP-UX 11.00.
Then Roger Foskett posted instructions for what turned out to be dynamic
build. Rogers's post got me further than I had previously gotten. In
fact, after resolving some undefined symbol errors, I succeeded where for
I had previously despaired of finding the time to hack out the right
incantation.
This document describes the combined knowledge of a number of
folks who invested many hours discovering a working set of build options.
The instructions in this file, which include building Perl from source,
will produce a working dynamically linked DBD-Oracle that can be used
with mod_perl and Apache.
See L<APPENDICES> for exact build configurations used by me an others.
For HPUX 11 on Itanium see also
http://www.nntp.perl.org/group/perl.dbi.users/23840
=head1 First things First: Introduction
The reason you are even reading this file is because you want to connect
to an Oracle database from your perl program using the DBD::Oracle DBI
driver. So before you start, install (at least the Oracle client
software) (SQL*Net, Pro*C, SQL*Plus) upon the machine you intend to
install Perl/DBI/DBD-Oracle. You B<do not>, I repeat, I<do not> need to
build a database on this machine.
After you have installed the Oracle client software, B<test it!>. Make
sure you can connect to the target database using SQL*Plus (or any other
Oracle supplied tool). The (gory) details of the install are beyond the
scope of this document, some information can be found in the section
L<Compiling on a Client Machine>, or see your friendly Oracle DBA.
One final remark, 3 years after this was first written. This has been
updated numerous times over the years. And some of the new build
recipe's see simpler than some of the original instructions in this file.
I think one reason the recipe is getting simpler may be that the build
hints, in the base perl build have gotten more right, as we have moved
from perl 5.6.1 to the 5.8.8 (now the stable version).
Someday, if I ever find myself building on HP again I should probably
update as many of these recipes (that I can test) by trying to remove
more of the special case stuff I have in my build scripts now.
Gram Ludlows's build for the default bundled C compiler shows that a lot
of this may no longer be necessary.
On the other hand, it would be bad if we deleted information that others
might need, so I err on the side of too much, in the hope that the
person who really needs the information, will not have to look beyond
this file.
-- Lincoln
=head1 Build your own Perl
HP's default Perl is no good (and antique).
By default, HP-UX 11.00 delivered Perl 5.00503 until September 2001.
Others tell me that the default is a threaded GNUpro build of 5.6.1.
This is not what I found on our systems, and it probably depends on which
packages you install. In any case, this version of Perl delivered by
HP will in all likelihood not work. Before you check, be sure to prevent
the perl4 located in /usr/contrib/bin from being the first Perl version
found in your $PATH.
As of application release September 2001, HP-UX 11.00 is shipped with
Perl-5.6.1 in /opt/perl. The first occurrence is on CD 5012-7954. The
build is a portable hppa-1.1 multithread build that supports large files
compiled with gcc-2.9-hppa-991112. When you have a modern system with a
hppa-2.0 architecture (PA8xxx processor) and/or the HP C-ANSI-C compiler
consider building your own Perl, which will surely outperform this
version.
If you are reading this, you have probably discovered that something did
not work. To get a working version of the DBD-Oracle driver, we have to
start with a Perl that as been built with the correct compiler flags and
shared libraries. This means that you must build your own version of
Perl from source.
The instructions below have been used for building a dynamically linked
working DBD-Oracle driver that works with mod_perl and Apache. These
instructions are based on Perl 5.6.0 and 5.6.1, and 5.8.0. To this
author's knowledge, they have not be tested on earlier versions of Perl.
Note that is important to build a B<non>-threaded Perl, but linked with
-lcl and -lpthread. Since Oracle on HP uses libpthread, everything that
dynamically loads it (such as DBD-Oracle) must be built/linked
with '-lpthread -lcl'. (When used with Apache, it and any associated
modules must also be built this way - otherwise all it does is core
dump when loading DBD::Oracle).
A good link that explains thread local storage problems is
http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0x0d0a6d96588ad4118fef0090279cd0f9!0,00.html
One more note, it would appear that the README.hpux in the Perl 5.8.0
directory, is somewhat out of date, but is up-to-date in versions 5.8.3
and up. H.Merijn Brand points out that Perl I<is> 64bit compliant when
the -Duse64bitall flag is used to Configure. While Perl will be built
in a pure LP64 environment via the +DD64 flag is used, the +DA2.0w flag
is preferred on PA-RISC, and when an incantation can be concocted that
eliminates the noisy warnings the produces at link time, this will
probably become the default. Older 64bit versions of GCC, are known to
be unable to build a good LP64 perl. And these flags will cause gcc to
barf. On HP-UX 11i (11.11), gcc-3.4.4 or gcc-3.4.5 is preferred over
gcc-4.0.2 (or older gcc-4 versions) as 64bit builds on PA-RISC with that
versions of the compiler are unreliable.
=head1 Compilers
=head2 HP Softbench Compiler
Both Roger Foskett, I and most others have been using the HP Softbench
C compiler normally installed in:
/opt/softbench/bin/cc.
While the DBD-Oracle F<Makefile.PL> checks for some of the conditions
which, when met, we know will produce a working build, there are many
variations of Oracle installations and features. Not all of these can
be tested by any one of us, if you discover a way to make a variation
which did not previously work, please submit patches to the Makefile.PL
to Tim Bunce, and patches to this README to me, and I will incorporate
them into the next README.
The instructions herein, have compiled, linked cleanly, and tested
cleanly using the HP softbench compiler, and Oracle 8.0.5 (32bit), and
Oracle 8.1.6, 8.1.7 (64 bit). Oracle 8.1.5 will probably work as well.
Oracle 8.1.7.4 (32bit) with DBI-1.35 and DBD-Oracle-1.13 has been proven
to work on HP-UX 11.00 (64bit) with Perl 5.6.1, Perl 5.8.x using the
guidelines in this document for both HP-C-ANSI-C and gcc-3.2. Later
versions have been proven to work as well. Current DBI-1.42 and
DBD-Oracle-1.16 have been proven to work. This Oracle 9.2 client (at
least) should be used if you plan to do work with Unicode. See the
DBD-Oracle POD/Man documentation.
=head2 gcc Compiler
As of gcc-3.4, perl-5.8.3 and up should build out-of-the box when
Configure is invoked with -Dcc=gcc. Please read README.hpux carefully
for the differences with HP C-ANSI-C. Once built, tested and installed,
both DBI and DBD-Oracle should be able to build against that perl
without trouble.
In the past, Waldemar Zurowski and Michael Schuh sent useful information
about builds of Perl with DBD-Oracle using gcc on HP-UX. Both were able
to get working executables, and their explanations shed much light on
the issues.
Waldemar's build is described in L<Appendix A>, and Michael's is
described in L<Appendix C>.
While I have not reproduced either of these configurations, I believe
the information is complete enough (particularly in the aggregate) to
be helpful to others who might wish to replicate it.
=head2 The "default" built in compiler 64bit build (/usr/bin/cc)
And now, at long last, we have a recipe for building perl and DBD-Oracle
using the default bundled C compiler. Please see the L<Appendix B> build
instructions provided by Gram Ludlow, using the default /usr/bin/cc
bundled compiler. Please note that perl itself will I<NOT> build using
that compiler.
=head2 Configure (doing it manually)
Once you have downloaded and unpacked the Perl sources (version 5.8.8
assumed here), you must configure Perl. For those of you new to building
Perl from source, the Configure program will ask you a series of
questions about how to build Perl. You may supply default answers to the
questions when you invoke the Configure program by command line flags.
We want to build a Perl that understands large files (over 2GB, which is
the default for building perl on HP-UX), and that is incompatible with
v5.005 Perl scripts (compiling with v5.005 compatibility causes mod_perl
to complain about malloc pollution). At the command prompt type:
cd perl-5.8.8
sh ./Configure -A prepend:libswanted='cl pthread ' -des
or, if you need a 64bit build
sh ./Configure -A prepend:libswanted='cl pthread ' -Duse64bitall -des
Do not forget the trailing space inside the single quotes. This is also
described by H.Merijn Brand in the README.hpux from the perl core
distribution.
When asked:
Any additional cc flags? - Answer by prepending: I<+Z> to enable
position independent code.
For example:
Any additional cc flags? [-D_HP-UX_SOURCE -Aa] -Ae +Z -z
Though this should be the default in more recent perl versions.
Lastly, and this is optional, when asked:
Do you want to install Perl as /usr/bin/perl? [y] n
You may or may not want to install directly in /usr/bin/perl,
many persons on HP install Perl in /opt/perl<version>/bin/perl and
put a symbolic link to /usr/bin/perl. Furthermore, you can supply
the answer to this question by adding an additional switch to the
invocation of Configure such as: Configure -Dprefix=/opt/perl
After you have answered the above questions, accept the default values
for all of the remaining questions. You may press <Enter> for each
remaining question, or you may enter "& -d" (good idea) at the next
question and the Configure will go into auto-pilot and use the Perl
supplied defaults.
BTW: If you add -lcl and -lpthread to the end of the list it will not
work. I wasted a day and a half trying to figure out why I had lost the
recipe, before I realized that this was the problem. The symptom will
be that
make test
of Perl itself will fail to load dynamic libraries.
You can check in the generated 'config.sh' that the options you selected
are correct. If not, modify config.sh and then re-run ./Configure with
the '-d' option to process the config.sh file.
Build & Install
make
make test
make install
If you are going to build mod_perl and Apache it has been suggested
that you modify Config.pm to the change the HP-UX ldflags & ccdlflags in
F</your/install/prefix/lib/5.6.0/PA-RISC2.0/Config.pm> as follows:
ccdlflags=''
cccdlflags='+Z'
ldflags=' -L/usr/local/lib'
This is not necessary if you are not using mod_perl and Apache.
=head1 Build and Install DBI
cd DBI-1.50
Perl Makefile.PL
make
make test
make install
=head1 Build and Install DBD-Oracle-1.07 and later
It is critical to setup your Oracle environmental variables. Many people
do this incorrectly and spend days trying to get a working version of
DBD-Oracle. Below are examples of a local database and a remote database
(i.e. the database is on a different machine than your Perl/DBI/DBD
installation) environmental variable setup.
Example (local database):
export ORACLE_USERID=<validuser/validpasswd>
export ORACLE_HOME=<path to oracle>
export ORACLE_SID=<a valid instance>
export SHLIB_PATH=$ORACLE_HOME/lib #for 32bit HP
export LD_LIBRARY_PATH=$ORACLE_HOME/lib #for 64bit HP (I defined them both)
Note that HP-UX supports I<both> SHLIB_PATH I<and> LD_LIBRARY_PATH for
all libraries that need to be found, but that each library itself can
enable or disable any of the two, and can also set preference for the
order they are used, so please set them to the same value.
Example (remote database):
export ORACLE_USERID=<validuser/validpasswd>
export ORACLE_HOME=<path to oracle>
export ORACLE_SID=@<valid tnsnames.ora entry>
export SHLIB_PATH=$ORACLE_HOME/lib #for 32bit HP
export LD_LIBRARY_PATH=$ORACLE_HOME/lib #for 64bit HP (I defined them both)
The standard mantra now works out of the box on HP-UX:
cd DBD-Oracle-1.07 # or more recent version
perl Makefile.PL
make
make test
make install # if all went smoothly
And with DBD-1.14 and later the following can be used:
cd DBD-Oracle-1.14 # or more recent version
perl Makefile.PL -l # uses a simple link to oracle's main library
make
make test
make install # if all went smoothly
If you have trouble, see the L<Trouble Shooting> instructions below, for
hints of what might be wrong... and send me a note, describing your
configuration, and what you did to fix it.
=head1 Trouble Shooting
=head2 "Unresolved symbol"
In general, find the symbols, edit the Makefile, and make test.
You'll have to modify the recipe accordingly, in my case the symbol
"LhtStrCreate" was unresolved. (Authors Note: thanks patch suggestions
by Jay Strauss this situation which occurs with Oracle 8.1.6 should
now be handled in Makefile.PL.)
1) Find the symbols.
a) The following ksh/bash code (courtesy of Roger) will search
from $ORACLE_HOME and below for Symbols in files in lib directories.
Save the following to a file called "findSymbol".
>>>> CUT HERE <<<<<
cd $ORACLE_HOME
echo "\nThis takes a while, grepping a lot of stuff"
echo " ignore the \"no symbols\" warnings\n"
sym=$1; shift;
libs="*.sl"
for lib in $(find . -name $libs -print); do
if nm -p $lib | grep -q $sym; then
echo "found \"$sym\" in $lib"
fi
done
>>>>> CUT HERE <<<<
Note that on Itanium machines (HP-UX 11.23), the shared libraries
have a .so extension instead of the .sl HP-UX uses on PA-RISC.
b) Run it (replace "LhtStrCreate" with your "Unresolved symbol").
For example, at my installation, findSymbols produced the
following output:
# chmod 755 findSymbols
# ./findSymbol LhtStrCreate
found "LhtStrCreate" in ./lib/libagtsh.sl
found "LhtStrCreate" in ./lib/libclntsh.sl
found "LhtStrCreate" in ./lib/libwtc8.sl
2) Edit the Makefile
In the previous step your unresolved symbol was found in one or more
library files. You will need to edit the OTHERLDFLAGS makefile macro,
and add the missing libraries.
When you add those library files to OTHERLDFLAGS you must convert the
name from the actual name to the notation that OTHERLDFLAGS uses.
libclntsh.sl becomes => -lclntsh
libagtsh.sl becomes => -lagtsh
libwtc8.sl becomes => -lwtc8
That is, you replace the "lib" in the name to "-l" and remove the ".sl"
(or the .so).
You can edit the Makefile in 2 ways:
a) Do this:
perl -pi -e's/\b(OTHERLDFLAGS.*$)/$1 -lclntsh/' Makefile
b) Using vi, emacs... edit the file, find OTHERLDFLAGS, and add the
above "-l" entries to the end of the line.
For example the line:
OTHERLDFLAGS = -L/opt/oracle/product/8.1.6/lib/... -lqsmashr
Becomes:
OTHERLDFLAGS = -L/opt/oracle/product/8.1.6/lib/... -lqsmashr -lclntsh
3) make test
Perform a make test, if symbols are still unresolved repeat the editing
of the Makefile and make test again.
=head1 DBD-Oracle-1.06
You are strongly urged to upgrade. However here is what you may need to
know to get it or work, if you insist on using an earlier version.
Check the output that above command produces, to verify that
-Wl,+n
-W1,+s
is b<NOT> present. and that
-lqsmashr
B<is> present.
If the version of Makefile.PL does not include the patch produced at the
time of this document, then the above conditions will likely not be
met.
You can fix this as follows:
perl -pi -e's/-Wl,\+[sn]//' Makefile
=head1 Building on a Oracle Client Machine
If you need to build or deliver the DBD-Oracle interface on or to a
machine upon which the Oracle database has not been installed you need
take the following into consideration:
=over
=item 1) Oracle files are needed for DBD::Oracle to compile
=item 2) Oracle files are needed for the compiled DBD to connect
=item 3) ORACLE_HOME environment variable must be set
=item 4) SHLIB_PATH environment variable must be set
=back
=head2 Compiling on a Client Machine
This may seem obvious to some, but the Oracle software has to be present
to compile and run DBD-Oracle. The best way to compile and install on a
client machine, is to use the oracle installer to install the oracle
(client) software locally. Install SQL*Net, Pro*C and SQL*Plus. After
this some tests with SQL*Net (tnsping at a minimum) are an good idea.
Make sure you can connect to your remote database, and everything works
with Oracle before you start bashing your head into the wall trying to
get DBD-Oracle to work.
If you do not have the Oracle installer handy, the following hack has
been known to work:
Either open an NFS share from the oracle installation directory on the
machine that has Oracle and point both of the above-mentioned env vars to
that share, or alternatively copy the following four directories from your
Oracle installation over to the machine on which you are compiling the DBD:
drwxr-xr-x 3 oracle dba 3072 Jul 3 09:36 lib
drwxr-xr-x 13 oracle dba 512 Jul 3 09:38 network
drwxr-xr-x 7 oracle dba 512 Jul 2 19:25 plsql
drwxr-xr-x 12 oracle dba 512 Jul 3 09:38 rdbms
then point the above-mentioned env vars to the containing directory (good
place to put them, if copying locally, might be /usr/lib/oracle,
/usr/local/lib/oracle, or /opt/oracle/lib )
In any case, the compiler needs to be able to find files in the above
four directories from Oracle in order to get all the source code needed
to compile properly.
=head2 Required Runtime environment
Again, use the Oracle installer to install the Oracle Client on the
machine where your scripts will be running. If the Oracle installer is
not available, the following hack should suffice:
For running the compiled DBD in Perl and connecting, you need only the
files in the 'lib' folder mentioned above, either connecting to them
through an NFS share on the Oracle machine, or having copied them
directly onto the local machine, say, in /usr/lib/oracle . Make sure the
env variable for ORACLE_HOME = /usr/lib/oracle and LD_LIBRARY_PATH
includes /usr/lib/oracle . You can set the env var in your perl script
by typing
$ENV{ORACLE_HOME} = '/usr/lib/oracle';
=head1 Apache and mod_perl
B<Nota Bene:> these instructions are now more than a year and a half old,
you may have to tinker.
If you are not building this version of Perl for Apache you can go on to
build what ever other modules you require. The following instructions
describe how these modules were built with the Perl/DBD-Oracle built
above: The following is what worked for Roger Foskett:
=head1 Apache Web server
cd apache_1.3.14/
LDFLAGS_SHLIB_EXPORT="" \
LDFLAGS="-lm -lpthread -lcl" \
CC=/usr/bin/cc \
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
--prefix=/opt/www/apache \
--enable-shared=max \
--disable-rule=EXPAT \
--enable-module=info \
--enable-rule=SHARED_CORE
The Expat XML parser is disabled as it conflicts with the Perl XML-Parser
module causing core dumps. -lcl is needed to ensure that Apache does not
coredump complaining about thread local storage
make
make install
Once installed, ensure that the generated httpd.conf is properly
configured, change the relevant lines to below (the default user/group
caused problems on HP (the user 'www' may need to be created)
User www
Group other
port 80
=head2 mod_perl
cd mod_perl-1.24_01/
perl Makefile.PL \
NO_HTTPD=1 \
USE_APXS=1 \
WITH_APXS=/opt/www/apache/bin/apxs \
EVERYTHING=1
make
make install
=head2 htdig intranet search engine
cd htdig-3.1.5/
CC='cc' CPP='aCC' \
./configure \
--prefix=/opt/www/htdig \
--with-cgi-bin-dir=/opt/www/htdig/cgi-bin \
--with-image-dir=/opt/www/htdig/images
=head1 CONTRIBUTORS
The following folks contributed to this document:
Lincoln A. Baxter <lab@lincolnbaxter.com.Fix.This>
H.Merijn Brand <h.m.brand@xs4all.nl>
Jay Strauss <me@heyjay.com.Fix.This>
Roger Foskett <Roger.Foskett@icl.com.Fix.This>
Weiguo Sun <wesun@cisco.com.Fix.This>
Tony Foiani <anthony_foiani@non.hp.com.Fix.This>
Hugh J. Hitchcock <hugh@hitchco.com.Fix.This>
Heiko Herms <Heiko.Herms.extern@HypoVereinsbank.de.Fix.This>
Waldemar Zurowski <bilbek0@poczta.onet.pl.Fix.This>
Michael Schuh <Michael.Schuh@airborne.com.Fix.This>
Gram M. Ludlow <LUDLOW_GRAM_M@cat.com.Fix.This>
And probably others unknown to me.
=head1 AUTHOR
Lincoln A. Baxter <lab@lincolnbaxter.com.Fix.This>
H.Merijn Brand <h.m.brand@xs4all.nl>
=head1 APPENDICES
=head2 Appendix A
(gcc build info from Waldemar Zurowski)
This is pretty much verbatim the build information I received from
Waldemar Zurowski on building Perl and DBD-Oracle using gcc on HP. Note
that this build was on a PA-RISC1.1 machine.
=head3 Host
HP-UX hostname B.11.11 U 9000/800 XXXXXXXXX unlimited-user license
=head3 Oracle
Oracle 8.1.7
=head3 Parameters to build Perl
./Configure -des -Uinstallusrbinperl -Uusethreads -Uuseithreads
-Duselargefiles -Dcc=gcc -Darchname=PA-RISC1.1 -Dprefix=/opt/perl-non-thread
-Dlibs='-lcl -lpthread -L${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads
-ljava -lnsl -lnm -lndbm -ldld -lm -lc -lndir -lcrypt -lsec'
-L${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads -ljava, was added
because DBD::Oracle wants to link with it (probably due to Oracle's own
build rules picked up by Makefile.PL)
Set environment variable LDOPTS to '+s' (see ld(1)). This holds extra
parameters to HP-UX's ld command, as I don't use GNU ld (does anybody?).
This allows you to build an executable, which when run would search for
dynamic linked libraries using SHLIB_PATH (for 32-bit executable) and
LD_LIBRARY_PATH (for 64-bit executable). Obviously LDOPTS is needed only
when building Perl _and_ DBI + DBD::Oracle.
Then, after building Perl + DBI + DBD::Oracle and moving it into
production environment it was enough to add to SHLIB_PATH
${ORACLE_HOME}/lib and ${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads,
for example:
SHLIB_PATH=${ORACLE_HOME}/lib:${ORACLE_HOME}/JRE/lib/PA_RISC/native_threads:
$SHLIB_PATH
Please note output of ldd command:
$ ldd -s ./perl
[...]
find library=/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl;
required by ./perl
search path=/home/ora817/lib:/home/ora817/JRE/lib/PA_RISC/native_threads
(SHLIB_PATH)
trying path=/home/ora817/lib/libjava.sl
trying path=/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl
/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl =>
/home/ora817/JRE/lib/PA_RISC/native_threads/libjava.sl
[...]
All of this mess is necessary because of weakness of shl_load(3X),
explained in this document and in some discussion forums at HP.com
site. I have learned, that HP issued patch PHSS_24304 for HP-UX 11.11
and PHSS_24303 for HP-UX 11.00, which introduced variable LD_PRELOAD.
I haven't tried it yet, but it seems promising that it would allow you
to completely avoid building your own Perl binary, as it would be enough
to set LD_PRELOAD to libjava.sl (for example) and all
'Cannot load XXXlibrary' during building of DBD::Oracle should be gone.
The documentation says, that setting this variable should have the same
effect as linking binary with this library. Also please note, that this
variable is used only when binary is not setuid nor setgid binary (for
obvious security reasons).
It seems, that the best way to find out if you already have this patch
applied, is to check if 'man 5 dld.sl' says anything about LD_PRELOAD
environment variable.
Best regards,
Waldemar Zurowski
Authors Note: Search for references to LD_PRELOAD else where in this
document. Using LD_PRELOAD is probably a fragile solution at best.
Better to do what Waldemar actually did, which is to include libjava in
the extra link options.
=head2 Appendix B
(64 bit build with /usr/bin/cc -- bundled C compiler)
Gram M. Ludlow writes:
I recently had a problem with Oracle 9 64-bit on HPUX 11i. We have
another application that required SH_LIBRARY_PATH to point to the 64-bit
libraries, which "broke" the Oraperl module. So I did some research and
successfully recompiled and re-installed with the most recent versions of
everything (perl, DBI, DBD) that works with 64-bit shared libraries. This
is the error we were getting (basically)
"/usr/lib/dld.sl: Bad magic number for shared library:
/ora1/app/oracle/product/9.2.0.1.0/lib32"
Here is my step-by-step instructions, pretty much what you have but
streamlined for this particular case.
Required software:
HPUX 11.11 (11i) PA-RISC
perl 5.8.4 source
DBI-1.42 source
DBD-Oracle-1.16 source
Oracle 9.2.0.1.0 installation
=over
=item Step 1: Compiling Perl
This compiles PERL using the default HPUX cc compiler. The important
things to note here are the configure parameters. the only non-default
option to take is to add "+z" to the additional cc flags step.
gunzip perl-5.8.4.tar.gz
tar -xf perl-5.8.4.tar
cd perl-5.8.4
./Configure -Ubincompat5005 -Duselargefiles -A prepend:libswanted='cl pthread ' -Duse64bitall
Any additional cc flags?
Add +z to beginning of list, include all other options.
make; make test
98% of tests should succeed. If less, something is wrong.
=item Step 2: DBI
gunzip DBI-1.42.tar.gz
tar -xvf DBI-1.42.tar
cd DBI-1.42
perl Makefile.PL
make;make test
make install
=item Step 3: Install DBD-Oracle
First, set the following environment variables specific you your Oracle
installation:
export ORACLE_USERID=user/pass
export ORACLE_HOME=/oracle/product/9.2.0.1.0
export ORACLE_SID=orap1
Then unpack and build:
gunzip DBD-Oracle-1.16.tar.gz
tar -xvf DBD-Oracle-1.16.tar
cd DBD-Oracle-1.16
perl Makefile.PL -l
make;make test
make install
=back
Note from H.Merijn Brand: In more recent perl distributions using
HP C-ANSI-C should "just work" (TM), provided your C compiler can be
found and used, your database is up and running, and your environment
variables are set as noted. Example is for a 64bit build, as Oracle
ships Oracle 9 and up for HP-UX only in 64bit builds.
gzip -d <perl-5.8.8.tgz | tar xf -
cd perl-5.8.8
sh ./Configure -Duse64bitall -A prepend:libswanted='cl pthread ' -des
make
make test_harness
make install
gzip -d <DBI-1.50.tgz | tar xf -
perl Makefile.PL
make
make test
make install
gzip -d <DBD-Oracle-1.17.tgz | tar xf -
perl Makefile.PL
make
make test
make install
=head2 Appendix C
(Miscellaneous links which might be useful)
Michael Schuh writes:
It was a bit by trial and error and a bit more by following your
suggestions (and mapping them to gcc) that I got something that worked.
One of the most significant "mappings" was to take your suggestion under
"Configure" to add "+Z" to the ccflags variable and to change that to
"-fPIC" (which, I learned from the gcc man page, is different than
"-fpic", which is the counterpart for +z). -fPIC (+Z) allows I<big>
offsets in the Position Independent Code, where -fpic (+z) only allows
small offsets.
I suspect that your hint about adding -lcl and -lpthread were crucial,
but (after doing so) I never encountered any problems that were related
to them.
One thing that I did was create a shell script to set some variables,
as the initial environment for root on the target system didn't work
very well. Here is that script, trimmed to remove a bunch of echo
statements, etc.:
# -------------------------------------------------------------------
# root.env - sets some environment variables the way I want them...
#
# Mike Schuh, June 2002, July 2002
export CC=/usr/local/bin/gcc
export INSTALL=./install-sh
. appl_setup DDD
export ORACLE_SID="SSS"
export ORACLE_USERID="XXX/YYY"
export PATH=/usr/local/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/opt/perl5/bin:/usr/c
ontrib/bin:/opt/nettladm/bin:/opt/fc/bin:/opt/fcms/bin:/opt/pd/bin:/usr/bin/X11:
/usr/contrib/bin/X11:/opt/hparray/bin:/opt/resmon/bin:/usr/sbin/diag/contrib:/op
t/pred/bin:/opt/gnome/bin:/sbin
# end of root.env
The appl_setup sets some Oracle variables (specific to our installation),
which I then override for the database that I am working on. The script
(which I source) also uses some variables specific to other applications
(e.g., Tivoli), mostly to unclutter my debugging. The INSTALL variable
is related to building libgdbm.
=head2 http://www.mail-archive.com/dbi-users@perl.org/msg18687.html
Garry Ferguson's notes on a successful build using perl 5.8.0, DBI-1.38
and DBD-Oracle-1.14 on HPUX 11.0 ( an L2000 machine ) with Oracle 9.0.1
=head2 http://www.sas.com/service/techsup/unotes/SN/001/001875.html
This is a note from the SAS support people documenting the
LhtStrInsert() and LhtStrCreate() undefined symbols errors, and how to
fix them in the Oracle makefiles.
=head1 Appendix D
(Why Dynamic Linking)
Some one posted to the DBI email list the following question:
What are the advantages of building a dynamically linked version?
Being able to use threads? Or something besides that?
The answer is there are too many to count, but here are several big ones:
=over
=item 1 Much smaller executables
Only the code referenced gets loaded... this
means faster execution times, and less machine resources (VM) used)
=item 2 Modular addition and updating of modules.
This is HUGE. One does not relink B<EVERYTHING, EVERY time> one changes
or updates a module.
=item 3 It eliminates Dynaloader warning (multiply defined).
This occurs with the static build when Perl is run with -w. I fixed
this by removing -w from my #! lines, converting the pragam "use
warnings;". However, it was annoying, since all my scripts had -w in the
#! line.
=item 4 It's the default build
Since almost every OS now supports dynamic linking, I believe that static
linking is NOT getting the same level of vetting it maybe used to.
Dynamically linking is what you get by default, so its way better tested.
=item 5 It's required for Apache and mod_perl.
=back
=head1 Appendix E
(WebLogic Driver for Oracle with the Oracle8i Server Lob Bug)
Michael Fox reported a bug when you are using DBD-Oracle-1.18 or later and when using older Oracle versions.
The bug will result in an error report
'Failed to load Oracle extension and/or shared libraries'.
This problem occurs if you use the WebLogic Driver for Oracle with the Oracle8i Server
- Enterprise Edition 8.1.7 and the corresponding Oracle Call Interface (OCI).
This problem occurs only in Oracle 8.1.7; it is fixed in Oracle 9i.
This link details the problem
=head1 http://e-docs.bea.com/platform/suppconfigs/configs70/hptru64unix51_alpha/70sp1.html#88784
The solution from this page is below;
To work around this problem, complete the following procedure:
=over
=item 1 Log in to your Oracle account:
su - oracle
=item 2 In a text editor, open the following file:
$ORACLE_HOME/rdbms/admin/shrept.lst
=item 3 Add the following line:
rdbms:OCILobLocatorAssign
=item 4 (optional) Add the names of any other missing functions needed by applications, other than WebLogic Server 7.0, that you want to execute.
Note: The OCILobLocatorAssign function is not the only missing function that WebLogic Server 7.0 should be able to call, but it is the only missing function that WebLogic Server 7.0 requires. Other functions that WebLogic Server should be able to call, such as OCIEnvCreate and OCIerminate, are also missing. If these functions are required by other applications that you plan to run, you must add them to your environment by specifying them, too, in $ORACLE_HOME/rdbms/admin/shrept.lst.
=item 5 Rebuild the shared client library:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk client_sharedlib
The make command updates the following files in /opt/oracle/product/8.1.7/lib:
clntsh.map
ldap.def libclntsh.so
libclntsh.so.8.0 libclntst8.a
network.def
plsql.def
precomp.def
rdbms.def
Because OCILobLocatorAssign is now visible in libclntsh.so, WebLogic Server can call it.
=back
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

166
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Linux.pod vendored Normal file
View File

@@ -0,0 +1,166 @@
#PODNAME: DBD::Oracle::Troubleshooting::Linux
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Linux
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Linux - Tips and Hints to Troubleshoot DBD::Oracle on Linux
=head1 VERSION
version 1.80
=head1 SELinux and httpd
If SELinux is running, it can prevents DBD::Oracle running in
an Apache process to load shared libraries it requires (libclntsh.so
or libnnz12.so). A typical symptom is a line like the following in
the Apache error logs:
[Tue Apr 17 13:22:45 2012] [error] Can't load '.../DBD/Oracle/Oracle.so' for
module DBD::Oracle: libnnz11.so: cannot enable executable stack as shared
object requires: Permission denied at .../DynaLoader.pm line 190.\n at
.../startup.pl line 17\nCompilation failed in require at ...
The fix:
/usr/sbin/setsebool -P httpd_execmem
=head1 Installing with Instantclient .rpm files.
Nothing special with this you just have to set up you permissions as follows;
1) Have permission for RWE on '/usr/lib/oracle/10.2.0.3/client/' or the other directory where you RPMed to
2) Set export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client
3) Set export LD_LIBRARY_PATH=$ORACLE_HOME/lib
4) If you plan to use tnsnames to connect to remote servers and your tnsnames.ora file is not in $ORACLE_HOME/network/admin, you will need to Export TNS_ADMIN=dir to point DBD::Oracle to where your tnsnames.ora file is
=head1 undefined symbol: __cmpdi2 comes up when Oracle isn't properly linked to the libgcc.a library.
In version 8, this was corrected by changing the SYSLIBS entry in
$ORACLE_HOME/bin/genclntsh to include
"-L/usr/lib/gcc-lib/i386-redhat-linux/3.2 -lgcc".
I had tried this with no success as when this program was then run, the
error "unable to find libgcc" was generated. Of course, this was the
library I was trying to describe!
It turns out that now it is necessary to edit the same file and append
"`gcc -print-libgcc-file-name`" (including the backquotes!). If you do
this and then run "genclntsh", the libclntsh is properly generated and
the linkage with DBD::Oracle proceeds properly.
=head1 cc1: invalid option `tune=pentium4'" error
If you get the above it seems that either your Perl or OS where compiled with a different version of GCC or the GCC that is on your system is very old.
No real problem with the above however you will have to
1) run Perl Makefile.PL
2) edit the Makefile and remove the offending '-mtune=pentium4' text
3) save and exit
4) do the make install and it should work fine for you
=head1 Oracle 9i Lite
The advice is to use the regular Oracle9i not the lite version.
Another great source of help was: http://www.puschitz.com/InstallingOracle9i.html
just getting 9i and 9i lite installed. I use fvwm2(nvidia X driver) as
a window manager which does not work with the 9i install program, works
fine with the default Gnomish(nv X driver), it could have been the X
driver too.
With Redhat9 it is REAL important to set LD_ASSUME_KERNEL to 2.4.1.
I didn't try this but it may be possible to install what is needed by
only downloading the first disk saving some 1.3GB of download fun.
I installed a custom install from the client group. The packages I
installed are the Programmers section and sqlplus. I noticed that the
Pro*C when on as a result of the checking the Programmers section I
assume.
Once Oracle was installed properly the DBD::Oracle install went as
smooth as just about every other CPAN module.
=head1 Oracle 10g Instantclient
The Makefile.PL will now work for Oracle 10g Instantclient. To have both the Compile and
the test.pl to work you must first have the LD_LIBRARY_PATH correctly set to your
"instantclient" directory. (http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html)
The present version of the make creates a link on your "instantclient" directory as follows
"ln -s libclntsh.so.10.1 libclntsh.so". It is needed for both the makefile creation and the compile
but is not need for the test.pl. It should be removed after the compile.
If the Makefile.PL or make fails try creating this link directly in your "instantclient" directory.
=head1 Oracle Database 10g Express Edition 10.2
To get 10Xe to compile correctly I had to add $ORACLE_HOME/lib to the LD_LIBRARY_PATH
as you would for an install against 10g Standard Edition, Standard Edition One, or
Enterprise Edition
=head1 UTF8 bug in Oracle 9.2.0.5.0 and 9.2.0.7.0
DBD::Oracle seems to hit some sort of bug with the above two versions of DB.
The bug seems to hit when you when the Oracle database charset: US7ASCII and the Oracle nchar charset: AL16UTF16 and it has also
been reported when the Oracle database charset: WE8ISO8850P1 Oracle nchar charset: AL32UTF16.
So far there is no patch for this but here are some workarounds
use DBD::Oracle qw( SQLCS_IMPLICIT SQLCS_NCHAR );
...
$sth->bind_param(1, $value, { ora_csform => SQLCS_NCHAR });
or this way
$dbh->{ora_ph_csform} = SQLCS_NCHAR; # default for all future placeholders
or this way
utf8::downgrade($parameter, 1);
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

601
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Macos.pod vendored Normal file
View File

@@ -0,0 +1,601 @@
#PODNAME: DBD::Oracle::Troubleshooting::Macos
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on MacOs
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Macos - Tips and Hints to Troubleshoot DBD::Oracle on MacOs
=head1 VERSION
version 1.80
=head1 General Info
These instructions allow for the compilation and successful testing of
DBD::Oracle on MacOS X 10.2.4 and higher, using Oracle 9iR2 DR
(Release 9.2.0.1.0) or the 10g Instant Client release (10.1.0.3 at the
time of writing).
MacOS X DBD::Oracle has been tested (and used) under Jaguar (10.2.x),
Panther (10.3.x), Snow Leopard (10.6.x), Lion (10.7.x). Jaguar comes
with a Perl version of 5.6.0., which I can report to work with
DBD::Oracle 1.14 and higher once you take certain steps (see below).
You may want to install a later perl, e.g., Perl 5.8.x. Please refer to:
Installing Perl 5.8 on Jaguar
http://developer.apple.com/internet/macosx/perl.html
for Perl 5.8.0 installation instructions.
DBD::Oracle is likely to not install out of the box on MacOS X
10.2. nor on 10.3. Manual but different changes will most likely be
required on both versions.
The key problem on 10.2. (Jaguar) is a symbol clash (caused by a
function poll() named identically) between the IO library in at least
Perl 5.6.0 (which is the version that comes with 10.2) and the Oracle
client library in 9iR2 developer's release for MacOS X. The symptom is
that your build appears to compile fine but then fails in the link
stage. If you are running a (possibly self-installed) version of Perl
other than 5.6.0, there's a chance that you are not affected by the
symbol clash. So, try to build first without any special measures, and
only resort to the instructions below if your build fails in the link
stage with a duplicate symbol error. Note: if it fails to even
compile, solve that problem first since it is not due to the symbol
clash.
The key problem on 10.3 (Panther) is that the default perl that comes
with the system is compiled with multi-threading turned on, which at
least with the 9iR2 developer's release exposes a memory leak. Your
DBD::Oracle build will compile, test, and install fine, but if you
execute the same prepared statement multiple times, the process will
quickly run up hundreds of megabytes of RAM, and depending on how much
memory you have it will die sooner or later.
Oracle recently released an "Instant Client" for MacOSX 10.3
(Panther), which as far as I can attest has none of the problems
above. Since it is also a very compact download (actually, a series of
downloads) I highly recommend you install and use the Instant Client
if you are on 10.3 (Panther) and you do not intend to run the Oracle
database server on your MacOSX box. See below (Instructions for
10.3.x) for details.
=head1 Instructions for 10.7.x (Lion)
Perl on Lion and later is built with 64-bit support, and therefore requires
the 64-bit Instant Client. As of this writing, only Instant Client 11.2
(64-bit) actually works. The 64-bit Instant Client 10.2 is L<incompatible with
Lion|http://only4left.jpiwowar.com/2011/08/instant-client-osx-lion-32-bit-only/>.
We therefore recommend the 11.2 client. If you must Instant Client 10.2, you
may need to recompile Perl with 32-bit support.
Either way, setup and configuration is the same:
=over
=item *
Download and install the basic, sqlplus, and sdk instantclient libraries and
install them in a central location, such as F</usr/oracle_instantclient>.
L<Downloads
here|http://www.oracle.com/technetwork/topics/intel-macsoft-096467.html>
=item *
Create a symlink from F<libclntsh.dylib.10.1> to F<libclntsh.dylib>:
cd /usr/oracle_instantclient/
ln -s libclntsh.dylib.* libclntsh.dylib
ln -s libocci.dylib.* libocci.dylib
=item *
Update your environment to point to the libraries:
export ORACLE_HOME=/usr/oracle_instantclient
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/oracle_instantclient
=item *
You should now be able to install DBD::Oracle from CPAN:
cpan DBD::Oracle
=back
=head1 Instructions for 10.6.x (Snow Leopard)
These are taken from a stackoverflow answer by "nickisfat" who gave
his/her permission for its inclusion here. You can see the original
question and answers at http://stackoverflow.com/questions/5964999.
Getting a mac install of perl to play nicely with oracle is a bit of a
pain - once it's running it is fantastic, getting it running is a
little frustrating..
The below has worked for me on a few different intel macs, there could
well be superfluous steps in there and it is likely not going to be
the same for other platforms.
This will require use of shell, the root user and a bit of CPANing -
nothing too onerous
First off create a directory for the oracle pap - libraries, instant client etc
sudo mkdir /usr/oracle_instantClient64
Download and extract all 64 bit instant client packages from oracle to
the above directory
Create a symlink within that directory for one of the files in there
sudo cd /usr/oracle_instantClient64
sudo ln -s /usr/oracle_instantClient64/libclntsh.dylib.10.1 libclntsh.dylib
The following dir is hardcoded into the oracle instant client - god knows why - so need to create and symlink it
sudo mkdir -p /b/227/rdbms/
sudo cd /b/227/rdbms/
sudo ln -s /usr/oracle_instantClient64/ lib
Need to add a couple of environment variables, so edit /etc/profile
and add them so they exist for all users:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now try and install DBD::Oracle through CPAN - this will fail, but it
means any dependencies will be downloaded and it retrieves the module
for us
sudo perl -MCPAN -e shell
install DBD::Oracle
When this fails exit CPAN and head to your .cpan/build dir - if you
used automatic config of CPAN it'll be
cd ~/.cpan/build
if you didn't auto configure you can find your build directory with
the following command in CPAN
o conf build_dir
Once in the build dir look for the DBD::Oracle dir which has just been
created (it'll be called something like DBD-Oracle-1.28-?) and cd into
it.
Now we need to switch to the root user. Root isn't enabled as default
in osx - for details on enabling see this post on the apple website
Once logged in as root we need to set the above environment variables for root:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now while still logged in as root we need to run the makefile for the
module, then make, then install
perl Makefile.pl
make
install
Assuming that all worked without error log out of root: we're DBD'd
up! If this didn't work it's time to bust out google on whatever
errors you're seeing
Now just to install the DBI module
sudo perl -MCPAN -e shell
install DBI
Now you're all set - enjoy your perly oracley new life
=head1 Instructions for 10.2.x (Jaguar)
1) Install Oracle exactly per Oracle documentation. If you change
install locations, then you'll need to modify paths accordingly.
2) There are two ways to remedy the symbol clash. Either edit the
symbol table of the Oracle client library
$ORACLE_HOME/lib/libclntsh.dylib.9.0 such that the symbol _poll is no
longer exported. Alternatively, download, patch, and re-install the
perl IO modules. I could not successfully repeat the report for the
former, but I did succeed by doing the latter. Instructions for both
follow nonetheless.
2a) SKIP IF YOU WANT TO OR HAVE SUCCESSFULLY TRIED 2b). Make a
backup copy of the $ORACLE_HOME/lib/libclntsh.dylib.9.0 file, or
the file this name points to, since we're about to modify that
library. Note that the ".9.0" suffix of the file name is version
dependent, and that you want to work with the file pointed to
through one or a series of symbolic links rather than any of the
symbolic links (e.g., one will be called libclntsh.dylib).
As user 'oracle' execute the following command to fix namespace
collisions in Oracle's dynamic libraries.
nmedit -R ./hints/macos_lib.syms $ORACLE_HOME/lib/libclntsh.dylib.9.0
*** Recall the above caveats regarding the file name.
The problem with this is that the version of nm that comes with
Jaguar doesn't support the -R flag. I'd be grateful to anyone who
can suggest how to edit the symbol table of libraries on MacOS X.
2b) SKIP IF YOU WANT TO OR HAVE SUCCESSFULLY TRIED 2a). In this
variant, we will patch the Perl IO modules to change the name of
the poll() function, as that is where it is defined. In this case,
we do not need to do anything with the Oracle libraries. Follow
these steps:
- Download the module IO (IO.pm) from CPAN and unpack it. Check
the documentation as to whether the version is compatible with
your version of Perl; I used v1.20 with Perl 5.6.0 and had
success.
- The files IO.xs, poll.c, and poll.h need to be patched. Apply
the following patches, e.g., by cutting and pasting the marked
section into a file perlio.patch and using that file as input
for patch:
$ patch -p0 < perlio.patch
The patch will basically rename the C implementation of poll()
to io_poll(). The other patches were necessary to make v1.20
compile with Perl 5.6.0; they may not be necessary with other
versions of IO and Perl, respectively.
+=+=+=+=+=+=+= Cut after this line
diff -c ../IO-orig/IO-1.20/IO.xs ./IO.xs
*** ../IO-orig/IO-1.20/IO.xs Mon Jul 13 23:36:24 1998
--- ./IO.xs Sat May 10 15:20:02 2003
***************
*** 205,211 ****
ST(0) = sv_2mortal(newSVpv((char*)&pos, sizeof(Fpos_t)));
}
else {
! ST(0) = &sv_undef;
errno = EINVAL;
}
--- 205,211 ----
ST(0) = sv_2mortal(newSVpv((char*)&pos, sizeof(Fpos_t)));
}
else {
! ST(0) = &PL_sv_undef;
errno = EINVAL;
}
***************
*** 249,255 ****
SvREFCNT_dec(gv); /* undo increment in newRV() */
}
else {
! ST(0) = &sv_undef;
SvREFCNT_dec(gv);
}
--- 249,255 ----
SvREFCNT_dec(gv); /* undo increment in newRV() */
}
else {
! ST(0) = &PL_sv_undef;
SvREFCNT_dec(gv);
}
***************
*** 272,278 ****
i++;
fds[j].revents = 0;
}
! if((ret = poll(fds,nfd,timeout)) >= 0) {
for(i=1, j=0 ; j < nfd ; j++) {
sv_setiv(ST(i), fds[j].fd); i++;
sv_setiv(ST(i), fds[j].revents); i++;
--- 272,278 ----
i++;
fds[j].revents = 0;
}
! if((ret = io_poll(fds,nfd,timeout)) >= 0) {
for(i=1, j=0 ; j < nfd ; j++) {
sv_setiv(ST(i), fds[j].fd); i++;
sv_setiv(ST(i), fds[j].revents); i++;
diff -c ../IO-orig/IO-1.20/poll.c ./poll.c
*** ../IO-orig/IO-1.20/poll.c Wed Mar 18 21:34:00 1998
--- ./poll.c Sat May 10 14:28:22 2003
***************
*** 35,41 ****
# define POLL_EVENTS_MASK (POLL_CAN_READ | POLL_CAN_WRITE | POLL_HAS_EXCP)
int
! poll(fds, nfds, timeout)
struct pollfd *fds;
unsigned long nfds;
int timeout;
--- 35,41 ----
# define POLL_EVENTS_MASK (POLL_CAN_READ | POLL_CAN_WRITE | POLL_HAS_EXCP)
int
! io_poll(fds, nfds, timeout)
struct pollfd *fds;
unsigned long nfds;
int timeout;
diff -c ../IO-orig/IO-1.20/poll.h ./poll.h
*** ../IO-orig/IO-1.20/poll.h Wed Apr 15 20:33:02 1998
--- ./poll.h Sat May 10 14:29:11 2003
***************
*** 44,50 ****
#define POLLHUP 0x0010
#define POLLNVAL 0x0020
! int poll _((struct pollfd *, unsigned long, int));
#ifndef HAS_POLL
# define HAS_POLL
--- 44,50 ----
#define POLLHUP 0x0010
#define POLLNVAL 0x0020
! int io_poll _((struct pollfd *, unsigned long, int));
#ifndef HAS_POLL
# define HAS_POLL
+=+=+=+=+=+=+= Cut to the previous line
- compile and install as you usually would, making sure that
existing but conflicting modules get removed:
$ perl Makefile.PL
$ make
$ make test
$ make install UNINST=1
- You are done. Continue with 3).
3) Install the module DBI as per its instructions, if you haven't
already done so.
4) Install the DBD::Oracle module.
$ perl Makefile.PL
$ make
$ make test
$ make install
=head1 Instructions for 10.3.x (Panther)
I highly recommend you install and use the Oracle 10g Instant Client
for MacOSX 10.3. Compared to traditional Oracle client installations
it is a very compact download, and it has the memory leak problem
fixed. As an added benefit, you will be able to seamlessly connect to
10g databases. Even if you do want to run the database server included
in the 9iR2 Developer's Release, I'd still use the Instant Client for
compiling OCI applications or drivers like DBD::Oracle.
If you still decide to use the full 9iR2 DR client, and if all you use
DBD::Oracle for on MacOSX is development and test scripts that don't
involve running the same query multiple times or many queries within
the same perl process, then note that the memory leak will most likely
never affect you in a serious way. In this case you may not need to
bother and instead just go ahead, build and install DBD::Oracle
straightforwardly without any special measures.
That said, here are the details.
0) (If you decided for the 9iR2 DR client, skip to 1.) If you decided
to use the 10g Instant Client, make sure you download and install
all parts. (Given that this is perl land you may not need the JDBC
driver, but why bother sorting out the 25% you may or may not ever
need.) Follow the Oracle instructions and copy the contents of each
part into the same destination directory. Change to this
destination directory and create a symlink lib pointing to '.'
(without the quotes):
$ cd </path/to/my/oracle/instantclient>
$ ln -s lib .
Also, set the environment variable ORACLE_HOME to the path to your
instantclient destination directory. Makefile.PL needs it.
Now return to your DBD::Oracle download. If the version is 1.16 or
less you will need to patch Makefile.PL; in later versions this may
be fixed already. Apply the following patch, e.g., by cutting and
pasting into a file Makefile.PL.patch and then executing
$ patch -p0 < Makefile.PL.patch
Here is the patch:
+=+=+=+=+=+=+= Cut after this line
*** Makefile.PL.orig Fri Oct 22 02:07:04 2004
--- Makefile.PL Fri May 13 14:28:53 2005
***************
*** 1252,1257 ****
--- 1252,1258 ----
print "Found $dir/$_\n" if $::opt_d;
}, "$OH/rdbms",
"$OH/plsql", # oratypes.h sometimes here (eg HPUX 11.23 Itanium Oracle 9.2.0)
+ "$OH/sdk", # Oracle Instant Client default location (10g)
);
@h_dir = keys %h_dir;
print "Found header files in @h_dir.\n" if @h_dir;
***************
*** 1286,1292 ****
--- 1287,1297 ----
open FH, ">define.sql" or warn "Can't create define.sql: $!";
print FH "DEFINE _SQLPLUS_RELEASE\nQUIT\n";
close FH;
+ # we need to temporarily disable login sql scripts
+ my $sqlpath = $ENV{SQLPATH};
+ delete $ENV{SQLPATH};
my $sqlplus_release = `$sqlplus_exe -S /nolog \@define.sql 2>&1`;
+ $ENV{SQLPATH} = $sqlpath if $sqlpath;
unlink "define.sql";
print $sqlplus_release;
if ($sqlplus_release =~ /^DEFINE _SQLPLUS_RELEASE = "(\d?\d)(\d\d)(\d\d)(\d\d)(\d\d)"/) {
+=+=+=+=+=+=+= Cut to the previous line
The first hunk allows Makefile.PL to find the header files which
are in a subdirectory sdk, and the second temporarily disables any
global and local login.sql scripts which may make the sqlplus call
fail. If you don't have a local login.sql script you will most
likely be fine without the second hunk.
Now run Makefile.PL and make sure you provide the -l flag:
$ perl Makefile.PL -l
If you receive some ugly error message stating that some *.mk file
couldn't be found you forgot to add the -l flag.
The continue the standard build process by running make. In
DBD::Oracle versions 1.16 and earlier this will end in an error due
to a failed execution of nmedit -R. Ignore this error. Move on to
running the tests, making sure the test scripts can log in to your
database (e.g., by setting ORACLE_USERID). Note that by default the
Instant Client does not have a network/admin/tnsnames.ora
installed. Either install a suitable one, or point TNS_ADMIN to the
directory where you keep your tnsnames.ora, or include the full
SQLNET connection string in ORACLE_USERID. All three options are
documented by Oracle in the README_IC.htm file that comes with the
Instant Client, so be sure you read it if you don't understand what
I'm writing here.
All tests should succeed. Complete by make install. You are done!
Skip the other steps below, they do NOT apply to the Instant
Client. (Although of course you may still install a later version
of perl if you have the need.)
1) Until the reason for the memory leak has been found and fixed, you
need to remove the condition that exposes it. Apparently, this is
multi-threading being enabled in Perl. The Perl 5.8.1RC3 that comes
with Panther was compiled with multi-threading enabled, and AFAIK
it cannot be turned off at runtime. Note that the problem is
independent of whether you run multiple concurrent threads or not.
Therefore, the solution is to build your own perl. I leave it up to
you whether you want to replace the system perl or not. At least
Perl 5.8.x comes with instructions as to how to replace the system
perl on MacOS X, and what the caveats and risks are. I used 5.8.4,
installed in /usr/local, and it worked perfectly fine.
The key when configuring your custom build of perl is to disable
multi-threading (usethreads, useithreads, and usemultiplicity
options). More precisely, do not enable them, as they are disabled
by default, at least up to version 5.8.5. You can check whether
threads are enabled or not by passing -V to ther Perl interpreter:
$ /path/to/your/perl -V | grep usethreads
You need to see a line saying, among other things,
usethreads=undef. If you see usethreads=define then multi-threading
is enabled.
2) If you choose not to replace the system perl, make sure that when
you build DBI and DBD::Oracle you provide the full path to your own
perl when running Makefile.PL, like so (assuming you installed in
/usr/local, which is the default):
$ /usr/local/bin/perl Makefile.PL
Also, every time you run a DBD::Oracle script, you must use the
full path too, unless your custom-built perl comes before the
system perl in the PATH environment. The easiest way to ensure you
are using the right perl is to uninstall DBI from the system perl
if you did install it under that as well.
3) Continue with 3) as in instructions for Jaguar (making path
substitutions for perl as discussed in 2).
======================================================================
If you have any problems then follow the instructions in the
README. Please post details of any problems (or changes you needed to
make) to dbi-users@perl.org and CC them to brooksch@mac.com on MacOSX
specific problems. Rewrite of part of this readme, Panther
instructions, and the Perl IO patch is credit to Hilmar Lapp, hlapp at
gmx.net.
Earlier and original instructions thanks to:
Andy Lester
Steve Sapovits
Tom Mornini
Date: Tue, 15 Apr 2003 16:02:17 +1000
Subject: Compilation bug in DBI on OSX with threaded Perl 5.8.0
From: Danial Pearce
In regards to a previous message on this list:
http://archive.develooper.com/dbi-users@perl.org/msg16365.html
I have some more info:
I have compiled and installed Perl just fine with threads enabled:
./Configure -de -Dusethreads -Dprefix=/usr
make
make test
sudo make install
I have then successfully installed Apache and mod_perl as well.
When I try to compile and install DBI, I get a bus error, just like the
people on this list have previously discussed on the thread above.
If I unpack the DBI, and run perl Makefile.pl, then alter the created
Makefile so that it uses gcc2 rather than just "cc" then it compiles,
installs and runs just fine.
The issue here is that Apple have just recently release 10.2.4, which
updates /usr/bin/{gcc3,gcc2,g++3,g++2} and /usr/bin/cc is a symlink to
/usr/bin/gcc3, so compilation of DBI under Apple's gcc3 does not work. It
works find with gcc2 however.
I had the same problem with DBD::Pg, and was able to compile and install
that using the same fix.
I am unsure if this is a problem with Apple's version of gcc, or a problem
with the DBI/DBD code itself. Given that all my other open source
applications are compiling and installing fine, I am thinking there isn't
anything Apple are going to do about it.
cheers
Danial
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

76
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Sun.pod vendored Normal file
View File

@@ -0,0 +1,76 @@
#PODNAME: DBD::Oracle::Troubleshooting::Sun
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Sun
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Sun - Tips and Hints to Troubleshoot DBD::Oracle on Sun
=head1 VERSION
version 1.80
=head1 General Info
If you get this on a Solaris 9 and 10 box
"Outofmemory!
Callback called exit.
END failed--call queue aborted."
The solution may be as simple as not having you "ORACLE_HOME" Defined in the
environment.
It seems that having it defined will prevent the error.
=head1 Setting library load path for instant client libraries
Usually you set LD_LIBRARY_PATH to point to the location of
your Oracle Instant Client (you need to do this when building
DBD::Oracle). However, afterwards it can be a pain to keep
ensuring this is set and changing LD_LIBRARY_PATH in your Perl
script does not work (needs to be done beforehand) as the dynamic
linker caches its value.
An alternative under newer versions of Solaris is:
root> crle -u -l /youroracledir/lib/instantclient_11_2
however, make sure you check the crle options as you may need to
set the architecture etc as well.
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

130
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Vms.pod vendored Normal file
View File

@@ -0,0 +1,130 @@
#PODNAME: DBD::Oracle::Troubleshooting::Vms
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Vms
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Vms - Tips and Hints to Troubleshoot DBD::Oracle on Vms
=head1 VERSION
version 1.80
=head1 General Info
This is related to Oracle RDBMS 9.2 and later, since Oracle
made fundamental changes to oracle installation requirements
and factual installation with this release.
Oracle's goal was to make VMS installation be more like on
*nix and Windows, with an all new Oracle Home structure too,
requiring an ODS-5 disk to install Oracle Home on instead of
the good old ODS-2.
Another major change is the introduction of an Oracle generated
logical name table for oracle logical names like ORA_ROOT and all
its derivatives like ORA_PROGINT etc. And that this logical name
table is inserted in LNM$FILE_DEV in LNM$PROCESS_DIRECTORY.
(LNM$PROCESS_DIRECTORY)
"LNM$FILE_DEV" = "SERVER_810111112"
= "LNM$PROCESS"
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"
= "DECW$LOGICAL_NAMES"
This ensures that any process that needs to have access to
oracle gets the environment by just adding one logical name table
to a central process specific mechanism.
But as it is inserted at the very top of LNM$FILE_DEV it also
represents a source of misfortune - especially if a user with
enough privilege to update the oracle table does so (presumably
unintentionally), as an example by changing NLS_LANG.
PERL has the ability to define, redefine and undefine (deassign)
logical names, but if not told otherwise by the user does it
in the first table in above list, and not as one would normally
expect in the process table.
Installing DBI and DBD::Oracle has influence upon this since in
both cases a few environment variables are read or set in the
test phase.
For DBI it is the logical SYS$SCRATCH, which is a JOB logical.
For DBD-Oracle it is when testing a new feature in the Oracle
RDBMS: UTF8 and UTF16 character set functionality, and in order
to do this it sets and unsets the related environment variables
NLS_NCHAR and NLS_LANG.
If one is not careful this changes the values set in the oracle
table - and in the worst case stays active until the next major
system reset. It can also be a very hard error to track down
since it happens in a place where one normally never looks.
Furthermore, it is very possibly that some or all of the UTF tests
fails, since if one have a variable like NLS_LANG in his process
table, then even though 'mms test' sets it in the wrong table
it is not invoked as it is overruled by the process logical...
The way to ensure that no logicals are set in the oracle table and
that the UTF tests get the best environment to test in, and that
DBI correctly translates the SYS$SCRATCH logical, use the
logical
PERL_ENV_TABLES
to ensure that PERL's behavior is to leave the oracle table alone and
use the process table instead:
$ DEFINE PERL_ENV_TABLES LNM$PROCESS, LNM$JOB
This tells PERL to use the LNM$PROCESS table as the default place to
set and unset variables so that only the perl users environment
is affected when installing DBD::Oracle, and ensures that the
LNM$JOB table is read when SYS$SCRATCH is to be translated.
PERL_ENV_TABLES is well documented in the PERLVMS man page.
Oracle8 releases are not affected, as they don't have the
oracle table implementation, and no UTF support.
Oracle 9.0 is uncertain, since testing has not been possible yet,
but the remedy will not hurt :)
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

278
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Win32.pod vendored Normal file
View File

@@ -0,0 +1,278 @@
#PODNAME: DBD::Oracle::Troubleshooting::Win32
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Win32
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Win32 - Tips and Hints to Troubleshoot DBD::Oracle on Win32
=head1 VERSION
version 1.80
=head1 GENERAL INFO
In general, on Windows, it's best to just use ActiveState Perl and the
PPM package manager to install a pre-built version of DBD::Oracle however only version 1.17 is available there.
=head1 Oracle Instant Client 11.1.0.6.0 Notes
So far I have managed to get it to Makefile and compile test and install and work. However it seems one needs to set "NLS_LANG" to a valid value
in the environment variables.
As well IC 11 seems to have trouble finding the .ORA files. A quick fix for this is to add "TNS_ADMIN"
to the environment variables and point it to where your .ORA files are.
=head1 Other information, some of which is out of date ---
DBD-Oracle for Windows and Oracle Instantclient and 10XE (Express Edition)
By: John Scoles
The Pythian Group
The preferred method of getting DBD::Oracle is to use a pre-built version from the ActiveState
repository, which can be installed with PPM.
Compiling and installing DBD::Oracle 1.18 or later on a windows 2000 professional or XP OS for use
with Oracle instantClient ver 10.2.0.1 & 10.1.0.5 or Oracle XE requires only a few downloads and
a minimal number of environment setting. The procedures below were tested on a clean
Windows platform having no Oracle or other development environment installed.
1) The first part of the process is to download and install the latest version of
Active Perl from http://www.activeperl.com/.
2) Use the PPM application to get the latest version of DBI
3) Download the latest DBD::Oracle from http://svn.perl.org/modules/dbd-oracle/trunk/
4) Download and unzip the Oracle Instant Client (10.2.0.1 or 10.1.0.5) 32 bit from
http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html
You will need all three of these products
i. Instant Client Package - Basic
ii. Instant Client Package - SQL*Plus:
iii. Instant Client Package - SDK:
or
install oracle 10XE http://www.oracle.com/technology/products/database/xe/index.html
5) You will now need the Microsoft Visual C++ toolkit 2003. Unfortunately this product is no longer available from Microsoft.
The file name was VCToolkitSetup.exe and is available at this mirror site http://www.filewatcher.com/m/VCToolkitSetup.exe.32952488.0.0.html at the time of writing.
Microsoft's replacement for this tool kit is Visual C++ 2005 Express Edition and all attempts to compile DBD::Oracle with this product fail. It has been successfully compiled
using a complete edition of Microsoft Visual Studio 2005.
Download and then install this product.
6) You will also need the Windows SDK. Which can be found at
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
You have the choice to of either to download the entire SDK and install or run an online install from the page.
Both have been tested and proven to work.
7) Next download and install the Microsoft .net framework 1.1 skd from
http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&displaylang=en
8) You will also need a copy of nmake.exe which you can download here http://download.microsoft.com/download/vc15/patch/1.52/w95/en-us/nmake15.exe
9) Enough Downloading and installing go have a coffee.
10) You should at this time attempt to connect to an Oracle database with the version SQL*Plus that
you installed in step 4. If you are unable to connect at this stage then any problems you encounter
later may have nothing to do with DBD::Oracle
11) On the path where you installed Visual C++ find and edit the vcvars32.bat file as follows. You may have to modify
these path values depending where you installed the products on you computer,
i. Add the local path to the windows platform SDK include directory to the Set INCLUDE
Command Line to include the needed files from the Windows SDK.
e.g. "C:\Program Files\Microsoft Platform SDK\Include;"
ii. Add the local path to the .net Vc7 lib directory to the Set LIB command
to include the needed library file from the .Net SKD
e.g. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
iii. Add the local path to the windows platform SDK Lib directory to the Set Lib command
to include the needed library files from the Windows SDK
e.g. C:\Program Files\Microsoft Platform SDK\Lib;
12) Open a Windows Visual C++ command window from the start menu.
13) Add the path to the instant client to the Path command. If you are compiling against a 10XE db/client then you can skip steps
12 to 14.
e.g. PATH = C:/Oracle/instantclient;%PATH%
14) Using the "Set" command add "ORACLE_HOME=path to Instant client" to the environment variables.
e.g. Set ORACLE_HOME=C:\Oracle\instantclient
15) Using the "Set" command add "NLS_LANG=.WE8ISO8859P15" to the environment variables. The globalization variable is required,
with this or another compatible value, by Oracle instantclient in order for it to compile correctly.
e.g. Set NLS_LANG=.WE8ISO8859P15
16) Using the "Set" command add "ORACLE_USERID=test/test@test" substituting test with the username/password@database
you wish to run the make test files against.
Note: it is not necessary to do this step for the compile and install to work.
However: The self-test programs included with Oracle-DBD will mostly fail.
17) Move to the DBD-Oracle directory in the Visual C++ window DOS prompt and enter the following.
c:\oracle-dbd\>perl Makefile.PL
The Makefile should then run and compile Oracle-dbd without reporting any errors.
18) From this DOS prompt enter the following command
c:\oracle-dbd\>nmake
The Visual C++ make executable will then build you DBD-execuable. There should be no errors at this point.
19) You can test the compile by either entering
c:\oracle-dbd\>nmake test
As long as you have given a valid user name, password and database name in step 15 you will see some results. If it appears to
run but you do not get a connection check the following.
i. User name password and DB Name
ii. Ensure the a valid TNSNAMES.ORA file is in the Instantclient directory
iii. Attempt to log into the version of SQLPLUS that comes with Instantclient.
If you manage to log on use the username password and TNS name with
the Set ORACLE_USERID = and rerun the tests.
iv If you are compiling against 10XE and have skipped steps 12 to 14 try again bu this time carry out these steps
20) You can now install DBD-Oracle into you system by entering the following command from the Visual C++ window dos prompt;
c:\oracle-dbd\>nmake install
21) You should now be able to run DBD-Oracle on you system
=head1 09/30 2006 from asu
DBD::Oracle 1.18a
Linux, Debian unstable (
DBI: 1.52
perl v5.8.8 built for i486-linux-gnu-thread-multi
)
Oracle Instant client (10.1.0.5)
The problem is in Makefile.PL. In line 130 the function find_oracle_home
is used to guess a value form $ORACLE_HOME if it is not set explicitly.
This value is used in line 138 to setup the environment (regardless
which client is used).
in line 1443 (sub get_client_version) sqlplus is used to get the
version string, but for the oracle instant client you must not set
$ORACLE_HOME (it will generate an error "SP2-0642: SQL*Plus internal
error state 2165, context 4294967295:0:0")
A solution that worked for me was to set
local $ENV{ORACLE_HOME} = '';
in line 1463 immediately before sqlplus is called (but I cannot tell if
this fails for full client installations)
11/30/05 -- John Scoles
I have confirmed that this Makefile.pl will work for both Oracle InstantClient
10.2.0.1 & 10.1.0.4 using same process the Andy Hassall uses. Starting with a clean OD
One needs only to get the latest version of Active Perl 5.8.7 use PPM to get DBI and then
install Microsoft Visual C++ toolkit, Windows SDK, and the Microsoft .net
framework 1.1. and modify the vcvars32.bat in C++ dir as follows
1) Add the local path to the windows platform SDK include directory to the
Set INCLUDE Command Line to include the needed files from the Windows SDK.
e.g. "C:\Program Files\Microsoft Platform SDK\Include;"
2) Add the local path to the .net Vc7 lib directory to the Set LIB
command to include the needed library files from the .Net SKD
e.g. C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
3) Add the local path to the windows platform SDK Lib directory to the Set Lib
command to include the needed library files from the Windows SDK
e.g. C:\Program Files\Microsoft Platform SDK\Lib;
If one happens to have visual studio installed you may not have to download additional MS products.
12/01/05 --- John Scoles
Oracle 10XE
No big problem here as 10XE seems to use the instantclient as well. Just ensure your
NLS_LANG and ORACLE_HOME are set to the same directory that 10XE uses
10/07/05 --John Scoles
Andy Hassall kindly added some changes to the Makefile.PL
so it will work for the Instant Client 10g on Windows OSs. Below is how he set
up his environment and the steps he preformed to get it to compile.
Setting environment for using Microsoft Visual Studio .NET 2003 tools.
(If you have another version of Visual Studio or Visual C++ installed and wish
to use its tools from the command line, run vcvars32.bat for that version.)
C:\Documents and Settings\andyh>d:
D:\>cd cygwin\home\andyh\src\pythian
D:\cygwin\home\andyh\src\pythian>set ORACLE_HOME=d:\lib\instantclient_10_2
D:\cygwin\home\andyh\src\pythian>set NLS_LANG=.WE8ISO8859P15
D:\cygwin\home\andyh\src\pythian>set PATH=d:\lib\instantclient_10_2;D:\Program F
iles\Microsoft Visual Studio .NET 2003\Common7\IDE;D:\Program Files\Microsoft Vi
sual Studio .NET 2003\VC7\BIN;D:\Program Files\Microsoft Visual Studio .NET 2003
\Common7\Tools;D:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\
bin\prerelease;D:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\
bin;D:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin;C:\WINNT\Mic
rosoft.NET\Framework\v1.1.4322;d:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\
System32\Wbem;D:\Program Files\Microsoft SDK\Bin;D:\Program Files\Microsoft SDK\
Bin\WinNT
D:\cygwin\home\andyh\src\pythian>set ORACLE_USERID=test/test@test102
D:\cygwin\home\andyh\src\pythian>perl Makefile.PL
4/27/04 -- Jeff Urlwin
Do not untar this distribution in a directory with spaces. This will not work.
i.e. C:\Program Files\ORacle\DBD Oracle Distribution is bad while
c:\dev\dbd-oracle-1.15 is good ;)
9/14/02 -- Michael Chase
Makefile.PL uses Win32::TieRegistry or Win32::Registry to find the
current Oracle Home directory if the ORACLE_HOME environment variable
is not set. If neither module is installed, you must set ORACLE_HOME
before running Makefile.PL. Since the registry location of the current
Oracle Home is in different locations in different Oracle versions,
it is usually safer to set ORACLE_HOME before running Makefile.PL.
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut

196
database/perl/vendor/lib/DBD/Oracle/Troubleshooting/Win64.pod vendored Normal file
View File

@@ -0,0 +1,196 @@
#PODNAME: DBD::Oracle::Troubleshooting::Win64
#ABSTRACT: Tips and Hints to Troubleshoot DBD::Oracle on Win64
__END__
=pod
=encoding UTF-8
=head1 NAME
DBD::Oracle::Troubleshooting::Win64 - Tips and Hints to Troubleshoot DBD::Oracle on Win64
=head1 VERSION
version 1.80
=head1 DBD::Oracle and Windows 64bit
I have successfully compiled and installed DBD::Oracle on Windows 2008 server 64bit operating system today.
I used the latest version of <a href='http://search.cpan.org/~pythian/DBD-Oracle-1.24a/'>DBD::Oracle 1.24</A>
version 11.2.0.1.0 for 64bit windows of Oracle's
<a href='http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winx64soft.html'>Instant Client Package - Basic</a>
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 <a href='http://www.microsoft.com/visualstudio/en-ca/download'>Visual Studio Ultimate</a>
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 DBB::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 (the make you can ignore them for now 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 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
are just a false trails. For more info on this check out this page <a href='http://www.alexander-foken.de/Censored%20copy%20of%20Oracle%20Troubleshooter%20HOWTO.html#oneoci'>Oracle Troubleshooter'</a>
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 simple 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.
In general compiling DBD:Oracle for 64 bit machines has been a hit or miss operation.
The main thing to remember is you will have to compile using 32 bit Perl and compile DBD::Oracle against a 32bit client
which sort of defeats the purpose of having a 64bit box.
So until 64bit Perl comes out we will be posing in this README any success stories we have come across
-------- Original Message --------
From: Alex Buttery, OCA, MCTS
Director, Database Architecture and Operations
Impact Rx, Inc.
I needed to get perl working on a 64-bit Windows Server so I got creative. Since I was unable to build DBD::Oracle on the Windows Server
(even with Visual Studio 6 installed), I decided that I would try another approach. Here are the steps I took to get it working
(yes, this is a hack and I'm not even sure that it does not violate someone's license agreements but I'm not going to be asking anyone
else to support this configuration).
Step 1: Install 32-bit Perl 5.8.8 from Activestate on the Server to the C: drive.
Step 2: Install the 32-bit Oracle client on the server (I'm assuming the 64-bit client has already been installed and is working) to
the c:\oracle\product\10.2.0\client32 directory in the OraHome_Client32 Home.
Step 3: Locate Oracle.dll in the new Oracle Home directory, it should be located somewhere close to
c:\oracle\product\10.2.0\client32\perl\site\5.8.3\MSWin32-x86-multi-thread\auto\DBD\Oracle.
Step 4: Locate Oracle.dll in the Perl 5.8.8 directory. (C:\Perl) It should be somewhere close to c:\Perl\site\lib\auto\DBD\Oracle.
Step 5: Copy the contents of the Oracle directory found in Step 3 to the Perl directory found in Step 4.
Step 6: Copy GetInfo.pm from C:\oracle\product\10.2.0\client32\perl\site\5.8.3\lib\MSWin32-x86-multi-thread\DBD\Oracle to C:\Perl\site\lib\DBD\Oracle
Step 7: Locate Oracle.pm in the new Oracle Home directory, it should be located somewhere close to
c:\oracle\product\10.2.0\client32\perl\site\5.8.3\MSWin32-x86-multi-thread\auto\DBD.
Step 8: Locate Oracle.pm in the Perl 5.8.8 directory. (C:\Perl) It should be somewhere close to c:\Perl\site\lib\auto\DBD.
Step 9: Copy Oracle.pm from the Oracle directory found in Step 7 to the Perl directory found in Step 8.
Step 10: Set up required ODBC connections using the 32-bit ODBC applet (odbcad32.exe) located in the C:\Windows\SysWOW64 directory.
Note: The ODBC applet in the Administrative Tools menu points to the odbcad32.exe located in the C:\Windows\system32 directory
and is actually the 64 bit version of the ODBC applet This cannot be used by Perl
Step 11: Create batch scripts to run Perl programs and include the following SET statements to point Perl to the correct Oracle Home:
SET ORACLE_HOME=c:\oracle\product\10.2.0\client32 <== 32-bit Oracle Home
SET ORACLE_SID=xyz123 <== SID of Production Database
SET NLS_LANG=.WE8ISO8859P1 <== Default Language from Database (preceding "." Is required)
SET PATH=%ORACLE_HOME%\bin;%PATH% <== Add 32-bit Oracle Home to beginning of default PATH
=head1 AUTHORS
=over 4
=item *
Tim Bunce <timb@cpan.org>
=item *
John Scoles <byterock@cpan.org>
=item *
Yanick Champoux <yanick@cpan.org>
=item *
Martin J. Evans <mjevans@cpan.org>
=back
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2019, 2014, 2013, 2012, 2011, 2010 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=cut