Re: DBD::Oracle forked client hangs with Oracle Client Libraries 19.20 and later.

[Justin Schoeman]

c5ef1c96c0) at 
pthread_cond_destroy.c:53
#3  0x7f0c35cac072 in sltspcdestroy () from 
/usr/lib/oracle/21/client64/lib/libclntshcore.so.21.1
#4  0x7f0c36ecf68e in kpucpstopthr () from 
/usr/lib/oracle/21/client64/lib/libclntsh.so.21.1
#5  0x7f0c39e9a42e in kpufhndl0 () from 
/usr/lib/oracle/21/client64/lib/libclntsh.so.21.1
#6  0x7f0c48a1028a in ora_db_destroy 
(dbh=dbh@entry=0x55c5ef32c5b0, imp_dbh=imp_dbh@entry=0x55c5ef035390) 
at /root/.local/share/.cpan/build/DBD-Oracle-1.83-2/dbdimp.c:1263
#7  0x7f0c48a10752 in XS_DBD__Oracle__db_DESTROY 
(my_perl=0x55c5eee272a0, cv=) at ./Oracle.xsi:432
#8  0x7f0c48a4d106 in XS_DBI_dispatch (my_perl=0x55c5eee272a0, 
cv=0x55c5ef13b9c8) at 
/usr/src/debug/perl-DBI-1.643-15.fc38.x86_64/DBI.xs:3783
#9  0x7f0c487265aa in Perl_pp_entersub (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/pp_hot.c:5353
#10 0x7f0c4867c7a6 in Perl_call_sv (my_perl=, 
sv=, flags=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:3057
#11 0x7f0c4872c643 in S_curse 
(my_perl=my_perl@entry=0x55c5eee272a0, sv=sv@entry=0x55c5ef34af38, 
check_refcnt=check_refcnt@entry=true) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6973
#12 0x7f0c4872cd88 in Perl_sv_clear 
(my_perl=my_perl@entry=0x55c5eee272a0, 
orig_sv=orig_sv@entry=0x55c5ef079858) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6536
#13 0x7f0c4872d3a2 in Perl_sv_free2 (my_perl=0x55c5eee272a0, 
sv=0x55c5ef079858, rc=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:7073
#14 0x7f0c486fc878 in Perl_SvREFCNT_dec (sv=, 
my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/inline.h:405
#15 S_mg_free_struct (my_perl=0x55c5eee272a0, sv=, 
mg=0x55c5ef34bb70) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/mg.c:563
#16 0x7f0c486fc8c9 in Perl_mg_free (my_perl=0x55c5eee272a0, 
sv=0x55c5ef34aec0) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/mg.c:585
#17 0x7f0c4872cdc3 in Perl_sv_clear 
(my_perl=my_perl@entry=0x55c5eee272a0, 
orig_sv=orig_sv@entry=0x55c5ef34aec0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6544
#18 0x7f0c4872d3a2 in Perl_sv_free2 (my_perl=0x55c5eee272a0, 
sv=0x55c5ef34aec0, rc=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:7073
#19 0x7f0c48722646 in Perl_SvREFCNT_dec_NN (sv=, 
my_perl=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/inline.h:419
#20 do_clean_objs (ref=0x55c5ef338ce0, my_perl=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:448
#21 S_visit (mask=2048, flags=2048, f=, 
my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:391
#22 Perl_sv_clean_objs (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:542
#23 0x7f0c48680160 in perl_destruct (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:880
#24 0x55c5eda0f324 in main (argc=, argv=out>, env=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perlmain.c:121


I have instrumented dbdimpl.c as follows:

    /* free global environment handle during 
destruction of last connection */
    } else if ( (imp_dbh->envhp == imp_drh->envhp) 
&& (SvTRUE(perl_get_sv("DBI::PERL_ENDING",0))) ) {
    PerlIO_printf(PerlIO_stderr(), 
"EXIT1\n");
    OCIHandleFree_log_stat(imp_dbh, 
imp_dbh->envhp, OCI_HTYPE_ENV, status);
    PerlIO_printf(PerlIO_stderr(), 
"EXIT2\n");

    if ( status == OCI_SUCCESS ) {
    PerlIO_printf(PerlIO_stderr(), 
"EXIT3\n");

    imp_dbh->envhp = NULL;
    imp_drh->envhp = NULL;
    }
    }

And the child prints 'EXIT1', but never 'EXIT2'. If I comment out the 
call to OCIHandleFree_log_stat() then the child process exits without 
error (although there are random segfaults after long run times).


1. A complete log of all steps of the build, e.g.:

Atatched (build.log)

2. Full details of which version of Oracle client and server you're using

# rpm -qa | grep oracle
oracle-instantclient-basic-21.11.0.0.0-1.x86_64
oracle-instantclient-devel-21.11.0.0.0-1.x86_64


3. The output of perl -V   (that's a capital V, not lowercase)

Attached (perl-V.log)

Thanks,
Justin

DBD::Oracle forked client hangs with Oracle Client Libraries 19.20 and later.

[Justin Schoeman]

Good day,

I am trying to dig into an issue after a recent Oracle update. The 
application has been running flawlessly from version 9.x to 18.5, and 
has only broken on the most recent client library updates.


Attached is a cut down application which demonstrates the issue.

The forked child processes never exit. Attaching to them with GDB gives:

(gdb) t a a bt

Thread 1 (Thread 0x7f0c48a62c40 (LWP 773676) "test.pl"):
#0  futex_wait (private=, expected=14, 
futex_word=0x55c5ef1c96e4) at ../sysdeps/nptl/futex-internal.h:146
#1  futex_wait_simple (private=, expected=14, 
futex_word=0x55c5ef1c96e4) at ../sysdeps/nptl/futex-internal.h:177
#2  __GI___pthread_cond_destroy (cond=0x55c5ef1c96c0) at 
pthread_cond_destroy.c:53
#3  0x7f0c35cac072 in sltspcdestroy () from 
/usr/lib/oracle/21/client64/lib/libclntshcore.so.21.1
#4  0x7f0c36ecf68e in kpucpstopthr () from 
/usr/lib/oracle/21/client64/lib/libclntsh.so.21.1
#5  0x7f0c39e9a42e in kpufhndl0 () from 
/usr/lib/oracle/21/client64/lib/libclntsh.so.21.1
#6  0x7f0c48a1028a in ora_db_destroy (dbh=dbh@entry=0x55c5ef32c5b0, 
imp_dbh=imp_dbh@entry=0x55c5ef035390) at 
/root/.local/share/.cpan/build/DBD-Oracle-1.83-2/dbdimp.c:1263
#7  0x7f0c48a10752 in XS_DBD__Oracle__db_DESTROY 
(my_perl=0x55c5eee272a0, cv=) at ./Oracle.xsi:432
#8  0x7f0c48a4d106 in XS_DBI_dispatch (my_perl=0x55c5eee272a0, 
cv=0x55c5ef13b9c8) at 
/usr/src/debug/perl-DBI-1.643-15.fc38.x86_64/DBI.xs:3783
#9  0x7f0c487265aa in Perl_pp_entersub (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/pp_hot.c:5353
#10 0x7f0c4867c7a6 in Perl_call_sv (my_perl=, 
sv=, flags=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:3057
#11 0x7f0c4872c643 in S_curse (my_perl=my_perl@entry=0x55c5eee272a0, 
sv=sv@entry=0x55c5ef34af38, check_refcnt=check_refcnt@entry=true) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6973
#12 0x7f0c4872cd88 in Perl_sv_clear 
(my_perl=my_perl@entry=0x55c5eee272a0, 
orig_sv=orig_sv@entry=0x55c5ef079858) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6536
#13 0x7f0c4872d3a2 in Perl_sv_free2 (my_perl=0x55c5eee272a0, 
sv=0x55c5ef079858, rc=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:7073
#14 0x7f0c486fc878 in Perl_SvREFCNT_dec (sv=, 
my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/inline.h:405
#15 S_mg_free_struct (my_perl=0x55c5eee272a0, sv=, 
mg=0x55c5ef34bb70) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/mg.c:563
#16 0x7f0c486fc8c9 in Perl_mg_free (my_perl=0x55c5eee272a0, 
sv=0x55c5ef34aec0) at /usr/src/debug/perl-5.36.1-497.fc38.x86_64/mg.c:585
#17 0x7f0c4872cdc3 in Perl_sv_clear 
(my_perl=my_perl@entry=0x55c5eee272a0, 
orig_sv=orig_sv@entry=0x55c5ef34aec0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:6544
#18 0x7f0c4872d3a2 in Perl_sv_free2 (my_perl=0x55c5eee272a0, 
sv=0x55c5ef34aec0, rc=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:7073
#19 0x7f0c48722646 in Perl_SvREFCNT_dec_NN (sv=, 
my_perl=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/inline.h:419
#20 do_clean_objs (ref=0x55c5ef338ce0, my_perl=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:448
#21 S_visit (mask=2048, flags=2048, f=, 
my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:391
#22 Perl_sv_clean_objs (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/sv.c:542
#23 0x7f0c48680160 in perl_destruct (my_perl=0x55c5eee272a0) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perl.c:880
#24 0x55c5eda0f324 in main (argc=, argv=out>, env=) at 
/usr/src/debug/perl-5.36.1-497.fc38.x86_64/perlmain.c:121


I have instrumented dbdimpl.c as follows:

    /* free global environment handle during 
destruction of last connection */
    } else if ( (imp_dbh->envhp == imp_drh->envhp) 
&& (SvTRUE(perl_get_sv("DBI::PERL_ENDING",0))) ) {

    PerlIO_printf(PerlIO_stderr(), "EXIT1\n");
    OCIHandleFree_log_stat(imp_dbh, 
imp_dbh->envhp, OCI_HTYPE_ENV, status);

    PerlIO_printf(PerlIO_stderr(), "EXIT2\n");
    if ( status == OCI_SUCCESS ) {
    PerlIO_printf(PerlIO_stderr(), "EXIT3\n");
    imp_dbh->envhp = NULL;
    imp_drh->envhp = NULL;
    }
    }

And the child prints 'EXIT1', but never 'EXIT2'. If I comment out the 
call to OCIHandleFree_log_stat() then the child process exits without 
error (although there are random segfaults after long run times).


1. A complete log of all steps of the build, e.g.:

Atatched (build.log)

2. Full details of which version of Oracle client and server you're using

# rpm -qa | grep oracle
oracle-instantclient-basic-21.11.0.0.0-1.x8

Re: please help with DBD-Oracle-1.76

[Bruce Johnson]

Also the SDK package needs to be installed or the build fails.

Minimum for DBD::Oracle are the Basic and SDK packages.

On Sep 5, 2022, at 6:43 AM, kmo...@esntech.com<mailto:kmo...@esntech.com> wrote:

Hi Daniel,

I have three questions.


  1.  Did you install the instant client as root? I always install it as Oracle.
  2.  LD_LIBRARY_PATH should be set as =/root/ora2pg/instantclient_21_7/lib in 
your case
  3.  The link you provided has a download to sqlplus, I’d suggest you download 
and install it to satisfy what is in your post


Regards,
Kevin

From: Tim Bunce mailto:tim.bu...@pobox.com>>
Sent: Monday, September 5, 2022 3:16 AM
To: dbi-users@perl.org<mailto:dbi-users@perl.org>
Subject: Fwd: please help with DBD-Oracle-1.76




Begin forwarded message:

From: Daniel Chmielewski 
mailto:daniel.chmielew...@gmail.com>>
Subject: Fwd: please help with DBD-Oracle-1.76
Date: 5 September 2022 at 10:03:15 IST
To: t...@cpan.org<mailto:t...@cpan.org>

Tim, please help.
Regards,
Daniel

-- Forwarded message -
Od: Daniel Chmielewski 
mailto:daniel.chmielew...@gmail.com>>
Date: śr., 31 sie 2022 o 15:10
Subject: please help with DBD-Oracle-1.76
To: mailto:t...@cpan.org>>

Hi TIm,
Can you help me.
I have problem with installing DBD-Oracle-1.76.

At all it works (make install), but tests fail (make tests). It seems that the 
software does not recognized oracle instant client version 21.7. This is a 
'portable' version with only requires unpack in place.
Have you ever made any test with this ?  Please help. Do you have any 
suggestions?
Regards,
Daniel


Short description:
1.
DBD-Oracle-1.76 requires DBI, and all the tests of DBI works fine.
2.
DBI-1.63 (all tests are successful, make, make test, make install => no error 
at all).
3.
I also install instant client from oracle:
https://www.oracle.com/pl/database/technologies/instant-client/linux-x86-64-downloads.html
export ORACLE_HOME=/root/ora2pg/instantclient_21_7
export LD_LIBRARY_PATH=/root/ora2pg/instantclient_21_7
export PATH=$ORACLE_HOME/bin:$PATH

4.
and set env. variable (all at root users), database is located on other server, 
not on this on which is perl installed.

But with DBD-Oracle-1.76 installed on it I get the following error:
========
root@stlx DBD-Oracle-1.76]# perl Makefile.PL
Using DBI 1.643 (for perl 5.026003 on x86_64-linux-thread-multi) installed in 
/usr/local/lib64/perl5/auto/DBI/
Configuring DBD::Oracle for perl 5.026003 on linux (x86_64-linux-thread-multi)

If you encounter any problem, a collection of troubleshooting
guides are available under lib/DBD/Oracle/Troubleshooting.
'DBD::Oracle::Troubleshooting' is the general troubleshooting
guide, while platform-specific troubleshooting hints
live in their labelled sub-document (e.g., Win32
hints are gathered in 'lib/DBD/Oracle/Troubleshooting/Win32.pod').

Installing on a linux, Ver#4.18
Using Oracle in /root/ora2pg/instantclient_21_7
Can't find sqlplus. Pity, it would have helped.
I'm having trouble finding your Oracle version number... trying harder

WARNING: Could not determine Oracle client version, defaulting to
version 9.2.0.4.0. Some features of DBD::Oracle may not work.
Oracle version-based logic in Makefile.PL may produce erroneous
results. You can use "perl Makefile.PL -V X.Y.Z" to specify your
client version.

Oracle Version 9.2.0.4.0 (9.2)
Looks like an Instant Client installation, okay
Your LD_LIBRARY_PATH env var is set to '/root/ora2pg/instantclient_21_7'
Oracle sysliblist:
Found header files in /root/ora2pg/instantclient_21_7/sdk/include.

client_version=9.2


DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"9.2.0.4.0\"


Checking for functioning wait.ph<http://wait.ph/>
_FORTIFY_SOURCE requires compiling with optimization (-O) at 
/usr/lib64/perl5/features.ph<http://features.ph/> line 207.


System: perl5.026003 linux 
x86-038.build.eng.bos.redhat.com<http://x86-038.build.eng.bos.redhat.com/> 
4.18.0-305.17.1.el8_4.x86_64 #1 smp mon aug 30 07:26:31 edt 2021 x86_64 x86_64 
x86_64 gnulinux
Compiler:   gcc   -g -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv 
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64
Linker: /usr/bin/ld
Sysliblist:
Linking with -lclntsh.

LD_RUN_PATH=/root/ora2pg/instantclient_21_7
Using DBD::Oracle 1.76.
Using DBD::Oracle 1.76.
=

Please help,
Daniel


--
Daniel Chmielewski


--
Daniel Chmielewski


--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

RE: please help with DBD-Oracle-1.76

[kmoore]

Hi Daniel,

 

I have three questions.

 

1.  Did you install the instant client as root? I always install it as 
Oracle.
2.  LD_LIBRARY_PATH should be set as =/root/ora2pg/instantclient_21_7/lib 
in your case
3.  The link you provided has a download to sqlplus, I’d suggest you 
download and install it to satisfy what is in your post

 

Regards,

Kevin

 

From: Tim Bunce  
Sent: Monday, September 5, 2022 3:16 AM
To: dbi-users@perl.org
Subject: Fwd: please help with DBD-Oracle-1.76

 

 





Begin forwarded message:

 

From: Daniel Chmielewski mailto:daniel.chmielew...@gmail.com> >

Subject: Fwd: please help with DBD-Oracle-1.76

Date: 5 September 2022 at 10:03:15 IST

To: t...@cpan.org <mailto:t...@cpan.org> 

 

Tim, please help. 

Regards,

Daniel

 

-- Forwarded message -
Od: Daniel Chmielewski mailto:daniel.chmielew...@gmail.com> >
Date: śr., 31 sie 2022 o 15:10
Subject: please help with DBD-Oracle-1.76
To: mailto:t...@cpan.org> >

 

Hi TIm,

Can you help me. 

I have problem with installing DBD-Oracle-1.76. 


At all it works (make install), but tests fail (make tests). It seems that the 
software does not recognized oracle instant client version 21.7. This is a 
'portable' version with only requires unpack in place. 

Have you ever made any test with this ?  Please help. Do you have any 
suggestions?
Regards,

Daniel


====
Short description:
1.
DBD-Oracle-1.76 requires DBI, and all the tests of DBI works fine. 

2.
DBI-1.63 (all tests are successful, make, make test, make install => no error 
at all).

3.

I also install instant client from oracle:
https://www.oracle.com/pl/database/technologies/instant-client/linux-x86-64-downloads.html

export ORACLE_HOME=/root/ora2pg/instantclient_21_7

export LD_LIBRARY_PATH=/root/ora2pg/instantclient_21_7

export PATH=$ORACLE_HOME/bin:$PATH


4.

and set env. variable (all at root users), database is located on other server, 
not on this on which is perl installed. 



But with DBD-Oracle-1.76 installed on it I get the following error:
========

root@stlx DBD-Oracle-1.76]# perl Makefile.PL

Using DBI 1.643 (for perl 5.026003 on x86_64-linux-thread-multi) installed in 
/usr/local/lib64/perl5/auto/DBI/

Configuring DBD::Oracle for perl 5.026003 on linux (x86_64-linux-thread-multi)

 

If you encounter any problem, a collection of troubleshooting

guides are available under lib/DBD/Oracle/Troubleshooting.

'DBD::Oracle::Troubleshooting' is the general troubleshooting

guide, while platform-specific troubleshooting hints

live in their labelled sub-document (e.g., Win32

hints are gathered in 'lib/DBD/Oracle/Troubleshooting/Win32.pod').

 

Installing on a linux, Ver#4.18

Using Oracle in /root/ora2pg/instantclient_21_7

Can't find sqlplus. Pity, it would have helped.

I'm having trouble finding your Oracle version number... trying harder

 

WARNING: Could not determine Oracle client version, defaulting to

version 9.2.0.4.0. Some features of DBD::Oracle may not work.

Oracle version-based logic in Makefile.PL may produce erroneous

results. You can use "perl Makefile.PL -V X.Y.Z" to specify your

client version.

 

Oracle Version 9.2.0.4.0 (9.2)

Looks like an Instant Client installation, okay

Your LD_LIBRARY_PATH env var is set to '/root/ora2pg/instantclient_21_7'

Oracle sysliblist:

Found header files in /root/ora2pg/instantclient_21_7/sdk/include.

 

client_version=9.2

 

 

DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"9.2.0.4.0\"

 

 

Checking for functioning wait.ph <http://wait.ph/> 

_FORTIFY_SOURCE requires compiling with optimization (-O) at 
/usr/lib64/perl5/features.ph <http://features.ph/>  line 207.

 

 

System: perl5.026003 linux x86-038.build.eng.bos.redhat.com 
<http://x86-038.build.eng.bos.redhat.com/>  4.18.0-305.17.1.el8_4.x86_64 #1 smp 
mon aug 30 07:26:31 edt 2021 x86_64 x86_64 x86_64 gnulinux

Compiler:   gcc   -g -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv 
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64

Linker: /usr/bin/ld

Sysliblist:

Linking with -lclntsh.

 

LD_RUN_PATH=/root/ora2pg/instantclient_21_7

Using DBD::Oracle 1.76.

Using DBD::Oracle 1.76.

=



Please help,

Daniel




 

-- 

Daniel Chmielewski




 

-- 

Daniel Chmielewski

 

Fwd: please help with DBD-Oracle-1.76

[Tim Bunce]

> Begin forwarded message:
> 
> From: Daniel Chmielewski 
> Subject: Fwd: please help with DBD-Oracle-1.76
> Date: 5 September 2022 at 10:03:15 IST
> To: t...@cpan.org
> 
> Tim, please help. 
> Regards,
> Daniel
> 
> 
> -- Forwarded message -
> Od: Daniel Chmielewski  <mailto:daniel.chmielew...@gmail.com>>
> Date: śr., 31 sie 2022 o 15:10
> Subject: please help with DBD-Oracle-1.76
> To: mailto:t...@cpan.org>>
> 
> 
> Hi TIm,
> Can you help me. 
> I have problem with installing DBD-Oracle-1.76. 
> 
> At all it works (make install), but tests fail (make tests). It seems that 
> the software does not recognized oracle instant client version 21.7. This is 
> a 'portable' version with only requires unpack in place. 
> Have you ever made any test with this ?  Please help. Do you have any 
> suggestions?
> Regards,
> Daniel
> 
> 
> Short description:
> 1.
> DBD-Oracle-1.76 requires DBI, and all the tests of DBI works fine. 
> 
> 2.
> DBI-1.63 (all tests are successful, make, make test, make install => no error 
> at all).
> 
> 3.
> I also install instant client from oracle:
> https://www.oracle.com/pl/database/technologies/instant-client/linux-x86-64-downloads.html
>  
> <https://www.oracle.com/pl/database/technologies/instant-client/linux-x86-64-downloads.html>
> 
> export ORACLE_HOME=/root/ora2pg/instantclient_21_7
> 
> export LD_LIBRARY_PATH=/root/ora2pg/instantclient_21_7
> 
> export PATH=$ORACLE_HOME/bin:$PATH
> 
> 
> 4.
> and set env. variable (all at root users), database is located on other 
> server, not on this on which is perl installed. 
> 
> 
> But with DBD-Oracle-1.76 installed on it I get the following error:
> ========
> root@stlx DBD-Oracle-1.76]# perl Makefile.PL
> 
> Using DBI 1.643 (for perl 5.026003 on x86_64-linux-thread-multi) installed in 
> /usr/local/lib64/perl5/auto/DBI/
> 
> Configuring DBD::Oracle for perl 5.026003 on linux (x86_64-linux-thread-multi)
> 
>  
> 
> If you encounter any problem, a collection of troubleshooting
> 
> guides are available under lib/DBD/Oracle/Troubleshooting.
> 
> 'DBD::Oracle::Troubleshooting' is the general troubleshooting
> 
> guide, while platform-specific troubleshooting hints
> 
> live in their labelled sub-document (e.g., Win32
> 
> hints are gathered in 'lib/DBD/Oracle/Troubleshooting/Win32.pod').
> 
>  
> 
> Installing on a linux, Ver#4.18
> 
> Using Oracle in /root/ora2pg/instantclient_21_7
> 
> Can't find sqlplus. Pity, it would have helped.
> 
> I'm having trouble finding your Oracle version number... trying harder
> 
>  
> 
> WARNING: Could not determine Oracle client version, defaulting to
> 
> version 9.2.0.4.0. Some features of DBD::Oracle may not work.
> 
> Oracle version-based logic in Makefile.PL may produce erroneous
> 
> results. You can use "perl Makefile.PL -V X.Y.Z" to specify your
> 
> client version.
> 
>  
> 
> Oracle Version 9.2.0.4.0 (9.2)
> 
> Looks like an Instant Client installation, okay
> 
> Your LD_LIBRARY_PATH env var is set to '/root/ora2pg/instantclient_21_7'
> 
> Oracle sysliblist:
> 
> Found header files in /root/ora2pg/instantclient_21_7/sdk/include.
> 
>  
> 
> client_version=9.2
> 
>  
> 
>  
> 
> DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"9.2.0.4.0\"
> 
>  
> 
>  
> 
> Checking for functioning wait.ph <http://wait.ph/>
> _FORTIFY_SOURCE requires compiling with optimization (-O) at 
> /usr/lib64/perl5/features.ph <http://features.ph/> line 207.
> 
>  
> 
>  
> 
> System: perl5.026003 linux x86-038.build.eng.bos.redhat.com 
> <http://x86-038.build.eng.bos.redhat.com/> 4.18.0-305.17.1.el8_4.x86_64 #1 
> smp mon aug 30 07:26:31 edt 2021 x86_64 x86_64 x86_64 gnulinux
> 
> Compiler:   gcc   -g -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -fexceptions -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv 
> -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64
> 
> Linker: /usr/bin/ld
> 
> Sysliblist:
> 
> Linking with -lclntsh.
> 
>  
> 
> LD_RUN_PATH=/root/ora2pg/instantclient_21_7
> 
> Using DBD::Oracle 1.76.
> 
> Using DBD::Oracle 1.76.
> 
> =
> 
> Please help,
> Daniel
> 
> 
> -- 
> Daniel Chmielewski
> 
> 
> -- 
> Daniel Chmielewski

Please test DBD::Oracle v1.90_1

[Dean Hamstead]

Hi All,

Anyone using DBD::Oracle is invited to test out out this dev release v1.90_1

