Re: DBD::Oracle forked client hangs with Oracle Client Libraries 19.20 and later.
1c96c0) 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.
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-instantclie
Re: please help with DBD-Oracle-1.76
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
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
> 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
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
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&id=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
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
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
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
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
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
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
> 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
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
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
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
> 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
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
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?
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
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
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
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
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
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
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
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 (
RE: Hunting down (possible) memory leak in DBD::Oracle
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_NA
RE: Hunting down (possible) memory leak in DBD::Oracle
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
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 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/DB
RE: Hunting down (possible) memory leak in DBD::Oracle
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 **
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 ; 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 ; 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 ; 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
RE: Hunting down (possible) memory leak in DBD::Oracle ** EXTERNAL **
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
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 erro
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 ; 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 tran
Re: Hunting down (possible) memory leak in DBD::Oracle
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 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
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
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
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 Subject: (Fwd) DBD::Oracle quote_identifier - Forwarded message from "LAWS, MICHAEL H" - Date: Tue, 16 Aug 2016 21:04:20 + From: "LAWS, MICHAEL H" To: "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
- Forwarded message from "LAWS, MICHAEL H" - Date: Tue, 16 Aug 2016 21:04:20 + From: "LAWS, MICHAEL H" To: "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
In message , "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
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 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
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 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
On 6/22/2016 2:05 PM, Bruce Johnson wrote: On Jun 22, 2016, at 1:34 PM, John R Pierce <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
> 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
On Jun 22, 2016, at 1:34 PM, John R Pierce 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. 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
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 > 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
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
> On Jun 22, 2016, at 12:32 PM, Tony D'Alfonso > 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
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 Date: Wednesday, June 22, 2016 at 2:00 PM To: "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
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 Date: Wednesday, June 22, 2016 at 2:00 PM To: "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
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
# 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 cr
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.
Re: Help with DBD::Oracle install
On 2/7/2016 3:12 AM, Martin J. Evans wrote: You need to install a C compiler - the one your Perl was built with is most likely to work. the perl that comes with solaris is built with Oracle Studio C (formerly Sun Forte C) ... but I seem to recall there was a solaris perl make script that worked with gcc. google suggests this, and it looks familiar (its been years since I had to deal with this) http://perldoc.perl.org/perlsolaris.html http://twiki.org/cgi-bin/view/Codev/SolarisInstallCookbookPerlModules http://search.cpan.org/~aburlison/Solaris-PerlGcc-1.3/pod/perlgcc.pod -- john r pierce, recycling bits in santa cruz
Re: Help with DBD::Oracle install
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
Re: Help with DBD::Oracle install
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' > > Steve Linn > Data Center, SA > Brockwell Technology, Inc > Team IBM (Contractor) > steven.d.linn@mail.mil > 256-313-0363 > DSN:897
Re: DBD::Oracle and RHEL Instant Client rpms
> On Oct 20, 2015, at 2:22 PM, Martin J. Evans 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
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
DBD::Oracle and RHEL Instant Client rpms
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 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)
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)
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)
According to Kurt Jaeger 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)
Hi! > According to Kurt Jaeger 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 !
Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)
According to Kurt Jaeger 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)
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 !
DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)
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%29&product=Ports%20%26%20Packages --
RE: (Fwd) Issue :DBD::Oracle installation
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 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
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 - Date: Wed, 4 Jun 2014 11:05:34 + From: Ranjitha To: "tim.bu...@pobox.com" , "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
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 mailto:ranji...@infosys.com>> - > > Date: Wed, 4 Jun 2014 11:05:34 + > From: Ranjitha mailto:ranji...@infosys.com>> > To: "tim.bu...@pobox.com <mailto:tim.bu...@pobox.com>" mailto:tim.bu...@pobox.com>>, "t...@cpan.org <mailto: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
Re: (Fwd) Issue :DBD::Oracle installation
On 04/06/14 12:44, tim.bu...@pobox.com wrote: - Forwarded message from Ranjitha - Date: Wed, 4 Jun 2014 11:05:34 + From: Ranjitha To: "tim.bu...@pobox.com" , "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
- Forwarded message from Ranjitha - Date: Wed, 4 Jun 2014 11:05:34 + From: Ranjitha To: "tim.bu...@pobox.com" , "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
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 !
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
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.com<mailto: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.com<mailto: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]
Re: make test failed for perl module DBD-Oracle-1.70
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
make test failed for perl module DBD-Oracle-1.70
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.com<mailto:ramakrishna.jillape...@xerox.com>, Ph: +1-214-530-, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).
Re: Surprising DBD::Oracle error raised
On 05/02/14 14:08, David Nicol wrote: On Wed, Feb 5, 2014 at 7:25 AM, Martin J. Evans 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
Re: Surprising DBD::Oracle error raised
On Wed, Feb 5, 2014 at 7:25 AM, Martin J. Evans 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
In message , 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
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
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
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
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
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: Surprising DBD::Oracle error raised
In message , 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
Surprising DBD::Oracle error raised
$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: Getting Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle
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 To: Tony Byorick ; "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/
Re: Getting Error Message "Can't load 'C:/Perl64/lib/auto/DBD/Oracle/Oracle.dll" While Connecting to Oracle
On Jan 27, 2014, at 12:25 PM, Bruce Johnson wrote: > > On Jan 27, 2014, at 12:04 PM, Alexander Foken 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
On Jan 27, 2014, at 12:04 PM, Alexander Foken 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
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
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\bin>perl -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
Re: Build error - DBD::Oracle, Oracle 11.2.0.1, 32-bit client, remote DB
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
Build error - DBD::Oracle, Oracle 11.2.0.1, 32-bit client, remote DB
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/aut
Re: DBD::Oracle installation
Hi Carl, On Fri, Dec 6, 2013 at 1:06 AM, Furst, Carl 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
Re: DBD::Oracle installation
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" wrote: > >On Dec 5, 2013, at 4:06 PM, Furst, Carl 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 > >
DBD::Oracle installation
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: (Fwd) Problems with DBD::Oracle package: function plsql_errstr
Thank you for providing this - please see below. On 03/11/2013 12:06, Tim Bunce wrote: - Forwarded message from "Eljot na Onet.pl" - Date: Sat, 02 Nov 2013 21:11:48 +0100 From: "Eljot na 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
(Fwd) Problems with DBD::Oracle package: function plsql_errstr
- Forwarded message from "Eljot na Onet.pl" - Date: Sat, 02 Nov 2013 21:11:48 +0100 From: "Eljot na 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 -