Download from metacpan https://metacpan.org/release/ZARQUON/DBD-Oracle-1.90_1

GH Tag https://github.com/perl5-dbi/DBD-Oracle/tree/v1.90_1

v1.90 candidate branch https://github.com/perl5-dbi/DBD-Oracle/tree/cand-v1.90

This commit is a big big change which should hopefully fix a lot of problems 
https://github.com/perl5-dbi/DBD-Oracle/commit/4dd996e84725ec122e5f2fa2365ca7109bbf1d98

Rewrite of login6
This changes the way things are done during login6 (connect). In
particular:

1. OCIEnv is cached based on character sets and mode. One copy
is used in all threads (so OCI_THREADED is important!)

2. There are no more global variables for character sets. So each
connection uses exactly what is specified at connection time. Thus
option ora_envhp is removed.

3. Improved support for DRCP. Now the pools are independent from
threads. The pool is defined by DSN and UID. No more leaking of
connections or pools. When last imp_drh goes away the pools
are released. It is now also possible to tag sessions in addition
to using connection_class (the latter works only with DRCP).

4. Reauthenticate now keeps old session as long as possible, so
if new identity is wrong, then old session stays intact.

5. Support for using shared variables is also improved. There is
now additional function ora_shared_release that cleans up shared
connection, when it is not needed anymore. Though it is still
cleaner to used DRCP. No more handles are leaking.

6. Support for imp_take is improved. No handles are leaking.
But it is cleaner to use DRCP.

7. Small fixes for compilation and handling of attributes.


Your feedback is most welcome via the pr 
https://github.com/perl5-dbi/DBD-Oracle/pull/150


Cheers

Dean

Re: [External] : DBD::Oracle use_drcp and connection class

[Christopher Jones]

On 5/3/2022 3:44 am, Andrei A. Voropaev via dbi-users wrote:

Hello,

after looking at the sources of DBD::Oracle I am somewhat confused. OCI
offers Session pooling and Connection pooling. "DRCP" is abbreviation
for "connection pooling", but DBD::Oracle offers "session pooling",
which is not exactly the same.

Connected to this is the question about "connection class"
(ora_drcp_class). This parameter is necessary for "connection pooling",
but I couldn't find anything about it in the documentation for "session 
pooling".
Can someone please clarify this? So far it appears, that this parameter
is simply ignored in "session pooling".

Thank you.


I'll give some background, some of which you may know.

For Oracle applications, Oracle Call Interface (OCI) Connection pooling is mostly superseded by OCI Session pooling.  For various reasons to do with 
searchability & user name expectations, we tend to generically refer to 'connection pools' in applications even if at the OCI level the underlying 
Session Pool API is used. As well as giving great app scalability, the Session Pool supports all the goodies of Oracle's "Continuous Availability" 
features.


DRCP is a different pool of 'server' processes that resides on the database host.  These processes are the database end of application connections.  
DRCP is great if the database host is short of memory but it's not a solution for every connection problem.  Check the doc for when it should be used: 
https://www.oracle.com/pls/topic/lookup?ctx=dblatest=GUID-015CA8C1-2386-4626-855D-CC546DDC1086


Both DRCP and OCI Session pools support the concept of a connection class name.  This allows some isolation of session memory if pools are shared 
between distinct use cases.  Commonly session pools are not shared, so connection class isn't set for them.  Setting the class name is more (very) 
important for DRCP since it directly affects performance (as well as giving the security separation).


Although DRCP can be used for any application connection, it is more efficient if it is used in conjunction with OCI Session Pooling (or JDBC 
equivalent). I was going to write more, but I recently put out a blog which mentions DRCP and has a diagram: "Always Use Connection Pools - and How" 
https://blogs.oracle.com/opal/post/always-use-connection-pools There is also further background in miscellaneous doc like 
https://oracle.github.io/node-oracledb/doc/api.html#drcp and https://www.oracle.com/technetwork/topics/php/whatsnew/php-scalability-ha-twp-128842.pdf 
My colleague is currently working on an updated DRCP technical brief; follow the above blog to be notified when it is published.


I can't comment on the DBD::Oracle specifics too much, however there is a reference in the doc to session pooling here: 
https://metacpan.org/pod/DBD::Oracle#ora_envhp  From tracing OCI, when you set ora_drcp then an OCI Session pool is created.  This is nice.  I 
couldn't quickly see if it is efficiently used like a full application pool, but the exposed settings would imply it is.   For example settings like 
ora_drcp_min seem related to sizing of the session pool (which is in the Perl process), not to the DRCP pool (which is in the Database tier).  Sizing 
of the DRCP pool is done via PL/SQL when the pool is created.


Overall, it looks like DBD::Oracle has DRCP+Session Pooling, or no pooling at 
all.

Chris

--
https://twitter.com/ghrd

DBD::Oracle use_drcp and connection class

[Andrei A. Voropaev]

Hello,

after looking at the sources of DBD::Oracle I am somewhat confused. OCI
offers Session pooling and Connection pooling. "DRCP" is abbreviation
for "connection pooling", but DBD::Oracle offers "session pooling",
which is not exactly the same.

Connected to this is the question about "connection class"
(ora_drcp_class). This parameter is necessary for "connection pooling",
but I couldn't find anything about it in the documentation for "session 
pooling".
Can someone please clarify this? So far it appears, that this parameter
is simply ignored in "session pooling".

Thank you.

Re: DBD::Oracle insert speed

[Christopher Jones]

On 10/1/21 11:22 am, Peter Meszaros wrote:

Hi,
I have already asked this question at perlmonks.org 
<https://urldefense.com/v3/__http://perlmonks.org__;!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpZEzbH1Ow$> but I 
did not get proper answer.


Module DBD::Oracle 
<https://urldefense.com/v3/__http://search.cpan.org/perldoc?DBD*3A*3AOracle__;JSU!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpZHuCdBzA$> 
has serious performance degradation at inserting rows. Except execute_array (or bind_param_array), all other insert solutions are pretty slow (eg. 
bind by name). DBD::Oracle use its own wrapper (dbimp.c, oci8.c) and seem to be implemented in an ineffective way. Comparing to otlv4 
(http://otl.sourceforge.net/otl3_intro.htm 
<https://urldefense.com/v3/__http://otl.sourceforge.net/otl3_intro.htm__;!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpYvQ6Ozwg$>) 
which is a wrapper over Oracle's OCI interface written in C++ the basic http://otl.sourceforge.net/otl3_ex10.htm 
<https://urldefense.com/v3/__http://otl.sourceforge.net/otl3_ex10.htm__;!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpaGeVTYiQ$> 
is much (~10 times) faster than DBD::Oracle row based insertion. DBD::Oracle implements DATA_AT_EXEC mode with OCIBindDynamic for row based 
insertion (not array) as can be seen below and this block is repeated for each value.


... dbd_bind_ph(1): bind :id <== '1774684594' (type 0 (DEFAULT (varchar))) dbd_rebind_ph() (1): rebinding :id as '17746...' (not-utf8, ftype 1 
(VARCHAR), csid 0, csform 0(0), inout 0) dbd_rebind_ph_char() (1): bind :id <== '17746...' (size 10/12/0, ptype 3(VARCHAR), otype 1 ) Changing 
maxlen to 12 dbd_rebind_ph_char() (2): bind :id <== '17746...' (size 10/12, otype 1(VARCHAR), indp 0, at_exec 1) bind :id as ftype 1 (VARCHAR) 
OCIBindByName(163ad08,1675e58,1614d20,":id",placeh_len=3,value_p=1675a00,value_sz=12,dty=1,indp=1675e78,alenp=0,rcodep=1675e70,maxarr_len=0,curelep=0 
(*=0),mode=DATA_AT_EXEC,2)=SUCCESS OCIBindDynamic(163a970,1614d20,1675e20,7fdf910dacc0,1675e20,7fdf910daf30)=SUCCESS 
OCIAttrGet(163a970,OCI_HTYPE_BIND,1675e3c,0,31,1614d20)=SUCCESS dbd_rebind_ph(): bind :id <== '17746...' (in, not-utf8, csid 873->0->873, ftype 1 
(VARCHAR), csform 0(0)->0(0), maxlen 12, maxdata_size 0) OCIAttrSet(163a970,OCI_HTYPE_BIND, 7ffda0f7f960,0,Attr=31,1614d20)=SUCCESS ...
[download] 
<https://urldefense.com/v3/__https://perlmonks.org/?displaytype=displaycode;abspart=1;part=1;node_id=11126161__;!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpbjTJWXvg$>
Is this design intentional? OCI documentation said that OCIBindDynamic can be useful at working with big data items 
https://web.stanford.edu/dept/itss/docs/oracle/10gR2/appdev.102/b14250/oci05bnd.htm#i427753 
<https://urldefense.com/v3/__https://web.stanford.edu/dept/itss/docs/oracle/10gR2/appdev.102/b14250/oci05bnd.htm*i427753__;Iw!!GqivPVa7Brio!OybtaVZUVoKl3qAbiNkFHQxZALNrn7ocQA5ft_OycHRoAtyyjCPfcy33Ob-PjpYj5lOcvQ$>. 
C++ code using otlv4 can process blob/clob data and it does not use OCIBindDynamic at all. So, why DBD::Oracle implemented this way?


Thanks in advance

In all language drivers for Oracle DB, the "Array DML" interface is significantly faster compared with a loop that executes individual statements.  
Reducing network round-trips is a big win. See 
https://docs.oracle.com/en/database/oracle/oracle-database/21/lnoci/binding-and-defining-in-oci.html#GUID-442E47AD-83A8-4959-9A73-DBFB7D3482A6


--
https://twitter.com/ghrd

DBD::Oracle insert speed

[Peter Meszaros]

Hi,
I have already asked this question at perlmonks.org but I did not get
proper answer.

Module DBD::Oracle <http://search.cpan.org/perldoc?DBD%3A%3AOracle> has
serious performance degradation at inserting rows. Except execute_array (or
bind_param_array), all other insert solutions are pretty slow (eg. bind by
name). DBD::Oracle use its own wrapper (dbimp.c, oci8.c) and seem to be
implemented in an ineffective way. Comparing to otlv4 (
http://otl.sourceforge.net/otl3_intro.htm) which is a wrapper over Oracle's
OCI interface written in C++ the basic
http://otl.sourceforge.net/otl3_ex10.htm is much (~10 times) faster than
DBD::Oracle row based insertion. DBD::Oracle implements DATA_AT_EXEC mode
with OCIBindDynamic for row based insertion (not array) as can be seen
below and this block is repeated for each value.

...
dbd_bind_ph(1): bind :id <== '1774684594' (type 0 (DEFAULT (varchar)))
dbd_rebind_ph() (1): rebinding :id as '17746...' (not-utf8, ftype 1
(VARCHAR), csid 0, csform 0(0), inout 0)
dbd_rebind_ph_char() (1): bind :id <== '17746...' (size 10/12/0, ptype
3(VARCHAR), otype 1 )
Changing maxlen to 12
dbd_rebind_ph_char() (2): bind :id <== '17746...' (size 10/12, otype
1(VARCHAR), indp 0, at_exec 1)
  bind :id as ftype 1 (VARCHAR)

OCIBindByName(163ad08,1675e58,1614d20,":id",placeh_len=3,value_p=1675a00,value_sz=12,dty=1,indp=1675e78,alenp=0,rcodep=1675e70,maxarr_len=0,curelep=0
(*=0),mode=DATA_AT_EXEC,2)=SUCCESS

OCIBindDynamic(163a970,1614d20,1675e20,7fdf910dacc0,1675e20,7fdf910daf30)=SUCCESS
OCIAttrGet(163a970,OCI_HTYPE_BIND,1675e3c,0,31,1614d20)=SUCCESS
dbd_rebind_ph(): bind :id <== '17746...' (in, not-utf8, csid
873->0->873, ftype 1 (VARCHAR), csform 0(0)->0(0), maxlen 12,
maxdata_size 0)
OCIAttrSet(163a970,OCI_HTYPE_BIND, 7ffda0f7f960,0,Attr=31,1614d20)=SUCCESS
...
[download] 
<https://perlmonks.org/?displaytype=displaycode;abspart=1;part=1;node_id=11126161>

Is this design intentional? OCI documentation said that OCIBindDynamic can
be useful at working with big data items
https://web.stanford.edu/dept/itss/docs/oracle/10gR2/appdev.102/b14250/oci05bnd.htm#i427753.
C++ code using otlv4 can process blob/clob data and it does not use
OCIBindDynamic at all. So, why DBD::Oracle implemented this way?

Thanks in advance

Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Peter Vanroose]

Actually, I did exactly this a few years ago.
Only problem: NULLs show up as blanks ...
Apart from that, it works like a charm!

-- Peter Vanroose.

Op 23 jun. 2020 22:10, om 22:10, "Fennell, Brian"  schreef:
>Another idea . . .
>
>You could also wrap Oracle SQLPlus in perl using qx
>
>How-to SQLPLUS and XML here:
>
>https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3512822500346787661
>
>That and a little perl text parsing could get you a long way - split ,
>grep, map, s and tr.
>
>This pure-perl module can parse the XML:
>https://metacpan.org/pod/XML::SAX::PurePerl
>
>It would be great to have an Oracle DBD driver using pure-perl and
>sqlplus only.   No C complier needed, no buffer overflows to chase
>down, no jvm and no "other" languages (except SQL).
>
>(no time for this kind of perl-uber-hacking myself but anyone looking
>for a fun project . . . )
>
>Another hack is to use perl with qx with jisql (and JDBC drivers) - I
>have used this to access Microsoft SQLServer from perl with little
>work.
>
>https://github.com/stdunbar/jisql
>
>Brian Fennell
>
>
>
>
>The information contained in this electronic mail transmission is
>intended only for the use of the individual or entity named in this
>transmission. If you are not the intended recipient of this
>transmission, you are hereby notified that any disclosure, copying or
>distribution of the contents of this transmission is strictly
>prohibited and that you should delete the contents of this transmission
>from your system immediately. Any comments or statements contained in
>this transmission do not necessarily reflect the views or position of
>Radial or its subsidiaries and/or affiliates.

Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Fennell, Brian]

Another idea . . .

You could also wrap Oracle SQLPlus in perl using qx

How-to SQLPLUS and XML here:

https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3512822500346787661

That and a little perl text parsing could get you a long way - split , grep, 
map, s and tr.

This pure-perl module can parse the XML:
https://metacpan.org/pod/XML::SAX::PurePerl

It would be great to have an Oracle DBD driver using pure-perl and sqlplus 
only.   No C complier needed, no buffer overflows to chase down, no jvm and no 
"other" languages (except SQL).

(no time for this kind of perl-uber-hacking myself but anyone looking for a fun 
project . . . )

Another hack is to use perl with qx with jisql (and JDBC drivers) - I have used 
this to access Microsoft SQLServer from perl with little work.

https://github.com/stdunbar/jisql

Brian Fennell




The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you should delete the contents of this 
transmission from your system immediately. Any comments or statements contained 
in this transmission do not necessarily reflect the views or position of Radial 
or its subsidiaries and/or affiliates.

RE: [EXTERNAL] Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Fennell, Brian]

FYI

The Oracle DBD driver is hard to build, it requires Oracle C Libraries and 
Header files.  It also requires Oracle Development files described by Oracle as 
Examples, but which are really templates for building any C client.  All Oracle 
C Clients are hard to build.  If I recall sometimes a library has to be 
included on the compiler / linker command line three times because of circular 
references of one library to another which cannot be resolved on one pass.  
Ambiguity in wide characters "bytes per character" can make for buffer 
overflows which require a lot of time to hunt down and fix.   Even if you are 
not using wide characters.

The CPAN version of the DBD driver (the last time I checked) is abandonware - 
someone keeps a patched fork on GIT.  You can use cpanm (cpanminus) to build 
directly from git but not cpan.  Docs in the cpanm man page.

Lost mindshare from Perl to python and ruby have contributed to the problem 
remaining unresolved (all bugs are shallow given enough eyeballs - this doesn't 
work so well when the number of eyeballs drops greatly).I ended up 
downgrading both perl 5 and Oracle DBD to workaround a problem we had with a 
Perl/Oracle bug causing buffer overflows and seg-faults. I just couldn't afford 
the hours to fix it properly.  Perl 5 internal structures had changed so much 
that older (working) versions of DBD no longer compiled against newer perl 5s.

One workaround it to consider using the perl JDBC driver to access the Oracle 
JDBC library instead of trying to get the Oracle C Library to compile bug-free. 
 You will need to bootstrap a jvm with the bridge in order to use it.  Calling 
out from perl to a python "select to CSV" or "select to xml" or "select to 
JSON" might be another work-around - depending on your requirements - might be 
faster than booting up a JVM.

Just my experience.




The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you should delete the contents of this 
transmission from your system immediately. Any comments or statements contained 
in this transmission do not necessarily reflect the views or position of Radial 
or its subsidiaries and/or affiliates.

Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Bruce Johnson]

> On Jun 19, 2020, at 3:48 PM, Scott  wrote:
> 
> We have run into an issue when we upgraded to Oracle client 19c. Some of the 
> users processes are segfaulting on exit.
> 
> #0  0x7f82ee84ccc0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1  0x7f82e6444f43 in kputxabt () from 
> /u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1
> #2  0x7f82e926e6c3 in ora_db_rollback () from 
> /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
> #3  0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from 
> /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
> #4  0x7f82ed10291d in XS_DBI_dispatch () from 
> /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so
> 
> I tested the same process on a server still  using the 18c client and the 
> core dump does not happen.  Our DBA is creating
> ticket with Oracle, but I wanted to see if anyone else has had the same issue.

I am not seeing this issue with the 19C instant client ( 19.6 ) running on 
CentOS8, DBD::Oracle 1.80, DBI 1.643.


-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Scott]

On 6/20/20 1:51 PM, Scott wrote:

More info, this error does not occur with DBD::Oracle 1.76.

DBD::Oracle 1.80 => works with 18c client,  but fails with 19c.
DBD::Oracle 1.76 => works with all client versions.


On 6/19/20 5:48 PM, Scott wrote:
We have run into an issue when we upgraded to Oracle client 19c. Some 
of the users processes are segfaulting on exit.


#0  0x7f82ee84ccc0 in pthread_mutex_lock () from 
/lib64/libpthread.so.0
#1  0x7f82e6444f43 in kputxabt () from 
/u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1
#2  0x7f82e926e6c3 in ora_db_rollback () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#3  0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#4  0x7f82ed10291d in XS_DBI_dispatch () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so


I tested the same process on a server still  using the 18c client and 
the core dump does not happen.  Our DBA is creating
ticket with Oracle, but I wanted to see if anyone else has had the 
same issue.


Thanks,

Scott



I assuming this is the change causing the segfault with 19c client.

 Destroy envhp with last dbh (GH#93, GH#89, Dean Hamstead, CarstenGrohmann)

 diff -w ../DBD-Oracle-1.76/dbdimp.c ./dbdimp.c 1
218,222d217
<   if (imp_drh->envhp) {
<   /* Free cached environment handle. */
<   OCIHandleFree_log_stat(imp_drh, imp_drh->envhp, 
OCI_HTYPE_ENV, status);

<   }
<
319c314
<   case ORA_XMLTYPE:   /* SQLT_NTY must be carefull 
here as its value (108) is the same for an embedded object Well realy 
only XML clobs not embedded objects  */

---
>   case ORA_XMLTYPE:   /* SQLT_NTY must be careful 
here as its value (108) is the same for an embedded object Well really 
only XML clobs not embedded objects */

863c858
<   session_pool_t pool_data = { };
---
>   session_pool_t pool_data = {0};
1258a1254
>   /* free session environment handle */
1260a1257,1266
>   if ( status == OCI_SUCCESS ) {
> imp_dbh->envhp = NULL;
>   }
>   /* free global environment handle during 
destruction of last connection */
>   } else if ( (imp_dbh->envhp == imp_drh->envhp) 
&& (SvTRUE(perl_get_sv("DBI::PERL_ENDING",0))) ) {

> OCIHandleFree_log_stat(imp_dbh, imp_dbh->envhp, OCI_HTYPE_ENV, status);
>   if ( status == OCI_SUCCESS ) {
> imp_dbh->envhp = NULL;
> imp_drh->envhp = NULL;
>   }
3739c3745
< as we may have more thatn one exe on a prepare*/
---
> as we may have more than one exe on a prepare*/
4779c4785
< bool can_taf = 0;
---
> boolean can_taf = 0;

Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Scott]

More info, this error does not occur with DBD::Oracle 1.76.

DBD::Oracle 1.80 => works with 18c client,  but fails with 19c.
DBD::Oracle 1.76 => works with all client versions.


On 6/19/20 5:48 PM, Scott wrote:
We have run into an issue when we upgraded to Oracle client 19c. Some 
of the users processes are segfaulting on exit.


#0  0x7f82ee84ccc0 in pthread_mutex_lock () from 
/lib64/libpthread.so.0
#1  0x7f82e6444f43 in kputxabt () from 
/u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1
#2  0x7f82e926e6c3 in ora_db_rollback () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#3  0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#4  0x7f82ed10291d in XS_DBI_dispatch () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so


I tested the same process on a server still  using the 18c client and 
the core dump does not happen.  Our DBA is creating
ticket with Oracle, but I wanted to see if anyone else has had the 
same issue.


Thanks,

Scott

DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy

[Scott]

We have run into an issue when we upgraded to Oracle client 19c. Some of 
the users processes are segfaulting on exit.


#0  0x7f82ee84ccc0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x7f82e6444f43 in kputxabt () from 
/u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1
#2  0x7f82e926e6c3 in ora_db_rollback () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#3  0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#4  0x7f82ed10291d in XS_DBI_dispatch () from 
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so


I tested the same process on a server still  using the 18c client and 
the core dump does not happen.  Our DBA is creating
ticket with Oracle, but I wanted to see if anyone else has had the same 
issue.


Thanks,

Scott

Re: DBD::Oracle install issue on CentOS 8 missing libnsl

[Bruce Johnson]

> On Feb 18, 2020, at 9:58 AM, Bruce Johnson  
> wrote:
> 
> Just a heads up for those of you on the close-to-the-bleeding-edge. libnsl is 
> no longer included with the standard glibc libs with CentOS (and I'm guessing 
> also in RHEL 8, and whatever the current Fedora build is) , and the 
> DBD::Oracle install fails during make test:
> 
> Can't load 
> '/root/.cpan/build/DBD-Oracle-1.80-1/blib/arch/auto/DBD/Oracle/Oracle.so' for 
> module DBD::Oracle: libnsl.so.1: cannot open shared object file: No such file 
> or directory at /usr/lib64/perl5/DynaLoader.pm line 193.
> at -e line 1.
> Compilation failed in require at -e line 1. 
> 
> fortunately it’s still in the repo, so yum install libnsl fixes it.

And because I have the memory of a crack-addled goldfish sometimes, I came back 
here to mention this the next time I ran into this problem :-) 

Since libnsl.so.2 IS installed if you you do the Dev tools group install (so 
you can compile DBD::Oracle in the first place), simply symlinking it to 
libnsl.so.1 also works.

" ln -s /usr/lib64/libnsl.so.2 /usr/lib64/libnsl.so.1”

Although to be fair Feb 18 does feel like it was a year or two ago… 

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

DBD::Oracle install issue on CentOS 8 missing libnsl

[Bruce Johnson]

Just a heads up for those of you on the close-to-the-bleeding-edge. libnsl is 
no longer included with the standard glibc libs with CentOS (and I'm guessing 
also in RHEL 8, and whatever the current Fedora build is) , and the DBD::Oracle 
install fails during make test:

Can't load 
'/root/.cpan/build/DBD-Oracle-1.80-1/blib/arch/auto/DBD/Oracle/Oracle.so' for 
module DBD::Oracle: libnsl.so.1: cannot open shared object file: No such file 
or directory at /usr/lib64/perl5/DynaLoader.pm line 193.
 at -e line 1.
Compilation failed in require at -e line 1. 

fortunately it’s still in the repo, so yum install libnsl fixes it.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

DBD::Oracle - Error with Oracle Wallet

[Gandhi, Rajesh]

Hello dbi-users,

I am modifying existing Perl code to use Oracle wallet functionality (Using 
alias in tnsnames.ora to connect to database without username and password).
The wallet setup is working fine through sqlplus but am getting the following 
error connecting thru perl:

DBI connect('ADW_ADW_DHDEV','',...) failed: ORA-12578: TNS:wallet open failed 
(DBD ERROR: OCISessionBegin) at /home/adw/scripts/tst_perl_conn.pl line 36.

This is how I am calling the DBI connect routine:
$dbh = DBI->connect( 'dbi:Oracle:ADW_ADW_DHDEV','','')

My environment is as below:
Linux RHEL 7.4
Oracle 12.2
DBD::Oracle 1.74


Has anybody in this group faced this or similar issues? Any help will be 
appreciated.
Thanks.


-Rajesh Gandhi


The information contained in this e-mail, and any attachment, is confidential 
and is intended solely for the use of the intended recipient. Access, copying 
or re-use of the e-mail or any attachment, or any information contained 
therein, by any other person is not authorized. If you are not the intended 
recipient please return the e-mail to the sender and delete it from your 
computer. Although we attempt to sweep e-mail and attachments for viruses, we 
do not guarantee that either are virus-free and accept no liability for any 
damage sustained as a result of viruses. 

Please refer to https://disclaimer.bnymellon.com/eu.htm for certain disclosures 
relating to European legal entities. We take our data protection and privacy 
responsibilities seriously and our privacy notice explains how we collect, use 
and share personal information in the course of our business activities. It can 
be accessed at the privacy section of www.albridge.com.

AIX (xlc) DBD::Oracle *without* LIBPATH?

[John Wiersba via dbi-users]

Hi!
I like to know: has anyone been able to get DBD::Oracle working on AIX (6 
and/or 7) using the xlc compiler, *without* having to set LIBPATH *at runtime*? 
 I am able to get it to work by setting LIBPATH, but that's very distasteful 
and I'm trying to find a way to avoid it.
On RHEL Linux, I'm able to avoid setting LD_LIBRARY_PATH, so I would think that 
I could do the same on AIX, but so far I haven't been successful.
I am able to load the Oracle driver without LIBPATH, but DBI->connect fails 
with:


DBI connect(...) failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME (Linux) env 
var  or PATH (Windows) and or NLS settings, permissions, etc. at -e line 30
connection error: ERROR OCIEnvNlsCreate. Check ORACLE_HOME (Linux) env var  or 
PATH (Windows) and or NLS settings, permissions, etc.

I can provide more details if someone thinks it's possible.
Thanks!-- John

DBD-Oracle 1.79 released to the CPAN

[Martin J. Evans]

I have just uploaded DBD::Oracle 1.79 to the CPAN.

  [BUG FIXES]

  Fix Avoid GCC-ism so that HP-UX can compile (GH#92, Dean Hamstead)

  Destroy envhp with last dbh (GH#93, GH#89, Dean Hamstead, 
CarstenGrohmann)


Thanks to everyone who contributed.

Martin

--
Martin J. Evans
Wetherby, UK

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

Thanks, Chris,

I looked at the two kde bugs you pointed out.  Neither of them was an "invalid 
write".
Also the software is actually failing here - not "working but getting valgrind 
errors" as was the case with the kde bugs.

In my case I have "failing and getting valgrind errors".  I can run the same 
case on an older version of perl and an older version of "DBD::Oracle" module 
(with the exact same oracle database) and get no errors.

Valgrind documentation describes an "invalid write" as follows:

http://valgrind.org/docs/manual/mc-manual.html#mc-manual.badrw

For example:

Invalid read of size 4
   at 0x40F6BBCC: (within /usr/lib/libpng.so.2.1.0.9)
   by 0x40F6B804: (within /usr/lib/libpng.so.2.1.0.9)
   by 0x40B07FF4: read_png_image(QImageIO *) (kernel/qpngio.cpp:326)
   by 0x40AC751B: QImageIO::read() (kernel/qimage.cpp:3621)
 Address 0xB0E0 is not stack'd, malloc'd or free'd

This happens when your program reads or writes memory at a place which Memcheck 
reckons it shouldn't. In this example, the program did a 4-byte read at address 
0xB0E0, somewhere within the system-supplied library libpng.so.2.1.0.9, 
which was called from somewhere else in the same library, called from line 326 
of qpngio.cpp, and so on.

Memcheck tries to establish what the illegal address might relate to, since 
that's often useful. So, if it points into a block of memory which has already 
been freed, you'll be informed of this, and also where the block was freed. 
Likewise, if it should turn out to be just off the end of a heap block, a 
common result of off-by-one-errors in array subscripting, you'll be informed of 
this fact, and also where the block was allocated. If you use the 
--read-var-info option Memcheck will run more slowly but may give a more 
detailed description of any illegal address.

In this example, Memcheck can't identify the address. Actually the address is 
on the stack, but, for some reason, this is not a valid stack address -- it is 
below the stack pointer and that isn't allowed. In this particular case it's 
probably caused by GCC generating invalid code, a known bug in some ancient 
versions of GCC.

Note that Memcheck only tells you that your program is about to access memory 
at an illegal address. It can't stop the access from happening. So, if your 
program makes an access which normally would result in a segmentation fault, 
you program will still suffer the same fate -- but you will get a message from 
Memcheck immediately prior to this. In this particular example, reading junk on 
the stack is non-fatal, and the program stays alive.



-Original Message-
From: Christopher Jones [mailto:christopher.jo...@oracle.com] 
Sent: Monday, January 15, 2018 6:56 PM
To: dbi-users@perl.org
Subject: Re: Hunting down (possible) memory leak in DBD::Oracle



On 16/1/18 9:17 am, Fennell, Brian wrote:

> $ egrep -B1 -A20 -i 'invalid write' 
> /copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22 
> ==19402== ==19402== Invalid write of size 4
> ==19402==at 0xBD747E6: __intel_ssse3_rep_memcpy (in 
> /db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
> ==19402==by 0xBD6CE95: _intel_fast_memcpy.P (in 
> /db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)

Valgrind doesn't do the greatest on binaries built with the Intel compiler:

https://bugs.kde.org/show_bug.cgi?id=286769
https://bugs.kde.org/show_bug.cgi?id=139776

Chris

--
http://twitter.com/ghrd

Re: Hunting down (possible) memory leak in DBD::Oracle

[Christopher Jones]

On 16/1/18 9:17 am, Fennell, Brian wrote:


$ egrep -B1 -A20 -i 'invalid write' 
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22
==19402==
==19402== Invalid write of size 4
==19402==at 0xBD747E6: __intel_ssse3_rep_memcpy (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xBD6CE95: _intel_fast_memcpy.P (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)


Valgrind doesn't do the greatest on binaries built with the Intel compiler:

https://bugs.kde.org/show_bug.cgi?id=286769
https://bugs.kde.org/show_bug.cgi?id=139776

Chris

--
http://twitter.com/ghrd

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

I got this case running with valgrind - 
Valgrind reported -
8 invalid writes, 8 invalid writes, 2239 accesses to uninitialized values.
All invalid writes have a stack trace leading back to 
XS_DBD__Oracle__st_fetchrow_array (Oracle.xsi:662) and ora_st_fetch 
(oci8.c:4032)

Details follow:

export DATE_MANIP=DM5;
export ORACLE_HOME=/db/app/oracle/product/12.1.0/client_1 ;
export LD_LIBRARY_PATH=$ORACLE_HOME/lib ;
export 
PATH="$ORACLE_HOME/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin";
export NLS_LANG="AMERICAN_AMERICA.WE8ISO8859P1";
export NLS_NCHAR="AL16UTF16" ;
export NLS_NCHAR_CHARACTERSET="AL16UTF16" ;
export LANGUAGE=en_US:en:C;
export LANG=C;
export LC_ALL=C;
export LC_CTYPE=C;
/bin/rm -rf/feeds/data/search4_1/ProductAttributes-dbi-trace.txt\
   /feeds/data/search4_1/getTableData-debug-log.txt \
   /feeds/data/search4_1/valgrind-log.txt ;
/usr/local/bin/valgrind \
--tool=memcheck \
--leak-check=yes \
--track-origins=yes \
--leak-check=full \
--show-leak-kinds=all \
--num-callers=100 \
--error-limit=no \
--log-file=/feeds/data/search4_1/valgrind-log.txt \
/usr/local/bin/perl \
  [ . . . ]


$ wc -l /copy/sandbox/feeds/data/search4_1/valgrind-log.txt
696325 /copy/sandbox/feeds/data/search4_1/valgrind-log.txt

$ du -h /copy/sandbox/feeds/data/search4_1/valgrind-log.txt
53M /copy/sandbox/feeds/data/search4_1/valgrind-log.txt

$ egrep -c -i 'invalid write' 
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt
8

$ egrep -c -i 'invalid read' /copy/sandbox/feeds/data/search4_1/valgrind-log.txt
8

$ egrep  -c -i 'uninitialised value' 
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt
2239

$ egrep -n -A20  -i 'invalid write' 
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt | egrep 
'(oci8\.c|Oracle\.xsi)'
51575-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51576-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51596-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51597-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51614-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51615-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51670-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51671-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51710-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51711-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51731-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51732-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51771-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51772-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)
51830-==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
51831-==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array 
(Oracle.xsi:662)

$ egrep -B1 -A20 -i 'invalid write' 
/copy/sandbox/feeds/data/search4_1/valgrind-log.txt | head -22
==19402==
==19402== Invalid write of size 4
==19402==at 0xBD747E6: __intel_ssse3_rep_memcpy (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xBD6CE95: _intel_fast_memcpy.P (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF70D36: kpccclr (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF705D7: kpccs2c (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF6ED9E: ttccfpg (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF6C799: ttcfour (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF3B0AE: kpufcpf (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF392F5: kpufch0 (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xCF37C34: kpufch (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xB14F1CA: OCIStmtFetch2 (in 
/db/app/oracle/product/12.1.0/client_1/lib/libclntsh.so.12.1)
==19402==by 0xAA0F269: ora_st_fetch (oci8.c:4032)
==19402==by 0xA9EE595: XS_DBD__Oracle__st_fetchrow_array (Oracle.xsi:662)
==19402==by 0x6D33069: XS_DBI_dispatch (DBI.xs:3797)
==19402==by 0x4EF240E: Perl_pp_entersub (in 
/usr/lib64/perl5/CORE/libperl.so)
==19402==by 0x4EEAB85: Perl_runops_standard (in 
/usr/lib64/perl5/CORE/libperl.so)
==19402==by 0x4E87984: perl_run (in /usr/lib64/perl5/CORE/libperl.so)
==19402==by 0x400D98: ??? (in /usr/bin/perl)
==19402==by 0x6174C04: (below main) (in /usr/lib64/libc-2.17.so)
==19402==  Address 0x14ec4275f is 4,095,739,679 bytes inside a block of size 
4,095,741,856 in arena "client"
==19402==

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

John,

Thanks for your incites.  I tried what you said.  

I read up on NVARCHAR2 v VARCHAR2 - interesting.  I also see that Oracle has a 
way (more than one way) to specify if a VARCHAR2 should contain bytes or 
characters - further while a VARCHAR2(11 byte) and a VARCHAR2(11 char) are 
different (the second can have as many as 4 times as many bytes in it as the 
first) VARCHAR2(4000 byte) and VARCHAR(4000 char) are not different - 4000 
bytes is the max for either - no matter the size of a character.

Unicode makes everything harder.  "CHAR" may mean "BYTE" "2 BYTES" or "4 
BYTES".  And client and server have to agree.

I tried this:  I uses SUBSTRB(field,1,) to truncate the actual bytes coming 
from oracle back to the client.  Results are a bit odd.
For 3999 no change.  For 2000 all errors disappear.   For 3000 - some cases 
that used to error now succeed - but some cases that used to succeed now fail.

I also played with "matching up" the inner select and the outer - which isn't 
really very valuable - the client never sees the data from the inner select - 
and I only added the outer select so I could select by row number (which I 
couldn't do on the inner select since "rownum" is a pseudo column).  The outer 
select is basically the interface that OCI sees.

Specifically cast(SUBSTRB(field,1,2000) as VARCHAR(4000)) errors out exactly 
the same way as no substrb().  

For the 2000 byte case I used cast(SUBSTRB(field,1,2000) as VARCHAR(2000 byte)).

For the 3000 byte case I used cast(SUBSTRB(field,1,3000) as VARCHAR(3000 byte)).

I don't think truncating to 2000 bytes is a solution, but I suppose I could try 
breaking the field into 2 2000 byte strings (or 4 1000 bytes strings) and 
recombine them in some other part of the code.  I would need to consider the 
best way to do that - perhaps a output column naming convention.

I ran all of my variations on the old server and the new server and nothing 
failed on the old server.  Too much output to send it all to the list - if 
anyone wants something specific I can send it.

My money is still on a wild pointer or similar.

I looked thru the DBI log and found the following various field rc error codes 
(sorted):

    field #3 with rc=12851(UNKNOWN RC=12851))
    field #3 with rc=12854(UNKNOWN RC=12854))
    field #3 with rc=20041(UNKNOWN RC=20041))
    field #3 with rc=25934(UNKNOWN RC=25934))
    field #3 with rc=26962(UNKNOWN RC=26962))
    field #3 with rc=48(UNKNOWN RC=48))
    field #3 with rc=83(UNKNOWN RC=83))
    field #4 with rc=1280(UNKNOWN RC=1280))
    field #4 with rc=12870(UNKNOWN RC=12870))
    field #4 with rc=14128(UNKNOWN RC=14128))
    field #4 with rc=17230(UNKNOWN RC=17230))
    field #4 with rc=18688(UNKNOWN RC=18688))
    field #4 with rc=24919(UNKNOWN RC=24919))
    field #4 with rc=25196(UNKNOWN RC=25196))
    field #4 with rc=25926(UNKNOWN RC=25926))
    field #4 with rc=26691(UNKNOWN RC=26691))

I am not really sure which goes with what case - but I am really not thinking 
that the codes are real oracle error codes - but junk data which is a symptom 
of a problem somewhere else.  I could modify the tests to clear out the log and 
capture the "UNKNOWN RC" codes for each, but I would rather to more digging on 
the original case I reported to this list.

Brian Fennell

Re: Hunting down (possible) memory leak in DBD::Oracle

[Peter J. Holzer]

On 2017-12-19 20:55:30 +, Fennell, Brian wrote:
> And, also with the log level set to 15 here are the LAST 200 lines
[...]
> -> fetchrow_array for DBD::Oracle::st 
> (AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
> dbd_st_fetch 6 fields...
> dbd_st_fetched 6 fields with status of 0(SUCCESS)
> field #1 with rc=0(OK)
> 
> 3abd340 (field=0): '1105427'
> field #2 with rc=0(OK)
> 
> 3abd340 (field=1): '1268254'
> field #3 with rc=0(OK)
> 
> 3abd340 (field=2): 'sampl...'
> field #4 with rc=25196(UNKNOWN RC=25196))
> OCIErrorGet(3b535c8,1,"",7ffd7b72b7cc,"ORA-01403: no data found
> ",1024,2)=SUCCESS
> OCIErrorGet after ORA-25196 error on field 4 of 6, ora_type 2 
> (er1:ok): -1, 1403: ORA-01403: no data found
> 
> OCIErrorGet(3b535c8,2,"",7ffd7b72b7cc,"ORA-01403: no data found
> ",1024,2)=NO_DATA
> -- HandleSetErr err=1403, errstr='ORA-01403: no data found (DBD ERROR: 
> ORA-25196 error on field 4 of 6, ora_type 2)', state=undef, undef
> 
> 3abd340 (field=3): undef

Can you check the actual contents of any rows in tableA with
field1=1268254 and field2='sampl...'? The error occurs in field3 which
is numeric, but it's adjacent to field4 which is VARCHAR2(4000). I
wonder if an overflow is possible if field4 is actually close to 4000
characters and it is expanded further by character encoding. Which
raises the next question: What are the database and client encodings set
to?

hp

-- 
   _  | Peter J. Holzer   | I think we need two definitions:
|_|_) | WSR - Softwaredevelopment | 1) The problem the *users* want us to solve
| |   | und Projektunterstützung  | 2) The problem our solution addresses.
__/   | h...@wsr.ac.at |-- Phillip Hallam-Baker on spam


signature.asc
Description: PGP signature

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

And, also with the log level set to 15 here are the LAST 200 lines

3abd340 (field=0): '1127646'
field #2 with rc=0(OK)

3abd340 (field=1): '1268251'
field #3 with rc=0(OK)

3abd340 (field=2): 'a...'
field #4 with rc=0(OK)

3abd340 (field=3): '1'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1127646' '1268251' 'aa' '1' undef 'en_US' 
) [6 items] row858 at /dirname/scriptname.pl line 196
-> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1093644'
field #2 with rc=0(OK)

3abd340 (field=1): '1268251'
field #3 with rc=0(OK)

3abd340 (field=2): 'sampl...'
field #4 with rc=0(OK)

3abd340 (field=3): '1'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1093644' '1268251' 'sampledata' '1' undef 'en_US' 
) [6 items] row859 at /dirname/scriptname.pl line 196
-> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1093997'
field #2 with rc=0(OK)

3abd340 (field=1): '1268252'
field #3 with rc=0(OK)

3abd340 (field=2): 'sampl...'
field #4 with rc=0(OK)

3abd340 (field=3): '1'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1093997' '1268252' 'sampledata' '1' undef 'en_US' 
) [6 items] row860 at /dirname/scriptname.pl line 196
-> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1093904'
field #2 with rc=0(OK)

3abd340 (field=1): '1268252'
field #3 with rc=0(OK)

3abd340 (field=2): 'sampl...'
field #4 with rc=0(OK)

3abd340 (field=3): '1'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1093904' '1268252' 'samplecc' '1' undef 'en_US' ) 
[6 items] row861 at /dirname/scriptname.pl line 196
-> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1127647'
field #2 with rc=0(OK)

3abd340 (field=1): '1268253'
field #3 with rc=0(OK)

3abd340 (field=2): 'd...'
field #4 with rc=0(OK)

3abd340 (field=3): '0'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1127647' '1268253' 'd' '0' undef 'en_US' 
) [6 items] row862 at /dirname/scriptname.pl line 196
    -> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1127648'
field #2 with rc=0(OK)

3abd340 (field=1): '1268253'
field #3 with rc=0(OK)

3abd340 (field=2): 'a...'
field #4 with rc=0(OK)

3abd340 (field=3): '0'
field #5 with rc=1405(NULL)

3abd340 (field=4): undef
field #6 with rc=0(OK)

3abd340 (field=5): 'en_US'
<- fetchrow_array= ( '1127648' '1268253' 'aa' '0' undef 'en_US' 
) [6 items] row863 at /dirname/scriptname.pl line 196
-> fetchrow_array for DBD::Oracle::st 
(AAA::DBI::Connection::st=HASH(0x3abd310)~0x39f75f0) thr#24d4010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)

3abd340 (field=0): '1105426'
field #2 with rc=0(OK)

3abd340 (field=1): '1268253'
field #3 with rc=0(O

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

With the log level set to 15 here are the first 200 lines of log

AAA::DBI::Connection::db=HASH(0x3abce00) trace level set to 0x0/15 (DBI @ 
0x0/0) in DBI 1.637-ithread (pid 12594)
-> STORE for DBD::Oracle::db 
(AAA::DBI::Connection::db=HASH(0x3abce00)~INNER 'RowCacheSize' 2097152) 
thr#24d4010
<- STORE= ( 1 ) [1 items] at /dirname/scriptname.pl line 78
-> prepare for DBD::Oracle::db 
(AAA::DBI::Connection::db=HASH(0x3abcef0)~0x3abce00 'SELECT [ yada yada yada 
]') thr#24d4010
New 'AAA::DBI::Connection::st' (for DBD::Oracle::st, 
parent=AAA::DBI::Connection::db=HASH(0x3abce00), id=undef)

dbih_setup_handle(AAA::DBI::Connection::st=HASH(0x3abd310)=>AAA::DBI::Connection::st=HASH(0x39f75f0),
 DBD::Oracle::st, 268ae18, Null!)
dbih_make_com(AAA::DBI::Connection::db=HASH(0x3abce00), 3abdfc0, 
DBD::Oracle::st, 464, 0) thr#24d4010
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), Err, 
AAA::DBI::Connection::db=HASH(0x3abce00)) SCALAR(0x268acc8) (already defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), State, 
AAA::DBI::Connection::db=HASH(0x3abce00)) SCALAR(0x268ad88) (already defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), Errstr, 
AAA::DBI::Connection::db=HASH(0x3abce00)) SCALAR(0x268ad28) (already defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), TraceLevel, 
AAA::DBI::Connection::db=HASH(0x3abce00)) 15 (already defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), 
FetchHashKeyName, AAA::DBI::Connection::db=HASH(0x3abce00)) 'NAME' (already 
defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), HandleSetErr, 
AAA::DBI::Connection::db=HASH(0x3abce00)) undef (not defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), HandleError, 
AAA::DBI::Connection::db=HASH(0x3abce00)) undef (not defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), ReadOnly, 
AAA::DBI::Connection::db=HASH(0x3abce00)) undef (not defined)
dbih_setup_attrib(AAA::DBI::Connection::st=HASH(0x39f75f0), Profile, 
AAA::DBI::Connection::db=HASH(0x3abce00)) undef (not defined)
OCIHandleAlloc(3b2c0f0,3be0cc8,OCI_HTYPE_STMT,0,0)=SUCCESS
OCIStmtPrepare(3ba3190,3b535c8,'SELECT [ yada yada yada 
]',513,1,0)=SUCCESS

OCIAttrGet(3ba3190,OCI_HTYPE_STMT,3be0cdc,0,OCI_ATTR_STMT_TYPE,3b535c8)=SUCCESS
dbd_st_prepare'd sql SELECT ( auto_lob1, check_sql1)
dbd_describe SELECT (EXPLICIT, lb 80)...

OCIStmtExecute(3b5b028,3ba3190,3b535c8,0,0,0,0,mode=DESCRIBE_ONLY,16)=SUCCESS

OCIAttrGet(3ba3190,OCI_HTYPE_STMT,7ffd7b72baa4,0,OCI_ATTR_PARAM_COUNT,3b535c8)=SUCCESS
OCIParamGet(3ba3190,4,3b535c8,3be10e0,1,OCI_HTYPE_STMT)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1110,0,OCI_ATTR_DATA_TYPE,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1112,0,OCI_ATTR_DATA_SIZE,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1128,0,OCI_ATTR_CHAR_USED,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be112a,0,OCI_ATTR_CHAR_SIZE,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be112c,0,OCI_ATTR_CHARSET_ID,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be112e,0,OCI_ATTR_CHARSET_FORM,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1114,0,OCI_ATTR_PRECISION,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1116,0,OCI_ATTR_SCALE,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1117,0,OCI_ATTR_IS_NULL,3b535c8)=SUCCESS

OCIAttrGet(3ba2e90,OCI_DTYPE_PARAM,3be1118,7ffd7b72baac,OCI_ATTR_NAME,3b535c8)=SUCCESS
Describe col #1 type=2(NVARCHAR2)
Described col  1: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 1, name 
ROW_NUMBER
  : dbsize 22, char_used 0, char_size 0, csid 0, csform 0(0), 
disize 171
fbh 1: 'ROW_NUMBER' NULLable, otype   2->  5, dbsize 22/172, 
p0.s-127
OCIParamGet(3ba3190,4,3b535c8,3be1188,2,OCI_HTYPE_STMT)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11b8,0,OCI_ATTR_DATA_TYPE,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11ba,0,OCI_ATTR_DATA_SIZE,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11d0,0,OCI_ATTR_CHAR_USED,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11d2,0,OCI_ATTR_CHAR_SIZE,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11d4,0,OCI_ATTR_CHARSET_ID,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11d6,0,OCI_ATTR_CHARSET_FORM,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11bc,0,OCI_ATTR_PRECISION,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11be,0,OCI_ATTR_SCALE,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11bf,0,OCI_ATTR_IS_NULL,3b535c8)=SUCCESS

OCIAttrGet(3ba07a0,OCI_DTYPE_PARAM,3be11c0,7ffd7b72baac,OCI_ATTR_NAME,3b535c8)=SUCCESS
Describe col #2 type=2(NVARCHAR2)
Described c

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

John,

Thanks for the ideas to change the cache params - I will try that!

Here is the SQL and the field types:

SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
A.field2 f2,
A.field3 f3,
A.field4 f4,
B.field5 f5
FROM
tableA A,
tableB B
WHERE
B.field6  IN  ( 'TOK3', 'TOK4', 'TOK5' )
AND B.field7  LIKE'A%'
AND B.field8  IN  ('TOK1', 'TOK2')
AND B.fkfield1=   A.field1
ORDER BY
2, 3, 4, 5, 6
  ) d
WHERE
d.row_number <  202
AND d.row_number >= 100

Field Types:

A.field1 NUMBER(12)
A.field2 VARCHAR2(20)
A.field3 NUMBER(15,3)
A.field4 VARCHAR2(4000)
B.field5 VARCHAR2(5)
B.field6 VARCHAR2(20)
B.field7 VARCHAR2(8)
B.field8 VARCHAR2(8)
B.fkfield1   NUMBER(12)

Re: Hunting down (possible) memory leak in DBD::Oracle

[John Scoles]

Well it will be in either one of two .c files  dbdimp.c or oci8.c  The XS side 
of things Oracle.xs is not used very much.


The level 15 debug will get deep inside the c to see where it is happening. The 
trace you gave is a little high level


you are right ORA-01403 dose not make much sense here.


If could be running out of buffer.  Give some of the caching params a tweak


https://metacpan.org/pod/DBD::Oracle#RowCacheSize


if you can try give  fetchrow_hashref a try as see if the error happens there 
as well.


Cheers

John

DBD::Oracle - Oracle database driver for the DBI module 
...<https://metacpan.org/pod/DBD::Oracle#RowCacheSize>
metacpan.org
Oracle database driver for the DBI module ... NAME; VERSION; SYNOPSIS; 
DESCRIPTION; CONSTANTS; DBI CLASS METHODS. connect. OS authentication






From: Fennell, Brian <fenne...@radial.com>
Sent: December 18, 2017 11:25 AM
To: John Scoles; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle

John,
Thanks so much for your reply!

I have put off this work for a few years and now the pressure is on - the 
original box and OS are so old that the DBA and System Engineer and the 
Operations manager have all ganged up on me.

I suppose I could try and work around by downgrading both the perl and the 
DBD::Oracle to the same version we use in production, but it would be nice to 
actually fix the bug if I can.

I tried just downgrading the DBD::Oracle, but changes in perl 5 to support 
MULTIPLICITY made that look like more than just a little work - spend two days 
on it and then backed off.

I am a polyglot programmer so I can program in C and Perl (and about a dozen 
other languages).  I have done enough time with C that it doesn't scare me.  
Valgrind is new to me, but make and gcc and ld are not.
I have started to read the Valgrind docs and it seems to make sense - it 
basically emulates all the CPU instructions with injected instrumentation - I 
assume it works for Intel and Red Hat if it works at all
(and it seems to have a long history and good open source support community).  
Perhaps I am fooling myself, but I figure it is worth a try.

I have negotiated support from both DBA and System Engineering (the Red Hat OS 
guys) so if I am going to fix this now is the time.

The only other option I can think of is to try to get the old code working with 
the DBD::JDBC driver (which would mean adding a JVM running in parallel and 
additional overhead - so I would rather not).

1) The error changes depending on the data - which is why I think it is a 
buffer overrun or a wild pointer - but it is  always in "field N of N" - 
Current I can reproduce with ORA-01403
2) I will re-try at level 15 and post the results - current at 4 (or perhaps 5) 
here is a section from the log (which suggests to me it is happing in the C 
code and not in the Perl

-> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=1405(NULL)
field #5 with rc=0(OK)
field #6 with rc=0(OK)
    -> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=14135(UNKNOWN RC=14135))
OCIErrorGet after ORA-14135 error on field 4 of 6, ora_type 2 (er1:ok): 
-1, 1403: ORA-01403: no data found

-- HandleSetErr err=1403, errstr='ORA-01403: no data found (DBD ERROR: 
ORA-14135 error on field 4 of 6, ora_type 2)', state=undef, undef
field #5 with rc=0(OK)
field #6 with rc=0(OK)
1   -> FETCH for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x286f6b0)~INNER 'ParamValues') thr#134c010

3) I think the most exotic thing in these tables is a VARCHAR2 but I will check 
and post the results.
4) I looks like it is in the XS to me (see answer to 2) - but I suppose it 
could be elsewhere - like a loopback-perl-ref that should be weak but is not.
5) I think I have what I need, DBA installed Oracle 12 OCI client and "dot.so" 
libraries but currently I am concerned that I am using "ins_rdbms.mk" when I 
should be using "demo.mk" or similar - I am getting a Warning (see details 
below) when I run Makefile.PL - I asked DBA to look into installing the 
"demo.mk" file and consider opening up a Oracle METALINK support ticket to see 
if another customer had already solved this with Oracle's help.

Details:

# /usr/local/bin/perl Makefile.PL -g
Using DBI 1.637 (for perl 5.016003 on x86_64-linux-thread-multi) installed in 
/usr/local/lib64/perl5/auto

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

Pluta,

Looks like it is worth a try - when I looked at the project before it looked 
like it was for installing a "per user" perl.  Does it work for root / all 
users on a box as well?

Brian

RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

[Fennell, Brian]

Good question - I have asked DBA and am waiting for a reply.

-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org] 
Sent: Monday, December 18, 2017 11:36 AM
To: Fennell, Brian <fenne...@radial.com>; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Fennell,

Are you seeing anything on the database side, in the alert log, etc.?


Howard


-Original Message-
From: Fennell, Brian [mailto:fenne...@radial.com] 
Sent: Monday, December 18, 2017 8:30 AM
To: Howard, Chris <howa...@prpa.org>; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Thanks for the reply, Howard,

I am using the exact same database - a test database that has copies of the 
production data put into it once a day - besides that it doesn't change much 
(if at all) during the day.

The SQL I am using doesn't leave out a "bad guy" - I thought of that and 
actually had an off-by-one gap in some of my early tests.  Closed that hole by 
changing a ">" to a ">=".

Here is the SQL (with the original table and field names changed to allow for 
sharing

SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
A.field2 f2,
A.field3 f3,
A.field4 f4,
B.field5 f5
FROM
tableA A,
tableB B
WHERE
B.field6  IN  ( 'TOK3', 'TOK4', 'TOK5' )
AND B.field7  LIKE'A%'
AND B.field8  IN  ('TOK1', 'TOK2')
AND B.fkfield1=   A.field1
ORDER BY
1, 2, 3, 4, 5
  ) d
WHERE
d.row_number <  202
AND d.row_number >= 100

-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org] 
Sent: Monday, December 18, 2017 9:21 AM
To: Fennell, Brian <fenne...@radial.com>; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Same database... do you mean the actual very same data source?

What is the Oracle error? 

To eliminate problems based on data (implicit conversions, that kind of thing) 
can you do a run from row 500,000 to 1,500,000 ?  (I think you have this 
covered, but maybe that row right at the breaking spot is somehow a bad guy.)




-Original Message-
From: Fennell, Brian [mailto:fenne...@radial.com]
Sent: Saturday, December 16, 2017 3:19 PM
To: dbi-users@perl.org
Subject: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Dear DBI people - 

I am trying to port some old perl code to a new box.  (see Details below) 
Needless to say the original box and code works fine, but the new box (and old 
code) does not.
Specifically what I am seeing is that when I select slightly over a million 
records from a specific join of two tables (to be dumped one row at a time into 
a TSV file) we get strange ORA-N errors that don't really make any sense in 
this context.
The Same database and same table works fine on the original box with the large 
number of records.  2 million records always causes errors but two groups of 
1million (divided up by ROWNUM - the EXACT same rows) causes no errors.  I am 
using a test database with little activity do I am reasonably certain that the 
queries deal with the same rows.
So I am thinking the problem is data volume and not any specific piece of data 
(originally I thought it might be an odd string/data related error, but I am 
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 , 
$filename )" shows that the error originates inside the DBD::Oracle module 
while reading field 3 of 6.  
Researching the ORA-NN error gives a perfectly sane description that makes 
no sense at all in the context of reading a specific field.  

We are going thru an Audit and tightening up security so there are some things 
(like REAL hostnames and REAL column/table names) that I cannot share - but I 
will try to share as much as I can.

The Host I am calling "prod" below is the only one NOT exhibiting this issue.

Things I want to try - 

1) recompile the DBD::Oracle module on Host "sandbox" with "perl Makefile.PL 
-g" and then use Valgrind.  I haven't used Valgrind before, but I guess it is 
time to learn.
2) Anything else this list suggests. 

Details:

Host: prod
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Perl: 5.8.8 built for x86_64-linux
DBI: 1.53
DBD::Oracle: 1.19
Oracle: 10.2.0.1.0

Host: dev
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.74
Oracle: 11.2.0.3.0

Host: prodnew
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built f

RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

[Fennell, Brian]

Ok . . . I am already benefiting from the support from this list : - ) 

I noticed that I was actually ordering my query BY rownum (which doesn't make 
much sense . . . and perhaps oracle's optimizer recognized this and ignored the 
pseudo column.)

Just to be sure, I change the query and then reran my tests - the results, 
however, did not change

New SQL

SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
A.field2 f2,
A.field3 f3,
A.field4 f4,
B.field5 f5
FROM
tableA A,
tableB B
WHERE
B.field6  IN  ( 'TOK3', 'TOK4', 'TOK5' )
AND B.field7  LIKE'A%'
AND B.field8  IN  ('TOK1', 'TOK2')
AND B.fkfield1=   A.field1
ORDER BY
2, 3, 4, 5, 6
  ) d
WHERE
d.row_number <  202
AND d.row_number >= 100

Here is a summary of the test results (I have a test harness which uses ssh to 
run the exact same tests on more than one host).

INPUT: ( ( HOSTNAME = sandbox ) ( RANGE = 200   0 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 2 )
INPUT: ( ( HOSTNAME = prod) ( RANGE = 200   0 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = sandbox ) ( RANGE = 100   0 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = prod) ( RANGE = 100   0 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = sandbox ) ( RANGE = 200 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = prod) ( RANGE = 200 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = sandbox ) ( RANGE = 202 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = prod) ( RANGE = 202 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )
INPUT: ( ( HOSTNAME = sandbox ) ( RANGE = 203 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 2 )
INPUT: ( ( HOSTNAME = prod) ( RANGE = 203 100 ) ) OUTPUT: ( 
ORACLE_ERROR_COUNT = 0 )

RE: Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

John,
Thanks so much for your reply!

I have put off this work for a few years and now the pressure is on - the 
original box and OS are so old that the DBA and System Engineer and the 
Operations manager have all ganged up on me.

I suppose I could try and work around by downgrading both the perl and the 
DBD::Oracle to the same version we use in production, but it would be nice to 
actually fix the bug if I can.

I tried just downgrading the DBD::Oracle, but changes in perl 5 to support 
MULTIPLICITY made that look like more than just a little work - spend two days 
on it and then backed off.  

I am a polyglot programmer so I can program in C and Perl (and about a dozen 
other languages).  I have done enough time with C that it doesn't scare me.  
Valgrind is new to me, but make and gcc and ld are not.
I have started to read the Valgrind docs and it seems to make sense - it 
basically emulates all the CPU instructions with injected instrumentation - I 
assume it works for Intel and Red Hat if it works at all 
(and it seems to have a long history and good open source support community).  
Perhaps I am fooling myself, but I figure it is worth a try.

I have negotiated support from both DBA and System Engineering (the Red Hat OS 
guys) so if I am going to fix this now is the time.

The only other option I can think of is to try to get the old code working with 
the DBD::JDBC driver (which would mean adding a JVM running in parallel and 
additional overhead - so I would rather not).

1) The error changes depending on the data - which is why I think it is a 
buffer overrun or a wild pointer - but it is  always in "field N of N" - 
Current I can reproduce with ORA-01403
2) I will re-try at level 15 and post the results - current at 4 (or perhaps 5) 
here is a section from the log (which suggests to me it is happing in the C 
code and not in the Perl

-> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=1405(NULL)
field #5 with rc=0(OK)
field #6 with rc=0(OK)
-> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=14135(UNKNOWN RC=14135))
OCIErrorGet after ORA-14135 error on field 4 of 6, ora_type 2 (er1:ok): 
-1, 1403: ORA-01403: no data found

-- HandleSetErr err=1403, errstr='ORA-01403: no data found (DBD ERROR: 
ORA-14135 error on field 4 of 6, ora_type 2)', state=undef, undef
field #5 with rc=0(OK)
field #6 with rc=0(OK)
1   -> FETCH for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x286f6b0)~INNER 'ParamValues') thr#134c010

3) I think the most exotic thing in these tables is a VARCHAR2 but I will check 
and post the results.
4) I looks like it is in the XS to me (see answer to 2) - but I suppose it 
could be elsewhere - like a loopback-perl-ref that should be weak but is not.
5) I think I have what I need, DBA installed Oracle 12 OCI client and "dot.so" 
libraries but currently I am concerned that I am using "ins_rdbms.mk" when I 
should be using "demo.mk" or similar - I am getting a Warning (see details 
below) when I run Makefile.PL - I asked DBA to look into installing the 
"demo.mk" file and consider opening up a Oracle METALINK support ticket to see 
if another customer had already solved this with Oracle's help.

Details:

# /usr/local/bin/perl Makefile.PL -g
Using DBI 1.637 (for perl 5.016003 on x86_64-linux-thread-multi) installed in 
/usr/local/lib64/perl5/auto/DBI/

Configuring DBD::Oracle for perl 5.016003 on linux (x86_64-linux-thread-multi)

Remember to actually *READ* the README file! Especially if you have any 
problems.

Installing on a linux, Ver#3.10
Using Oracle in /db/app/oracle/product/12.1.0/client_1
DEFINE _SQLPLUS_RELEASE = "1201000200" (CHAR)
Oracle version 12.1.0.2 (12.1)
Found /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk
Using /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk
Your LD_LIBRARY_PATH env var is set to 
'/db/app/oracle/product/12.1.0/client_1/lib:/db/app/oracle/product/12.1.0/client_1'
Reading /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk
Reading /db/app/oracle/product/12.1.0/client_1/rdbms/lib/env_rdbms.mk
WARNING: Oracle /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk 
doesn't define a 'build' rule.

WARNING: I will now try to guess how to build and link DBD::Oracle for you.
 This kind of guess work is very error prone and Oracle-version 
sensitive.
     It is p

RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

[Fennell, Brian]

Thanks for the reply, Howard,

I am using the exact same database - a test database that has copies of the 
production data put into it once a day - besides that it doesn't change much 
(if at all) during the day.

The SQL I am using doesn't leave out a "bad guy" - I thought of that and 
actually had an off-by-one gap in some of my early tests.  Closed that hole by 
changing a ">" to a ">=".

Here is the SQL (with the original table and field names changed to allow for 
sharing

SELECT
d.ROW_NUMBER,
d.f1,
d.f2,
d.f3,
d.f4,
d.f5
FROM
(
SELECT /*+ FULL(A) PARALLEL(A 6) */
rownum ROW_NUMBER,
A.field1 f1 ,
A.field2 f2,
A.field3 f3,
A.field4 f4,
B.field5 f5
FROM
tableA A,
tableB B
WHERE
B.field6  IN  ( 'TOK3', 'TOK4', 'TOK5' )
AND B.field7  LIKE'A%'
AND B.field8  IN  ('TOK1', 'TOK2')
AND B.fkfield1=   A.field1
ORDER BY
1, 2, 3, 4, 5
  ) d
WHERE
d.row_number <  202
AND d.row_number >= 100

-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org] 
Sent: Monday, December 18, 2017 9:21 AM
To: Fennell, Brian <fenne...@radial.com>; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Same database... do you mean the actual very same data source?

What is the Oracle error? 

To eliminate problems based on data (implicit conversions, that kind of thing) 
can you do a run from row 500,000 to 1,500,000 ?  (I think you have this 
covered, but maybe that row right at the breaking spot is somehow a bad guy.)




-Original Message-
From: Fennell, Brian [mailto:fenne...@radial.com]
Sent: Saturday, December 16, 2017 3:19 PM
To: dbi-users@perl.org
Subject: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **

Dear DBI people - 

I am trying to port some old perl code to a new box.  (see Details below) 
Needless to say the original box and code works fine, but the new box (and old 
code) does not.
Specifically what I am seeing is that when I select slightly over a million 
records from a specific join of two tables (to be dumped one row at a time into 
a TSV file) we get strange ORA-N errors that don't really make any sense in 
this context.
The Same database and same table works fine on the original box with the large 
number of records.  2 million records always causes errors but two groups of 
1million (divided up by ROWNUM - the EXACT same rows) causes no errors.  I am 
using a test database with little activity do I am reasonably certain that the 
queries deal with the same rows.
So I am thinking the problem is data volume and not any specific piece of data 
(originally I thought it might be an odd string/data related error, but I am 
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 , 
$filename )" shows that the error originates inside the DBD::Oracle module 
while reading field 3 of 6.  
Researching the ORA-NN error gives a perfectly sane description that makes 
no sense at all in the context of reading a specific field.  

We are going thru an Audit and tightening up security so there are some things 
(like REAL hostnames and REAL column/table names) that I cannot share - but I 
will try to share as much as I can.

The Host I am calling "prod" below is the only one NOT exhibiting this issue.

Things I want to try - 

1) recompile the DBD::Oracle module on Host "sandbox" with "perl Makefile.PL 
-g" and then use Valgrind.  I haven't used Valgrind before, but I guess it is 
time to learn.
2) Anything else this list suggests. 

Details:

Host: prod
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Perl: 5.8.8 built for x86_64-linux
DBI: 1.53
DBD::Oracle: 1.19
Oracle: 10.2.0.1.0

Host: dev
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.74
Oracle: 11.2.0.3.0

Host: prodnew
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.70
Oracle: 11.2.0.1.0

Host: sandbox
OS: CentOS Linux release 7.4.1708 (Core)
Perl: 5.16.3  built for x86_64-linux-thread-multi
DBI: 1.637
DBD::Oracle: 1.74
Oracle: 12.1.0.2.0

--
Brian Fennell, Software Engineer | Radial
O: 610 491 7308 | M: 484 354 1699
fenne...@radial.com

The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you 

Re: Hunting down (possible) memory leak in DBD::Oracle

[John Scoles]

Hmm this type of DBD::Oracle debugging will be tricky.

Could be almost anything.  You are jumping versions in a big way but that still 
should be ok

A few questions

1)  What is the  ORA-NN  in question
2) Set trace to 15  to see if that give you more details
3) What are the type of fields?  Lob and blob and large varchars can be tricky
4) does the error happen in perl or XS (the 15 trace should)
5) To recompile you will need the latest version of the OCI client. Not sure 
what that is

Cheers
John





From: Fennell, Brian <fenne...@radial.com>
Sent: December 16, 2017 5:19 PM
To: dbi-users@perl.org
Subject: Hunting down (possible) memory leak in DBD::Oracle

Dear DBI people -

I am trying to port some old perl code to a new box.  (see Details below) 
Needless to say the original box and code works fine, but the new box (and old 
code) does not.
Specifically what I am seeing is that when I select slightly over a million 
records from a specific join of two tables (to be dumped one row at a time into 
a TSV file) we get strange ORA-N errors that don't really make any sense in 
this context.
The Same database and same table works fine on the original box with the large 
number of records.  2 million records always causes errors but two groups of 
1million (divided up by ROWNUM - the EXACT same rows) causes no errors.  I am 
using a test database with little activity do I am reasonably certain that the 
queries deal with the same rows.
So I am thinking the problem is data volume and not any specific piece of data 
(originally I thought it might be an odd string/data related error, but I am 
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 , 
$filename )" shows that the error originates inside the DBD::Oracle module 
while reading field 3 of 6.
Researching the ORA-NN error gives a perfectly sane description that makes 
no sense at all in the context of reading a specific field.

We are going thru an Audit and tightening up security so there are some things 
(like REAL hostnames and REAL column/table names) that I cannot share - but I 
will try to share as much as I can.

The Host I am calling "prod" below is the only one NOT exhibiting this issue.

Things I want to try -

1) recompile the DBD::Oracle module on Host "sandbox" with "perl Makefile.PL 
-g" and then use Valgrind.  I haven't used Valgrind before, but I guess it is 
time to learn.
2) Anything else this list suggests.

Details:

Host: prod
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Perl: 5.8.8 built for x86_64-linux
DBI: 1.53
DBD::Oracle: 1.19
Oracle: 10.2.0.1.0

Host: dev
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.74
Oracle: 11.2.0.3.0

Host: prodnew
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.70
Oracle: 11.2.0.1.0

Host: sandbox
OS: CentOS Linux release 7.4.1708 (Core)
Perl: 5.16.3  built for x86_64-linux-thread-multi
DBI: 1.637
DBD::Oracle: 1.74
Oracle: 12.1.0.2.0

--
Brian Fennell, Software Engineer | Radial
O: 610 491 7308 | M: 484 354 1699
fenne...@radial.com

The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you should delete the contents of this 
transmission from your system immediately. Any comments or statements contained 
in this transmission do not necessarily reflect the views or position of Radial 
or its subsidiaries and/or affiliates.

 >++[>++>++>++>+++>+++>++>+++>+++><<<<<<<<<-]>-->++>+>>>+>-->--><<<<<<<<<>.>.>.>.>.>.>.>.

Hunting down (possible) memory leak in DBD::Oracle

[Fennell, Brian]

Dear DBI people - 

I am trying to port some old perl code to a new box.  (see Details below) 
Needless to say the original box and code works fine, but the new box (and old 
code) does not.
Specifically what I am seeing is that when I select slightly over a million 
records from a specific join of two tables (to be dumped one row at a time into 
a TSV file) we get strange ORA-N errors that don't really make any sense in 
this context.
The Same database and same table works fine on the original box with the large 
number of records.  2 million records always causes errors but two groups of 
1million (divided up by ROWNUM - the EXACT same rows) causes no errors.  I am 
using a test database with little activity do I am reasonably certain that the 
queries deal with the same rows.
So I am thinking the problem is data volume and not any specific piece of data 
(originally I thought it might be an odd string/data related error, but I am 
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 , 
$filename )" shows that the error originates inside the DBD::Oracle module 
while reading field 3 of 6.  
Researching the ORA-NN error gives a perfectly sane description that makes 
no sense at all in the context of reading a specific field.  

We are going thru an Audit and tightening up security so there are some things 
(like REAL hostnames and REAL column/table names) that I cannot share - but I 
will try to share as much as I can.

The Host I am calling "prod" below is the only one NOT exhibiting this issue.

Things I want to try - 

1) recompile the DBD::Oracle module on Host "sandbox" with "perl Makefile.PL 
-g" and then use Valgrind.  I haven't used Valgrind before, but I guess it is 
time to learn.
2) Anything else this list suggests. 

Details:

Host: prod
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Perl: 5.8.8 built for x86_64-linux
DBI: 1.53
DBD::Oracle: 1.19
Oracle: 10.2.0.1.0

Host: dev
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.74
Oracle: 11.2.0.3.0

Host: prodnew
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.70
Oracle: 11.2.0.1.0

Host: sandbox
OS: CentOS Linux release 7.4.1708 (Core)
Perl: 5.16.3  built for x86_64-linux-thread-multi
DBI: 1.637
DBD::Oracle: 1.74
Oracle: 12.1.0.2.0

--
Brian Fennell, Software Engineer | Radial
O: 610 491 7308 | M: 484 354 1699
fenne...@radial.com

The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you should delete the contents of this 
transmission from your system immediately. Any comments or statements contained 
in this transmission do not necessarily reflect the views or position of Radial 
or its subsidiaries and/or affiliates.

 >++[>++>++>++>+++>+++>++>+++>+++><<<<<<<<<-]>-->++>+>>>+>-->--><<<<<<<<<>.>.>.>.>.>.>.>.

DBD::Oracle BLOB updates on multiple rows

[Marcus Bergner]

Hi,?

Running an update like below with DBD::Oracle that updates 2 rows with the same 
BLOB value bound as ORA_BLOB fails with the following inside oci8.c


if (row_count  > 1)
return oci_error(sth, errhp, OCI_ERROR, "LOB refetch attempted for 
multiple rows");

and I'm having a hard time understanding why it isn't possible to do something 
like this?


UPDATE tbl SET blobcol=? WHERE id IN (?,?)


I've found advise saying I should bind the parameter as SQLT_BIN (which is the 
same as ORA_RAW, both have the value 23) and I'm wondering if anyone can 
explain what is going on here? RAW and BLOB are different data types with 
different storage mechanisms in Oracle so it feels strange to bind it as 
SQLT_BIN when the column is a BLOB. It seems to work ok when binding with 
SQLT_BIN but I would appreciate some clarification on that this is the right 
way to do it.


If I hack oci8.c and literally remove the above if statement the UPDATE goes 
through but seemingly produces a broken result where only the last row gets the 
correct BLOB value and the preceding rows now contain an empty BLOB (i.e. if 
they had a previous value it gets wiped out).


Just trying to understand what is special about BLOBs in this case. It feels 
like a perfectly normal use case to be able to update more than one row in a 
single statement regardless of column data types.


Thanks & kind regards,


/ Marcus

RE: (Fwd) DBD::Oracle quote_identifier

[LAWS, MICHAEL H]

Never mind,  I think I found the problem...

I was utilizing  the wrong database handle (!!) ..

I think it works as expected, which explains why I could find nothing on this. 

Please disregard.
Thanks,

Michael Laws

-Original Message-
From: Tim Bunce [mailto:tim.bu...@pobox.com] 
Sent: Wednesday, August 17, 2016 4:25 AM
To: dbi-users@perl.org
Cc: LAWS, MICHAEL H <ml3...@att.com>
Subject: (Fwd) DBD::Oracle quote_identifier

- Forwarded message from "LAWS, MICHAEL H" <ml3...@att.com> -

Date: Tue, 16 Aug 2016 21:04:20 +
From: "LAWS, MICHAEL H" <ml3...@att.com>
To: "t...@cpan.org" <t...@cpan.org>
Subject: DBD::Oracle quote_identifier

   Hello,



   I was using quote_identifier for table names on an oracle database.

   My code uses DBI, which implements the specifics in this case via 
DBD::Oracle.

   It appears to be using backticks which oracle throws an error when it sees 
an invalid character.

   Substituting all instances of backtick with the double quote, from oracle 
documentation,

   Causes it to work and is hopefully still more secure than not using quote 
functions at all.



   Am I missing something or would this be an open or previously closed issue?



   Thanks,

   Michael Laws

- End forwarded message -

(Fwd) DBD::Oracle quote_identifier

[Tim Bunce]

- Forwarded message from "LAWS, MICHAEL H" <ml3...@att.com> -

Date: Tue, 16 Aug 2016 21:04:20 +
From: "LAWS, MICHAEL H" <ml3...@att.com>
To: "t...@cpan.org" <t...@cpan.org>
Subject: DBD::Oracle quote_identifier

   Hello,



   I was using quote_identifier for table names on an oracle database.

   My code uses DBI, which implements the specifics in this case via 
DBD::Oracle.

   It appears to be using backticks which oracle throws an error when it sees 
an invalid character.

   Substituting all instances of backtick with the double quote, from oracle 
documentation,

   Causes it to work and is hopefully still more secure than not using quote 
functions at all.



   Am I missing something or would this be an open or previously closed issue?



   Thanks,

   Michael Laws

- End forwarded message -

Re: Bundle::DBI and DBD::Oracle failing

[John D Groenveld]

In message <e6f16041fbdb904fb1f53d6a2b651858a62...@server.smi-ieso.lan>, "Tony 
D'Alfonso" writes:
>Does it still make a difference running it as 32-bit on a 64-bit machine.  I`v
>e strictly been trying it on 64 bit.

What does file(1) report about the architecture of your Oracle.so?
# file /root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so

What does ldd(1) report about missing dependencies?
# ldd /root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so

Are the dependencies installed?
Can you find(1) them?

John
groenv...@acm.org

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

Does it still make a difference running it as 32-bit on a 64-bit machine.  I`ve 
strictly been trying it on 64 bit.

Regards,
 Tony.

-Original Message-
From: Tony D'Alfonso 
Sent: June 23, 2016 9:55 AM
To: 'Bruce Johnson'
Cc: dbi users
Subject: RE: Bundle::DBI and DBD::Oracle failing

Already have that one too!  This thing has been killing me!!!

# yum install libstdc++-devel.x86_64
Loaded plugins: product-id, search-disabled-repos, subscription-manager
rhel-7-server-optional-rpms 
 | 2.1 kB  00:00:00 
rhel-7-server-rpms  
 | 2.5 kB  00:00:00 
rhel-7-server-supplementary-rpms
 | 2.5 kB  00:00:00 
(1/6): rhel-7-server-optional-rpms/7Server/x86_64/updateinfo
 | 2.5 MB  00:00:00 
(2/6): rhel-7-server-supplementary-rpms/7Server/x86_64/updateinfo   
 |  36 kB  00:00:00 
(3/6): rhel-7-server-optional-rpms/7Server/x86_64/primary   
 | 2.6 MB  00:00:00 
(4/6): rhel-7-server-rpms/7Server/x86_64/updateinfo 
 | 2.8 MB  00:00:00 
(5/6): rhel-7-server-supplementary-rpms/7Server/x86_64/primary  
 |  51 kB  00:00:00 
(6/6): rhel-7-server-rpms/7Server/x86_64/primary
 |  19 MB  00:00:01 
rhel-7-server-optional-rpms 
16576/16576
rhel-7-server-rpms  
20802/20802
rhel-7-server-supplementary-rpms
226/226
Package libstdc++-devel-4.8.5-4.el7.x86_64 already installed and latest version 
Nothing to do

Regards,
Tony.

-Original Message-
From: Bruce Johnson [mailto:john...@pharmacy.arizona.edu]
Sent: June 22, 2016 5:12 PM
To: Tony D'Alfonso
Cc: dbi users
Subject: Re: Bundle::DBI and DBD::Oracle failing


> On Jun 22, 2016, at 1:26 PM, Tony D'Alfonso <tony.dalfo...@smi-ieso.ca> wrote:
> 
> SDK was installed too:
> 
> # yum list oracle-instantclient*
> Loaded plugins: product-id, search-disabled-repos, 
> subscription-manager Installed Packages
> oracle-instantclient-basic.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-devel.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-sqlplus.x86_64   
> 10.2.0.3-1   installed
> 

You know it’s vaguely coming back to me that I had to install several _devel 
packages as well as the lib packages when I last set up a linux server.

You may need the libstdc++-devel.x86_64 package...



--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

Already have that one too!  This thing has been killing me!!!

# yum install libstdc++-devel.x86_64 
Loaded plugins: product-id, search-disabled-repos, subscription-manager
rhel-7-server-optional-rpms 
 | 2.1 kB  00:00:00 
rhel-7-server-rpms  
 | 2.5 kB  00:00:00 
rhel-7-server-supplementary-rpms
 | 2.5 kB  00:00:00 
(1/6): rhel-7-server-optional-rpms/7Server/x86_64/updateinfo
 | 2.5 MB  00:00:00 
(2/6): rhel-7-server-supplementary-rpms/7Server/x86_64/updateinfo   
 |  36 kB  00:00:00 
(3/6): rhel-7-server-optional-rpms/7Server/x86_64/primary   
 | 2.6 MB  00:00:00 
(4/6): rhel-7-server-rpms/7Server/x86_64/updateinfo 
 | 2.8 MB  00:00:00 
(5/6): rhel-7-server-supplementary-rpms/7Server/x86_64/primary  
 |  51 kB  00:00:00 
(6/6): rhel-7-server-rpms/7Server/x86_64/primary
 |  19 MB  00:00:01 
rhel-7-server-optional-rpms 
16576/16576
rhel-7-server-rpms  
20802/20802
rhel-7-server-supplementary-rpms
226/226
Package libstdc++-devel-4.8.5-4.el7.x86_64 already installed and latest version
Nothing to do

Regards,
Tony.

-Original Message-
From: Bruce Johnson [mailto:john...@pharmacy.arizona.edu] 
Sent: June 22, 2016 5:12 PM
To: Tony D'Alfonso
Cc: dbi users
Subject: Re: Bundle::DBI and DBD::Oracle failing


> On Jun 22, 2016, at 1:26 PM, Tony D'Alfonso <tony.dalfo...@smi-ieso.ca> wrote:
> 
> SDK was installed too:
> 
> # yum list oracle-instantclient*
> Loaded plugins: product-id, search-disabled-repos, 
> subscription-manager Installed Packages
> oracle-instantclient-basic.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-devel.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-sqlplus.x86_64   
> 10.2.0.3-1   installed
> 

You know it’s vaguely coming back to me that I had to install several _devel 
packages as well as the lib packages when I last set up a linux server.

You may need the libstdc++-devel.x86_64 package...



--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Bundle::DBI and DBD::Oracle failing

[John R Pierce]

On 6/22/2016 2:05 PM, Bruce Johnson wrote:
On Jun 22, 2016, at 1:34 PM, John R Pierce <pie...@hogranch.com 
<mailto:pie...@hogranch.com>> wrote:


if root installed it to /root, no other user can see or access that.


running cpan as root is fine, since that doesn’t affect the 
permissions of the final perl executables. The only thing it affects 
is keeping track of what has been installed via cpan, since the .cpan 
metadata lives in root’s home directory. 


but the OP also said...


perl /stl/bin/test.pl

install_driver(Oracle) failed: Can't load 
'/root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so' 
for module DBD::Oracle: libstdc++.so.5: cannot open shared object file


which suggests Oracle.so was built under /root/perl5

OTOH, as others suggested, the OP probably needs to 'yum install 
compat-libstdc++'  (for RHEL/centos 6, which I believe is what the OP has)




--
john r pierce, recycling bits in santa cruz

Re: Bundle::DBI and DBD::Oracle failing

[Bruce Johnson]

> On Jun 22, 2016, at 1:26 PM, Tony D'Alfonso  wrote:
> 
> SDK was installed too:
> 
> # yum list oracle-instantclient*
> Loaded plugins: product-id, search-disabled-repos, subscription-manager
> Installed Packages
> oracle-instantclient-basic.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-devel.x86_64 
> 10.2.0.3-1   installed
> oracle-instantclient-sqlplus.x86_64   
> 10.2.0.3-1   installed
> 

You know it’s vaguely coming back to me that I had to install several _devel 
packages as well as the lib packages when I last set up a linux server.

You may need the libstdc++-devel.x86_64 package...



-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Bundle::DBI and DBD::Oracle failing

[Bruce Johnson]

On Jun 22, 2016, at 1:34 PM, John R Pierce 
> wrote:


if root installed it to /root, no other user can see or access that.

running cpan as root is fine, since that doesn’t affect the permissions of the 
final perl executables. The only thing it affects is keeping track of what has 
been installed via cpan, since the .cpan metadata lives in root’s home 
directory.

Heck in OS X, I have to run cpan via sudo or I can’t install anything.

 and no way no how you should be doing Oracle database work while logged on as 
the unix root user.


Oracle won’t even let you install it as root as of 11.2 (at least, probably 
much earlier but I went from 8.1.2 to 11.2 in one swell foop) .



--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

SDK was installed too:

# yum list oracle-instantclient*
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Installed Packages
oracle-instantclient-basic.x86_64 
10.2.0.3-1   installed
oracle-instantclient-devel.x86_64 
10.2.0.3-1   installed
oracle-instantclient-sqlplus.x86_64   
10.2.0.3-1   installed

-Original Message-
From: Bruce Johnson [mailto:john...@pharmacy.arizona.edu] 
Sent: June 22, 2016 4:23 PM
To: Tony D'Alfonso
Cc: dbi users
Subject: Re: Bundle::DBI and DBD::Oracle failing


> On Jun 22, 2016, at 12:32 PM, Tony D'Alfonso <tony.dalfo...@smi-ieso.ca> 
> wrote:
> 
> Hi Carl,
> 
> I used CPAN to install them and it appeared as though they are in place:
> 
> # cpan -i Bundle::DBI
> Reading '/root/.cpan/Metadata'
>  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT DBI is up to 
> date (1.636).
> DBI::Shell is up to date (11.95).
> Storable is up to date (2.51).
> Net::Daemon is up to date (0.48).
> RPC::PlServer is up to date (0.2020).
> DBD::Multiplex is up to date (2.11).
> [root@screendoor ~]# cpan -i DBD::Oracle Reading 
> '/root/.cpan/Metadata'
>  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT DBD::Oracle 
> is up to date (1.74).
> 
> I'm using the Oracle 10 client.  Defined the environment variables as:
> export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client64
> export LD_LIBRARY_PATH=$ORACLE_HOME/lib export 
> LD_RUN_PATH=$ORACLE_HOME/lib export PATH=$PATH:$ORACLE_HOME/bin

I know I’ve gotten this error with Instant Client when the SDK component wasn’t 
installed. I haven’t used the full client in years so I don’t know if the SDK 
is automatically installed or not. 


--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Bundle::DBI and DBD::Oracle failing

[John R Pierce]

On 6/22/2016 12:32 PM, Tony D'Alfonso wrote:

I used CPAN to install them and it appeared as though they are in place:

# cpan -i Bundle::DBI
Reading '/root/.cpan/Metadata'
   Database was generated on Wed, 22 Jun 2016 13:29:02 GMT


if root installed it to /root, no other user can see or access that.

the Oracle user account that wants to run the perl scripts should 
instead be the ones to run CPAN.   and no way no how you should be doing 
Oracle database work while logged on as the unix root user.



--
john r pierce, recycling bits in santa cruz

Re: Bundle::DBI and DBD::Oracle failing

[Bruce Johnson]

> On Jun 22, 2016, at 12:32 PM, Tony D'Alfonso <tony.dalfo...@smi-ieso.ca> 
> wrote:
> 
> Hi Carl,
> 
> I used CPAN to install them and it appeared as though they are in place:
> 
> # cpan -i Bundle::DBI
> Reading '/root/.cpan/Metadata'
>  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT
> DBI is up to date (1.636).
> DBI::Shell is up to date (11.95).
> Storable is up to date (2.51).
> Net::Daemon is up to date (0.48).
> RPC::PlServer is up to date (0.2020).
> DBD::Multiplex is up to date (2.11).
> [root@screendoor ~]# cpan -i DBD::Oracle
> Reading '/root/.cpan/Metadata'
>  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT
> DBD::Oracle is up to date (1.74).
> 
> I'm using the Oracle 10 client.  Defined the environment variables as:
> export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client64
> export LD_LIBRARY_PATH=$ORACLE_HOME/lib
> export LD_RUN_PATH=$ORACLE_HOME/lib
> export PATH=$PATH:$ORACLE_HOME/bin

I know I’ve gotten this error with Instant Client when the SDK component wasn’t 
installed. I haven’t used the full client in years so I don’t know if the SDK 
is automatically installed or not. 


-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Bundle::DBI and DBD::Oracle failing

[Furst, Carl]

It means you don¹t have the Oracle DBD installed. Or its installed to a
different place.

Did you install it? Where?

Carl Yamamoto-Furst
-- 





From:  Tony D'Alfonso <tony.dalfo...@smi-ieso.ca>
Date:  Wednesday, June 22, 2016 at 2:00 PM
To:  "dbi-users@perl.org" <dbi-users@perl.org>
Subject:  RE: Bundle::DBI and DBD::Oracle failing


Confirming this email made it through.  Slicing the output into multiple
messages.  Can you help me with this error message?
 
perl /stl/bin/test.pl
install_driver(Oracle) failed: Can't load
'/root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
 for module DBD::Oracle:
 libstdc++.so.5: cannot open shared object file: No such file or directory
at /usr/lib64/perl5/DynaLoader.pm line 190.
at (eval 4) line 3.
Compilation failed in require at (eval 4) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /stl/bin/test.pl line 3.
 




**

MLB.com <http://mlb.com> - Where Baseball is Always On.

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

Hi Carl,

I used CPAN to install them and it appeared as though they are in place:

# cpan -i Bundle::DBI
Reading '/root/.cpan/Metadata'
  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT
DBI is up to date (1.636).
DBI::Shell is up to date (11.95).
Storable is up to date (2.51).
Net::Daemon is up to date (0.48).
RPC::PlServer is up to date (0.2020).
DBD::Multiplex is up to date (2.11).
[root@screendoor ~]# cpan -i DBD::Oracle
Reading '/root/.cpan/Metadata'
  Database was generated on Wed, 22 Jun 2016 13:29:02 GMT
DBD::Oracle is up to date (1.74).

I'm using the Oracle 10 client.  Defined the environment variables as:
export ORACLE_HOME=/usr/lib/oracle/10.2.0.3/client64
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export LD_RUN_PATH=$ORACLE_HOME/lib
export PATH=$PATH:$ORACLE_HOME/bin

Here's a snippet of a perl -V output:
Summary of my perl5 (revision 5 version 16 subversion 3) configuration:
   
  Platform:
osname=linux, osvers=2.6.32-504.16.2.el6.x86_64, 
archname=x86_64-linux-thread-multi
uname='linux x86-021.build.eng.bos.redhat.com 2.6.32-504.16.2.el6.x86_64 #1 
smp tue mar 10 17:01:00 edt 2015 x86_64 x86_64 x86_64 gnulinux '



Built under linux
  Compiled at Jul  7 2015 08:36:18
  %ENV:
PERL5LIB="/root/perl5/lib/perl5:"
PERL_LOCAL_LIB_ROOT=":/root/perl5"
PERL_MB_OPT="--install_base /root/perl5"
PERL_MM_OPT="INSTALL_BASE=/root/perl5"
  @INC:
/root/perl5/lib/perl5/x86_64-linux-thread-multi
/root/perl5/lib/perl5
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5



-Original Message-
From: Furst, Carl [mailto:carl.yamamotofu...@mlb.com] 
Sent: June 22, 2016 3:28 PM
To: Tony D'Alfonso; dbi-users@perl.org
Subject: Re: Bundle::DBI and DBD::Oracle failing

It means you don¹t have the Oracle DBD installed. Or its installed to a 
different place.

Did you install it? Where?

Carl Yamamoto-Furst
-- 





From:  Tony D'Alfonso <tony.dalfo...@smi-ieso.ca>
Date:  Wednesday, June 22, 2016 at 2:00 PM
To:  "dbi-users@perl.org" <dbi-users@perl.org>
Subject:  RE: Bundle::DBI and DBD::Oracle failing


Confirming this email made it through.  Slicing the output into multiple 
messages.  Can you help me with this error message?
 
perl /stl/bin/test.pl
install_driver(Oracle) failed: Can't load 
'/root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
 for module DBD::Oracle:
 libstdc++.so.5: cannot open shared object file: No such file or directory at 
/usr/lib64/perl5/DynaLoader.pm line 190.
at (eval 4) line 3.
Compilation failed in require at (eval 4) line 3.
Perhaps a required shared library or dll isn't installed where expected at 
/stl/bin/test.pl line 3.
 




**

MLB.com <http://mlb.com> - Where Baseball is Always On.

Re: Bundle::DBI and DBD::Oracle failing

[Dean Pearce]

That library is part of a compatibility package that isn't installed by 
default. On my build machine I've had to do the following:


sudo yum -y install compat-libstdc++-33

After that the build succeeded.

On 2016-06-22 2:00 PM, Tony D'Alfonso wrote:


Confirming this email made it through.  Slicing the output into 
multiple messages.  Can you help me with this error message?


perl /stl/bin/test.pl

install_driver(Oracle) failed: Can't load 
'/root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so' 
for module DBD::Oracle: libstdc++.so.5: cannot open shared object 
file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 
190.


at (eval 4) line 3.

Compilation failed in require at (eval 4) line 3.

Perhaps a required shared library or dll isn't installed where expected

at /stl/bin/test.pl line 3.



--
*Dean Pearce*
Software Developer - Monitoring Tools Prime

Pythian - Love your data

pea...@pythian.com <mailto:pea...@pythian.com> | Twitter: @deanpearce 
<http://www.twitter.com/deanpearce> | Linkedin: Dean Pearce 
<http://www.linkedin.com/in/deanpearce89>


Tel: +1 613 565 8696 x 1384
Mobile: +1 613 697 2114
www.pythian.com <http://www.pythian.com>


--


--

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

 

 

# perl -V

Summary of my perl5 (revision 5 version 16 subversion 3) configuration:

   

  Platform:

osname=linux, osvers=2.6.32-504.16.2.el6.x86_64, 
archname=x86_64-linux-thread-multi

uname='linux x86-021.build.eng.bos.redhat.com 2.6.32-504.16.2.el6.x86_64 #1 
smp tue mar 10 17:01:00 edt 2015 x86_64 x86_64 x86_64 gnulinux '

config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches   -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags 
-Dlddlflags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 
-mtune=generic -Wl,-z,relro  -DDEBUGGING=-g -Dversion=5.16.3 
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, 
Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local 
-Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 
-Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl 
-Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl 
-Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 
/usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace 
-Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog 
-Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly 
-Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto 
-Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto 
-Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin 
-Dusesitecustomize'

hint=recommended, useposix=true, d_sigaction=define

useithreads=define, usemultiplicity=define

useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef

use64bitint=define, use64bitall=define, uselongdouble=undef

usemymalloc=n, bincompat5005=undef

  Compiler:

cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64',

optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
-mtune=generic',

cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-fstack-protector -I/usr/local/include'

ccversion='', gccversion='4.8.3 20140911 (Red Hat 4.8.3-9)', gccosandvers=''

intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678

d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16

ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8

alignbytes=8, prototype=define

  Linker and Libraries:

ld='gcc', ldflags =' -fstack-protector'

libpth=/usr/local/lib64 /lib64 /usr/lib64

libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc 
-lgdbm_compat

perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc

libc=, so=so, useshrplib=true, libperl=libperl.so

gnulibc_version='2.17'

  Dynamic Linking:

dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, 
ccdlflags='-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE'

cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic 
-Wl,-z,relro '

 

 

Characteristics of this binary (from libperl): 

  Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS

PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT

PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_64_BIT_ALL

USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES

USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE

USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF

USE_REENTRANT_API USE_SITECUSTOMIZE

  Locally applied patches:

 Fedora Patch1: Removes date check, Fedora/RHEL specific

 Fedora Patch3: support for libdir64

 Fedora Patch4: use libresolv instead of libbind

 Fedora Patch5: USE_MM_LD_RUN_PATH

 Fedora Patch6: Skip hostname tests, due to builders not being network 
capable

 Fedora Patch7: Dont run one io test due to random builder failures

 Fedora Patch9: Fix find2perl to translate ? glob properly (RT#113054)

 Fedora Patch10: Fix broken atof (RT#109318)

 Fedora Patch13: Clear $@ before "do" I/O error (RT#113730)

 Fedora Patch14: Do not truncate syscall() return value to 32 bits 
(RT#113980)

 Fedora Patch15: Override the Pod::Simple::parse_file (CPANRT#77530)

 Fedora Patch16: Do not leak with attribute on my variable (RT#114764)

 Fedora Patch17: Allow operator after numeric keyword argument (RT#105924)

 Fedora Patch18: Extend stack in File::Glob::glob, (RT#114984)

 Fedora Patch19: Do not 

RE: Bundle::DBI and DBD::Oracle failing

[Tony D'Alfonso]

Confirming this email made it through.  Slicing the output into multiple 
messages.  Can you help me with this error message?

 

perl /stl/bin/test.pl

install_driver(Oracle) failed: Can't load 
'/root/perl5/lib/perl5/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so' for 
module DBD::Oracle: libstdc++.so.5: cannot open shared object file: No such 
file or directory at /usr/lib64/perl5/DynaLoader.pm line 190.

at (eval 4) line 3.

Compilation failed in require at (eval 4) line 3.

Perhaps a required shared library or dll isn't installed where expected

at /stl/bin/test.pl line 3.

 

Re: Help with DBD::Oracle install

[Martin J. Evans]

On 05/02/2016 20:35, Tim Bunce wrote:

Hi. I don't provide support for DBD::Oracle directly. Please email
dbi-users@perl.org or, if you'd rather not just yet, then something here
will probably help:
https://www.google.com/search?q=dbd-oracle+/usr/ucb/cc:++language+optional+software+package+not+installed

Tim.

On Fri, Feb 05, 2016 at 05:40:52PM +, Linn, Steven D CTR (US) wrote:

Hi Tim,

I have hit a wall as far as trying to get this module to install, so I was
wondering if you might know where I go from here...I am on a Solaris 10
server running Oracle 10.2.0. When I run 'make', I get the following
error...Any help would be greatly appreciated!


[root: ]
rsol0018# ls
CONTRIBUTING.mkd  Makefile.PL   blib  oci.def
CONTRIBUTORS  Oracle.c  dbdimp.c  oci8.c
Changes   Oracle.h  dbdimp.h  ocitrace.h
INSTALL   Oracle.xs dbivport.hpm_to_blib
LICENSE   Oracle.xsiexamples  t
MANIFEST  READMEhints typemap
META.json README.help.txt   lib
META.yml  README.mkdn   mk.pm
Makefile  Todo  mkta.pl
[root: ]
redslsa0sol0018# make
cc -c  -I/opt/oracle/product/10.2.0/client_1/rdbms/public
-I/opt/oracle/product/10.2.0/client_1/rdbms/demo
-I/opt/oracle/product/10.2.0/client_1/rdbms/public
-I/opt/oracle/product/10.2.0/client_1/plsql/public
-I/opt/oracle/product/10.2.0/client_1/network/public
-I/usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int/auto/DBI
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO
-DPERL_USE_SAFE_PUTENV -xO3 -xspace -xildoff-DVERSION=\"1.74\"
-DXS_VERSION=\"1.74\" -KPIC
"-I/usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE"  -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"10.2.0.5\" -DORA_OCI_102 Oracle.c
/usr/ucb/cc:  language optional software package not installed
*** Error code 1
make: Fatal error: Command failed for target `Oracle.o'



You need to install a C compiler - the one your Perl was built with is 
most likely to work.


Martin
--
Martin J. Evans
Wetherby, UK

DBD::Oracle and RHEL Instant Client rpms

[Bruce Johnson]

Has anyone else had trouble installing DBD::Oracle with the latest 12.1 instant 
client? 

I installed the Basic and Development IC rpm’s and the DBD installer complained 
it couldn’t determine what version I had, then complained it couldn’t find 
demo.mk. I finally got it to work by manually telling it what version and the 
path to the .mk file (which hadn’t changed from previous versions: 
/usr/share/oracle//client64…)

The various env values were set correctly, and the files were installed in the 
usual place, the only difference between this time and the last time I set up a 
RHEL system was I used the latest 12.1 instant client files rather than 11.2.

[root@kalendaetest DBD-Oracle-1.74-EIJTlU]# set |grep ora
LD_LIBRARY_PATH=/usr/lib/oracle/12.1/client64/lib
ORACLE_HOME=/usr/lib/oracle/12.1/client64
PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lib/oracle/12.1/client64/bin
TNS_ADMIN=/usr/lib/oracle/12.1/client64/admin

It worked, eventually, just wondering if others have run into the issue...

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: DBD::Oracle and RHEL Instant Client rpms

[Bruce Johnson]

> On Oct 20, 2015, at 2:22 PM, Martin J. Evans <boh...@ntlworld.com> wrote:
> 
> 
> I don't use an RPM based system. I download instantclient basic, devel and 
> sqlplus zips and unzip them then point DBD::Oracle at them by setting 
> LD_LIBRARY_PATH.
> 
> Did you download the sqlplus RPM (assuming there is one) as DBD::Oracle uses 
> sqlplus during the install to work out what version of the Oracle client you 
> have?

No I didn’t, since I don’t need it on this system, and figured I’d save some 
time/disk space. Probably a bad idea on my part. 

The server is working fine though, I was just a bit puzzled. I”ll have to go 
look back and see if I did install SQLPlus on the other systems. The problem is 
I set up a new server just once in a blue moon, not all the time, and forget 
all the bits and bobs I need.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: DBD::Oracle and RHEL Instant Client rpms

[Martin J. Evans]

On 20/10/2015 19:53, Bruce  Johnson wrote:

Has anyone else had trouble installing DBD::Oracle with the latest 12.1 instant 
client?

I installed the Basic and Development IC rpm’s and the DBD installer complained it 
couldn’t determine what version I had, then complained it couldn’t find demo.mk. I 
finally got it to work by manually telling it what version and the path to the .mk 
file (which hadn’t changed from previous versions: 
/usr/share/oracle//client64…)

The various env values were set correctly, and the files were installed in the 
usual place, the only difference between this time and the last time I set up a 
RHEL system was I used the latest 12.1 instant client files rather than 11.2.

[root@kalendaetest DBD-Oracle-1.74-EIJTlU]# set |grep ora
LD_LIBRARY_PATH=/usr/lib/oracle/12.1/client64/lib
ORACLE_HOME=/usr/lib/oracle/12.1/client64
PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lib/oracle/12.1/client64/bin
TNS_ADMIN=/usr/lib/oracle/12.1/client64/admin

It worked, eventually, just wondering if others have run into the issue...



I don't use an RPM based system. I download instantclient basic, devel 
and sqlplus zips and unzip them then point DBD::Oracle at them by 
setting LD_LIBRARY_PATH.


Did you download the sqlplus RPM (assuming there is one) as DBD::Oracle 
uses sqlplus during the install to work out what version of the Oracle 
client you have?


Martin
--
Martin J. Evans
Wetherby, UK

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[Kurt Jaeger]

Hi!

  There's a newer linux-oracle-instantclient-sdk available in the
  ports (10.2.0.3), and maybe it helps to compile and link a newer
  DBD::Oracle.
 
 I have that one (actually, those three), but they are nine
 years old as well: 20061115_5 is coded into the ports name.

The API did not change that much, so I guess it might work to use 10.2.0.3
to update the DBD::Oracle port to 1.74.

I'm currently upgrading my test host from perl5.20 to perl5.22, so it
will take some time until I can experiment with 1.74.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[William Bulley]

According to Kurt Jaeger dbi-us...@opsec.eu on Thu, 06/04/15 at 09:38:
 
 My guess: no-one had the need, time and skills to fix it.
 
 There's a newer linux-oracle-instantclient-sdk available in the
 ports (10.2.0.3), and maybe it helps to compile and link a newer
 DBD::Oracle.

I have that one (actually, those three), but they are nine
years old as well: 20061115_5 is coded into the ports name.

 And there's an newer version (12.1.0.2.0) pending commit:
 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157544

Thanks!  :-)

Regards,

web...

-- 

 /\   ASCII RIBBON  / William Bulley
 \ /   CAMPAIGN AGAINST / 
  XHTML E-MAIL AND / E-MAIL: w...@umich.edu
 / \   LISTSERV POSTINGS  /

72 characters width template -|

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[Kurt Jaeger]

Hi!

 What is confusing to me is why FreeBSD _still_ contains
 DBD::Oracle 1.19 in their ports tree!  After all these years!

Because:

DBD::Oracle no longer supports Oracle client versions before 9.2 
 Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.

and there is no oracle9-client port on FreeBSD.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[Kurt Jaeger]

Hi!

   There's a newer linux-oracle-instantclient-sdk available in the
   ports (10.2.0.3), and maybe it helps to compile and link a newer
   DBD::Oracle.
  
  I have that one (actually, those three), but they are nine
  years old as well: 20061115_5 is coded into the ports name.
 
 The API did not change that much, so I guess it might work to use 10.2.0.3
 to update the DBD::Oracle port to 1.74.
 
 I'm currently upgrading my test host from perl5.20 to perl5.22, so it
 will take some time until I can experiment with 1.74.

It looks promising, but:

The FreeBSD ld does not like the SYSV shared lib to link with:

LD_RUN_PATH=/compat/linux/usr/lib/oracle/10.2.0.3/client/lib cc  -shared  
-L/usr/ports/lang/perl5.22/work/perl-5.22.0 
-L/usr/local/lib/perl5/5.22/mach/CORE 
-Wl,-rpath=/usr/local/lib/perl5/5.22/mach/CORE -lperl -L/usr/local/lib 
-fstack-protector Oracle.o  dbdimp.o  oci8.o  -o 
blib/arch/auto/DBD/Oracle/Oracle.so
-L/compat/linux/usr/lib/oracle/10.2.0.3/client/lib 
-L/usr/local/home/pi/myp/databases/p5-DBD-Oracle/work/DBD-Oracle-1.74/../.. 
-locci -lclntsh -lpthread   
/usr/bin/ld: skipping incompatible 
/compat/linux/usr/lib/oracle/10.2.0.3/client/lib/libocci.so when searching for 
-locci
/usr/bin/ld: cannot find -locci
cc: error: linker command failed with exit code 1 (use -v to see invocation)

file /compat/linux/usr/lib/oracle/10.2.0.3/client/lib/libocci.so

libocci.so.10.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), 
dynamically linked, not stripped

and I do not have a non-shared lib to link against. Any ideas ?

Can a SYSV shared lib be transformed into some other shlib ?

-- 
p...@opsec.eu+49 171 3101372 5 years to go !

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[William Bulley]

According to Kurt Jaeger dbi-us...@opsec.eu on Thu, 06/04/15 at 02:50:
 
 DBD::Oracle no longer supports Oracle client versions before 9.2 
  Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.
 
 and there is no oracle9-client port on FreeBSD.

Thanks.  That makes sense.  What doesn't make sense and begs the
following question is:

   Why isn't there an oracle9-client port for FreeBSD?

Is this an Oracle issue?  Is this a FreeBSD issue?  Or what?  Thanks!

Regards,

web...

-- 

 /\   ASCII RIBBON  / William Bulley
 \ /   CAMPAIGN AGAINST / 
  XHTML E-MAIL AND / E-MAIL: w...@umich.edu
 / \   LISTSERV POSTINGS  /

72 characters width template -|

Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[Kurt Jaeger]

Hi!

 According to Kurt Jaeger dbi-us...@opsec.eu on Thu, 06/04/15 at 02:50:

  DBD::Oracle no longer supports Oracle client versions before 9.2 
   Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.
  
  and there is no oracle9-client port on FreeBSD.
 
 Thanks.  That makes sense.  What doesn't make sense and begs the
 following question is:
 
Why isn't there an oracle9-client port for FreeBSD?
 
 Is this an Oracle issue?  Is this a FreeBSD issue?  Or what?  Thanks!

My guess: no-one had the need, time and skills to fix it.

There's a newer linux-oracle-instantclient-sdk available in the
ports (10.2.0.3), and maybe it helps to compile and link a newer
DBD::Oracle.

And there's an newer version (12.1.0.2.0) pending commit:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157544

-- 
p...@opsec.eu+49 171 3101372 5 years to go !

DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)

[parv]

in message 20150603172207.gf2...@itcom245.staff.itd.umich.edu,
wrote William Bulley thusly...

...
 My focus now is trying to install DBD::Oracle 1.74 from CPAN (from
 April of 2014) on my system.
...
 What is confusing to me is why FreeBSD _still_ contains
 DBD::Oracle 1.19 in their ports tree!  After all these years!

Since it's maintainership was passed to perl@freebsd ...

  r296145 | skv | 2012-05-07 05:42:51 -1000 (Mon, 07 May 2012) | 4 lines

  Pass maintainership of almost of my p5-* ports to perl@.

  (I hope updating of them will be improved).


... DBD::Oracle has not been updated. (The updates that are there are
related to Ports infrastructure  build/install.)

Somebody needs to file a PR to update the port. (Tsk, tsk [0,1].)


  - parv


  [0] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

  [1] 
https://bugs.freebsd.org/bugzilla/enter_bug.cgi?component=Individual%20Port%28s%29product=Ports%20%26%20Packages

-- 

RE: (Fwd) Issue :DBD::Oracle installation

[Ranjitha]

Yeah .. I was still getting the error even after loading oracle library path.. 
, but somehow it  is installed now.. with some warnings.. I think I can ignore 
those warning.. and all good now :) :)

Thanks a lot Bruce, Martin and Tim for your timely reply and help :) :),, you 
guys just rock !!!

Thanks and regards,
Ranjitha

M:  +91 9739463575
T:   +91 8039136322
ranji...@infosys.com

-Original Message-
From: Bruce Johnson [mailto:john...@pharmacy.arizona.edu]
Sent: Monday, June 09, 2014 12:58 AM
To: Ranjitha
Subject: Re: (Fwd) Issue :DBD::Oracle installation


On Jun 5, 2014, at 10:49 PM, Ranjitha ranji...@infosys.com wrote:

   Installing on a linux, Ver#2.6

   Using Oracle in /usr/lib/oracle/11.2/client64

   sqlplus: error while loading shared libraries: libsqlplus.so: cannot open 
 shared object file: No such
   file or directory



   If sqlplus failed due to a linker/symbol/relocation/library 
 error or similar problem

   then it's likely that you've not configured your environment 
 correctly.

   Specifically, your LD_LIBRARY_PATH environment variable

   set to include the directory containing the Oracle libraries.

This is exactly the answer: You need to make sure that the LD_LIBRARY_PATH is 
properly set *in the environment of the process running the perl script*

This is what Martin meant about being able to RUN sqlplus, not that it's 
installed. Log on as the user you're doing the install as and check the 
environment. When that user can run sqlplus, DBD::Oracle will successfully 
build.

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are 
not
to copy, disclose, or distribute this e-mail or its contents to any other 
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
every reasonable precaution to minimize this risk, but is not liable for any 
damage
you may sustain as a result of any virus in this e-mail. You should carry out 
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this 
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

RE: (Fwd) Issue :DBD::Oracle installation

[Ranjitha]

Hi Tim/Dbi-users

Please help :)

Thanks and regards,
Ranjitha

M:  +91 9739463575
T:   +91 8039136322
ranji...@infosys.com

-Original Message-
From: tim.bu...@pobox.com [mailto:tim.bu...@pobox.com] 
Sent: Wednesday, June 04, 2014 5:14 PM
To: dbi-users@perl.org
Cc: Ranjitha
Subject: (Fwd) Issue :DBD::Oracle installation

- Forwarded message from Ranjitha ranji...@infosys.com -

Date: Wed, 4 Jun 2014 11:05:34 +
From: Ranjitha ranji...@infosys.com
To: tim.bu...@pobox.com tim.bu...@pobox.com, t...@cpan.org t...@cpan.org
Subject: Issue :DBD::Oracle installation

   Hi Tim

   Facing an issue while installing DBD::Oracle  module from CPAN.

   Direct installation on server cpan DBD::Oracle is failing.

   I manually tried installing the module which CPAN has downloaded, below is 
the log.

   ciw-app1:~/.cpan/build/DBD-Oracle-1.74-vjnZmt # perl Makefile.PL

   Multiple copies of Driver.xst found in:
   /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/
   /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/ at 
Makefile.PL line 39

   Using DBI 1.631 (for perl 5.01 on x86_64-linux-thread-multi) installed in
   /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/



   Configuring DBD::Oracle for perl 5.01 on linux 
(x86_64-linux-thread-multi)



   Remember to actually *READ* the README file! Especially if you have any 
problems.



   Installing on a linux, Ver#2.6

   Using Oracle in /usr/lib/oracle/11.2/client64

   sqlplus: error while loading shared libraries: libsqlplus.so: cannot open 
shared object file: No such
   file or directory



   If sqlplus failed due to a linker/symbol/relocation/library 
error or similar problem

   then it's likely that you've not configured your environment 
correctly.

   Specifically, your LD_LIBRARY_PATH environment variable

   set to include the directory containing the Oracle libraries.



   I'm having trouble finding your Oracle version number... trying harder



   WARNING: I could not determine Oracle client version so I'll just

   default to version 8.0.0.0. Some features of DBD::Oracle may not work.

   Oracle version based logic in Makefile.PL may produce erroneous results.

   You can use perl Makefile.PL -V X.Y.Z to specify a your client version.



   Oracle version 8.0.0.0 (8.0)

   DBD::Oracle no longer supports Oracle client versions before 9.2

   Try a version before 1.25 for 9 and 1.18 for 8! at Makefile.PL line 271.



   Oracle client installed on the server is 11.2 , then why the issue ?? Could 
you please suggest some
   alternate solution /fix for the same.?

   Thanks and regards,

   Ranjitha

   [1]Description: Description: Description: A NEW BTE_Email-signature_

   M:  +91 9739463575

   T:   +91 8039136322

   [2]ranji...@infosys.com



    CAUTION - Disclaimer *
   This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
   for the use of the addressee(s). If you are not the intended recipient, 
please
   notify the sender by e-mail and delete the original message. Further, you 
are not
   to copy, disclose, or distribute this e-mail or its contents to any other 
person and
   any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
   every reasonable precaution to minimize this risk, but is not liable for any 
damage
   you may sustain as a result of any virus in this e-mail. You should carry 
out your
   own virus checks before opening the e-mail or attachment. Infosys reserves 
the
   right to monitor and review the content of all messages sent to or from this 
e-mail
   address. Messages sent to or from this e-mail address may be stored on the
   Infosys e-mail system.
   ***INFOSYS End of Disclaimer INFOSYS***

References

   Visible links
   1. http://www.infosys.com/bte
   2. mailto:ranji...@infosys.com



- End forwarded message -

Re: (Fwd) Issue :DBD::Oracle installation

[Martin J. Evans]

On 04/06/14 12:44, tim.bu...@pobox.com wrote:

- Forwarded message from Ranjitha ranji...@infosys.com -

Date: Wed, 4 Jun 2014 11:05:34 +
From: Ranjitha ranji...@infosys.com
To: tim.bu...@pobox.com tim.bu...@pobox.com, t...@cpan.org t...@cpan.org
Subject: Issue :DBD::Oracle installation

Hi Tim

Facing an issue while installing DBD::Oracle  module from CPAN.

Direct installation on server cpan DBD::Oracle is failing.

I manually tried installing the module which CPAN has downloaded, below is 
the log.

ciw-app1:~/.cpan/build/DBD-Oracle-1.74-vjnZmt # perl Makefile.PL

Multiple copies of Driver.xst found in:
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/ at 
Makefile.PL line 39

Using DBI 1.631 (for perl 5.01 on x86_64-linux-thread-multi) installed 
in
/usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/



Configuring DBD::Oracle for perl 5.01 on linux 
(x86_64-linux-thread-multi)



Remember to actually *READ* the README file! Especially if you have any 
problems.



Installing on a linux, Ver#2.6

Using Oracle in /usr/lib/oracle/11.2/client64

sqlplus: error while loading shared libraries: libsqlplus.so: cannot open 
shared object file: No such
file or directory


This is your problem. You need to get sqlplus working in your environment 
before attempting to build DBD::Oracle.

Martin

Re: (Fwd) Issue :DBD::Oracle installation

[Martin J. Evans]

On 06/06/14 12:17, Ranjitha wrote:

Hi Martin

Screen shot from yast :


showing sqlplus is installed.


I have sqlplus installed in my server, then why the error?

Same way I have installed sqlplus in other servers also, no issue there.

Thanks and regards,


You've misunderstood me. I wasn't saying you have not installed sqlplus. I was 
saying you need to make sure you can run sqlplus before attempting to build 
DBD::Oracle. So sqlplus should be on your PATH or findable under 
LD_LIBRARY_PATH which you should set and export.

It is pointless trying to build DBD::Oracle if you cannot successfully run 
sqlplus - at best it will default to oracle 8.

Martin


-Original Message-
From: Martin J. Evans [mailto:martin.ev...@easysoft.com]
Sent: Friday, June 06, 2014 1:44 PM
To: Ranjitha; dbi-users@perl.org
Subject: Re: (Fwd) Issue :DBD::Oracle installation

On 04/06/14 12:44, tim.bu...@pobox.com mailto:tim.bu...@pobox.com wrote:

  - Forwarded message from Ranjitha ranji...@infosys.com 
mailto:ranji...@infosys.com -

 

  Date: Wed, 4 Jun 2014 11:05:34 +

  From: Ranjitha ranji...@infosys.com mailto:ranji...@infosys.com

  To: tim.bu...@pobox.com mailto:tim.bu...@pobox.com tim.bu...@pobox.com 
mailto:tim.bu...@pobox.com, t...@cpan.org mailto:t...@cpan.org t...@cpan.org 
mailto:t...@cpan.org

  Subject: Issue :DBD::Oracle installation

 

  Hi Tim

 

  Facing an issue while installing DBD::Oracle  module from CPAN.

 

  Direct installation on server cpan DBD::Oracle is failing.

 

  I manually tried installing the module which CPAN has downloaded, below 
is the log.

 

  ciw-app1:~/.cpan/build/DBD-Oracle-1.74-vjnZmt # perl Makefile.PL

 

  Multiple copies of Driver.xst found in:

  /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/

  /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/ at 
Makefile.PL line 39

 

  Using DBI 1.631 (for perl 5.01 on x86_64-linux-thread-multi) 
installed in

  /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/

 

 

 

  Configuring DBD::Oracle for perl 5.01 on linux 
(x86_64-linux-thread-multi)

 

 

 

  Remember to actually *READ* the README file! Especially if you have any 
problems.

 

 

 

  Installing on a linux, Ver#2.6

 

  Using Oracle in /usr/lib/oracle/11.2/client64

 

  sqlplus: error while loading shared libraries: libsqlplus.so: cannot 
open shared object file: No such

  file or directory

This is your problem. You need to get sqlplus working in your environment 
before attempting to build DBD::Oracle.

Martin

(Fwd) Issue :DBD::Oracle installation

[tim.bu...@pobox.com]

- Forwarded message from Ranjitha ranji...@infosys.com -

Date: Wed, 4 Jun 2014 11:05:34 +
From: Ranjitha ranji...@infosys.com
To: tim.bu...@pobox.com tim.bu...@pobox.com, t...@cpan.org t...@cpan.org
Subject: Issue :DBD::Oracle installation

   Hi Tim

   Facing an issue while installing DBD::Oracle  module from CPAN.

   Direct installation on server cpan DBD::Oracle is failing.

   I manually tried installing the module which CPAN has downloaded, below is 
the log.

   ciw-app1:~/.cpan/build/DBD-Oracle-1.74-vjnZmt # perl Makefile.PL

   Multiple copies of Driver.xst found in:
   /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/
   /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/ at 
Makefile.PL line 39

   Using DBI 1.631 (for perl 5.01 on x86_64-linux-thread-multi) installed in
   /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/auto/DBI/



   Configuring DBD::Oracle for perl 5.01 on linux 
(x86_64-linux-thread-multi)



   Remember to actually *READ* the README file! Especially if you have any 
problems.



   Installing on a linux, Ver#2.6

   Using Oracle in /usr/lib/oracle/11.2/client64

   sqlplus: error while loading shared libraries: libsqlplus.so: cannot open 
shared object file: No such
   file or directory



   If sqlplus failed due to a linker/symbol/relocation/library 
error or similar problem

   then it's likely that you've not configured your environment 
correctly.

   Specifically, your LD_LIBRARY_PATH environment variable

   set to include the directory containing the Oracle libraries.



   I'm having trouble finding your Oracle version number... trying harder



   WARNING: I could not determine Oracle client version so I'll just

   default to version 8.0.0.0. Some features of DBD::Oracle may not work.

   Oracle version based logic in Makefile.PL may produce erroneous results.

   You can use perl Makefile.PL -V X.Y.Z to specify a your client version.



   Oracle version 8.0.0.0 (8.0)

   DBD::Oracle no longer supports Oracle client versions before 9.2

   Try a version before 1.25 for 9 and 1.18 for 8! at Makefile.PL line 271.



   Oracle client installed on the server is 11.2 , then why the issue ?? Could 
you please suggest some
   alternate solution /fix for the same.?

   Thanks and regards,

   Ranjitha

   [1]Description: Description: Description: A NEW BTE_Email-signature_

   M:  +91 9739463575

   T:   +91 8039136322

   [2]ranji...@infosys.com



    CAUTION - Disclaimer *
   This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
   for the use of the addressee(s). If you are not the intended recipient, 
please
   notify the sender by e-mail and delete the original message. Further, you 
are not
   to copy, disclose, or distribute this e-mail or its contents to any other 
person and
   any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
   every reasonable precaution to minimize this risk, but is not liable for any 
damage
   you may sustain as a result of any virus in this e-mail. You should carry 
out your
   own virus checks before opening the e-mail or attachment. Infosys reserves 
the
   right to monitor and review the content of all messages sent to or from this 
e-mail
   address. Messages sent to or from this e-mail address may be stored on the
   Infosys e-mail system.
   ***INFOSYS End of Disclaimer INFOSYS***

References

   Visible links
   1. http://www.infosys.com/bte
   2. mailto:ranji...@infosys.com



- End forwarded message -

RE: FW: Perl module DBD::Oracle installation failing

[Jillapelli, Ramakrishna]

Hi Kurt,

Good News, today we have received all the reports.

Thank you very much once again.

Thanks  Regards, 

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services, 
9th Floor, Explorer Block, White Field Road, ITPL, 
Bangalore - 560066, India.

E-Mail: ramakrishna.jillape...@xerox.com, 
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).


-Original Message-
From: Jillapelli, Ramakrishna 
Sent: Monday, April 07, 2014 9:35 PM
To: 'Kurt Jaeger'
Cc: dbi-users@perl.org
Subject: RE: FW: Perl module DBD::Oracle installation failing

Hi Kurt,

Thanks a lot, I was able to generate one report in the evening. Perl script is 
connecting to Oracle database.
Some of URLs (links) also depending on Perl scripts which will indirectly 
connects to Databases fetches the data.

I think, Perl Oracle module installed successfully.

Still verifying lot of other scripts are working or not.

Once again thank you very much.

Thanks  Regards, 

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services,
9th Floor, Explorer Block, White Field Road, ITPL, Bangalore - 560066, India.

E-Mail: ramakrishna.jillape...@xerox.com,
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).


-Original Message-
From: Kurt Jaeger [mailto:p...@opsec.eu] 
Sent: Monday, April 07, 2014 8:25 PM
To: Jillapelli, Ramakrishna
Subject: Re: FW: Perl module DBD::Oracle installation failing

Hi!

Did it work out ?

Or do you still have problems ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !

FW: Perl module DBD::Oracle installation failing

[Jillapelli, Ramakrishna]

Hi,

Can you please help me, how to fix the issue and install Perl DBD::Oracle 
module.

Thanks  Regards,

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services,
9th Floor, Explorer Block, White Field Road, ITPL,
Bangalore - 560066, India.

E-Mail: 
ramakrishna.jillape...@xerox.commailto:ramakrishna.jillape...@xerox.com,
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).

From: Jillapelli, Ramakrishna
Sent: Saturday, April 05, 2014 12:15 AM
To: 't...@cpan.org'; 'byter...@cpan.org'; 'yan...@cpan.org'; 'mjev...@cpan.org'
Subject: Perl module DBD::Oracle installation failing

Hi,

While installing Perl module DBD::Oracle getting errors.
Recently AIX upgraded on couple of servers that installed Perl version 5.10.1.

We are using couple of Perl modules in our perl scripts, those are not working 
after AIX upgradation to 7.1

Used the following two methods installing the Perl module DBD::Oracle.

/usr/bin/perl MakeFile.PL

and

/usr/bin/perl -MCPAN -e 'install DBD::Oracle'

We are able to install all required Perl modules except DBD::Oracle module on 
our servers.
Please help me, how to fix this issue and install the Oracle module.



Please help me to fix.

Thanks  Regards,

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services,
9th Floor, Explorer Block, White Field Road, ITPL,
Bangalore - 560066, India.

E-Mail: 
ramakrishna.jillape...@xerox.commailto:ramakrishna.jillape...@xerox.com,
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).



Perl-DBD-Oracle-errors.docx
Description: Perl-DBD-Oracle-errors.docx
# /usr/bin/perl Makefile.PL
Using DBI 1.631 (for perl 5.010001 on aix-thread-multi) installed in 
/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/

Configuring DBD::Oracle for perl 5.010001 on aix (aix-thread-multi)

Remember to actually *READ* the README file! Especially if you have any 
problems.

Installing on a aix, Ver#5.3
Using Oracle in /oracle/product/v102/fullclnt
DEFINE _SQLPLUS_RELEASE = 1002000100 (CHAR)
Oracle version 10.2.0.1 (10.2)
Found /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk
Found /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms.mk
Found /oracle/product/v102/fullclnt/rdbms/lib/ins_rdbms.mk
Using /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk
Your LIBPATH env var is set to 
'/usr/local/Tivoli/lib/aix4-r1:/usr/lib:/opt/netcool/platform/aix5/lib:/opt/netcool/omnibus/platform/aix5/lib'
WARNING: Your LIBPATH env var doesn't include 
'/oracle/product/v102/fullclnt/lib32' but probably needs to.
Reading /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk
Reading /oracle/product/v102/fullclnt/rdbms/lib/env_rdbms.mk
Deleting -b64 from COMPOBJS because -b64 doesn't exist.

Attempting to discover Oracle OCI build rules
xlc_r -q32 -O -c DBD_ORA_OBJ.c
by executing: [make -f /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk 
build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true OPTIMIZE= 
CCFLD_ORA_EXE OBJS=DBD_ORA_OBJ.o]
Oracle oci build command:
[   true -q32 -L/oracle/product/v102/fullclnt/lib32/ 
-L/oracle/product/v102/fullclnt/rdbms//lib32/ -o DBD_ORA_EXE DBD_ORA_OBJ.o 
-lclntsh  -lld -lcle/product/v102/fullclnt/lib32/sysliblist`  -lm  -lpthreads]

Found header files in /oracle/product/v102/fullclnt/rdbms/public.

client_version=10.2


DEFINE= -DUTF8_SUPPORT -DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102


Checking for functioning wait.ph


System: perl5.010001 aix dennis01 3 5 00c72e9a4c00
Compiler:   xlc_r -q32 -O -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE 
-qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT 
-qlanglvl=extendedal/include -q32 -D_LARGE_FILES -qlonglong
Linker: /usr/bin/ld
Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat
Oracle makefiles would have used these definitions but we override them:
  CC:   $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS)
  CFLAGS:   $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\
$(SHARED_CFLAG) $(USRFLAGS)
   [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni 
-DAIXRIOS -qtocmerge -bimport:/oracle/product/v102/fullclnt/lib/ksms.imp 
-I/ora/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/plsql/public 
-I/oracle/product/v102/fullclnt/network/pLAGS) $(LPFLAGS) $(USRFLAGS)]
  LDFLAGS:  -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME)
   [-o $@ -L/oracle/product/v102/fullclnt/rdbms/lib/ -L$(LIBHOME)]
Linking with OTHERLDFLAGS = -q32 -L/oracle/product/v102/fullclnt/lib32/ 
-L/oracle/product/v102/fullclnt/rdbms//lib32/   -lclntsh  -lld -lm `cat 
/oracle/produlclnt/lib32/sysliblist`  -lm  -lpthreads [from 'build' rule]


WARNING: You will may need to rebuild perl using the xlc_r compiler.
 The important thing is that perl and DBD::Oracle be built with the 
same compiler.
 You

RE: FW: Perl module DBD::Oracle installation failing

[Jillapelli, Ramakrishna]

Hi Kurt,

Thanks a lot, I was able to generate one report in the evening. Perl script is 
connecting to Oracle database.
Some of URLs (links) also depending on Perl scripts which will indirectly 
connects to Databases fetches the data.

I think, Perl Oracle module installed successfully.

Still verifying lot of other scripts are working or not.

Once again thank you very much.

Thanks  Regards, 

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services, 
9th Floor, Explorer Block, White Field Road, ITPL, 
Bangalore - 560066, India.

E-Mail: ramakrishna.jillape...@xerox.com, 
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).


-Original Message-
From: Kurt Jaeger [mailto:p...@opsec.eu] 
Sent: Monday, April 07, 2014 8:25 PM
To: Jillapelli, Ramakrishna
Subject: Re: FW: Perl module DBD::Oracle installation failing

Hi!

Did it work out ?

Or do you still have problems ?

-- 
p...@opsec.eu+49 171 3101372 6 years to go !

make test failed for perl module DBD-Oracle-1.70

[Jillapelli, Ramakrishna]

Hi,

struck with DBD-Oracle-1.70

Make test returned the following error:


cp lib/DBD/Oracle/Troubleshooting/Win32.pod 
blib/lib/DBD/Oracle/Troubleshooting/Win32.pod
cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm
/usr/bin/perl -e 'use ExtUtils::Mksymlists;  Mksymlists(NAME = 
DBD::Oracle, DL_FUNCS = {  }, FUNCLIST = [], DL_VARS = []);'
/usr/bin/perl -p -e s/~DRIVER~/Oracle/g 
/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst  
Oracle.xsi
/usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp  -typemap 
/usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap  Oracle.xs  
Oracle.xsc  mv Oracle.xsc Oracle.c
xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/rdbms/demo 
-I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/plsql/public 
-I/oracle/product/v102/fullclnt/network/public 
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI  -D_ALL_SOURCE 
-D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN 
-DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES 
-qlonglong -O-DVERSION=\1.70\  -DXS_VERSION=\1.70\  
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT 
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 Oracle.c
xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/rdbms/demo 
-I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/plsql/public 
-I/oracle/product/v102/fullclnt/network/public 
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI  -D_ALL_SOURCE 
-D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN 
-DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES 
-qlonglong -O-DVERSION=\1.70\  -DXS_VERSION=\1.70\  
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT 
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 dbdimp.c
xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/rdbms/demo 
-I/oracle/product/v102/fullclnt/rdbms/public 
-I/oracle/product/v102/fullclnt/plsql/public 
-I/oracle/product/v102/fullclnt/network/public 
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI  -D_ALL_SOURCE 
-D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN 
-DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES 
-qlonglong -O-DVERSION=\1.70\  -DXS_VERSION=\1.70\  
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT 
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 oci8.c
Running Mkbootstrap for DBD::Oracle ()
chmod 644 Oracle.bs
rm -f blib/arch/auto/DBD/Oracle/Oracle.so

LD_RUN_PATH=/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32
 ld  -bhalt:4 -G -bI:/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE/perl.exp 
-bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o  dbdimp.o 
 oci8.o -q32 -L/oracle/product/v102/fullclnt/lib32/ 
-L/oracle/product/v102/fullclnt/rdbms//lib32/   -lclntsh  -lld -lm `cat 
/oracle/product/v102/fullclnt/lib32/sysliblist`  -lm  -lpthreads -o 
blib/arch/auto/DBD/Oracle/Oracle.so
ld: 0706-012 The -q flag is not recognized.
ld: 0706-012 The -3 flag is not recognized.
ld: 0706-012 The -2 flag is not recognized.
make: The error code from the last command is 255.


Stop.

[root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70

q32 option is mandatory?

Can you please guide how to proceed on this?


Thanks  Regards,

Ramakrishna Jillapelli,
Global Services, Operations and Engineering,

XEROX Business Services,
9th Floor, Explorer Block, White Field Road, ITPL,
Bangalore - 560066, India.

E-Mail: 
ramakrishna.jillape...@xerox.commailto:ramakrishna.jillape...@xerox.com,
Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).

Re: make test failed for perl module DBD-Oracle-1.70

[Martin J. Evans]

On 19/03/2014 18:31, Jillapelli, Ramakrishna wrote:

Hi,

struck with “DBD-Oracle-1.70”


You are likely to get more/better help if you tell us more. Platform? 
Perl version and where it came from? compiler? Oracle you are compiling 
against - full Oracle or Instant Client and version?


Anyway, I can guess some from the following:


Make test returned the following error:

cp lib/DBD/Oracle/Troubleshooting/Win32.pod
blib/lib/DBD/Oracle/Troubleshooting/Win32.pod

cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm

 /usr/bin/perl -e 'use ExtUtils::Mksymlists;  Mksymlists(NAME
= DBD::Oracle, DL_FUNCS = {  }, FUNCLIST = [], DL_VARS = []);'

 /usr/bin/perl -p -e s/~DRIVER~/Oracle/g
/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst
  Oracle.xsi


You are possibly using perl 5.10.1 - pretty old now but should still be 
ok. /usr/opt is an unusual place to see Perl so I'm guessing this is a 
Perl installed via your operating system vendor.



 /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp
-typemap /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap
Oracle.xs  Oracle.xsc  mv Oracle.xsc Oracle.c

 xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public


xlc_r. That looks like the IBM AIX compiler?

You need to compile and link DBD::Oracle using the same tools (compiler 
and linker) as IBM (or whoever) built your Perl. If this is an IBM 
compiled Perl for AIX they probably used their compiler (xlc) - a perl 
-V should verify this.



-I/oracle/product/v102/fullclnt/rdbms/demo
-I/oracle/product/v102/fullclnt/rdbms/public
-I/oracle/product/v102/fullclnt/plsql/public
-I/oracle/product/v102/fullclnt/network/public
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI
-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias
-DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended
-I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O
-DVERSION=\1.70\ -DXS_VERSION=\1.70\
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 Oracle.c


Guessing you are using Oracle OCI 10.2.0.1 and this is a full install of 
Oracle and not instant client.



 xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public
-I/oracle/product/v102/fullclnt/rdbms/demo
-I/oracle/product/v102/fullclnt/rdbms/public
-I/oracle/product/v102/fullclnt/plsql/public
-I/oracle/product/v102/fullclnt/network/public
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI
-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias
-DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended
-I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O
-DVERSION=\1.70\ -DXS_VERSION=\1.70\
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 dbdimp.c

 xlc_r -q32 -c  -I/oracle/product/v102/fullclnt/rdbms/public
-I/oracle/product/v102/fullclnt/rdbms/demo
-I/oracle/product/v102/fullclnt/rdbms/public
-I/oracle/product/v102/fullclnt/plsql/public
-I/oracle/product/v102/fullclnt/network/public
-I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI
-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias
-DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended
-I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O
  -DVERSION=\1.70\ -DXS_VERSION=\1.70\
-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE  -DUTF8_SUPPORT
-DORA_OCI_VERSION=\10.2.0.1\ -DORA_OCI_102 oci8.c

Running Mkbootstrap for DBD::Oracle ()

 chmod 644 Oracle.bs

 rm -f blib/arch/auto/DBD/Oracle/Oracle.so


LD_RUN_PATH=/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32
ld  -bhalt:4 -G
-bI:/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE/perl.exp
-bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o
dbdimp.o  oci8.o -q32 -L/oracle/product/v102/fullclnt/lib32/
-L/oracle/product/v102/fullclnt/rdbms//lib32/   -lclntsh  -lld -lm `cat
/oracle/product/v102/fullclnt/lib32/sysliblist`  -lm  -lpthreads -o
blib/arch/auto/DBD/Oracle/Oracle.so

ld: 0706-012 The -q flag is not recognized.

ld: 0706-012 The -3 flag is not recognized.

ld: 0706-012 The -2 flag is not recognized.


That is a bit strange as it is passing -q32 to ld which is the linker.

What does a perl -V output?

You could try searching the Makefile for -q32 and removing it from 
anything that looks like a linker (ld) command argument e.g., LDFLAGS. 
That is a bit of a hack but it should get you further. If you are 
struggling with this mail the Makefile to me (only) and I'll take a look.




make: The error code from the last command is 255.

Stop.

[root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70

q32 option is mandatory?


no idea what your question is there.



Can you please guide how to proceed on this?

Thanks  Regards,



Martin
--
Martin J. Evans
Wetherby, UK

RE: Surprising DBD::Oracle error raised

[John Scoles]

You are fetching off the end of a cursor so you would expect an error on any sql

Would be the same sort of thing as 

 

my @test= (1,2);

print $test[100];

 

If you know your recordset will be small I would use fetchall_arrrayref  or 
fetchall_hashref rather than just fetch.

 

 The normal way is to fetch is in a loop with  'while'.  As there is no way to 
tell how many records will be in 

your set before you do you SQL unless you tell the SQL to return only x rows.

 

Cheers

John

 

 Date: Tue, 4 Feb 2014 13:36:50 -0600
 Subject: Surprising DBD::Oracle error raised
 From: davidni...@gmail.com
 To: dbi-users@perl.org
 
 $price_sth-execute;
 my ($o_file_price) = $price_sth-fetchrow_array();
 if ($price_sth-fetch) {
 $this-log_error('ERROR: scalar select returned second row at
 %s line %d', __FILE__, __LINE__);
 }
 
 
 I expected the fetch to return undef, but it throws an Oracle error.
 My best ignorant guess here is that fetchrow_array does some cleanup
 on one-row datasets, but that isn't documented.
 
 Advise?
 
 
 -- 
 The one L lama, he's a priest
 The two L llama, he's a beast
 And I will bet my silk pyjama
 There isn't any three L lllama. -- Ogden Nash
  

Re: Surprising DBD::Oracle error raised

[Martin J. Evans]

On 04/02/14 19:36, David Nicol wrote:

 $price_sth-execute;
 my ($o_file_price) = $price_sth-fetchrow_array();
 if ($price_sth-fetch) {
 $this-log_error('ERROR: scalar select returned second row at
%s line %d', __FILE__, __LINE__);
 }


I expected the fetch to return undef, but it throws an Oracle error.
My best ignorant guess here is that fetchrow_array does some cleanup
on one-row datasets, but that isn't documented.

Advise?




That is in deed interesting. When I run the following with DBD::ODBC to MS SQL 
Server:

use strict;
use warnings;
use DBI;

my $h = DBI-connect();
eval {
$h-do(q/drop table mje/);
};

$h-do(q/create table mje (a int)/);
my $s = $h-prepare(q/insert into mje values(?)/);
$s-execute(1);
$s-execute(2);

$s = $h-prepare(q/select * from mje where a = 1/);
$s-execute;
my ($row) = $s-fetchrow_array;
print $row\n;
$row = $s-fetch;
print $row\n;


I get:

1
Use of uninitialized value $row in concatenation (.) or string at 
mje/fetch_off_end.pl line 20.

However, I get the same with DBD::Oracle so how is you code different from the 
above.

Martin

RE: Surprising DBD::Oracle error raised

[John Scoles]

Well isn't he is calling with the alias 'fetch' and he is calling it in I think 
scalar context

 

 

my ($row) = $s-fetchrow_array;


vs

 

 if ($price_sth-fetch) 


There is the odd chance that he is doing the SQL against a 'view', 'cursor'   
or alike but I doupt that is it.

 

 

 Date: Wed, 5 Feb 2014 13:25:03 +
 From: martin.ev...@easysoft.com
 To: davidni...@gmail.com; dbi-users@perl.org
 Subject: Re: Surprising DBD::Oracle error raised
 
 On 04/02/14 19:36, David Nicol wrote:
  $price_sth-execute;
  my ($o_file_price) = $price_sth-fetchrow_array();
  if ($price_sth-fetch) {
  $this-log_error('ERROR: scalar select returned second row at
  %s line %d', __FILE__, __LINE__);
  }
 
 
  I expected the fetch to return undef, but it throws an Oracle error.
  My best ignorant guess here is that fetchrow_array does some cleanup
  on one-row datasets, but that isn't documented.
 
  Advise?
 
 
 
 That is in deed interesting. When I run the following with DBD::ODBC to MS 
 SQL Server:
 
 use strict;
 use warnings;
 use DBI;
 
 my $h = DBI-connect();
 eval {
 $h-do(q/drop table mje/);
 };
 
 $h-do(q/create table mje (a int)/);
 my $s = $h-prepare(q/insert into mje values(?)/);
 $s-execute(1);
 $s-execute(2);
 
 $s = $h-prepare(q/select * from mje where a = 1/);
 $s-execute;
 my ($row) = $s-fetchrow_array;
 print $row\n;
 $row = $s-fetch;
 print $row\n;
 
 
 I get:
 
 1
 Use of uninitialized value $row in concatenation (.) or string at 
 mje/fetch_off_end.pl line 20.
 
 However, I get the same with DBD::Oracle so how is you code different from 
 the above.
 
 Martin
  

Re: Surprising DBD::Oracle error raised

[Martin J. Evans]

On 05/02/14 13:36, John Scoles wrote:

Well isn't he is calling with the alias 'fetch'


isn't he:

if ($price_sth-fetch) {


and he is calling it in I think scalar context


$row = $s-fetch;

so am I.




my ($row) = $s-fetchrow_array;


As far as I can see I did the same.


vs

  if ($price_sth-fetch)

There is the odd chance that he is doing the SQL against a 'view', 'cursor'   
or alike but I doupt that is it.


Perhaps David can tell us more.

Martin



  Date: Wed, 5 Feb 2014 13:25:03 +
  From: martin.ev...@easysoft.com
  To: davidni...@gmail.com; dbi-users@perl.org
  Subject: Re: Surprising DBD::Oracle error raised
 
  On 04/02/14 19:36, David Nicol wrote:
   $price_sth-execute;
   my ($o_file_price) = $price_sth-fetchrow_array();
   if ($price_sth-fetch) {
   $this-log_error('ERROR: scalar select returned second row at
   %s line %d', __FILE__, __LINE__);
   }
  
  
   I expected the fetch to return undef, but it throws an Oracle error.
   My best ignorant guess here is that fetchrow_array does some cleanup
   on one-row datasets, but that isn't documented.
  
   Advise?
  
  
 
  That is in deed interesting. When I run the following with DBD::ODBC to MS 
SQL Server:
 
  use strict;
  use warnings;
  use DBI;
 
  my $h = DBI-connect();
  eval {
  $h-do(q/drop table mje/);
  };
 
  $h-do(q/create table mje (a int)/);
  my $s = $h-prepare(q/insert into mje values(?)/);
  $s-execute(1);
  $s-execute(2);
 
  $s = $h-prepare(q/select * from mje where a = 1/);
  $s-execute;
  my ($row) = $s-fetchrow_array;
  print $row\n;
  $row = $s-fetch;
  print $row\n;
 
 
  I get:
 
  1
  Use of uninitialized value $row in concatenation (.) or string at 
mje/fetch_off_end.pl line 20.
 
  However, I get the same with DBD::Oracle so how is you code different from 
the above.
 
  Martin

Re: Surprising DBD::Oracle error raised

[John D Groenveld]

In message cafwsco-tqp5yycpptawzqkkyhz6qjs3d_g+yv5r9x9apdbm...@mail.gmail.com
, David Nicol writes:
the error message claimed I hadn't executed the statement.

Where is your DBI_TRACE?
I can't reproduce.

John
groenv...@acm.org

use strict;
use DBI;

my $dbh = DBI-connect( dbi:Oracle:, scott, tiger,
   { RaiseError = 1 } );
my $sth = $dbh-prepare( qq{
 SELECT 'FOO','BAR' FROM dual
} );
$sth-execute;
my ( $foo ) = $sth-fetchrow_array;
if ($sth-fetch) {
   warn should not enter;
}
$sth-finish;
$dbh-disconnect;

Re: Surprising DBD::Oracle error raised

[David Nicol]

On Wed, Feb 5, 2014 at 7:25 AM, Martin J. Evans
martin.ev...@easysoft.com wrote:

 That is indeed interesting. When I run the following with DBD::ODBC to MS
 SQL Server:

 use strict;
 use warnings;
 use DBI;

 my $h = DBI-connect();
 eval {
 $h-do(q/drop table mje/);
 };

 $h-do(q/create table mje (a int)/);
 my $s = $h-prepare(q/insert into mje values(?)/);
 $s-execute(1);
 $s-execute(2);

 $s = $h-prepare(q/select a from mje where a = 1/);
 $s-execute;
 my ($row) = $s-fetchrow_array;  # fetch result
 print $row\n;
 $row = $s-fetch;  # fetch status
 print $row\n;


 I get:

 1
 Use of uninitialized value $row in concatenation (.) or string at
 mje/fetch_off_end.pl line 20.

 However, I get the same with DBD::Oracle so how is you code different from
 the above.

 Martin

The code is the same. Rather, close enough, my second fetch was in
boolean context
while yours is in a storage context, but I don't think Perl cares,
both contexts are scalar.
And I've got RaiseError set. And my SQL, which joins two tables, has
three placeholders, bound with bind_param between the prepare_cached
and the execute.

And your warning verifies that the second fetch returned an undef, as
documented, while mine threw an exception falsely claiming that the
statement hadn't been executed yet:

An Oracle error has occurred :
DBD::Oracle::st fetch failed: ERROR no statement executing (perhaps
you need to call execute first)
 SQL Text 
select a from mje where a = 1
...


And you're certainly using more recent builds of everything.



-- 
The one L lama, he's a priest
The two L llama, he's a beast
And I will bet my silk pyjama
There isn't any three L lllama. -- Ogden Nash

Re: Surprising DBD::Oracle error raised

[Martin J. Evans]

On 05/02/14 14:08, David Nicol wrote:

On Wed, Feb 5, 2014 at 7:25 AM, Martin J. Evans
martin.ev...@easysoft.com wrote:


That is indeed interesting. When I run the following with DBD::ODBC to MS
SQL Server:

use strict;
use warnings;
use DBI;

my $h = DBI-connect();
eval {
 $h-do(q/drop table mje/);
};

$h-do(q/create table mje (a int)/);
my $s = $h-prepare(q/insert into mje values(?)/);
$s-execute(1);
$s-execute(2);

$s = $h-prepare(q/select a from mje where a = 1/);
$s-execute;
my ($row) = $s-fetchrow_array;  # fetch result
print $row\n;
$row = $s-fetch;  # fetch status
print $row\n;


I get:

1
Use of uninitialized value $row in concatenation (.) or string at
mje/fetch_off_end.pl line 20.

However, I get the same with DBD::Oracle so how is you code different from
the above.

Martin


The code is the same. Rather, close enough, my second fetch was in
boolean context
while yours is in a storage context, but I don't think Perl cares,
both contexts are scalar.
And I've got RaiseError set.


So have I now and it made no difference.


And my SQL, which joins two tables, has
three placeholders, bound with bind_param between the prepare_cached
and the execute.


Mine also use prepare_cached and a bind_param now - no change.


And your warning verifies that the second fetch returned an undef, as
documented, while mine threw an exception falsely claiming that the
statement hadn't been executed yet:

An Oracle error has occurred :
DBD::Oracle::st fetch failed: ERROR no statement executing (perhaps
you need to call execute first)
 SQL Text 
select a from mje where a = 1
...


And you're certainly using more recent builds of everything.


Which is probably it.
Can you try updated versions so we can rule this out or alternatively, tell me 
what you are using and I'll try and reproduce it.

Martin

Surprising DBD::Oracle error raised

[David Nicol]

$price_sth-execute;
my ($o_file_price) = $price_sth-fetchrow_array();
if ($price_sth-fetch) {
$this-log_error('ERROR: scalar select returned second row at
%s line %d', __FILE__, __LINE__);
}


I expected the fetch to return undef, but it throws an Oracle error.
My best ignorant guess here is that fetchrow_array does some cleanup
on one-row datasets, but that isn't documented.

Advise?


-- 
The one L lama, he's a priest
The two L llama, he's a beast
And I will bet my silk pyjama
There isn't any three L lllama. -- Ogden Nash

Re: Surprising DBD::Oracle error raised

[John D Groenveld]

In message CAFwScO-0DchsbSLPSmR9JY+KmBUF3BfUREH9XdDSVgEAo=p...@mail.gmail.com
, David Nicol writes:
$price_sth-execute;
my ($o_file_price) = $price_sth-fetchrow_array();
if ($price_sth-fetch) {
$this-log_error('ERROR: scalar select returned second row at
%s line %d', __FILE__, __LINE__);
}


I expected the fetch to return undef, but it throws an Oracle error.

What does your DBI_TRACE reveal?

John
groenv...@acm.org

Re: Surprising DBD::Oracle error raised

[David Nicol]

the error message claimed I hadn't executed the statement.
I changed it to

if (eval { $price_sth-fetch}) {
$this-log_error('ERROR: scalar select returned second row at
%s line %d', __FILE__, __LINE__);
}

but I think I'll change it again to

if ($price_sth-{Active} and $price_sth-fetch) {
$this-log_error('ERROR: scalar select returned second row at
%s line %d', __FILE__, __LINE__);
}

but if that's the right thing to do, the documentation (in
DBD::Oracle) should mention it in fetchrow_array's section IMO.




-- 
The one L lama, he's a priest
The two L llama, he's a beast
And I will bet my silk pyjama
There isn't any three L lllama. -- Ogden Nash

Re: Getting Error Message Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle

[Alexander Foken]

On 26.01.2014 01:19, Tony Byorick wrote:
I am trying to configure an Oracle connection from Perl running on a 
Windows 7 desktop to an Oracle 11g database running on Linux; however 
the database connection step is failing.


The following line of perl code fails:

   use DBD::Oracle;

Below is the full error message:

Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll' for module 
DBD::Oracle: load_file:%1 is not a valid Win32 application at 
C:/Perl64/lib/DynaLoader.pm line 191. at 
C:\go\perl\tracker\pingOracle.pl line 17.

[...]

I'm running 64 bit Windows and 64 bit Perl. Is it possible the DBD 
loader is failing because it is trying to load a 32 bit version of the 
Oracle driver?


Yes. The bitness of Perl and the database libraries must match, not 
only for Oracle, but for every database (and every C/C++ library you 
want to use from Perl).

[...]


Try to get a 64 bit Oracle client, or use a 32 bit Perl.

Alexander

--
Alexander Foken
mailto:alexan...@foken.de  http://www.foken.de/alexander/

Re: Getting Error Message Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle

[Bruce Johnson]

On Jan 27, 2014, at 12:04 PM, Alexander Foken alexan...@foken.de wrote:

 
 I'm running 64 bit Windows and 64 bit Perl. Is it possible the DBD loader is 
 failing because it is trying to load a 32 bit version of the Oracle driver?
 
 Yes. The bitness of Perl and the database libraries must match, not only 
 for Oracle, but for every database (and every C/C++ library you want to use 
 from Perl).
 [...]
 
 Try to get a 64 bit Oracle client, or use a 32 bit Perl.

The Oracle Instant Client is very useful for this; you can use both 32-bit and 
64-bit Oracle libraries on one system; just install them in different 
directories and ensure that the environmental variables are properly set prior 
to running the perl code.

I never install the full Oracle client on anything any more.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Getting Error Message Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle

[Bruce Johnson]

On Jan 27, 2014, at 12:25 PM, Bruce Johnson john...@pharmacy.arizona.edu 
wrote:

 
 On Jan 27, 2014, at 12:04 PM, Alexander Foken alexan...@foken.de wrote:
 
 
 I'm running 64 bit Windows and 64 bit Perl. Is it possible the DBD loader 
 is failing because it is trying to load a 32 bit version of the Oracle 
 driver?
 
 Yes. The bitness of Perl and the database libraries must match, not only 
 for Oracle, but for every database (and every C/C++ library you want to use 
 from Perl).
 [...]
 
 Try to get a 64 bit Oracle client, or use a 32 bit Perl.
 
 The Oracle Instant Client is very useful for this; you can use both 32-bit 
 and 64-bit Oracle libraries on one system; just install them in different 
 directories and ensure that the environmental variables are properly set 
 prior to running the perl code.

I should clarify this statement: you can do this with the appropriately 
compiled perl and DBI modules as well. I’ve mainly had to do this when there 
were 32-bit apps other than perl on the system that needed to connect to 
Oracle, like Office ODBC and other applications.

To use different bit-ness perl applications you need to maintain two separate 
perl stacks. Also not impossible, but a lot easier on a linux system than 
Windows.


-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Getting Error Message Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle

[Tony Byorick]

Thanks for the responses to my question.

I have not found a root cause for the problem however, I have found a 
workaround by installing the 32 bit version of ActiveState Perl and using it 
rather than the 64 bit version.

With 32 bit Perl, $dbh = 
DBI-connect(dbi:Oracle:host=$host;sid=$sid;port=$port, $user, $passwd); 
performs without complaining and then executes SQL and returns the answer set.

-Tony




 From: Alexander Foken alexan...@foken.de
To: Tony Byorick t...@byorick.com; dbi-users@perl.org dbi-users@perl.org 
Sent: Monday, January 27, 2014 11:04 AM
Subject: Re: Getting Error Message Can't load 
'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle
 


On 26.01.2014 01:19, Tony Byorick wrote:

I am trying to configure an Oracle connection from Perl running on a Windows 7 
desktop to an Oracle 11g database running on Linux; however the database 
connection step is failing.

The following line of perl code fails:

   use DBD::Oracle;

Below is the full error message:

Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: 
load_file:%1 is not a valid Win32 application at C:/Perl64/lib/DynaLoader.pm 
line 191. at C:\go\perl\tracker\pingOracle.pl line 17.
[...]


I'm running 64 bit Windows and 64 bit Perl. Is it possible the DBD loader is 
failing because it is trying to load a 32 bit version of the Oracle driver?
Yes. The bitness of Perl and the database libraries must match,
not only for Oracle, but for every database (and every C/C++ library
you want to use from Perl).

 [...]



Try to get a 64 bit Oracle client, or use a 32 bit Perl.

Alexander


-- 
Alexander Foken mailto:alexan...@foken.de http://www.foken.de/alexander/

Getting Error Message Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll While Connecting to Oracle

[Tony Byorick]

I am trying to configure an Oracle connection from Perl running on a Windows 7 
desktop to an Oracle 11g database running on Linux; however the database 
connection step is failing.

The following line of perl code fails:

   use DBD::Oracle;

Below is the full error message:

Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll' for module DBD::Oracle: 
load_file:%1 is not a valid Win32 application at C:/Perl64/lib/DynaLoader.pm 
line 191. at C:\go\perl\tracker\pingOracle.pl line 17.

The following line of perl code fails with a similar error message:

   $dbh = DBI-connect(dbi:Oracle:host=$host;sid=$sid;port=$port, $user, 
$passwd);

The version of my Perl install is:

# C:\Perl64\binperl -v
# 
# This is perl 5, version 16, subversion 3 (v5.16.3) built for 
MSWin32-x64-multi-thread
# (with 1 registered patch, see perl -V for more detail)
# Binary build 1603 [296746] provided by ActiveState http://www.ActiveState.com
# Built Mar 13 2013 13:31:10

The DBI version is: 1.623
The DBD::Oracle version is 1.58

I'm running 64 bit Windows and 64 bit Perl. Is it possible the DBD loader is 
failing because it is trying to load a 32 bit version of the Oracle driver?

The Oracle 11.2 client package of drivers is installed on the same desktop PC 
and these drivers successfully connect my Toad client to the Oracle database. 

From the Perl error message above, it appears Perl is trying to load a driver 
that was installed along with ActiveState Perl.

Should I try to configure Perl to use the Oracle 11.2 drivers? Or should Perl 
be loading drivers installed from ActiveState?

Any help or thoughts would greatly appreciated.  -Tony

Build error - DBD::Oracle, Oracle 11.2.0.1, 32-bit client, remote DB

[Vaughan, Mark]

I'm trying to build DBI and DBD::Oracle to run on a Linux server 
(2.6.18-274.7.1.el5) using the 11g (11.2.0.1) 32-bit client. The database 
resides on a remote server and I can get to it just fine using sqlplus.

Here is the output from the make:
mvaughan - ni00 - /u/mvaughan/.cpan/build/DBD-Oracle-1.68-BdHkR5 make
cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod 
blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod
cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm
cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h
cp lib/DBD/Oracle/Troubleshooting/Hpux.pod 
blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod
cp lib/DBD/Oracle/Troubleshooting/Vms.pod 
blib/lib/DBD/Oracle/Troubleshooting/Vms.pod
cp lib/DBD/Oracle/Troubleshooting/Linux.pod 
blib/lib/DBD/Oracle/Troubleshooting/Linux.pod
cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm
cp lib/DBD/Oracle/Troubleshooting.pod blib/lib/DBD/Oracle/Troubleshooting.pod
cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h
cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h
cp lib/DBD/Oracle/Troubleshooting/Sun.pod 
blib/lib/DBD/Oracle/Troubleshooting/Sun.pod
cp lib/DBD/Oracle/Troubleshooting/Macos.pod 
blib/lib/DBD/Oracle/Troubleshooting/Macos.pod
cp lib/DBD/Oracle/Troubleshooting/Aix.pod 
blib/lib/DBD/Oracle/Troubleshooting/Aix.pod
cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm
cp lib/DBD/Oracle/Troubleshooting/Win64.pod 
blib/lib/DBD/Oracle/Troubleshooting/Win64.pod
cp lib/DBD/Oracle/Troubleshooting/Win32.pod 
blib/lib/DBD/Oracle/Troubleshooting/Win32.pod
cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm
/usr/bin/perl -p -e s/~DRIVER~/Oracle/g 
/u/mvaughan/perl.lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/Driver.xst
  Oracle.xsi
/usr/bin/perl /usr/lib/perl5/5.8.8/ExtUtils/xsubpp  -typemap 
/usr/lib/perl5/5.8.8/ExtUtils/typemap -typemap typemap  Oracle.xs  Oracle.xsc 
 mv Oracle.xsc Oracle.c
gcc -c  -I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/demo 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/plsql/public 
-I/u01/app/oracle/product/11.2.0/client32/network/public 
-I/u/mvaughan/perl.lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI
 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic   -DVERSION=\1.68\ 
-DXS_VERSION=\1.68\ -fPIC 
-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE  -Wall -Wno-comment 
-DUTF8_SUPPORT -DORA_OCI_VERSION=\11.2.0.1\ -DORA_OCI_102 -DORA_OCI_112 
Oracle.c
gcc -c  -I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/demo 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/plsql/public 
-I/u01/app/oracle/product/11.2.0/client32/network/public 
-I/u/mvaughan/perl.lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI
 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic   -DVERSION=\1.68\ 
-DXS_VERSION=\1.68\ -fPIC 
-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE  -Wall -Wno-comment 
-DUTF8_SUPPORT -DORA_OCI_VERSION=\11.2.0.1\ -DORA_OCI_102 -DORA_OCI_112 
dbdimp.c
dbdimp.c: In function 'fb_ary_cb_alloc':
dbdimp.c:324: warning: comparison is always false due to limited range of data 
type
dbdimp.c:325: warning: comparison is always false due to limited range of data 
type
dbdimp.c:326: warning: comparison is always false due to limited range of data 
type
dbdimp.c:327: warning: comparison is always false due to limited range of data 
type
dbdimp.c:328: warning: comparison is always false due to limited range of data 
type
dbdimp.c: In function 'fb_ary_alloc':
dbdimp.c:344: warning: comparison is always false due to limited range of data 
type
dbdimp.c:345: warning: comparison is always false due to limited range of data 
type
dbdimp.c:346: warning: comparison is always false due to limited range of data 
type
dbdimp.c:347: warning: comparison is always false due to limited range of data 
type
gcc -c  -I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/demo 
-I/u01/app/oracle/product/11.2.0/client32/rdbms/public 
-I/u01/app/oracle/product/11.2.0/client32/plsql/public 
-I/u01/app/oracle/product/11.2.0/client32/network/public 
-I/u/mvaughan/perl.lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI
 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe 
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -I/usr/include

Re: Build error - DBD::Oracle, Oracle 11.2.0.1, 32-bit client, remote DB

[John D Groenveld]

In message 55bc400cff41a94aae7062ab10940b3f022...@stntexmb12.cis.neustar.com,
 Vaughan, Mark writes:
I'm trying to build DBI and DBD::Oracle to run on a Linux server (2.6.18-27=
4.7.1.el5) using the 11g (11.2.0.1) 32-bit client. The database resides on =

Your perl must be 32-bit to build 32-bit DBD::Oracle.

/usr/bin/perl -p -e s/~DRIVER~/Oracle/g /u/mvaughan/perl.lib/lib64/perl5/=
site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/Driver.xst  Oracle.xsi

/usr/bin/perl is 64-bit.

/usr/bin/ld: skipping incompatible /u01/app/oracle/product/11.2.0/client32/=
lib//libclntsh.so when searching for -lclntsh
/usr/bin/ld: cannot find -lclntsh

Install the 64-bit Oracle InstantClient and set your ORACLE_HOME
to it or install a 32-bit Perl and use it to build 32-bit DBD::Oracle.

John
groenv...@acm.org

Re: DBD::Oracle installation

[Michiel Beijen]

Hi Carl,

On Fri, Dec 6, 2013 at 1:06 AM, Furst, Carl carl.fu...@mlb.com wrote:

 However, I'm wondering why this information is not in the INSTALL file at
 least? Would be a good hint so people know what they would need to get
 going.


It could be one of the reasons is there are so many different installation
scenarios and platforms.
I think the most 'common' method nowadays would be to use the Oracle
InstantClient.

A couple months ago I added installation instructions to the OTRS manual
for how to compile DBD::Oracle on different platforms for usage with the
OTRS software. It might be of use, and of course could be moved into the
DBD::Oracle docs as well.

For CentOS/RHEL the instructions are here:
http://doc.otrs.org/3.3/en/html/installation.html#rhel-installation-dbd-oracle

--
Mike

DBD::Oracle installation

[Furst, Carl]

What libs from oracle are exactly required to install this..

We just installed the client libs, including sql plus on Centos and it seems 
that Makefile.pl is having trouble finding the version:

WARNING: I could not determine Oracle client version so I'll just
default to version 8.0.0.0. Some features of DBD::Oracle may not work.
Oracle version based logic in Makefile.PL may produce erroneous results.
You can use perl Makefile.PL -V X.Y.Z to specify a your client version.

Now if I had to specify that manually is that the sqlplus version?? How is it 
determining that version?? We have 12.4 installed.

Thanks,
Carl Furst

Re: DBD::Oracle installation

[Furst, Carl]

Thanks! We got it going with an oracle client rpm, sqlplus and demo.mk
probably from SDK packages. Seems to be working.

However, I'm wondering why this information is not in the INSTALL file at
least? Would be a good hint so people know what they would need to get
going.

Thanks,
Carl Furst





On 12/5/13 6:57 PM, Bruce Johnson john...@pharmacy.arizona.edu wrote:


On Dec 5, 2013, at 4:06 PM, Furst, Carl carl.fu...@mlb.com wrote:

 What libs from oracle are exactly required to install this..
 
 We just installed the client libs, including sql plus on Centos and it
seems that Makefile.pl is having trouble finding the version:
 
 WARNING: I could not determine Oracle client version so I'll just
 default to version 8.0.0.0. Some features of DBD::Oracle may not work.
 Oracle version based logic in Makefile.PL may produce erroneous results.
 You can use perl Makefile.PL -V X.Y.Z to specify a your client
version.
 
 Now if I had to specify that manually is that the sqlplus version?? How
is it determining that version?? We have 12.4 installed.
 
 Thanks,
 Carl Furst

If you’re using the Instant Client, you need to install the Basic Client
and the SDK packages; most likely it’s breaking because of the missing
SDK stuff or your environment variables aren’t set. These cause 99% of
the problems I’ve ever had getting DBD::Oracle running.


http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html

Then set up the $ORACLE_HOME, $TNS_ADMIN and $LD_LIBRARY_PATH environment
variables:


ORACLE_HOME=/usr/lib/oracle/11.2/client64
TNS_ADMIN=/usr/lib/oracle/11.2/client64/admin
LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib

This is on a RHEL server, but it’s in the same place on a CentOS server.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

(Fwd) Problems with DBD::Oracle package: function plsql_errstr

[Tim Bunce]

- Forwarded message from Eljot na Onet.pl eljot_...@poczta.onet.pl -

Date: Sat, 02 Nov 2013 21:11:48 +0100
From: Eljot na Onet.pl eljot_...@poczta.onet.pl
To: t...@cpan.org
Subject: Problems with DBD::Oracle package: function plsql_errstr

Hi,

I have found two problems with your DBD::Oracle package.

(you have all examples in the attachment plsql_errstr.zip, please read
README.txt file)

problems concern sub plsql_errstr described in
http://search.cpan.org/~pythian/DBD-Oracle-1.64/lib/DBD/Oracle.pm

What's the point? You use view *user_errors* to fetch info about
errors in *last* query parsed. But the view returns list of ALL
current user errors - as name of the view means.

So if I execute example code from pod :

EXAMPLE 1: (01-example-1-sub.sh, calls pl/01-example-1-sub.pl)

# Show the errors if CREATE PROCEDURE fails
$dbh-{RaiseError} = 0;
if ( $dbh-do( q{
CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test as
BEGIN
PROCEDURE filltab( stuff OUT TAB ); asdf
END; } ) ) {} # Statement succeeded
}
elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
else {
my $msg = $dbh-func( 'plsql_errstr' );
die $dbh-errstr if ! defined $msg;
die $msg if $msg;
}

I will get msg as in attachment 01-example-01.log containing the error
info I have expected. But the following code will not work properly:

(please execute 00.example-del-subs.sh first)

EXAMPLE 2: (02-example-2-subs.sh, calls pl/02-example-2-subs.pl)

# Show the errors if CREATE PROCEDURE fails
$dbh-{RaiseError} = 0;
if ( $dbh-do( q{
CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test_1st as
BEGIN
PROCEDURE filltab( stuff OUT TAB ); asdf
END; } ) ) {} # Statement succeeded
}
elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
else {
my $msg = $dbh-func( 'plsql_errstr' );
warn $dbh-errstr, \n if ! defined $msg  defined $dbh-errstr;
warn $msg, \n if $msg;
}

# but this works not exactly as one should expect...
$dbh-{RaiseError} = 0;
if ( $dbh-do( q{
CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test_2nd as
BEGIN
PROCEDURE filltab( stuff OUT TAB ); asdf
END; } ) ) {} # Statement succeeded
}
elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
else {
my $msg = $dbh-func( 'plsql_errstr' );
warn $dbh-errstr, \n if ! defined $msg  defined $dbh-errstr;
warn $msg, \n if $msg;
}

ooops - first we've got info about procedure perl_dbd_oracle_test_1st
(that's ok) but then we've got info about *both* procedures:
perl_dbd_oracle_test_1st and perl_dbd_oracle_test_2nd as well...

The second problem is more subtle. I think the common idea due to
security reasons is to have only one database user which has resource
and CREATE USER privilege, and the only user creates other users and
tables, views, etc for the them. Other users can do only DML queries.
In this case the view user_errors will obviously return the empty row
list. So the code:

EXAMPLE 3 (03-example-other-user.sh)
# Show the errors if CREATE PROCEDURE fails
$dbh-{RaiseError} = 0;
if ( $dbh-do( q{
CREATE OR REPLACE PROCEDURE myuser.perl_dbd_oracle_test as
BEGIN
PROCEDURE filltab( stuff OUT TAB ); asdf
END; } ) ) {} # Statement succeeded
}
elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
else {
my $msg = $dbh-func( 'plsql_errstr' );
die $dbh-errstr if ! defined $msg;
die $msg if $msg;
}

will return no info at all!

I have solved both problems, would You look at my version of
plsql_errstr in file 04-example-new-plsql-errstr.pl, please?

As You can see I have defined *sub* *plsql_errarray* which select
error info from database and returns them in array reference much more
convinient for later use; *plsql_errstr* only converts that array into
a single string. Of course one should provide at least two additional
parameters to new plsql_errstr function.

-- 
Greetings
Jarek Lubczyński

There are 10 kinds of people:
Those who understand binary and those who don't



- End forwarded message -

Re: (Fwd) Problems with DBD::Oracle package: function plsql_errstr

[Martin J. Evans]

Thank you for providing this - please see below.

On 03/11/2013 12:06, Tim Bunce wrote:

- Forwarded message from Eljot na Onet.pl eljot_...@poczta.onet.pl -

Date: Sat, 02 Nov 2013 21:11:48 +0100
From: Eljot na Onet.pl eljot_...@poczta.onet.pl
To: t...@cpan.org
Subject: Problems with DBD::Oracle package: function plsql_errstr

Hi,

I have found two problems with your DBD::Oracle package.

(you have all examples in the attachment plsql_errstr.zip, please read
README.txt file)


which was missing unfortunately - perhaps when it was forwarded on.


problems concern sub plsql_errstr described in
http://search.cpan.org/~pythian/DBD-Oracle-1.64/lib/DBD/Oracle.pm

What's the point? You use view *user_errors* to fetch info about
errors in *last* query parsed. But the view returns list of ALL
current user errors - as name of the view means.

So if I execute example code from pod :

EXAMPLE 1: (01-example-1-sub.sh, calls pl/01-example-1-sub.pl)

 # Show the errors if CREATE PROCEDURE fails
 $dbh-{RaiseError} = 0;
 if ( $dbh-do( q{
 CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test as
 BEGIN
 PROCEDURE filltab( stuff OUT TAB ); asdf
 END; } ) ) {} # Statement succeeded
 }
 elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
 else {
 my $msg = $dbh-func( 'plsql_errstr' );
 die $dbh-errstr if ! defined $msg;
 die $msg if $msg;
 }

I will get msg as in attachment 01-example-01.log containing the error
info I have expected. But the following code will not work properly:

(please execute 00.example-del-subs.sh first)

EXAMPLE 2: (02-example-2-subs.sh, calls pl/02-example-2-subs.pl)

 # Show the errors if CREATE PROCEDURE fails
 $dbh-{RaiseError} = 0;
 if ( $dbh-do( q{
 CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test_1st as
 BEGIN
 PROCEDURE filltab( stuff OUT TAB ); asdf
 END; } ) ) {} # Statement succeeded
 }
 elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
 else {
 my $msg = $dbh-func( 'plsql_errstr' );
 warn $dbh-errstr, \n if ! defined $msg  defined $dbh-errstr;
 warn $msg, \n if $msg;
 }

 # but this works not exactly as one should expect...
 $dbh-{RaiseError} = 0;
 if ( $dbh-do( q{
 CREATE OR REPLACE PROCEDURE perl_dbd_oracle_test_2nd as
 BEGIN
 PROCEDURE filltab( stuff OUT TAB ); asdf
 END; } ) ) {} # Statement succeeded
 }
 elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
 else {
 my $msg = $dbh-func( 'plsql_errstr' );
 warn $dbh-errstr, \n if ! defined $msg  defined $dbh-errstr;
 warn $msg, \n if $msg;
 }

ooops - first we've got info about procedure perl_dbd_oracle_test_1st
(that's ok) but then we've got info about *both* procedures:
perl_dbd_oracle_test_1st and perl_dbd_oracle_test_2nd as well...

The second problem is more subtle. I think the common idea due to
security reasons is to have only one database user which has resource
and CREATE USER privilege, and the only user creates other users and
tables, views, etc for the them. Other users can do only DML queries.
In this case the view user_errors will obviously return the empty row
list. So the code:

EXAMPLE 3 (03-example-other-user.sh)
 # Show the errors if CREATE PROCEDURE fails
 $dbh-{RaiseError} = 0;
 if ( $dbh-do( q{
 CREATE OR REPLACE PROCEDURE myuser.perl_dbd_oracle_test as
 BEGIN
 PROCEDURE filltab( stuff OUT TAB ); asdf
 END; } ) ) {} # Statement succeeded
 }
 elsif ( 6550 != $dbh-err ) { die $dbh-errstr; } # Utter failure
 else {
 my $msg = $dbh-func( 'plsql_errstr' );
 die $dbh-errstr if ! defined $msg;
 die $msg if $msg;
 }

will return no info at all!

I have solved both problems, would You look at my version of
plsql_errstr in file 04-example-new-plsql-errstr.pl, please?


I don't know if you omitted an attachment of it didn't get passed on 
when it was forwarded to dbi-users list. Would you mind sending me your 
full email again with your new files/changes.


Alternatively, if you use git you could always submit a pull request to 
the github repository (which you'll find at 
https://github.com/pythian/DBD-Oracle).



As You can see I have defined *sub* *plsql_errarray* which select
error info from database and returns them in array reference much more
convinient for later use; *plsql_errstr* only converts that array into
a single string. Of course one should provide at least two additional
parameters to new plsql_errstr function.



Martin
--
Martin J. Evans
Wetherby, UK

RE: Failed DBD oracle module

[John Scoles]

No time to look at it today but these two sites might help

 

http://coding.derkeiler.com/Archive/Perl/perl.dbi.users/2006-12/msg00029.html 

 

or

 

http://www.pythian.com/blog/fixing-the-dreaded-unable-to-locate-an-oracle-mk-proc-mk-or-other-suitable-mk-error-in-dbdoracle-insalls/
 

 From: john...@pharmacy.arizona.edu
 CC: dbi-users@perl.org
 Subject: Re: Failed DBD oracle module
 Date: Mon, 23 Sep 2013 21:09:34 +
 
 
 On Sep 23, 2013, at 2:02 PM, Bruce Johnson john...@pharmacy.arizona.edu 
 wrote:
 
  This can happen if you have 32-bit oracle db installed on the system, but 
  use the 64-bit Oracle Instant Client to compile DBD::Oracle. 
 
 Or Vice-versa, of course, which might be what your problem is.
 
 -- 
 Bruce Johnson
 University of Arizona
 College of Pharmacy
 Information Technology Group
 
 Institutions do not have opinions, merely customs
 
 
  

Failed DBD oracle module

[Lieng, Gia]

Hi,

I had installed perl 5.18.1 and two other modules DBI and DBD::Oralce.
And using the simple script below to test both modules, DBI worked but
DBD::Oracle gives the following errors.  Both modules compile and
installed without errors.

 

 

- Testing module DBI worked:

$ vi perl_test.script

perl_test.script 4 lines, 55 characters

#!/usr/bin/perl

 

use DBI

print hello world\n;

~

~

~

~

~

~

~

~

~

perl_test.script 4 lines, 48 characters

$

$ perl perl_test.script

hello world

$

 

 

 

 

- Testing module DBD::Oracle, it failed:

$ vi perl_test.script

perl_test.script 4 lines, 48 characters

#!/usr/bin/perl

 

use DBD::Oracle

print hello world\n;

 

 

 

~

~

~

perl_test.script 4 lines, 56 characters

$

 

 

$ perl perl_test.script

Can't load
'/usr/local/lib/perl5/site_perl/5.18.1/sun4-solaris/auto/DBD/Oracle/Orac
le.so' for module DBD::Oracle: ld.so.1: perl: fatal: 

/opt/oracle/10.2.0.3/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64
at /usr/local/lib/perl5/5.18.1/sun4-solaris/DynaLoader.pm line 190.

at perl_test.script line 4.

Compilation failed in require at perl_test.script line 4.

BEGIN failed--compilation aborted at perl_test.script line 4.

 

 

 

Can you please assist?