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: DBD::Oracle and RHEL8
On Mon, 6 Jul 2020 12:50:44 +0200, Oliver Dörr wrote: > Hi, > > i just tried to install DBD::Oracle 1.80 on RHEL 8 and the make > command failes. > gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib > -fstack-protector-strong Oracle.o dbdimp.o oci8.o -o > blib/arch/auto/DBD/Oracle/Oracle.so \ > -L/db/main/oraclient193/lib -lclntsh -ldl -lm -lpthread -lnsl > -lirc -limf -lirc -lrt -laio -lresolv -lsvml -lperl \ > > */usr/bin/ld: cannot find -lnsl* > collect2: error: ld returned 1 exit status > make: *** [Makefile:524: blib/arch/auto/DBD/Oracle/Oracle.so] Error 1 > > A little research and comparing to RHEL 7 shows the problem. > *RHEL7:* > ll /usr/lib64/libnsl* > -rwxr-xr-x 1 root root 115816 Jan 22 06:19 /usr/lib64/libnsl-2.17.so > *lrwxrwxrwx 1 root root 23 May 5 06:05 /usr/lib64/libnsl.so -> > ../../lib64/libnsl.so.1* > lrwxrwxrwx 1 root root 14 May 5 06:00 /usr/lib64/libnsl.so.1 -> > libnsl-2.17.so > > RHEL8: > ll /usr/lib64/libnsl* > -rwxr-xr-x 1 root root 163520 Jan 16 21:40 /usr/lib64/libnsl-2.28.so > lrwxrwxrwx 1 root root 14 Jan 16 21:29 /usr/lib64/libnsl.so.1 -> > libnsl-2.28.so > lrwxrwxrwx. 1 root root 15 Aug 12 2018 /usr/lib64/libnsl.so.2 -> > libnsl.so.2.0.0 > -rwxr-xr-x. 1 root root 116408 Aug 12 2018 /usr/lib64/libnsl.so.2.0.0 > > > So the softlink is */usr/lib64/libnsl.so* missing in RHEl8. > Everything compiles if I add the softlink, but I'm not sure if this > is a good idea. Should that not be fixed inside the Makefile.PL or so? You most likely forgot to install the libnsl2-devel package $ rpm -qf /usr/lib64/libnsl.so libnsl2-devel-1.2.0-2.20180605git4a062cf.el8.x86_64 $ sudo dnf install -y libnsl2-devel > Any hints are welcome > > Regards > Oliver -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle and RHEL8
On 6/7/20 8:50 pm, Oliver Dörr wrote: Hi, i just tried to install DBD::Oracle 1.80 on RHEL 8 and the make command failes. gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so \ -L/db/main/oraclient193/lib -lclntsh -ldl -lm -lpthread -lnsl -lirc -limf -lirc -lrt -laio -lresolv -lsvml -lperl \ */usr/bin/ld: cannot find -lnsl* collect2: error: ld returned 1 exit status make: *** [Makefile:524: blib/arch/auto/DBD/Oracle/Oracle.so] Error 1 A little research and comparing to RHEL 7 shows the problem. *RHEL7:* ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 115816 Jan 22 06:19 /usr/lib64/libnsl-2.17.so *lrwxrwxrwx 1 root root 23 May 5 06:05 /usr/lib64/libnsl.so -> ../../lib64/libnsl.so.1* lrwxrwxrwx 1 root root 14 May 5 06:00 /usr/lib64/libnsl.so.1 -> libnsl-2.17.so RHEL8: ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 163520 Jan 16 21:40 /usr/lib64/libnsl-2.28.so lrwxrwxrwx 1 root root 14 Jan 16 21:29 /usr/lib64/libnsl.so.1 -> libnsl-2.28.so lrwxrwxrwx. 1 root root 15 Aug 12 2018 /usr/lib64/libnsl.so.2 -> libnsl.so.2.0.0 -rwxr-xr-x. 1 root root 116408 Aug 12 2018 /usr/lib64/libnsl.so.2.0.0 So the softlink is */usr/lib64/libnsl.so* missing in RHEl8. Everything compiles if I add the softlink, but I'm not sure if this is a good idea. Should that not be fixed inside the Makefile.PL or so? Any hints are welcome On RHEL8 or OL8 (or similar) you should install the 'libnsl' package to use Oracle Instant Client. My update to the Instant Client install instructions about this seems to have gone AWOL. A future Instant Client RPM will install this package by default. Work is also ongoing to review the need for this dependency in the first place. Chris -- https://twitter.com/ghrd
DBD::Oracle and RHEL8
Hi, i just tried to install DBD::Oracle 1.80 on RHEL 8 and the make command failes. gcc -lpthread -shared -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so \ -L/db/main/oraclient193/lib -lclntsh -ldl -lm -lpthread -lnsl -lirc -limf -lirc -lrt -laio -lresolv -lsvml -lperl \ */usr/bin/ld: cannot find -lnsl* collect2: error: ld returned 1 exit status make: *** [Makefile:524: blib/arch/auto/DBD/Oracle/Oracle.so] Error 1 A little research and comparing to RHEL 7 shows the problem. *RHEL7:* ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 115816 Jan 22 06:19 /usr/lib64/libnsl-2.17.so *lrwxrwxrwx 1 root root 23 May 5 06:05 /usr/lib64/libnsl.so -> ../../lib64/libnsl.so.1* lrwxrwxrwx 1 root root 14 May 5 06:00 /usr/lib64/libnsl.so.1 -> libnsl-2.17.so RHEL8: ll /usr/lib64/libnsl* -rwxr-xr-x 1 root root 163520 Jan 16 21:40 /usr/lib64/libnsl-2.28.so lrwxrwxrwx 1 root root 14 Jan 16 21:29 /usr/lib64/libnsl.so.1 -> libnsl-2.28.so lrwxrwxrwx. 1 root root 15 Aug 12 2018 /usr/lib64/libnsl.so.2 -> libnsl.so.2.0.0 -rwxr-xr-x. 1 root root 116408 Aug 12 2018 /usr/lib64/libnsl.so.2.0.0 So the softlink is */usr/lib64/libnsl.so* missing in RHEl8. Everything compiles if I add the softlink, but I'm not sure if this is a good idea. Should that not be fixed inside the Makefile.PL or so? Any hints are welcome Regards Oliver
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
Right shutdown for DBD::Oracle
Hi DBI Developers, I spent some time to find the root cause of a segfault in DBD::Oracle (https://github.com/perl5-dbi/DBD-Oracle/issues/65). During running the test suite a segfault is triggered by ressource "OCIHandleFree(OCI_HTYPE_ENV)" in dr::DESTROY if a database connaction still exists. The test runs fine if the database connection is close before ($dbh->disconnect). The segfault itself occurrs in db::DESTRY (dbd_db_destroy()) because of the earlier freed ressource. From my understanding of the Oracle interface freeing the ressource "OCIHandleFree(OCI_HTYPE_ENV)" late in the destruction process is right. Currently I'm not sure about the right DBI shutdown sequence. The documentation DBI::DBD doesn't state anything about this. I expect a top-down process, freeing open statements, shutdown the database and last shutdown the driver. In the sequence as shown with DBI_TRACE the driver is destroyed first and the database level in a later step. Is there a way to change the shutdown sequence to destroy the database first and the driver last? Another option would be calling dbd_db_disconnect() from dr::DESTROY but I don't have any dbh in this function. Just for reference: DBI trace with a segfault ! >> DESTROY DISPATCH (DBI::dr=HASH(0x556494047aa0) rc1/1 @1 g2 ima10004 pid#28793) during global destruction >> DESTROY DBI::dr=HASH(0x556494047aa0) clearing 1 CachedKids ! -> DESTROY for DBD::Oracle::dr (DBI::dr=HASH(0x556494047aa0)~INNER) thr#5564920f3010 OCIHandleFree(5564940d2480,OCI_HTYPE_ENV)=SUCCESS ! <- DESTROY= ( undef ) [1 items] during global destruction DESTROY (dbih_clearcom) (drh 0x556494047a28, com 0x55649404b230, imp global destruction): FLAGS 0x102215: COMSET Active Warn PrintWarn ShowErrorStatement AutoCommit PARENT undef KIDS 1 (1 Active) dbih_clearcom 0x556494047a28 (com 0x55649404b230, type 1) done. ! >> DESTROY DISPATCH (DBIx::ContextualFetch::db=HASH(0x55649404e2c0) rc1/1 @1 g2 ima10004 pid#28793) during global destruction ! -> DESTROY for DBD::Oracle::db (DBIx::ContextualFetch::db=HASH(0x55649404e2c0)~INNER) thr#5564920f3010 **Segmentation fault** Do you have any ideas / hints how I can fix this shutdown sequence? Thank you for your support, Carsten
"password will expire" Re: proposed DBD::Oracle patch for ORA-28002
On Tue, May 05, 2015 at 07:42:14AM -0600, J.D. Laub wrote:
>I'd like to propose a small enhancement to DBD::Oracle.
>However, when I connect via DBI using an oracle wallet (SEPS) entry, that
> information is never
>presented. I tracked the inconsistency to
> DBD-Oracle-1.74/lib/DBD/Oracle.pm , line 309:
>
>309 unless (length $user_only) {
>310 $user_only = $dbh->selectrow_array(q{
>311 SELECT SYS_CONTEXT('userenv','session_user') FROM
> DUAL
>312 })||'';
>313 $dbh_inner->{Username} = $user_only;
>314 # these two are just for backwards compatibility
>315 $dbh_inner->{USER} = $dbh_inner->{CURRENT_USER} = uc
> $user_only;
>316 }
That 'uc' looks suspicious to me, but that would be a pre-existing issue.
>I'm thinking maybe it should save off the existing values for those 3
> attributes, run the query, and
>then append the old values onto those resulting from the selectrow_array.
> (Technically that would leave
>them in the wrong order - with the selectrow_array info ahead of the
> connect info - but maybe that's not
>important.) The attached patch rather clumsily does that, and has
> resolved the problem in my
>environment. I'm happy to revise the patch - just tell me where it's
> lacking.
> unless (length $user_only) {
> + # It may be we've already encountered a warning by this point,
> + # such as "ORA-28002: the password will expire within %d days".
> + # We'll cache it for reinstatement.
> + my ($err, $errstr, $state) =
> + ($dbh->err, $dbh->errstr, $dbh->state);
> $user_only = $dbh->selectrow_array(q{
> SELECT SYS_CONTEXT('userenv','session_user') FROM DUAL
> })||'';
> + # Now we'll reinstate the earlier warning. We're just
> + # appending it, so in the extremeley unlikely case that the
> + # selectrow_array we just issued also issued a warning, the
> + # 2 warnings will appear out of order.
> + $dbh->set_err($err, $errstr, $state) if defined $err;
Looks ok to me.
Tim.
proposed DBD::Oracle patch for ORA-28002
I'd like to propose a small enhancement to DBD::Oracle. When I connect
via sqlplus, I see:
ORA-28002: the password will expire within 9951 days
When I connect via DBI using normal user/pass credentials, I also see
that information, automatically generated by the connect:
DBD::Oracle::dr
connect warning: ORA-28002: the password will expire within 9951 days (DBD
SUCCESS_WITH_INFO: OCISessionBegin) at
/oracle/local/perl/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/DBI.pm
line 671, line 1.
However, when I connect via DBI using an oracle
wallet (SEPS) entry, that information is never presented. I tracked the
inconsistency to DBD-Oracle-1.74/lib/DBD/Oracle.pm , line 309:
309
unless (length $user_only) {
310 $user_only = $dbh->selectrow_array(q{
311 SELECT SYS_CONTEXT('userenv','session_user') FROM DUAL
312 })||'';
313 $dbh_inner->{Username} = $user_only;
314 # these two are just for
backwards compatibility
315 $dbh_inner->{USER} =
$dbh_inner->{CURRENT_USER} = uc $user_only;
316 }
$user_only is null
when a wallet entry is used, so the code goes back to the db to get the
username. Unfortunately that overwrites (clears) $dbh->err, $dbh->errstr,
and $dbh->state, which had contained the expiration info.
I'm thinking
maybe it should save off the existing values for those 3 attributes, run
the query, and then append the old values onto those resulting from the
selectrow_array. (Technically that would leave them in the wrong order -
with the selectrow_array info ahead of the connect info - but maybe that's
not important.) The attached patch rather clumsily does that, and has
resolved the problem in my environment. I'm happy to revise the patch -
just tell me where it's lacking.
To create the test condition, I did
this:
create profile myprofile limit PASSWORD_LOCK_TIME 1
PASSWORD_GRACE_TIME 9876 PASSWORD_LIFE_TIME 1;
alter user myuser profile
myprofile; diff -r -u DBD-Oracle-1.74/lib/DBD/Oracle.pm
DBD-Oracle-1.74.ora-28002/lib/DBD/Oracle.pm
--- DBD-Oracle-1.74/lib/DBD/Oracle.pm 2014-04-24 19:03:05.0 -0600
+++ DBD-Oracle-1.74.ora-28002/lib/DBD/Oracle.pm 2015-04-20 09:32:28.0
-0600
@@ -307,9 +307,19 @@
}
unless (length $user_only) {
+ # It may be we've already encountered a warning by this point,
+ # such as "ORA-28002: the password will expire within %d days".
+ # We'll cache it for reinstatement.
+ my ($err, $errstr, $state) =
+ ($dbh->err, $dbh->errstr, $dbh->state);
$user_only = $dbh->selectrow_array(q{
SELECT SYS_CONTEXT('userenv','session_user') FROM DUAL
})||'';
+ # Now we'll reinstate the earlier warning. We're just
+ # appending it, so in the extremeley unlikely case that the
+ # selectrow_array we just issued also issued a warning, the
+ # 2 warnings will appear out of order.
+ $dbh->set_err($err, $errstr, $state) if defined $err;
$dbh_inner->{Username} = $user_only;
# these two are just for backwards compatibility
$dbh_inner->{USER} = $dbh_inner->{CURRENT_USER} = uc $user_only;
Re: DBD::Oracle sometimes return wrong PRECISION
On Wed, 31 Dec 2014 18:49:24 +0100, "H.Merijn Brand"
wrote:
> On Wed, 31 Dec 2014 16:58:02 +0100, "H.Merijn Brand"
> wrote:
>
> > I have something weird in DBD::Oracle (1.44 and 1.74)
> > Client = 10.2.0.1.0 / AIX-5.3 - Server = 11.2.0.3.0 - 64bit / Linux
> >
> > consider a field that looks like this:
> >
> > { LINK => undef,
> > NAME => 'D_GELD',
> > NAME_lc => 'd_geld',
> > NAME_uc => 'D_GELD',
> > NULLABLE => '',
> > PRECISION=> 8,
> > SCALE=> 0,
> > TYPE => 3,
> > TYPE_NAME=> 'DECIMAL',
> > dbd_type => undef,
> > ora_est_row_width => undef,
> > ora_fail_over=> undef,
> > ora_lengths => 172,
> > ora_rowid=> undef,
> > ora_type => undef,
> > ora_types=> 2
> > }
> >
> > *sometimes* I get 126 in the PRECISION entry instead of 8
> > does that ring any bells?
> >
> > I get 126 only if I use a where clause that addresses a field that is
> > first in an index on that table otherwise I get 8
>
> I can reproduce it with this:
>
> --8<--- test.pl
> use 5.16.2;
> use warnings;
>
> use DBI;
>
> my $dbh = DBI->connect ("dbi:Oracle:", $ENV{DBI_USER}, $ENV{DBI_PASS}, {
> RaiseError => 1,
> PrintError => 1,
> AutoCommit => 1,
> ChopBlanks => 1,
> ShowErrorStatement => 1,
> FetchHashKeyName => "NAME_lc",
> });
>
> say "DBI: $DBI::VERSION";
> say "DBD: $DBD::Oracle::VERSION";
> say "OCI: ", ORA_OCI;
> say "Svr: @{$dbh->func ('ora_server_version')}";
>
> $dbh->do (qq;
> create table foo (
> a1 number (3) default -1,
> a2 number (4) default -1,
> a3 number (3) default -1,
> d_foonumber (8) default -1,
> v_foonumber (2) default 0,
> hist char (1) default 'A'
> ););
>
> sub prec
> {
> my $sth = $dbh->prepare (shift);
> $sth->execute;
> printf "PRECISION: %3d, St: %s\n", $sth->{PRECISION}[3],
> $sth->{Statement};
> } # prec
>
> sub test
> {
> prec ("select a1, a2, a3, d_foo, v_foo from foo");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where a1 = 111");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where a2 = 111");
> prec ("select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111");
> } # test
>
> test ();
>
> $dbh->do ("insert into foo values (101, 101, 25, 19841213, 0, 'A')");
>
> test ();
>
> $dbh->do ("create index idx_foo on foo (a1, a2, a3, d_foo desc, v_foo desc,
> hist)");
>
> test ();
>
> END { $dbh->do ("drop table foo"); }
> -->8---
>
> $ perl test.pl
> DBI: 1.632
> DBD: 1.74
> OCI: 11.2.0.3
> Svr: 11 2 0 3 0
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
> PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
> PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
>
>
> SQL*Plus: Release 11.2.0.3.0 Production on Wed Dec 31 18:42:36 2014
> This is perl 5, version 20, subversion 0 (v5.20.0) built for
> x86_64-linux-thread-multi-ld
SQLite (all undef):
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: -, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: -, St: s
Re: DBD::Oracle sometimes return wrong PRECISION
On Wed, 31 Dec 2014 16:58:02 +0100, "H.Merijn Brand"
wrote:
> I have something weird in DBD::Oracle (1.44 and 1.74)
> Client = 10.2.0.1.0 / AIX-5.3 - Server = 11.2.0.3.0 - 64bit / Linux
>
> consider a field that looks like this:
>
> { LINK => undef,
> NAME => 'D_GELD',
> NAME_lc => 'd_geld',
> NAME_uc => 'D_GELD',
> NULLABLE => '',
> PRECISION=> 8,
> SCALE=> 0,
> TYPE => 3,
> TYPE_NAME=> 'DECIMAL',
> dbd_type => undef,
> ora_est_row_width => undef,
> ora_fail_over=> undef,
> ora_lengths => 172,
> ora_rowid=> undef,
> ora_type => undef,
> ora_types=> 2
> }
>
> *sometimes* I get 126 in the PRECISION entry instead of 8
> does that ring any bells?
>
> I get 126 only if I use a where clause that addresses a field that is
> first in an index on that table otherwise I get 8
I can reproduce it with this:
--8<--- test.pl
use 5.16.2;
use warnings;
use DBI;
my $dbh = DBI->connect ("dbi:Oracle:", $ENV{DBI_USER}, $ENV{DBI_PASS}, {
RaiseError => 1,
PrintError => 1,
AutoCommit => 1,
ChopBlanks => 1,
ShowErrorStatement => 1,
FetchHashKeyName => "NAME_lc",
});
say "DBI: $DBI::VERSION";
say "DBD: $DBD::Oracle::VERSION";
say "OCI: ", ORA_OCI;
say "Svr: @{$dbh->func ('ora_server_version')}";
$dbh->do (qq;
create table foo (
a1 number (3) default -1,
a2 number (4) default -1,
a3 number (3) default -1,
d_foonumber (8) default -1,
v_foonumber (2) default 0,
hist char (1) default 'A'
););
sub prec
{
my $sth = $dbh->prepare (shift);
$sth->execute;
printf "PRECISION: %3d, St: %s\n", $sth->{PRECISION}[3], $sth->{Statement};
} # prec
sub test
{
prec ("select a1, a2, a3, d_foo, v_foo from foo");
prec ("select a1, a2, a3, d_foo, v_foo from foo where a1 = 111");
prec ("select a1, a2, a3, d_foo, v_foo from foo where a2 = 111");
prec ("select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111");
} # test
test ();
$dbh->do ("insert into foo values (101, 101, 25, 19841213, 0, 'A')");
test ();
$dbh->do ("create index idx_foo on foo (a1, a2, a3, d_foo desc, v_foo desc,
hist)");
test ();
END { $dbh->do ("drop table foo"); }
-->8---
$ perl test.pl
DBI: 1.632
DBD: 1.74
OCI: 11.2.0.3
Svr: 11 2 0 3 0
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
PRECISION: 8, St: select a1, a2, a3, d_foo, v_foo from foo
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a1 = 111
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where a2 = 111
PRECISION: 126, St: select a1, a2, a3, d_foo, v_foo from foo where d_foo = 111
SQL*Plus: Release 11.2.0.3.0 Production on Wed Dec 31 18:42:36 2014
This is perl 5, version 20, subversion 0 (v5.20.0) built for
x86_64-linux-thread-multi-ld
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
pgp6dS65H8sK6.pgp
Description: OpenPGP digital signature
DBD::Oracle sometimes return wrong PRECISION
I have something weird in DBD::Oracle (1.44 and 1.74)
Client = 10.2.0.1.0 / AIX-5.3 - Server = 11.2.0.3.0 - 64bit / Linux
consider a field that looks like this:
{ LINK => undef,
NAME => 'D_GELD',
NAME_lc => 'd_geld',
NAME_uc => 'D_GELD',
NULLABLE => '',
PRECISION=> 8,
SCALE=> 0,
TYPE => 3,
TYPE_NAME=> 'DECIMAL',
dbd_type => undef,
ora_est_row_width => undef,
ora_fail_over=> undef,
ora_lengths => 172,
ora_rowid=> undef,
ora_type => undef,
ora_types=> 2
}
*sometimes* I get 126 in the PRECISION entry instead of 8
does that ring any bells?
I get 126 only if I use a where clause that addresses a field that is
first in an index on that table otherwise I get 8
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
pgpWN7ZjzwcBU.pgp
Description: OpenPGP digital signature
Re: DBD::Oracle 1.72 fail
On Thu, 22 May 2014 07:49:15 -0700, Christopher Jones wrote: > On 5/21/14, 11:03 PM, H.Merijn Brand wrote: > > On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones > > wrote: > > > >> > >> > >> On 05/19/2014 01:48 PM, H.Merijn Brand wrote: > >>> On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones > >>> wrote: > >>> > >>>> > >>>> I appreciate the wealth of information. > >>>> It really does help when we have to prioritize project and features. > >>> > >>> FEEDBACK! > >>> > >>> I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) > >> > >> It sounds like you have a client using 12c libraries from a mixed > >> environment directory! > >> I'd have to ask "why?". I couldn't recommend doing it. > > > > Neither would I, BUT … > > > > perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does > > not work for quite a few of our applications when linking DBD::Oracle > > to the 10g client that is available in the 10g database environment. > > The problem is the interesting part. I'd like to know what "does not > work". Our SOAP clients. I am not able/allowed to reveal code on that. I might be able to reproduce an error message, but as I recall the message, it did not hint to *anything* useful at all > > The client is not (yet) willing to move on to 11g or 12c, so the 10g is > > there to stay. > > It sounds like you've moved them, at least for Perl. No, they are fully 10g, but now the 10g /lib has three extra .so's from 12c and those timezone files: their 10g installation doesn't care if there are a few extra files in there. They are just used by DBD::Oracle > Chris -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle 1.72 fail
On 5/21/14, 11:03 PM, H.Merijn Brand wrote: On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones wrote: On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: I appreciate the wealth of information. It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) It sounds like you have a client using 12c libraries from a mixed environment directory! I'd have to ask "why?". I couldn't recommend doing it. Neither would I, BUT … perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does not work for quite a few of our applications when linking DBD::Oracle to the 10g client that is available in the 10g database environment. The problem is the interesting part. I'd like to know what "does not work". The client is not (yet) willing to move on to 11g or 12c, so the 10g is there to stay. It sounds like you've moved them, at least for Perl. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Wed, 21 May 2014 17:28:53 -0700, Christopher Jones wrote: > > > On 05/19/2014 01:48 PM, H.Merijn Brand wrote: > > On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones > > wrote: > > > >> > >> I appreciate the wealth of information. > >> It really does help when we have to prioritize project and features. > > > > FEEDBACK! > > > > I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) > > It sounds like you have a client using 12c libraries from a mixed environment > directory! > I'd have to ask "why?". I couldn't recommend doing it. Neither would I, BUT … perl-5.14.2 and newer with OpenSSL-1.0.0 or newer and DBD::Oracle does not work for quite a few of our applications when linking DBD::Oracle to the 10g client that is available in the 10g database environment. The client is not (yet) willing to move on to 11g or 12c, so the 10g is there to stay. Being a perl-hacker one tries to find a way to make it work :) The whole thing worked fine (same OS, same perl, same version of DBI and DBD::Oracle and the same version of OpenSSL) under a 12c install environment, so the obvious solution is to try to get DBD::Oracle linked against 12c client libraries working in the 10g environment to make the client, and thus us, happy. > Chris > > > 1. Install 12c-client for HP-UX itanium > > 2. Build DBD::Oracle against that and install > > > > 3. Move to the 10g environment > > 4. Get these files from 12c into the 10g tree: none of them overwrites > > an other file! > > > > lib/libclntsh.so.12.1 > > lib/libnnz12.so > > lib/libclntshcore.so.12.1 > > oracore/zoneinfo/timezdif.csv > > oracore/zoneinfo/timezlrg_1.dat > > oracore/zoneinfo/timezlrg_10.dat > > oracore/zoneinfo/timezlrg_11.dat > > oracore/zoneinfo/timezlrg_12.dat > > oracore/zoneinfo/timezlrg_13.dat > > oracore/zoneinfo/timezlrg_14.dat > > oracore/zoneinfo/timezlrg_15.dat > > oracore/zoneinfo/timezlrg_16.dat > > oracore/zoneinfo/timezlrg_17.dat > > oracore/zoneinfo/timezlrg_18.dat > > oracore/zoneinfo/timezlrg_2.dat > > oracore/zoneinfo/timezlrg_3.dat > > oracore/zoneinfo/timezlrg_4.dat > > oracore/zoneinfo/timezlrg_5.dat > > oracore/zoneinfo/timezlrg_6.dat > > oracore/zoneinfo/timezlrg_7.dat > > oracore/zoneinfo/timezlrg_8.dat > > oracore/zoneinfo/timezlrg_9.dat > > oracore/zoneinfo/timezone_1.dat > > oracore/zoneinfo/timezone_10.dat > > oracore/zoneinfo/timezone_11.dat > > oracore/zoneinfo/timezone_12.dat > > oracore/zoneinfo/timezone_13.dat > > oracore/zoneinfo/timezone_14.dat > > oracore/zoneinfo/timezone_15.dat > > oracore/zoneinfo/timezone_16.dat > > oracore/zoneinfo/timezone_17.dat > > oracore/zoneinfo/timezone_18.dat > > oracore/zoneinfo/timezone_2.dat > > oracore/zoneinfo/timezone_3.dat > > oracore/zoneinfo/timezone_4.dat > > oracore/zoneinfo/timezone_5.dat > > oracore/zoneinfo/timezone_6.dat > > oracore/zoneinfo/timezone_7.dat > > oracore/zoneinfo/timezone_8.dat > > oracore/zoneinfo/timezone_9.dat > > > > > > HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb > > > > This is perl 5, version 14, subversion 2 (v5.14.2) built for > > IA64.ARCHREV_0-LP64-ld > > > > DBI-1.631 > > DBD::Oracle-1.74 > > > > SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 > > > > Copyright (c) 1982, 2005, Oracle. All rights reserved. > > > > > > Connected to: > > Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production > > With the Partitioning, OLAP and Data Mining options > > > > $ llldd > > /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so > > > > Lib Real path > > Size DateRefs > > > > - --- > > /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. > > 668072 2014-05-19 18:39:46 25 > > /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 > > 117402552 2014-05-19 18:33:03 21 > > /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so > > 16442824 2013-12-05 09:29:34 12 > > /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s > > 14541616 2014-05-19 18:33:03 11 > > /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 > > 85568 2007-02-15 22:36:36
Re: DBD::Oracle 1.72 fail
On 05/19/2014 01:48 PM, H.Merijn Brand wrote: On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: I appreciate the wealth of information. It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) It sounds like you have a client using 12c libraries from a mixed environment directory! I'd have to ask "why?". I couldn't recommend doing it. Chris 1. Install 12c-client for HP-UX itanium 2. Build DBD::Oracle against that and install 3. Move to the 10g environment 4. Get these files from 12c into the 10g tree: none of them overwrites an other file! lib/libclntsh.so.12.1 lib/libnnz12.so lib/libclntshcore.so.12.1 oracore/zoneinfo/timezdif.csv oracore/zoneinfo/timezlrg_1.dat oracore/zoneinfo/timezlrg_10.dat oracore/zoneinfo/timezlrg_11.dat oracore/zoneinfo/timezlrg_12.dat oracore/zoneinfo/timezlrg_13.dat oracore/zoneinfo/timezlrg_14.dat oracore/zoneinfo/timezlrg_15.dat oracore/zoneinfo/timezlrg_16.dat oracore/zoneinfo/timezlrg_17.dat oracore/zoneinfo/timezlrg_18.dat oracore/zoneinfo/timezlrg_2.dat oracore/zoneinfo/timezlrg_3.dat oracore/zoneinfo/timezlrg_4.dat oracore/zoneinfo/timezlrg_5.dat oracore/zoneinfo/timezlrg_6.dat oracore/zoneinfo/timezlrg_7.dat oracore/zoneinfo/timezlrg_8.dat oracore/zoneinfo/timezlrg_9.dat oracore/zoneinfo/timezone_1.dat oracore/zoneinfo/timezone_10.dat oracore/zoneinfo/timezone_11.dat oracore/zoneinfo/timezone_12.dat oracore/zoneinfo/timezone_13.dat oracore/zoneinfo/timezone_14.dat oracore/zoneinfo/timezone_15.dat oracore/zoneinfo/timezone_16.dat oracore/zoneinfo/timezone_17.dat oracore/zoneinfo/timezone_18.dat oracore/zoneinfo/timezone_2.dat oracore/zoneinfo/timezone_3.dat oracore/zoneinfo/timezone_4.dat oracore/zoneinfo/timezone_5.dat oracore/zoneinfo/timezone_6.dat oracore/zoneinfo/timezone_7.dat oracore/zoneinfo/timezone_8.dat oracore/zoneinfo/timezone_9.dat HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb This is perl 5, version 14, subversion 2 (v5.14.2) built for IA64.ARCHREV_0-LP64-ld DBI-1.631 DBD::Oracle-1.74 SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options $ llldd /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so Lib Real pathSize DateRefs - --- /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. 668072 2014-05-19 18:39:46 25 /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 117402552 2014-05-19 18:33:03 21 /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so 16442824 2013-12-05 09:29:34 12 /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s 14541616 2014-05-19 18:33:03 11 /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 85568 2007-02-15 22:36:361 /usr/lib/hpux64/libdl.so.1 /usr/lib/hpux64/libdl.so.1 78704 2012-07-20 08:34:040 /usr/lib/hpux64/libm.so.1/usr/lib/hpux64/libm.so.1 6481912 2011-05-18 22:53:120 /usr/lib/hpux64/libpthread.so.1 /usr/lib/hpux64/libpthread.so.1 1613024 2011-08-10 22:04:540 /usr/lib/hpux64/libnsl.so.1 /usr/lib/hpux64/libnsl.so.1 1511400 2010-07-30 16:06:083 /usr/lib/hpux64/libc.so.1/usr/lib/hpux64/libc.so.1 4900360 2012-08-27 09:33:451 /usr/lib/hpux64/libxti.so.1 /usr/lib/hpux64/libxti.so.1 298552 2011-02-22 16:00:360 /usr/lib/hpux64/libunwind.so.1 /usr/lib/hpux64/libunwind.so.1 714608 2010-12-06 22:57:421 /usr/lib/hpux64/libuca.so.1 /usr/lib/hpux64/libuca.so.1 85680 2007-02-15 22:36:360 /usr/lib/hpux64/libdiskown.so/usr/lib/hpux64/libdiskown.so.1 95736 2013-04-01 10:43:490 /pro/oracle/v102/lib/libons.so /pro/oracle/v102/lib/libons10.so 218944 2005-06-27 10:04:005 In the end, all products work with both the libons.so from 10g as well as with libons.so from 12c -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Thu, 17 Apr 2014 23:49:24 -0700, Christopher Jones wrote: > > I appreciate the wealth of information. > It really does help when we have to prioritize project and features. FEEDBACK! I have perl-5.18.2-ia64 running with 12c client in a 10g environment :) 1. Install 12c-client for HP-UX itanium 2. Build DBD::Oracle against that and install 3. Move to the 10g environment 4. Get these files from 12c into the 10g tree: none of them overwrites an other file! lib/libclntsh.so.12.1 lib/libnnz12.so lib/libclntshcore.so.12.1 oracore/zoneinfo/timezdif.csv oracore/zoneinfo/timezlrg_1.dat oracore/zoneinfo/timezlrg_10.dat oracore/zoneinfo/timezlrg_11.dat oracore/zoneinfo/timezlrg_12.dat oracore/zoneinfo/timezlrg_13.dat oracore/zoneinfo/timezlrg_14.dat oracore/zoneinfo/timezlrg_15.dat oracore/zoneinfo/timezlrg_16.dat oracore/zoneinfo/timezlrg_17.dat oracore/zoneinfo/timezlrg_18.dat oracore/zoneinfo/timezlrg_2.dat oracore/zoneinfo/timezlrg_3.dat oracore/zoneinfo/timezlrg_4.dat oracore/zoneinfo/timezlrg_5.dat oracore/zoneinfo/timezlrg_6.dat oracore/zoneinfo/timezlrg_7.dat oracore/zoneinfo/timezlrg_8.dat oracore/zoneinfo/timezlrg_9.dat oracore/zoneinfo/timezone_1.dat oracore/zoneinfo/timezone_10.dat oracore/zoneinfo/timezone_11.dat oracore/zoneinfo/timezone_12.dat oracore/zoneinfo/timezone_13.dat oracore/zoneinfo/timezone_14.dat oracore/zoneinfo/timezone_15.dat oracore/zoneinfo/timezone_16.dat oracore/zoneinfo/timezone_17.dat oracore/zoneinfo/timezone_18.dat oracore/zoneinfo/timezone_2.dat oracore/zoneinfo/timezone_3.dat oracore/zoneinfo/timezone_4.dat oracore/zoneinfo/timezone_5.dat oracore/zoneinfo/timezone_6.dat oracore/zoneinfo/timezone_7.dat oracore/zoneinfo/timezone_8.dat oracore/zoneinfo/timezone_9.dat HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 4075 Mb This is perl 5, version 14, subversion 2 (v5.14.2) built for IA64.ARCHREV_0-LP64-ld DBI-1.631 DBD::Oracle-1.74 SQL*Plus: Release 10.2.0.1.0 - Production on Mon May 19 22:45:19 2014 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options $ llldd /pro/asql/o83R/lib/perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBD/Oracle/Oracle.so Lib Real pathSize DateRefs - --- /pro/asql/o83R/lib/perl/5.14.2/IA64. /pro/asql/o83R/lib/perl/5.14.2/IA64. 668072 2014-05-19 18:39:46 25 /pro/oracle/v102/lib/libclntsh.so.12 /pro/oracle/v102/lib/libclntsh.so.12 117402552 2014-05-19 18:33:03 21 /pro/oracle/v102/lib/libnnz12.so /pro/oracle/v102/lib/libnnz12.so 16442824 2013-12-05 09:29:34 12 /pro/oracle/v102/lib/libclntshcore.s /pro/oracle/v102/lib/libclntshcore.s 14541616 2014-05-19 18:33:03 11 /usr/lib/hpux64/librt.so.1 /usr/lib/hpux64/librt.so.1 85568 2007-02-15 22:36:361 /usr/lib/hpux64/libdl.so.1 /usr/lib/hpux64/libdl.so.1 78704 2012-07-20 08:34:040 /usr/lib/hpux64/libm.so.1/usr/lib/hpux64/libm.so.1 6481912 2011-05-18 22:53:120 /usr/lib/hpux64/libpthread.so.1 /usr/lib/hpux64/libpthread.so.1 1613024 2011-08-10 22:04:540 /usr/lib/hpux64/libnsl.so.1 /usr/lib/hpux64/libnsl.so.1 1511400 2010-07-30 16:06:083 /usr/lib/hpux64/libc.so.1/usr/lib/hpux64/libc.so.1 4900360 2012-08-27 09:33:451 /usr/lib/hpux64/libxti.so.1 /usr/lib/hpux64/libxti.so.1 298552 2011-02-22 16:00:360 /usr/lib/hpux64/libunwind.so.1 /usr/lib/hpux64/libunwind.so.1 714608 2010-12-06 22:57:421 /usr/lib/hpux64/libuca.so.1 /usr/lib/hpux64/libuca.so.1 85680 2007-02-15 22:36:360 /usr/lib/hpux64/libdiskown.so/usr/lib/hpux64/libdiskown.so.1 95736 2013-04-01 10:43:490 /pro/oracle/v102/lib/libons.so /pro/oracle/v102/lib/libons10.so 218944 2005-06-27 10:04:005 In the end, all products work with both the libons.so from 10g as well as with libons.so from 12c > Chris > > On 4/17/14, 11:41 PM, H.Merijn Brand wrote: > > On Thu, 17 Apr 2014 15:55:27 -0700, Christopher Jones > > wrote: > > > >> > >> [I thought I'd replied this morning, but can't see it in my outbox] > >> > >> On 04/16/2014 08:42 AM, H.Merijn Brand wrote: > >>> On Wed, 16 Apr 2014 08:18:10 -0700, Christopher Jones > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> An enhancement request for including tnsping already exists in the > >>>> Oracle bug database. If you can give me a description of how you use > >>>> tnsping, I will add it to the e
Re: DBD::Oracle 1.72 fail
On 15/04/2014 12:38, H.Merijn Brand wrote:
Builds fail on Linux with OIC-12.1
As a side note, is anyone able to fetch Oracle Instant Client-12 for
HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :(
http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html
# Box 1
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] x86_64 Xeon(R) CPU E5-1650 0
@ 3.20GHz/3072(12) x86_64 16008 Mb
Using DBI 1.631 (for perl 5.016002 on x86_64-linux-ld) installed in
/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.016002 on linux (x86_64-linux-ld)
Installing on a linux, Ver#3.4
Using Oracle in /usr/lib/oracle/12.1/client64
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client64/demo.mk
Using /usr/share/oracle/12.1/client64/demo.mk
ccache cc -c -I/usr/include/oracle/12.1/client64 -I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64 -I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.c:4355:31: error: âimp_dbhâ undeclared (first use in this function)
if (CSFORM_IMPLIES_UTF8(SQLCS_IMPLICIT)) {
^
dbdimp.c:4355:31: note: each undeclared identifier is reported only once for
each function it appears in
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
# Box 2
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] i386 Core(TM) i7-2620M CPU @
2.70GHz/2619(4) i686 8032 Mb
Using DBI 1.631 (for perl 5.018002 on i686-linux-64int-ld) installed in
/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.018002 on linux (i686-linux-64int-ld)
Using Oracle in /usr/lib/oracle/12.1/client
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client/demo.mk
Using /usr/share/oracle/12.1/client/demo.mk
cc -c -I/usr/include/oracle/12.1/client -I/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" -fPIC
"-I/pro/lib/perl5/5.18.2/i686-linux-64int-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT
-DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c
dbdimp.c: In function âdbd_rebind_ph_charâ:
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing 96 phs sv to %ld resulted in buffer
%ld\n", phs->maxlen - 1, SvLEN(phs->sv)
^
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing phs sv to %ld resulted in buffer %ld\n",
phs->maxlen +1, SvLEN(phs->sv));
^
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2605:27: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âSTRLENâ [-Wformat=]
"Changing maxlen to %ld\n", SvLEN(phs->sv));
^
dbdimp.c: In function âdbd_rebind_ph_xmlâ:
dbdimp.c:2889:17: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
phs->progv = (void*) SvIV(ptr);
^
In file included from Oracle.h:52:0,
from dbdimp.
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 13:38:38 +0200, "H.Merijn Brand" wrote: > Builds fail on Linux with OIC-12.1 tl;dr; if you are not interested in porting DBD::Oracle I have now installed/gathered the available stuff for HP-UX Itanium 64bit, moved all into the required locations and tried to build DBD::Oracle Using rpm's on Linux is straightforward, and all works immediately after that. On HP-UX, one has to move the files a bit after extracting the following zips: instantclient-basic-hpux.ia64-12.1.0.1.0.zip instantclient-jdbc-hpux.ia64-12.1.0.1.0.zip instantclient-odbc-hpux.ia64-12.1.0.1.0.zip instantclient-sdk-hpux.ia64-12.1.0.1.0.zip instantclient-sqlplus-hpux.ia64-12.1.0.1.0.zip instantclient-tools-hpux.ia64-12.1.0.1.0.zip instantclient-precomp-hpux.ia64-12.1.0.1.0.zip I added tnsping from the 10.2 database product (and the two required messgae files). The Instant Client seems to work: DBD-Oracle-1.72-2g6rU8 511 > tnsping $TWO_TASK TNS Ping Utility for HPUX: Version 10.2.0.1.0 - Production on 16-APR-2014 10:38:17 Copyright (c) 1997, 2005, Oracle. All rights reserved. Used parameter files: /pro/oracle/ic121/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact ( DESCRIPTION = ( ADDRESS_LIST = ( ADDRESS = ( HOST = dbo)( PORT = 1521)( PROTOCOL = TCP))) ( CONNECT_DATA = ( SERVICE_NAME = xxx0123))) OK (210 msec) DBD-Oracle-1.72-2g6rU8 512 > sqlplus $ORACLE_USERID SQL*Plus: Release 12.1.0.1.0 Production on Wed Apr 16 10:40:49 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> So far so good. I had to read Makefile.PL to check what it expects where, as all those zips install in different locations. The final SUCCESS for that stage results in DBD-Oracle-1.72-2g6rU8 520 > perl Makefile.PL Using DBI 1.631 (for perl 5.014002 on IA64.ARCHREV_0-LP64-ld) installed in /pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI/ Configuring DBD::Oracle for perl 5.014002 on hpux (IA64.ARCHREV_0-LP64-ld) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a hpux, Ver#11.31 Using Oracle in /pro/oracle/ic121 DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR) Oracle version 12.1.0.1 (12.1) Looks like an Instant Client installation, okay Your LD_LIBRARY_PATH/SHLIB_PATH env var is set to '/pro/oracle/ic121/lib:/pro/local/lib:/usr/local/ssl/lib:/pro/pgsql/lib:/usr/local/lib:/usr/lib/hpux64:/usr/lib:/pro/pgsql/lib:/etc/opt/resmon/lib:/opt/gnome/lib:/usr/local/ia64/lib/hpux64' WARNING: Your LD_LIBRARY_PATH/SHLIB_PATH env var doesn't include '/pro/oracle/ic121' but probably needs to. Oracle sysliblist: Found header files in /pro/oracle/ic121/sdk/include. client_version=12.1 DEFINE= -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 WARNING: If you have trouble, see README.hpux.txt... you may have to build your own perl, or go hunting for libraries WARNING: If you have trouble, try perl Makefile.PL -l Checking for functioning wait.ph System: perl5.014002 hp-ux x2 b.11.31 u ia64 2977233888 unlimited-user license Compiler: cc +O2 +Onolimit -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/bin/ld Sysliblist: Linking with -lclntsh. WARNING: If you have problems you may need to rebuild perl with threading enabled. LD_RUN_PATH=/pro/oracle/ic121 Using DBD::Oracle 1.72. Using DBD::Oracle 1.72. Using DBI 1.631 (for perl 5.014002 on IA64.ARCHREV_0-LP64-ld) installed in /pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI/ Generating a Unix-style Makefile Writing Makefile for DBD::Oracle Writing MYMETA.yml and MYMETA.json *** If you have problems... read all the log printed above, and the README and README.help.txt files. (Of course, you have read README by now anyway, haven't you?) Next, building … cc -c -I/pro/oracle/ic121/sdk/include -I/pro/lib/perl5/site_perl/5.14.2/IA64.ARCHREV_0-LP64-ld/auto/DBI -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit -DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" +Z "-I/pro/lib/perl5/5.14.2/IA64.ARCHREV_0-LP64-ld/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c "/pro/lib/perl5/5.14.2/IA64.ARCHREV_0-LP64-ld/CORE/regexp.h", line 329: warning #2111-D: statement is unreachable return "?"; /* Unknown */ ^ "dbdimp.c", line 736: warning #2181-D: argument is incompatible with corresponding format string conversion
Re: DBD::Oracle 1.72 fail
On 4/15/14, 10:56 AM, H.Merijn Brand wrote: On Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones wrote: On 04/15/2014 04:38 AM, H.Merijn Brand wrote: As a side note, is anyone able to fetch Oracle Instant Client-12 for HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html It downloads for me: I had to log into OTN first, though. If you can describe your actual problem, I can ask an admin to review it. My colleague is currently downloading all of them. Lets just assume it was a temporary glitch FWIW I also logged in to OTN before I tried Thanks for the status update. Let me know if the issue reappears. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 10:33:19 -0700, Christopher Jones wrote: > On 04/15/2014 04:38 AM, H.Merijn Brand wrote: > > > As a side note, is anyone able to fetch Oracle Instant Client-12 for > > HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( > > http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html > > It downloads for me: I had to log into OTN first, though. > If you can describe your actual problem, I can ask an admin to review it. My colleague is currently downloading all of them. Lets just assume it was a temporary glitch FWIW I also logged in to OTN before I tried -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle 1.72 fail
On 04/15/2014 04:38 AM, H.Merijn Brand wrote: As a side note, is anyone able to fetch Oracle Instant Client-12 for HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :( http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html It downloads for me: I had to log into OTN first, though. If you can describe your actual problem, I can ask an admin to review it. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Re: DBD::Oracle 1.72 fail
On 2014-04-15, 11:18 AM, H.Merijn Brand wrote: Is 1.70 faring any better? Thanks, that help a lot! The culprit seems to be https://github.com/pythian/DBD-Oracle/commit/957f54750ba8c1972beabd1dcd305bd6c47c4586 I'll check with Martin, as he wrote the code and has much, much higher chances to understand what is going there. :-) Cheers, `/anick -- Yanick Champoux Solutions Architect Pythian - Love your data champ...@pythian.com Tel: +1 613 565 8696 x 274 www.pythian.com -- --
Re: DBD::Oracle 1.72 fail
On Tue, 15 Apr 2014 11:06:47 -0400, Yanick Champoux
wrote:
> On 2014-04-15, 7:38 AM, H.Merijn Brand wrote:
> > Builds fail on Linux with OIC-12.1
>
> Is 1.70 faring any better? If I read the logs correctly, the problem is
>
> > dbdimp.h:311:27: error: âimp_dbhâ undeclared (first use in this function)
> >((csform==SQLCS_NCHAR) ? imp_dbh->ncharsetid : imp_dbh->charsetid)
>
> and that didn't change since last December, so it should be in 1.70, but
> not 1.68.
$ git co v1.70
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:725:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:725:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
^
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.70\"
-DXS_VERSION=\"1.70\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 oci8.c
oci8.c: In function âora_blob_read_mb_pieceâ:
oci8.c:1847:4: warning: format â%luâ expects argument of type âlong unsigned
intâ, but argument 6 has type âub4â [-Wformat=]
fbh->field_num+1, ftype, offset, len, destoffset, ul_t(amtp));
^
oci8.c: At top level:
oci8.c:20:93: warning: âdbi_get_stateâ defined but not used [-Wunused-function]
DBISTATE_DECLARE;
^
$ git co v1.71_00
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.71_00\"
-DXS_VERSION=\"1.71_00\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.71_00\"
-DXS_VERSION=\"1.71_00\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.c:4355:31: error: âimp_dbhâ undeclared (first use in this function)
if (CSFORM_IMPLIES_UTF8(SQLCS_IMPLICIT)) {
^
dbdimp.c:4355:31: note: each undeclared identifier is reported only once for
each function it appears in
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
^
make: *** [dbdimp.o] Error 1
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.19 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle 1.72 fail
On 2014-04-15, 7:38 AM, H.Merijn Brand wrote: Builds fail on Linux with OIC-12.1 Is 1.70 faring any better? If I read the logs correctly, the problem is dbdimp.h:311:27: error: âimp_dbhâ undeclared (first use in this function) ((csform==SQLCS_NCHAR) ? imp_dbh->ncharsetid : imp_dbh->charsetid) and that didn't change since last December, so it should be in 1.70, but not 1.68. Cheers, `/anick -- Yanick Champoux Solutions Architect Pythian - Love your data champ...@pythian.com Tel: +1 613 565 8696 x 274 www.pythian.com -- --
DBD::Oracle 1.72 fail
Builds fail on Linux with OIC-12.1
As a side note, is anyone able to fetch Oracle Instant Client-12 for
HP-UX Itanium 64 bit? Even on WinBlow$ that doesn't work :(
http://www.oracle.com/technetwork/topics/hpitanium64soft-091490.html
# Box 1
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] x86_64 Xeon(R) CPU E5-1650 0
@ 3.20GHz/3072(12) x86_64 16008 Mb
Using DBI 1.631 (for perl 5.016002 on x86_64-linux-ld) installed in
/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.016002 on linux (x86_64-linux-ld)
Installing on a linux, Ver#3.4
Using Oracle in /usr/lib/oracle/12.1/client64
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client64/demo.mk
Using /usr/share/oracle/12.1/client64/demo.mk
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.72\"
-DXS_VERSION=\"1.72\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 Oracle.c
ccache cc -c -I/usr/include/oracle/12.1/client64
-I/pro/lib/perl5/site_perl/5.16.2/x86_64-linux-ld/auto/DBI -fPIC
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.72\"
-DXS_VERSION=\"1.72\" -fPIC "-I/pro/lib/perl5/5.16.2/x86_64-linux-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âora_db_login6â:
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 12 has type âsize_tâ [-Wformat=]
OCISessionPoolCreate_log_stat(
^
dbdimp.c:723:5: warning: format â%dâ expects argument of type âintâ, but
argument 14 has type âsize_tâ [-Wformat=]
dbdimp.c: In function âora_st_FETCH_attribâ:
dbdimp.c:4355:31: error: âimp_dbhâ undeclared (first use in this function)
if (CSFORM_IMPLIES_UTF8(SQLCS_IMPLICIT)) {
^
dbdimp.c:4355:31: note: each undeclared identifier is reported only once for
each function it appears in
dbdimp.c: At top level:
dbdimp.c:32:93: warning: âdbi_get_stateâ defined but not used
[-Wunused-function]
DBISTATE_DECLARE;
# Box 2
Linux 3.11.10-7-desktop [openSUSE 13.1 (Bottle)] i386 Core(TM) i7-2620M CPU @
2.70GHz/2619(4) i686 8032 Mb
Using DBI 1.631 (for perl 5.018002 on i686-linux-64int-ld) installed in
/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI/
Configuring DBD::Oracle for perl 5.018002 on linux (i686-linux-64int-ld)
Using Oracle in /usr/lib/oracle/12.1/client
DEFINE _SQLPLUS_RELEASE = "1201000100" (CHAR)
Oracle version 12.1.0.1 (12.1)
Found /usr/share/oracle/12.1/client/demo.mk
Using /usr/share/oracle/12.1/client/demo.mk
cc -c -I/usr/include/oracle/12.1/client
-I/pro/lib/perl5/site_perl/5.18.2/i686-linux-64int-ld/auto/DBI
-fno-strict-aliasing -pipe -fstack-protector -I/pro/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.72\"
-DXS_VERSION=\"1.72\" -fPIC "-I/pro/lib/perl5/5.18.2/i686-linux-64int-ld/CORE"
-Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"12.1.0.1\" -DORA_OCI_102
-DORA_OCI_112 dbdimp.c
dbdimp.c: In function âdbd_rebind_ph_charâ:
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing 96 phs sv to %ld resulted in buffer
%ld\n", phs->maxlen - 1, SvLEN(phs->sv)
^
dbdimp.c:2558:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âIVâ [-Wformat=]
"Growing phs sv to %ld resulted in buffer
%ld\n", phs->maxlen +1, SvLEN(phs->sv));
^
dbdimp.c:2572:35: warning: format â%ldâ expects argument of type âlong intâ,
but argument 4 has type âSTRLENâ [-Wformat=]
dbdimp.c:2605:27: warning: format â%ldâ expects argument of type âlong intâ,
but argument 3 has type âSTRLENâ [-Wformat=]
"Changing maxlen to %ld\n", SvLEN(phs->sv));
^
dbdimp.c: In function âdbd_rebind_ph_xmlâ:
dbdimp.c:2889:17: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
phs->progv = (void*) SvIV(ptr);
^
In file included from Oracle.h:52:0,
from dbdimp.c:21:
dbdimp.c: In function âora_st_FETCH_attribâ:
dbd
patch for SYS[BACKUKP|KM|DG] on DBD::Oracle 1.66
Hi,
I needed the new Oracle 12c feature to connect to the database with
SYSBACKUP.
So I patched the latest DBD::Oracle.
This patch supports ORA_SYSBACKUP, ORA_SYSDG and ORA_SYSKM.
The OCI parameter are OCI_SYSBKP, OCI_SYSDGD and OCI_SYSKMT
but since DBD::Oracle will be used by users who are used to use '/ as
sysbackup'
I decided to use ORA_SYSBACKUP over ORA_SYSBKP.
My test results :
Extract from my $OH/rdbms/lib/config.c
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "dba"
#define SS_ASM_GRP ""
#define SS_BKP_GRP "bkpdba"
#define SS_DGD_GRP "dgddba"
#define SS_KMT_GRP "kmtdba"
My os users :
grep dba /etc/passwd
bkpdba:x:4102:15001::/home/bkpdba:/bin/bash
dgddba:x:4103:15002::/home/dgddba:/bin/bash
kmtdba:x:4104:15003::/home/kmtdba:/bin/bash
My os grps :
grep dba /etc/group
dba:x:15000:
bkpdba:x:15001:oracle
dgddba:x:15002:oracle
kmtdba:x:15003:oracle
Test script (quick and dirty) :
#!/usr/local/bin/perl
use DBI;
use DBD::Oracle qw(:ora_session_modes);
use Data::Dumper;
my @session_modes = (ORA_SYSDBA, ORA_SYSBACKUP, ORA_SYSKM, ORA_SYSDG);
print "Execution user is :\n";
system("id");
foreach $session_mode ( @session_modes ) {
printf( "Session mode is %x\n", $session_mode);
$dbh = DBI->connect("dbi:Oracle:", "/", "", {PrintError=>0,
ora_session_mode=>$session_mode});
if (defined $dbh) {
$ary_ref = $dbh->selectall_arrayref("SELECT username FROM
user_users");
print $ary_ref->[0]->[0]."\n";
$dbh->disconnect;
} else {
print $DBI::errstr . "\n";
}
print "\n";
}
Execution user is :
uid=8649(oracle) gid=15000(dba)
groups=15000(dba),15001(bkpdba),15002(dgddba),15003(kmtdba)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Session mode is 2
SYS
Session mode is 2
SYSBACKUP
Session mode is 8
SYSKM
Session mode is 4
SYSDG
Execution user is :
uid=4102(bkpdba) gid=15001(bkpdba) groups=15001(bkpdba)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Session mode is 2
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 2
SYSBACKUP
Session mode is 8
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 4
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Execution user is :
uid=4103(dgddba) gid=15002(dgddba) groups=15002(dgddba)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Session mode is 2
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 2
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 8
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 4
SYSDG
Execution user is :
uid=4104(kmtdba) gid=15003(kmtdba) groups=15003(kmtdba)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Session mode is 2
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 2
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Session mode is 8
SYSKM
Session mode is 4
ORA-01017: invalid username/password; logon denied (DBD ERROR:
OCISessionBegin)
Met vriendelijke groeten,
Yours truly,
Kris Lemaire, Oracle DBA
Tel. + 32 15 35 93 38 - fax + 015 35 20 18 - server.databa...@kbc.be
Application Hosting Product Factory 1 - Server Frameworks - Databases
KBC Global Services NV, COX (MECPark4 - COR+2 - CMS Infrastructuur -
Databanken)
E. Walschaertsstraat 3, 2800 Mechelen, België
For additional information on our private cloud services we recommend the
HPC portal (available internal KBC only)
Be green – keep it on the screen. Please think before you print this
e-mail.
KBC Global NV, Havenlaan 2, 1080 Brussels, Belgium, VAT BE 0465.746.488,
RLP Brussels
A division of the KBC-group
This e-mail and any attached files are confidential and may be legally
privileged. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this communication is
strictly prohibited. If you have received this transmission in error please
notify KBC immediately and then delete this e-mail.
KBC does not accept liability for the correct and complete transmission of the
information, nor for any delay or interruption of the transmission, nor for
damages arising from the use of or reliance on the information.
All e-mail messages addressed to, received or sent by KBC or KBC employees are
deemed to be professional in nature. Accordingly, the sender or recipient of
these messages agrees that they may be read by other KBC employees than the
official recipient or sender in order to ensure the continuity of work-related
activities and allow supervision thereof.
<>
DBD-Oracle-1.66.withSYSBACKUP.patch
Description: Binary data
Re: DBD::Oracle v1.61_00 on its way to CPAN
The trial version has been promoted to 1.62 (changelog below) and is now on CPAN. 1.62 2013-04-30 - promote 1.61_00 to official release Thanks to everyone who contributed to this release! Michael -- *Michael Portnoy * Software Developer Pythian love your data www.pythian.com office:+1 613 565 8696 x 381 mobile : +1 613 325 3788 On Mon, Apr 15, 2013 at 3:41 PM, Yanick Champoux wrote: > > This one is a minor release (changelog's below). As usual, if no issue > is found with this trial version, it's going to be promoted to 1.62 and > stable in two weeks' time. > > 1.61_00 2013-04-15 > > [BUG FIXES] > - Adjust the privs needed for the DROP/CREATE table test. [GH#35] > (Joe Crotty) > > - Fixed RT84170 - when using scrollable cursors and you've done a > positioned fetch and then keep fetching until the end of the > result-set calls to fetch never return undef and you keep getting > the last row forever. Also added test case to the 51scroll.t test > (Martin J. Evans). > > > Enjoy, > `/anick > > -- > Yanick Champoux > Senior Perl Developer > Pythian - Love your data > > champ...@pythian.com > > Tel: +1 613 565 8696 x 274 > www.pythian.com > > > -- > > > -- > > > > -- --
RE: Building DBD::Oracle with one version but deploying with another
Should Allways work for 1 DB version forward and one back. So a 10 instantshould should work a 9,10 and 11 at least that is the theory. Oracle is a little unclear on what a Version is. What I usually do is complie with the instant client and depoly it with the compiled code. This is how activestae gets awaywith it as they install the IC along with the dll so they need only compile it once/\. One can freely ditribute the IC with no gruff from Oracle. Cheers > Date: Fri, 19 Apr 2013 08:35:39 +0100 > From: boh...@ntlworld.com > To: dbi-dev@perl.org > Subject: Re: Building DBD::Oracle with one version but deploying with another > > On 18/04/13 18:41, Jan Dubois wrote: > > Sorry, I can't remember the details. I think you must use clients for > > the same version of Oracle on the server, e.g. if you compiled > > DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to > > work with an Oracle 11 client. But my memories of that are foggy; I > > don't know if this is just a limitation on Windows, or if it applies > > everywhere. > > > > I also never tried to run DBD::Oracle compiled against the instant > > client with a server that has the regular client installed. I kind of > > expect it to work, if they are the same versions, but haven't verified > > it. > > > > Cheers, > > -Jan > > DBD::Oracle attempts to find the version of your client using sqlplus etc. > Once it knows the version it sets macros which affect what support is built > into DBD::Oracle. > > e.g., > > Installing on a linux, Ver#2.6 > Using Oracle in /home/martin/instantclient_11_2/ > DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR) > Oracle version 11.2.0.2 (11.2) > Looks like an Instant Client installation, okay > Your LD_LIBRARY_PATH env var is set to '/home/martin/instantclient_11_2/' > > DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" > -DORA_OCI_102 -DORA_OCI_112 > > Notice the ORA_OCI_102 and ORA_OCI_112 macros are defined in this case since > this was Oracle 11.2. If you search the source for those macros you'll see > loads of places where code is only included if they are defined and hence it > affects what you can do with DBD::Oracle. > > So if you built against a 10.2 client and then attempted to run against a > 11.2 client there are a) things you would not be able to do and b) possibly > DBD::Oracle would make a different set of OCI calls (you'd need to read the > code to see what). > > If you did it the other way around it is quite likely some things won't work. > > The instant client files required to run DBD::Oracle (as opposed to build it) > are quite small. What cannot you distribute those with the DBD::Oracle you > build. > > Martin > > > On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: > >> Yes, I'm doing that. Each server can have a different environment than the > >> server the original DBD:Oracle was built on. Or the question still applies > >> if I want to use a different version of Oracle installed on the original > >> build server, especially if I remove the version of Oracle that was used to > >> build the original DBD::Oracle. > >> > >> > >> From: Jan Dubois > >> To: John Wiersba > >> Cc: Lyle ; "dbi-dev@perl.org" > >> Sent: Thursday, April 18, 2013 1:09 PM > >> > >> Subject: Re: Building DBD::Oracle with one version but deploying with > >> another > >> > >> I think you also need to add the ORACLE_HOME directory to > >> LD_LIBRARY_PATH (on the deployment machine) to make it work. > >> > >> Cheers, > >> -Jan > >> > >> On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: > >>> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for > >>> distribution to another server (assume the OS and perl versions on both > >>> servers) which will have a different ORACLE_HOME, possibly a different > >>> version of the Oracle client and likely in a different location. The > >>> target > >>> server may not have a C compiler. > >>> > >>> That's the same situation that ActiveState must have encountered, building > >>> DBD::Oracle with whatever version of Oracle they had downloaded and > >>> installed in some random location, but deploying it on the user's server > >>> which likely has a different version of Oracle installed in a different > >>> location. > &g
Re: Building DBD::Oracle with one version but deploying with another
On Fri, Apr 19, 2013 at 12:35 AM, Martin J. Evans wrote: > The instant client files required to run DBD::Oracle (as opposed to build > it) are quite small. What cannot you distribute those with the DBD::Oracle > you build. It is my understanding that you have to present the OIC license to the user before installation and have them *actively* accept it (click on an "I accept" button, or answering "yes" to a prompt, with "yes" not being the default etc). The last time I checked, you couldn't even download the OIC without accepting the license first via JavaScript; there were no direct download link. And somewhere in their redistribution license was a clause that says they expect you to do the same thing when you redistribute. So it is possible, but requires non-trivial extra effort in your installer to do this. Cheers, -Jan
Re: Building DBD::Oracle with one version but deploying with another
On 18/04/13 18:41, Jan Dubois wrote: Sorry, I can't remember the details. I think you must use clients for the same version of Oracle on the server, e.g. if you compiled DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to work with an Oracle 11 client. But my memories of that are foggy; I don't know if this is just a limitation on Windows, or if it applies everywhere. I also never tried to run DBD::Oracle compiled against the instant client with a server that has the regular client installed. I kind of expect it to work, if they are the same versions, but haven't verified it. Cheers, -Jan DBD::Oracle attempts to find the version of your client using sqlplus etc. Once it knows the version it sets macros which affect what support is built into DBD::Oracle. e.g., Installing on a linux, Ver#2.6 Using Oracle in /home/martin/instantclient_11_2/ DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR) Oracle version 11.2.0.2 (11.2) Looks like an Instant Client installation, okay Your LD_LIBRARY_PATH env var is set to '/home/martin/instantclient_11_2/' DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" -DORA_OCI_102 -DORA_OCI_112 Notice the ORA_OCI_102 and ORA_OCI_112 macros are defined in this case since this was Oracle 11.2. If you search the source for those macros you'll see loads of places where code is only included if they are defined and hence it affects what you can do with DBD::Oracle. So if you built against a 10.2 client and then attempted to run against a 11.2 client there are a) things you would not be able to do and b) possibly DBD::Oracle would make a different set of OCI calls (you'd need to read the code to see what). If you did it the other way around it is quite likely some things won't work. The instant client files required to run DBD::Oracle (as opposed to build it) are quite small. What cannot you distribute those with the DBD::Oracle you build. Martin On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: Yes, I'm doing that. Each server can have a different environment than the server the original DBD:Oracle was built on. Or the question still applies if I want to use a different version of Oracle installed on the original build server, especially if I remove the version of Oracle that was used to build the original DBD::Oracle. From: Jan Dubois To: John Wiersba Cc: Lyle ; "dbi-dev@perl.org" Sent: Thursday, April 18, 2013 1:09 PM Subject: Re: Building DBD::Oracle with one version but deploying with another I think you also need to add the ORACLE_HOME directory to LD_LIBRARY_PATH (on the deployment machine) to make it work. Cheers, -Jan On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for distribution to another server (assume the OS and perl versions on both servers) which will have a different ORACLE_HOME, possibly a different version of the Oracle client and likely in a different location. The target server may not have a C compiler. That's the same situation that ActiveState must have encountered, building DBD::Oracle with whatever version of Oracle they had downloaded and installed in some random location, but deploying it on the user's server which likely has a different version of Oracle installed in a different location. From: Lyle To: dbi-dev@perl.org Sent: Thursday, April 18, 2013 11:43 AM Subject: Re: Building DBD::Oracle with one version but deploying with another On 18/04/2013 16:22, John Wiersba wrote: [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? I built DBD::Oracle on windows recently. I did need the Oracle client libraries for the tests to pass, and ActiveState would have too. Once built they package up the binaries for distribution, and expect the target system to have the appropriate libraries. If I remember correctly, I had to download the appropriate libraries from Oracle. I spoke to the vanilla Perl people about this, as they currently don't have a DBD::Oracle bundled in with th
Re: Building DBD::Oracle with one version but deploying with another
Yep, that's exactly what I'm getting at. Apparently ActiveState makes this work with their DBD::Oracle package. So, I'm wondering how I can make it work, too. What are the limitations? Why does ORACLE_HOME and LD_LIBRARY_PATH need to be set during build/installation rather than just during runtime? > > From: Jan Dubois >To: John Wiersba >Cc: Lyle ; "dbi-dev@perl.org" >Sent: Thursday, April 18, 2013 1:41 PM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >Sorry, I can't remember the details. I think you must use clients for >the same version of Oracle on the server, e.g. if you compiled >DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to >work with an Oracle 11 client. But my memories of that are foggy; I >don't know if this is just a limitation on Windows, or if it applies >everywhere. > >I also never tried to run DBD::Oracle compiled against the instant >client with a server that has the regular client installed. I kind of >expect it to work, if they are the same versions, but haven't verified >it. > >Cheers, >-Jan > > >On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: >> Yes, I'm doing that. Each server can have a different environment than the >> server the original DBD:Oracle was built on. Or the question still applies >> if I want to use a different version of Oracle installed on the original >> build server, especially if I remove the version of Oracle that was used to >> build the original DBD::Oracle. >> >> ________ >> From: Jan Dubois >> To: John Wiersba >> Cc: Lyle ; "dbi-dev@perl.org" >> Sent: Thursday, April 18, 2013 1:09 PM >> >> Subject: Re: Building DBD::Oracle with one version but deploying with >> another >> >> I think you also need to add the ORACLE_HOME directory to >> LD_LIBRARY_PATH (on the deployment machine) to make it work. >> >> Cheers, >> -Jan >> >> On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >>> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >>> distribution to another server (assume the OS and perl versions on both >>> servers) which will have a different ORACLE_HOME, possibly a different >>> version of the Oracle client and likely in a different location. The target >>> server may not have a C compiler. >>> >>> That's the same situation that ActiveState must have encountered, building >>> DBD::Oracle with whatever version of Oracle they had downloaded and >>> installed in some random location, but deploying it on the user's server >>> which likely has a different version of Oracle installed in a different >>> location. >>> >>> >>> >>> >>>> >>>> From: Lyle >>>>To: dbi-dev@perl.org >>>>Sent: Thursday, April 18, 2013 11:43 AM >>>>Subject: Re: Building DBD::Oracle with one version but deploying with >>>> another >>>> >>>> >>>>On 18/04/2013 16:22, John Wiersba wrote: >>>>> [A previous version of this question was asked on dbi-users -- I haven't >>>>> gotten any response there. Not sure which list to post to.] >>>>> >>>>> Hi, I'd like to find out how to build/install DBD::Oracle with one >>>>> version of Oracle client but then deploy it with a potentially different >>>>> client version, say on a server without the original client version (or >>>>> with >>>>> it installed in a different location). It seems like the Oracle >>>>> client libraries can be loaded dynamically at runtime, based on >>>>> ORACLE_HOME, so there doesn't need to be a dependency on those exact >>>>> client libraries that were used at build/install time. >>>>> >>>>> Another >>>>> way of asking: How does ActiveState deploy DBD::Oracle without needing >>>>> to build it (maybe no C compiler is available), on servers with >>>>> different versions of the Oracle client libraries installed? >>>> >>>>I built DBD::Oracle on windows recently. I did need the Oracle client >>>> libraries for the tests to pass, and ActiveState would have too. Once built >>>> they package up the binaries for distribution, and expect the target system >>>> to have the appropriate libraries. If I remember corre
Re: Building DBD::Oracle with one version but deploying with another
Sorry, I can't remember the details. I think you must use clients for the same version of Oracle on the server, e.g. if you compiled DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to work with an Oracle 11 client. But my memories of that are foggy; I don't know if this is just a limitation on Windows, or if it applies everywhere. I also never tried to run DBD::Oracle compiled against the instant client with a server that has the regular client installed. I kind of expect it to work, if they are the same versions, but haven't verified it. Cheers, -Jan On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: > Yes, I'm doing that. Each server can have a different environment than the > server the original DBD:Oracle was built on. Or the question still applies > if I want to use a different version of Oracle installed on the original > build server, especially if I remove the version of Oracle that was used to > build the original DBD::Oracle. > > > From: Jan Dubois > To: John Wiersba > Cc: Lyle ; "dbi-dev@perl.org" > Sent: Thursday, April 18, 2013 1:09 PM > > Subject: Re: Building DBD::Oracle with one version but deploying with > another > > I think you also need to add the ORACLE_HOME directory to > LD_LIBRARY_PATH (on the deployment machine) to make it work. > > Cheers, > -Jan > > On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >> distribution to another server (assume the OS and perl versions on both >> servers) which will have a different ORACLE_HOME, possibly a different >> version of the Oracle client and likely in a different location. The target >> server may not have a C compiler. >> >> That's the same situation that ActiveState must have encountered, building >> DBD::Oracle with whatever version of Oracle they had downloaded and >> installed in some random location, but deploying it on the user's server >> which likely has a different version of Oracle installed in a different >> location. >> >> >> >> >>> >>> From: Lyle >>>To: dbi-dev@perl.org >>>Sent: Thursday, April 18, 2013 11:43 AM >>>Subject: Re: Building DBD::Oracle with one version but deploying with >>> another >>> >>> >>>On 18/04/2013 16:22, John Wiersba wrote: >>>> [A previous version of this question was asked on dbi-users -- I haven't >>>> gotten any response there. Not sure which list to post to.] >>>> >>>> Hi, I'd like to find out how to build/install DBD::Oracle with one >>>> version of Oracle client but then deploy it with a potentially different >>>> client version, say on a server without the original client version (or >>>> with >>>> it installed in a different location). It seems like the Oracle >>>> client libraries can be loaded dynamically at runtime, based on >>>> ORACLE_HOME, so there doesn't need to be a dependency on those exact >>>> client libraries that were used at build/install time. >>>> >>>> Another >>>> way of asking: How does ActiveState deploy DBD::Oracle without needing >>>> to build it (maybe no C compiler is available), on servers with >>>> different versions of the Oracle client libraries installed? >>> >>>I built DBD::Oracle on windows recently. I did need the Oracle client >>> libraries for the tests to pass, and ActiveState would have too. Once built >>> they package up the binaries for distribution, and expect the target system >>> to have the appropriate libraries. If I remember correctly, I had to >>> download the appropriate libraries from Oracle. I spoke to the vanilla Perl >>> people about this, as they currently don't have a DBD::Oracle bundled in >>> with their distro. They had been looking at bundling the client libraries as >>> well, but I think there is a licensing issues surrounding doing that which >>> is why ActiveState do not do it. We agreed to take another look at it next >>> month as I'm very busy this month. >>> >>>> I've searched the archives for both dbi-dev and dbi-users and can't find >>>> this issue addressed, although I did see a similar issue asked once. If >>>> there's any reference material that I have overlooked, could you please >>>> point it out. The README for DBD::Oracle seems to indicate that this is >>>> not >>>> possible or not advised, but then what is ActiveState doing to make it >>>> work? >>> >>>With ActiveState's ppm, it wont work on the target system unless the >>> correct client libraries are there. I think that's what led me to build my >>> own DBD::Oracle in the first place. I was building for 64 bit Windows, and >>> found this blog post: >>>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>>I found errors in that post and commented with my findings, yet my comment >>> has yet to be accepted. I think Pythian is on this list? So maybe they will >>> comment. >>> >>> >>>Lyle >>> >>> >>> >>> > >
Re: Building DBD::Oracle with one version but deploying with another
Yes, I'm doing that. Each server can have a different environment than the server the original DBD:Oracle was built on. Or the question still applies if I want to use a different version of Oracle installed on the original build server, especially if I remove the version of Oracle that was used to build the original DBD::Oracle. > > From: Jan Dubois >To: John Wiersba >Cc: Lyle ; "dbi-dev@perl.org" >Sent: Thursday, April 18, 2013 1:09 PM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >I think you also need to add the ORACLE_HOME directory to >LD_LIBRARY_PATH (on the deployment machine) to make it work. > >Cheers, >-Jan > >On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >> distribution to another server (assume the OS and perl versions on both >> servers) which will have a different ORACLE_HOME, possibly a different >> version of the Oracle client and likely in a different location. The target >> server may not have a C compiler. >> >> That's the same situation that ActiveState must have encountered, building >> DBD::Oracle with whatever version of Oracle they had downloaded and >> installed in some random location, but deploying it on the user's server >> which likely has a different version of Oracle installed in a different >> location. >> >> >> >> >>> >>> From: Lyle >>>To: dbi-dev@perl.org >>>Sent: Thursday, April 18, 2013 11:43 AM >>>Subject: Re: Building DBD::Oracle with one version but deploying with another >>> >>> >>>On 18/04/2013 16:22, John Wiersba wrote: >>>> [A previous version of this question was asked on dbi-users -- I haven't >>>> gotten any response there. Not sure which list to post to.] >>>> >>>> Hi, I'd like to find out how to build/install DBD::Oracle with one >>>> version of Oracle client but then deploy it with a potentially different >>>> client version, say on a server without the original client version (or >>>> with it installed in a different location). It seems like the Oracle >>>> client libraries can be loaded dynamically at runtime, based on >>>> ORACLE_HOME, so there doesn't need to be a dependency on those exact >>>> client libraries that were used at build/install time. >>>> >>>> Another >>>> way of asking: How does ActiveState deploy DBD::Oracle without needing >>>> to build it (maybe no C compiler is available), on servers with >>>> different versions of the Oracle client libraries installed? >>> >>>I built DBD::Oracle on windows recently. I did need the Oracle client >>>libraries for the tests to pass, and ActiveState would have too. Once built >>>they package up the binaries for distribution, and expect the target system >>>to have the appropriate libraries. If I remember correctly, I had to >>>download the appropriate libraries from Oracle. I spoke to the vanilla Perl >>>people about this, as they currently don't have a DBD::Oracle bundled in >>>with their distro. They had been looking at bundling the client libraries as >>>well, but I think there is a licensing issues surrounding doing that which >>>is why ActiveState do not do it. We agreed to take another look at it next >>>month as I'm very busy this month. >>> >>>> I've searched the archives for both dbi-dev and dbi-users and can't find >>>> this issue addressed, although I did see a similar issue asked once. If >>>> there's any reference material that I have overlooked, could you please >>>> point it out. The README for DBD::Oracle seems to indicate that this is >>>> not possible or not advised, but then what is ActiveState doing to make it >>>> work? >>> >>>With ActiveState's ppm, it wont work on the target system unless the correct >>>client libraries are there. I think that's what led me to build my own >>>DBD::Oracle in the first place. I was building for 64 bit Windows, and found >>>this blog post: >>>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>>I found errors in that post and commented with my findings, yet my comment >>>has yet to be accepted. I think Pythian is on this list? So maybe they will >>>comment. >>> >>> >>>Lyle >>> >>> >>> >>> > > >
Re: Building DBD::Oracle with one version but deploying with another
I think you also need to add the ORACLE_HOME directory to LD_LIBRARY_PATH (on the deployment machine) to make it work. Cheers, -Jan On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: > Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for > distribution to another server (assume the OS and perl versions on both > servers) which will have a different ORACLE_HOME, possibly a different > version of the Oracle client and likely in a different location. The target > server may not have a C compiler. > > That's the same situation that ActiveState must have encountered, building > DBD::Oracle with whatever version of Oracle they had downloaded and installed > in some random location, but deploying it on the user's server which likely > has a different version of Oracle installed in a different location. > > > > >> >> From: Lyle >>To: dbi-dev@perl.org >>Sent: Thursday, April 18, 2013 11:43 AM >>Subject: Re: Building DBD::Oracle with one version but deploying with another >> >> >>On 18/04/2013 16:22, John Wiersba wrote: >>> [A previous version of this question was asked on dbi-users -- I haven't >>> gotten any response there. Not sure which list to post to.] >>> >>> Hi, I'd like to find out how to build/install DBD::Oracle with one >>> version of Oracle client but then deploy it with a potentially different >>> client version, say on a server without the original client version (or >>> with it installed in a different location). It seems like the Oracle >>> client libraries can be loaded dynamically at runtime, based on >>> ORACLE_HOME, so there doesn't need to be a dependency on those exact >>> client libraries that were used at build/install time. >>> >>> Another >>> way of asking: How does ActiveState deploy DBD::Oracle without needing >>> to build it (maybe no C compiler is available), on servers with >>> different versions of the Oracle client libraries installed? >> >>I built DBD::Oracle on windows recently. I did need the Oracle client >>libraries for the tests to pass, and ActiveState would have too. Once built >>they package up the binaries for distribution, and expect the target system >>to have the appropriate libraries. If I remember correctly, I had to download >>the appropriate libraries from Oracle. I spoke to the vanilla Perl people >>about this, as they currently don't have a DBD::Oracle bundled in with their >>distro. They had been looking at bundling the client libraries as well, but I >>think there is a licensing issues surrounding doing that which is why >>ActiveState do not do it. We agreed to take another look at it next month as >>I'm very busy this month. >> >>> I've searched the archives for both dbi-dev and dbi-users and can't find >>> this issue addressed, although I did see a similar issue asked once. If >>> there's any reference material that I have overlooked, could you please >>> point it out. The README for DBD::Oracle seems to indicate that this is >>> not possible or not advised, but then what is ActiveState doing to make it >>> work? >> >>With ActiveState's ppm, it wont work on the target system unless the correct >>client libraries are there. I think that's what led me to build my own >>DBD::Oracle in the first place. I was building for 64 bit Windows, and found >>this blog post: >>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>I found errors in that post and commented with my findings, yet my comment >>has yet to be accepted. I think Pythian is on this list? So maybe they will >>comment. >> >> >>Lyle >> >> >> >>
Re: Building DBD::Oracle with one version but deploying with another
Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for distribution to another server (assume the OS and perl versions on both servers) which will have a different ORACLE_HOME, possibly a different version of the Oracle client and likely in a different location. The target server may not have a C compiler. That's the same situation that ActiveState must have encountered, building DBD::Oracle with whatever version of Oracle they had downloaded and installed in some random location, but deploying it on the user's server which likely has a different version of Oracle installed in a different location. > > From: Lyle >To: dbi-dev@perl.org >Sent: Thursday, April 18, 2013 11:43 AM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >On 18/04/2013 16:22, John Wiersba wrote: >> [A previous version of this question was asked on dbi-users -- I haven't >> gotten any response there. Not sure which list to post to.] >> >> Hi, I'd like to find out how to build/install DBD::Oracle with one >> version of Oracle client but then deploy it with a potentially different >> client version, say on a server without the original client version (or with >> it installed in a different location). It seems like the Oracle >> client libraries can be loaded dynamically at runtime, based on >> ORACLE_HOME, so there doesn't need to be a dependency on those exact >> client libraries that were used at build/install time. >> >> Another >> way of asking: How does ActiveState deploy DBD::Oracle without needing >> to build it (maybe no C compiler is available), on servers with >> different versions of the Oracle client libraries installed? > >I built DBD::Oracle on windows recently. I did need the Oracle client >libraries for the tests to pass, and ActiveState would have too. Once built >they package up the binaries for distribution, and expect the target system to >have the appropriate libraries. If I remember correctly, I had to download the >appropriate libraries from Oracle. I spoke to the vanilla Perl people about >this, as they currently don't have a DBD::Oracle bundled in with their distro. >They had been looking at bundling the client libraries as well, but I think >there is a licensing issues surrounding doing that which is why ActiveState do >not do it. We agreed to take another look at it next month as I'm very busy >this month. > >> I've searched the archives for both dbi-dev and dbi-users and can't find >> this issue addressed, although I did see a similar issue asked once. If >> there's any reference material that I have overlooked, could you please >> point it out. The README for DBD::Oracle seems to indicate that this is not >> possible or not advised, but then what is ActiveState doing to make it work? > >With ActiveState's ppm, it wont work on the target system unless the correct >client libraries are there. I think that's what led me to build my own >DBD::Oracle in the first place. I was building for 64 bit Windows, and found >this blog post: >http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >I found errors in that post and commented with my findings, yet my comment has >yet to be accepted. I think Pythian is on this list? So maybe they will >comment. > > >Lyle > > > >
Re: Building DBD::Oracle with one version but deploying with another
On 18/04/2013 16:22, John Wiersba wrote: [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? I built DBD::Oracle on windows recently. I did need the Oracle client libraries for the tests to pass, and ActiveState would have too. Once built they package up the binaries for distribution, and expect the target system to have the appropriate libraries. If I remember correctly, I had to download the appropriate libraries from Oracle. I spoke to the vanilla Perl people about this, as they currently don't have a DBD::Oracle bundled in with their distro. They had been looking at bundling the client libraries as well, but I think there is a licensing issues surrounding doing that which is why ActiveState do not do it. We agreed to take another look at it next month as I'm very busy this month. I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? With ActiveState's ppm, it wont work on the target system unless the correct client libraries are there. I think that's what led me to build my own DBD::Oracle in the first place. I was building for 64 bit Windows, and found this blog post: http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ I found errors in that post and commented with my findings, yet my comment has yet to be accepted. I think Pythian is on this list? So maybe they will comment. Lyle
Building DBD::Oracle with one version but deploying with another
[A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? Thanks!-- John
DBD::Oracle v1.61_00 on its way to CPAN
This one is a minor release (changelog's below). As usual, if no issue is found with this trial version, it's going to be promoted to 1.62 and stable in two weeks' time. 1.61_00 2013-04-15 [BUG FIXES] - Adjust the privs needed for the DROP/CREATE table test. [GH#35] (Joe Crotty) - Fixed RT84170 - when using scrollable cursors and you've done a positioned fetch and then keep fetching until the end of the result-set calls to fetch never return undef and you keep getting the last row forever. Also added test case to the 51scroll.t test (Martin J. Evans). Enjoy, `/anick -- Yanick Champoux Senior Perl Developer Pythian - Love your data champ...@pythian.com Tel: +1 613 565 8696 x 274 www.pythian.com -- --
dev release DBD::Oracle 1.57_00 is on its way to CPAN
DBD::Oracle version 1.57_00 is on its way to CPAN. This release is small, but should make some Win32 users happy. The changelog is pasted below. As usual, the dev release will be promoted to general use in two weeks, assuming no problem is found. Enjoy, `/anick 1.57_00 2013-02-07 [BUG FIXES] - fix RT46628 - bind_param_inout ORA_RSET causes MSWin32 access violation and RT82663 - Errors if a returned SYS_REFCURSOR is not opened (Martin J. Evans) If a procedure/function returns a SYS_REFCURSOR which was never opened DBD::Oracle magics a DBI statement handle into existence and attempts to describe it (which fails). This change examines a returned SYS_REFCURSOR and if it it is initialised but not executed does not create a DBI statement handle and returns undef instead. So now if you have a procedure/function which returns a SYS_REFCURSOR and never open it you'll get undef back instead of a useless statement handle. Extended 50cursor.t test to check the above fix. [DOCUMENTATION] - Update Lion instructions for 64-bit Instant Client. (GH#37, patch by theory) -- --
DBD::Oracle v1.54 on its way to CPAN
Hi all, DBD::Oracle v1.54 is on its way to CPAN. In this iteration, no new feature, but a large amount of bug fixes. (see full changelog below) As usual, a big thank to the peeps who actually reported the bugs and did the work: Pierre-Alain Blanc, Alexandr Ciornii, Joe Crotty, Rob Davies, Dave Mitchell, and John Scoles, with a special shout-out to Steffen Goeldner and Martin J. Evans, who are indisputably patching kings. Joy, `/anick 1.54 2013-01-03 [BUG FIXES] - Fix RT69350 - 31lob.t was using $lob after destroying its parent $sth (Rob Davies) - Fix memory leak in execute_array (John Scoles, Pierre-Alain Blanc) - Fix RT80349 - The error message in execute_for_fetch when a row fails can contain the wrong error count. Thanks to Steffen Goeldner for RT and patch. - Fix RT80375 - no exception when execute_for_fetch fails and ArrayTupleStatus is not specified. Also the tuple count calculation resulted in an undefined warning. Thanks to Steffen Goeldner for RT and patch. - Fix RT80487. Skip XMLType tests if Oracle less than V9. Thanks to Steffen Goeldner for RT and patch. - Fix RT80486 for 31lob_extended.t. In old old Oracle8, SYS_REFCURSOR is not defined. Instead of CREATE/DROP PROCEDURE, use anonymous block. Thanks to Steffen Goeldner for RT and patch. - Fix bug in 39attr.t which could fail if using an Oracle Client > 11 but not >= 11.2 (Martin J. Evans) - ora_server_version was not documented. - Fix RT80566. 70meta.t test fails with Oracle 8 because ALL_TAB_COLUMNS.CHAR_LENGTH is new in Oracle 9. Use DATA_LENGTH instead on pre-9 versions. Thanks to Steffen Goeldner for RT and patch. - Fix RT80704. 51scroll.t test checks scrollable cursors but assumes all Oracles support them (only 9 and above). Thanks to Steffen Goeldner for RT and patch. - Fix RT81067. 58object.t has some subtype tests and subtypes were introduced in Oracle 9. Skip if < Oracle 9. Thanks to Steffen Goeldner for RT and patch. - Fix RT81317. 34pres_lobs.t uses the Data Interface for Persistent LOBs which is new in Oracle 9. Skip if < Oracle 9. Thanks to Steffen Goeldner for RT and patch. [MISCELLANEOUS] - The original 26exe_array test was replaced some time ago with a copy of the one from DBD::ODBC. Since then I've fixed issues in the DBD::ODBC one and added more tests (like tests for some RTs above). To make keeping them in synch easier I've modularised the tests. Hence new ExecuteArray.pm. (Martin J. Evans) - simple code clean up, replacing 3 uses of safemalloc with Newz (John Scoles) - Add DBI as a configure prereq for the META* files (thanks to Joe Crotty) - New FAQ entry on Solaris and setting linker library path (Martin J. Evans) - Removed ineffective commit in 34pres_lobs.t (Martin J. Evans) - Remove dead README link in Win32 documentation. (pointed out by Alexandr Ciornii, RT#82040) - Changed any use of if SvUPGRADE to remove the if test as per email from Dave Mitchell and posting at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-12/msg00424.html (Martin J. Evans) -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- --
Re: DBD::Oracle - rt13865.t
On 12/14/2012 03:52 AM, Martin J. Evans wrote:
On 13/12/12 17:46, Scott wrote:
Do you have the DROP ANY TABLE privilege set for the userid? That is
the only DROP TABLE priv I can see, so I probably need to have the
dba grant it to my install-test user.
I do have drop any table privilege as I have the DBA role.
Can't you just ignore that test?
Yes, I just wanted to report that the test works without out the check
for the DROP privileges.
Martin
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to
run. In Oracle, AFAIK, there is not a DROP TABLE privilege. If
you can create it, you can drop it. Does this test not run for
everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'}
) ){ #and ( $priv{'DROP TABLE'} or $priv{'DROP ANY
TABLE'} ) ) { plan skip_all => q{requires permissions 'CREATE
TABLE' and 'DROP TABLE'}; }
Scott
Works and runs for me:
$ prove -vb t/rt13865.t t/rt13865.t .. 1..9 ok 1 - INTEGER is alias
for NUMBER(38) ok 2 - NUMBER(37) ok 3 - NUMBER ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69) ok 6 - NVARCHAR2(69) ok 7 - NCHAR(69) ok 8 -
CHAR(67) ok 9 - CHAR(69) ok All tests successful. Files=1, Tests=9,
12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07 csys =
0.25 CPU) Result: PASS
Re: DBD::Oracle - rt13865.t
On 13/12/12 17:46, Scott wrote:
Do you have the DROP ANY TABLE privilege set for the userid? That is
the only DROP TABLE priv I can see, so I probably need to have the
dba grant it to my install-test user.
I do have drop any table privilege as I have the DBA role.
Can't you just ignore that test?
Martin
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to
run. In Oracle, AFAIK, there is not a DROP TABLE privilege. If
you can create it, you can drop it. Does this test not run for
everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'}
) ){ #and ( $priv{'DROP TABLE'} or $priv{'DROP ANY
TABLE'} ) ) { plan skip_all => q{requires permissions 'CREATE
TABLE' and 'DROP TABLE'}; }
Scott
Works and runs for me:
$ prove -vb t/rt13865.t t/rt13865.t .. 1..9 ok 1 - INTEGER is alias
for NUMBER(38) ok 2 - NUMBER(37) ok 3 - NUMBER ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69) ok 6 - NVARCHAR2(69) ok 7 - NCHAR(69) ok 8 -
CHAR(67) ok 9 - CHAR(69) ok All tests successful. Files=1, Tests=9,
12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07 csys =
0.25 CPU) Result: PASS
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Re: DBD::Oracle - rt13865.t
Do you have the DROP ANY TABLE privilege set for the userid?
That is the only DROP TABLE priv I can see, so I probably need to have
the dba grant it to my install-test user.
On 12/13/2012 11:03 AM, Martin J. Evans wrote:
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run.
In Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does
this test not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP
TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr
0.07 csys = 0.25 CPU)
Result: PASS
Re: DBD::Oracle - rt13865.t
On 13/12/12 16:38, Scott wrote:
I have to comment out the 'DROP TABLE' check to get this test to run. In
Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does this test
not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP TABLE'};
}
Scott
Works and runs for me:
$ prove -vb t/rt13865.t
t/rt13865.t ..
1..9
ok 1 - INTEGER is alias for NUMBER(38)
ok 2 - NUMBER(37)
ok 3 - NUMBER
ok 4 - VARCHAR(67)
ok 5 - VARCHAR(69)
ok 6 - NVARCHAR2(69)
ok 7 - NCHAR(69)
ok 8 - CHAR(67)
ok 9 - CHAR(69)
ok
All tests successful.
Files=1, Tests=9, 12 wallclock secs ( 0.03 usr 0.01 sys + 0.14 cusr 0.07
csys = 0.25 CPU)
Result: PASS
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
DBD::Oracle - rt13865.t
I have to comment out the 'DROP TABLE' check to get this test to run.
In Oracle, AFAIK, there is not a
DROP TABLE privilege. If you can create it, you can drop it. Does
this test not run for everyone?
unless (( $priv{'CREATE TABLE'} or $priv{'CREATE ANY TABLE'} )
){
#and ( $priv{'DROP TABLE'} or $priv{'DROP ANY TABLE'} ) ) {
plan skip_all => q{requires permissions 'CREATE TABLE' and 'DROP
TABLE'};
}
Scott
DBD::oracle v1.52 is on CPAN
Hi everyone, Nothing bad or funky was reported for v1.51_00, so it was promoted to the all new and shiny v1.52. I'm pasting the changelog below for convenience, but this release is basically Martin Evans heroically making TAF work, with some additional awesomeness sprinkled by Merijn, Douglas and David. All of you guys rock. :-) Enjoy! `/anick 1.52 [BUG FIXES] - fix serious memory corruption in TAF support (Martin J. Evans) - fix finding client in situation where client and server both installed but different architectures (patch by H.Merijn Brand) - fix memory leak in TAF handling - the TAF function was leaked (Martin J. Evans) - fix issue with taf_function being set to a scalar which goes out of scope before the callback is made (Martin J. Evans) - fix RT46739 if a connection breaks the environment handle is not thrown away (Martin J. Evans) - ora_driver_name was not defaulted to the correct DBD::Oracle version (Martin J. Evans) - ora_driver_name, ora_client_info, ora_client_identifier, ora_action and ora_oci_success_warn were set twice (if specified) on connect as they were not deleted from the connect attributes once handled. Code now leaves the setting to the later STORE DBI calls (Martin J. Evans) - fixed some compiler warnings for %lf (Martin J. Evans) - fixed RT78700 - column_info reports wrong size for char semantic char type columns (Douglas Wilson). [CHANGE IN BEHAVIOUR] - ora_taf and ora_taf_sleep were redundant and have been removed. To enable/disable TAF simply set ora_taf_function and if you want to sleep do it in your callback (Martin J. Evans) - ora_taf_function can now be a code reference as well as a string (Martin J. Evans) [ENHANCEMENTS] - the ora_can_taf method was virtually useless since you can only call it after connecting and to enable TAF you had to do it in the connect call. Now you can enable and disable TAF at any time by simply setting or clearing the ora_taf_function (see RT78811) (Martin J. Evans) - the ora_taf_function is now passed a third argument of the connection handle (Martin J. Evans) - RT78987 - removed Oraperl.pm and oraperl.ph; these files will be available in a separate distribution named "Oraperl" (David Perry) [MISCELLANEOUS] - hide dr, db and st packages from PAUSE (Martin J. Evans) - added a few more simple TAF tests (Martin J. Evans) -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- --
RE: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
Hi guys had some time today to play again
Seems we have one of three choices
SvREFCNT_dec(tuples_utf8_av);
as pathced
or
av_clear(tuples_utf8_av);
at the send of the 'i' loop or
sv_2mortal((SV*)tuples_utf8_av);
at the begining
I have tried them all and they all get rid of the leak.
I also noticed that we are useing
safemalloc
which is sort of ugly Newz is better
My choice is to use the
sv_2mortal((SV*)tuples_utf8_av);
at the beginning and let perl worry about it.
I will do another pathc I think to get rid of the malloc code as I see it in
other places as well
Any more thoughts before I stick it in trunk???
cheers
John
> Date: Tue, 9 Oct 2012 21:21:13 +0200
> From: blan...@worldcom.ch
> To: martin.ev...@easysoft.com
> CC: dbi-dev@perl.org
> Subject: Re: Patch proposal for leak in DBD::Oracle when calling
> 'execute_array' with UTF-8 NLS...
>
>
>
> Hello Martin,
>
> Sorry for the late reply.
> Basically what my script tries to do is to copy lots of records from one
> database to another. To do this, I've come to the idea of using "execute
> array" to speed up the process. I generally use NLS_LANG set to UTF-8
> for Oracle, because it's the default encoding on my Linux distribution,
> so it was not a choice I've made for that specific application.
>
> It's when reviewing the code (after a little help from valgrind
> memory-checker), that I got the idea to turn UTF-8 off. Specifically the
> lines around ~ 3825 : ...
> /* update the utf8_flgs for this value */
> if (SvUTF8(sv)) {
> utf8_flgs[i] |= ARRAY_BIND_UTF8;
> if (SvTRUE(tuples_status)){
> av_push(tuples_utf8_av,newSViv(j));
> }
>
> ... made me think it was probably worth a try.
>
> As so far I understand, the 'tuples_utf8_av' is not given back to perl
> interpreter, I assumed that it was safe to decrement it's reference
> count to allow it to be garbage-collected. But as I said in my previous
> mail, I've no experience in Perl internals and that may be a false
> assumption.
>
> Thanks very much for your feedback.
> Best regards,
> Pierre-Alain Blanc
>
> On 09/10/12 09:53, Martin J. Evans wrote:
> > On 08/10/12 13:46, Pierre-Alain Blanc wrote:
> >>
> >>
> >> Hello,
> >>
> >> I've had a problem when using 'execute_array' to insert (lots of)
> >> records with DBD::Oracle (version 1.50): the script consumed too much
> >> memory and finally crashed (killed by kernel). I tried to trigger the
> >> garbage-collection with some code rewrite but it didn't help. But if
> >> I told Oracle *not* to use an UTF-8 charset (changing NLS_LANG from
> >> (for example) "german_germany.utf8" to "german_germany.we8dec"), the
> >> problem disappeared.
> >>
> >> After some investigations, I think the leak is in
> >> 'ora_st_execute_array' method of dbdimp.c. Please find the patch as
> >> attachment. As I'm completly new to writing C for Perl, it may be
> >> something I did not understand or did not correctly fixed. Sorry if
> >> it would be the case.
> >>
> >> Thanks & best regards, Pierre-Alain Blanc
> >>
> >>
> >
> > Thanks for looking into this. The patch:
> >
> > Index: dbdimp.c
> > ===
> > --- dbdimp.c (revision 15435)
> > +++ dbdimp.c (working copy)
> > @@ -3839,6 +3839,7 @@
> > }
> > Safefree(phs);
> > Safefree(utf8_flgs);
> > + SvREFCNT_dec(tuples_utf8_av);
> > /* Store array of bind typles, for use in OCIBindDynamic()
> > callback. */
> > imp_sth->bind_tuples = tuples_av;
> > imp_sth->rowwise = (columns_av == NULL);
> >
> > looks good but it does not explain how changing chrset made the
> > problem go away. Perhaps you could give me a better idea of what you
> > were doing then I can replicate and test it.
> >
> > Martin
>
Re: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
Hello Martin,
Sorry for the late reply.
Basically what my script tries to do is to copy lots of records from one
database to another. To do this, I've come to the idea of using "execute
array" to speed up the process. I generally use NLS_LANG set to UTF-8
for Oracle, because it's the default encoding on my Linux distribution,
so it was not a choice I've made for that specific application.
It's when reviewing the code (after a little help from valgrind
memory-checker), that I got the idea to turn UTF-8 off. Specifically the
lines around ~ 3825 : ...
/* update the utf8_flgs for this value */
if (SvUTF8(sv)) {
utf8_flgs[i] |= ARRAY_BIND_UTF8;
if (SvTRUE(tuples_status)){
av_push(tuples_utf8_av,newSViv(j));
}
... made me think it was probably worth a try.
As so far I understand, the 'tuples_utf8_av' is not given back to perl
interpreter, I assumed that it was safe to decrement it's reference
count to allow it to be garbage-collected. But as I said in my previous
mail, I've no experience in Perl internals and that may be a false
assumption.
Thanks very much for your feedback.
Best regards,
Pierre-Alain Blanc
On 09/10/12 09:53, Martin J. Evans wrote:
On 08/10/12 13:46, Pierre-Alain Blanc wrote:
Hello,
I've had a problem when using 'execute_array' to insert (lots of)
records with DBD::Oracle (version 1.50): the script consumed too much
memory and finally crashed (killed by kernel). I tried to trigger the
garbage-collection with some code rewrite but it didn't help. But if
I told Oracle *not* to use an UTF-8 charset (changing NLS_LANG from
(for example) "german_germany.utf8" to "german_germany.we8dec"), the
problem disappeared.
After some investigations, I think the leak is in
'ora_st_execute_array' method of dbdimp.c. Please find the patch as
attachment. As I'm completly new to writing C for Perl, it may be
something I did not understand or did not correctly fixed. Sorry if
it would be the case.
Thanks & best regards, Pierre-Alain Blanc
Thanks for looking into this. The patch:
Index: dbdimp.c
===
--- dbdimp.c(revision 15435)
+++ dbdimp.c(working copy)
@@ -3839,6 +3839,7 @@
}
Safefree(phs);
Safefree(utf8_flgs);
+SvREFCNT_dec(tuples_utf8_av);
/* Store array of bind typles, for use in OCIBindDynamic()
callback. */
imp_sth->bind_tuples = tuples_av;
imp_sth->rowwise = (columns_av == NULL);
looks good but it does not explain how changing chrset made the
problem go away. Perhaps you could give me a better idea of what you
were doing then I can replicate and test it.
Martin
RE: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
Well playing with it a bit tonight I tried this patch instead ++ AV *tuples_av =sv_2mortal(newAV()); -- tuples_utf8_av=newAV(); and it worked exactly the same. I have noticed a little thing though that may be another leak. Seems If I change the value of 'ora_array_chunk_size' It becomes stable but then seems to leak again later on. I will have to investigate a little more. Might just have to juggle things about a little to clear out memory when dealing with big ''ora_array_chunk_size' Cheers John > Date: Tue, 9 Oct 2012 16:57:05 +0200 > Subject: Re: Patch proposal for leak in DBD::Oracle when calling > 'execute_array' with UTF-8 NLS... > From: demer...@gmail.com > To: byter...@hotmail.com > CC: martin.ev...@easysoft.com; blan...@worldcom.ch; dbi-dev@perl.org > > On 9 October 2012 14:29, John Scoles wrote: > > > > I am sort of with Martin on this one as we would like to know why? > > > > At first glace decrementing the reference count like this would not seem to > > be a little overkill as tuples_utf8_av is created with newAV() which should > > take care of that for us. > > Should take care of what? > > newAV() doesnt create a mortal. > > Yves > > > -- > perl -Mre=debug -e "/just|another|perl|hacker/"
RE: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
Opps you are right Should read perlguts again. Looking again putting the tuples_utf8_av in the iteration may work but perhapse one should use 'sv_2mortal' at some point in the into to take care of the garbage collection for us. Like I said I only had a quick look at it. My preferace is to let XS take case for any decrementing for us, is my point I was trying to get across. cheers John > Date: Tue, 9 Oct 2012 16:57:05 +0200 > Subject: Re: Patch proposal for leak in DBD::Oracle when calling > 'execute_array' with UTF-8 NLS... > From: demer...@gmail.com > To: byter...@hotmail.com > CC: martin.ev...@easysoft.com; blan...@worldcom.ch; dbi-dev@perl.org > > On 9 October 2012 14:29, John Scoles wrote: > > > > I am sort of with Martin on this one as we would like to know why? > > > > At first glace decrementing the reference count like this would not seem to > > be a little overkill as tuples_utf8_av is created with newAV() which should > > take care of that for us. > > Should take care of what? > > newAV() doesnt create a mortal. > > Yves > > > -- > perl -Mre=debug -e "/just|another|perl|hacker/" >
Re: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
On 9 October 2012 14:29, John Scoles wrote: > > I am sort of with Martin on this one as we would like to know why? > > At first glace decrementing the reference count like this would not seem to > be a little overkill as tuples_utf8_av is created with newAV() which should > take care of that for us. Should take care of what? newAV() doesnt create a mortal. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
RE: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
I am sort of with Martin on this one as we would like to know why? At first glace decrementing the reference count like this would not seem to be a little overkill as tuples_utf8_av is created with newAV() which should take care of that for us. However looking a little deeper maybe we need to move where we tuples_utf8_av=newAV(); down into the iteration of exe_count or at least clean it out at that level at each iteration. Seems the tuples_utf8_av is used just for the exe_count set of tuples not the full set of tuples. Just a few quick thoughts on it. Any testing I can do will have to wait till tonight when I can get to a UTF8 DB. Cheers John > Date: Tue, 9 Oct 2012 08:53:15 +0100 > From: martin.ev...@easysoft.com > To: blan...@worldcom.ch > CC: dbi-dev@perl.org > Subject: Re: Patch proposal for leak in DBD::Oracle when calling > 'execute_array' with UTF-8 NLS... > > On 08/10/12 13:46, Pierre-Alain Blanc wrote: > > > > > > Hello, > > > > I've had a problem when using 'execute_array' to insert (lots of) > > records with DBD::Oracle (version 1.50): the script consumed too much > > memory and finally crashed (killed by kernel). I tried to trigger the > > garbage-collection with some code rewrite but it didn't help. But if > > I told Oracle *not* to use an UTF-8 charset (changing NLS_LANG from > > (for example) "german_germany.utf8" to "german_germany.we8dec"), the > > problem disappeared. > > > > After some investigations, I think the leak is in > > 'ora_st_execute_array' method of dbdimp.c. Please find the patch as > > attachment. As I'm completly new to writing C for Perl, it may be > > something I did not understand or did not correctly fixed. Sorry if > > it would be the case. > > > > Thanks & best regards, Pierre-Alain Blanc > > > > > > Thanks for looking into this. The patch: > > Index: dbdimp.c > === > --- dbdimp.c (revision 15435) > +++ dbdimp.c (working copy) > @@ -3839,6 +3839,7 @@ > } > Safefree(phs); > Safefree(utf8_flgs); > + SvREFCNT_dec(tuples_utf8_av); > /* Store array of bind typles, for use in OCIBindDynamic() callback. */ > imp_sth->bind_tuples = tuples_av; > imp_sth->rowwise = (columns_av == NULL); > > looks good but it does not explain how changing chrset made the problem go > away. Perhaps you could give me a better idea of what you were doing then I > can replicate and test it. > > Martin > -- > Martin J. Evans > Easysoft Limited > http://www.easysoft.com
Re: Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
On 08/10/12 13:46, Pierre-Alain Blanc wrote: Hello, I've had a problem when using 'execute_array' to insert (lots of) records with DBD::Oracle (version 1.50): the script consumed too much memory and finally crashed (killed by kernel). I tried to trigger the garbage-collection with some code rewrite but it didn't help. But if I told Oracle *not* to use an UTF-8 charset (changing NLS_LANG from (for example) "german_germany.utf8" to "german_germany.we8dec"), the problem disappeared. After some investigations, I think the leak is in 'ora_st_execute_array' method of dbdimp.c. Please find the patch as attachment. As I'm completly new to writing C for Perl, it may be something I did not understand or did not correctly fixed. Sorry if it would be the case. Thanks & best regards, Pierre-Alain Blanc Thanks for looking into this. The patch: Index: dbdimp.c === --- dbdimp.c(revision 15435) +++ dbdimp.c(working copy) @@ -3839,6 +3839,7 @@ } Safefree(phs); Safefree(utf8_flgs); + SvREFCNT_dec(tuples_utf8_av); /* Store array of bind typles, for use in OCIBindDynamic() callback. */ imp_sth->bind_tuples = tuples_av; imp_sth->rowwise = (columns_av == NULL); looks good but it does not explain how changing chrset made the problem go away. Perhaps you could give me a better idea of what you were doing then I can replicate and test it. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Patch proposal for leak in DBD::Oracle when calling 'execute_array' with UTF-8 NLS...
Hello, I've had a problem when using 'execute_array' to insert (lots of) records with DBD::Oracle (version 1.50): the script consumed too much memory and finally crashed (killed by kernel). I tried to trigger the garbage-collection with some code rewrite but it didn't help. But if I told Oracle *not* to use an UTF-8 charset (changing NLS_LANG from (for example) "german_germany.utf8" to "german_germany.we8dec"), the problem disappeared. After some investigations, I think the leak is in 'ora_st_execute_array' method of dbdimp.c. Please find the patch as attachment. As I'm completly new to writing C for Perl, it may be something I did not understand or did not correctly fixed. Sorry if it would be the case. Thanks & best regards, Pierre-Alain Blanc Index: dbdimp.c === --- dbdimp.c (revision 15435) +++ dbdimp.c (working copy) @@ -3839,6 +3839,7 @@ } Safefree(phs); Safefree(utf8_flgs); + SvREFCNT_dec(tuples_utf8_av); /* Store array of bind typles, for use in OCIBindDynamic() callback. */ imp_sth->bind_tuples = tuples_av; imp_sth->rowwise = (columns_av == NULL);
DBD::Oracle v1.51_00 is on CPAN
Hi everyone, DBD::Oracle v1.51_00 is on CPAN, on the ready for your testing pleasure. The full changelog is below, but the main thing for this release is TAF. The previous state of TAF in DBD::Oracle was... suboptimal (or, if you prefer, balefully b0rked). Thanks to Martin, it got better. So, anyway, as usual, I'll let the new candidate release simmer for at least 2 weeks, and then -- if no issue is found -- promote it for general consumption. Cheers, `/anick 1.51_00 [BUG FIXES] - fix serious memory corruption in TAF support (Martin J. Evans) - fix finding client in situation where client and server both installed but different architectures (patch by H.Merijn Brand) - fix memory leak in TAF handling - the TAF function was leaked (Martin J. Evans) - fix issue with taf_function being set to a scalar which goes out of scope before the callback is made (Martin J. Evans) - fix RT46739 if a connection breaks the environment handle is not thrown away (Martin J. Evans) - ora_driver_name was not defaulted to the correct DBD::Oracle version (Martin J. Evans) - ora_driver_name, ora_client_info, ora_client_identifier, ora_action and ora_oci_success_warn were set twice (if specified) on connect as they were not deleted from the connect attributes once handled. Code now leaves the setting to the later STORE DBI calls (Martin J. Evans) - fixed some compiler warnings for %lf (Martin J. Evans) - fixed RT78700 - column_info reports wrong size for char semantic char type columns (Douglas Wilson). [CHANGE IN BEHAVIOUR] - ora_taf and ora_taf_sleep were redundant and have been removed. To enable/disable TAF simply set ora_taf_function and if you want to sleep do it in your callback (Martin J. Evans) - ora_taf_function can now be a code reference as well as a string (Martin J. Evans) [ENHANCEMENTS] - the ora_can_taf method was virtually useless since you can only call it after connecting and to enable TAF you had to do it in the connect call. Now you can enable and disable TAF at any time by simply setting or clearing the ora_taf_function (see RT78811) (Martin J. Evans) - the ora_taf_function is now passed a third argument of the connection handle (Martin J. Evans) - RT78987 - removed Oraperl.pm and oraperl.ph; these files will be available in a separate distribution named "Oraperl" (David Perry) [MISCELLANEOUS] - hide dr, db and st packages from PAUSE (Martin J. Evans) - added a few more simple TAF tests (Martin J. Evans) -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- -- Attending Oracle OpenWorld? Be sure to watch out for the Pythian team and to catch one of our many speaking sessions bit.ly/OOW12sessions
Re: Are you using TAF support in DBD::Oracle?
On 07/08/12 10:32, Martin J. Evans wrote: Hi, I didn't implement TAF support in DBD::Oracle but I want to use it. I've just started using it and have had to fix some problems with memory corruption, memory leaks and issues with scalars going out of scope but now I've reached a point where the functionality I require could change the current interface so if you are using TAF (or think you may have an opinion) please read on. There are 3 taf attributes: ora_taf - set to 1 to enable and 0 does not enable BUT 0 does not disable it when previously enabled It only works when connect (login6 actually) is called ora_sleep - a time to sleep between retries The sleep is in DBD::Oracle and not your callback so I believe it is redundant - you can just put it in your callback and ora_sleep can be removed from DBD::Oracle (I've already documented it will go away in trunk). ora_taf_function - the Perl sub to call This is a string which is annoying as it means if your callback is in your module XX::YY and called callback you have to pass 'XX::YY::callback'. I'd really like to just change this to be a code ref. Also the callback does not receive the dbh handle which limits its usefulness. Obviously I could just add this to the end of the args passed to the callback without affecting anyone with existing code. So, ideally I'd like to: remove ora_sleep - it is unnecessary make ora_taf enable and disable TAF whenever it is changed not just in connect add the dbh arg to the callback (at the end to avoid breaking anyone) allow ora_taf_function to be a code ref I might also want to add a user definable scalar to be passed to the callback too. Is this going to affect you? Probably not if I do it as described but I'd like to hear from you especially if you are already using TAF. All feedback welcome. Martin I got one private response to this email but nothing else. I've gone ahead and made the following (hopefully backwards compatible) changes: 1. the taf_function can now be a code ref or a sub name 2. the dbh is passed to the Perl callback sub you register (as the last arg) In doing this I found a number of other inefficiencies in the handling of attributes in the login6/connect method which I've hopefully fixed. FYI these were mostly ora_* attributes specifically handled in the connect method but not deleted from the attribute hash and hence DBI called STORE for them anyway - so quite a bit of code duplication was removed. I've tested this on a 2 node RAC system and TAF seems to work fine. This is now checked in to the subversion trunk. I still plan to allow TAF to be enabled/disabled at any time (not just at connect) and ideally I'd like to get rid of ora_taf and ora_taf_sleep as they are both redundant so: If you are already using TAF in DBD::Oracle please shout out now. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Are you using TAF support in DBD::Oracle?
Hi, I didn't implement TAF support in DBD::Oracle but I want to use it. I've just started using it and have had to fix some problems with memory corruption, memory leaks and issues with scalars going out of scope but now I've reached a point where the functionality I require could change the current interface so if you are using TAF (or think you may have an opinion) please read on. There are 3 taf attributes: ora_taf - set to 1 to enable and 0 does not enable BUT 0 does not disable it when previously enabled It only works when connect (login6 actually) is called ora_sleep - a time to sleep between retries The sleep is in DBD::Oracle and not your callback so I believe it is redundant - you can just put it in your callback and ora_sleep can be removed from DBD::Oracle (I've already documented it will go away in trunk). ora_taf_function - the Perl sub to call This is a string which is annoying as it means if your callback is in your module XX::YY and called callback you have to pass 'XX::YY::callback'. I'd really like to just change this to be a code ref. Also the callback does not receive the dbh handle which limits its usefulness. Obviously I could just add this to the end of the args passed to the callback without affecting anyone with existing code. So, ideally I'd like to: remove ora_sleep - it is unnecessary make ora_taf enable and disable TAF whenever it is changed not just in connect add the dbh arg to the callback (at the end to avoid breaking anyone) allow ora_taf_function to be a code ref I might also want to add a user definable scalar to be passed to the callback too. Is this going to affect you? Probably not if I do it as described but I'd like to hear from you especially if you are already using TAF. All feedback welcome. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
DBD::Oracle v1.46 and v1.47_00 on their way to CPAN
After a little bit more than two weeks of soaking without any issues (yay!), version 1.45_00 of DBD::Oracle has been promoted to general use as v1.46. And because some contributors have been very busy in the meantime, the next trial version, v1.47_00, is also already on its way to CPAN. This new version offers a few bug fixes (more details in the changelog excerpt below), as well as a rework of the platform-specific troubleshooting guides as POD documents. As usual, it’ll be left around for a minimum of two weeks before it gets promoted to v1.48. So... everybody: enjoy. Testers: you know what to do. :-) Joy, `/anick == CHANGELOG == 1.47_00 2012-07-11 [BUG FIXES] - fixed redeclaration of $len in 31lob.t - (Martin J, Evans) - RT55028 - stop segfaulting when attempting to read empty lobs (Martin J. Evans) - RT69059 - Despite OCIPing being documented as added in 10.2 AIX does not seem to have it in 10.2 leading to undefined symbol - Martin J. Evans [DOCUMENTATION] - Promoted the troubleshooting for the different architectures to POD documents, for easier/prettier access. - Added a troubleshooting entry for RT71819 - bound output parameters may be returned in the wrong order (Martin J. Evans) 1.46 2012-07-11 - promote 1.45_00 to official release 1.45_00 2012-06-21 [CHANGE IN BEHAVIOUR] - In future versions of DBD::Oracle ora_verbose will be changed so that it is simply a switch to turn DBI's DBD tracing on or off. A true value will turn it on and a false value will turn it off. DBI's "DBD" tracing was not available when ora_verbose was created and ora_verbose adds an additional test to every trace test. [BUG FIXES] - Fixed RT76695 - offset passed to ora_fetch_scroll should not affect normal fetches (Martin J. Evans) - Fixed RT76410 - fetch after fetch absolute always returns the same row (Martin J. Evans); - Fixed RT75721 - does not build with Oracle 9.2 (Martin J. Evans) - Fixed RT71343 - Oracle 9i does not have OCI_ATTR_TAF_ENABLED or OCI_ATTR_RESERVED_15/16 so cannot build (Martin J. Evans) - skip 24implicit_utf8.t if chr set is not UTF-8 (Martin J. Evans) - Fixed RT76269 - ora_taf_sleep was documented as taf_sleep by accident. There was no way to stop the TAF reconnect attempts. If you want to try another connect attempt in your taf handler you now need to return OCI_FO_RETRY from it. (Martin J. Evans) [MISCELLANEOUS] - minor change to confusing debug output for input parameters (Martin J. Evans) - RT72989 - add note to trouble shooting guide re this RT and Module::Runtime (Martin J. Evans) -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- -- Try Pythian managed services risk-free for operational support, upgrades/migrations, special projects or increased performance.
Re: DBD::Oracle RTs a summary and request for help
On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) and fixed in 10.2.0.2
Re: DBD::Oracle RTs a summary and request for help
On 27/06/12 09:01, Martin Hall wrote: On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) and fixed in 10.2.0.2 Interesting Martin, as someone found it was fixed in 10.2.0.5 and broken in 10.2.0.4. See http://comments.gmane.org/gmane.comp.lang.perl.modules.dbi.general/16206 and that is what I documented. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Oracle RTs a summary and request for help
On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :)
Re: DBD::Oracle RTs a summary and request for help
On 26/06/2012 21:51, Richie wrote: On 6/24/2012 6:25 AM, Martin J. Evans wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. This looks like Oracle Bug 5759845: LD: 0711-317 OCI APPLICATION LINKING FAILS WITH UNDEFINED SYMBOL ON OCIPING of which they marked as WORKAROUND: n/a -> don't use OCIPing() :) Thanks. I have fixed it for now by assuming OCIPing is not defined in 10.2 for AIX. The code now says you need 11.2 on AIX for OCIPing. Merijn confirmed this worked. Martin
Re: DBD::Oracle RTs a summary and request for help
On 24/06/2012 13:26, H.Merijn Brand wrote: On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" wrote: https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. I have AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb plus Oracle 10.2.0.1.0 I'll have a look later. maybe even today This one is fixed now - thanks to Merijn. Martin
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 14:26:13 +0200, "H.Merijn Brand" wrote: > On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" > wrote: > > > https://rt.cpan.org/Ticket/Display.html?id=69059 > > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > > 0712-001 Symbol OCIPing was referenced > > I don't have access to AIX or an Oracle 10 and op gone quiet. > > I have > AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb > plus Oracle 10.2.0.1.0 > > I'll have a look later. maybe even today Test results added to ticket. Available now for help. (Will start xchat now) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle RTs a summary and request for help
On Sun, 24 Jun 2012 11:25:00 +0100, "Martin J. Evans" wrote: > https://rt.cpan.org/Ticket/Display.html?id=69059 > Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: > 0712-001 Symbol OCIPing was referenced > I don't have access to AIX or an Oracle 10 and op gone quiet. I have AIX 5.3.0.0/ML12 IBM,9115-505 PowerPC_POWER5/1898(2) 3920 Mb plus Oracle 10.2.0.1.0 I'll have a look later. maybe even today -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD::Oracle RTs a summary and request for help
Yanick and I have been trying to keep on top of DBD::Oracle RTs but the time I have to do this is short. There are also some issues I don't feel in a position to investigate. There are 35 outstanding RTs which is a significant improvement on 2 years ago when it was over 50 but that is still a depressing number in my mind. stalled: 5 patched: 1 new/open: 29 time since last post on rt: under 6 months: 5 (and half of these simply because I marked them stalled) 6 months - 1 year: 8 1-2 years: 8 2-3 years: 3 3-4 years: 5 4-5 years: 4 over 5 years: 1 2 issues are internal errors reported by Oracle and I cannot personally report issues to Oracle and especially not ones I cannot reproduce. If you've reported an issue which is still outstanding please take another look at it. I often wonder how many people look at the rt list before installing a module and might be put of by that list; I always do and I would be put off by the RT queue for DBD::Oracle. As always a few issues are stalled because they have not been reproduced and the reporter does not answer (I've never really known what the best thing to do with these is). However there are a few I feel someone else might be able to help with: https://rt.cpan.org/Ticket/Display.html?id=72432 bind_param for ORA_..._TABLE use previous size of array if it is empty problem with ORA_VARCHAR2_TABLE - test case supplied. I don't use varchar tables and I'm totally unfamiliar with the code which handles this. https://rt.cpan.org/Ticket/Display.html?id=73733 panic in t/30long.t with a -DDEBUGGING perl For me, every test fails when I build a debugging Perl https://rt.cpan.org/Ticket/Display.html?id=72471 Scary warning during install against 11.2 Oracle database server DBD::Oracle no longer builds with a full Oracle installation due to missing make files but the problem is trickier than it seems. https://rt.cpan.org/Ticket/Display.html?id=72577 core dump with 38taf.t Bus error in this test on Solaris. I cannot reproduce and the reporter has disappeared. I would be happy to look into this if someone could reproduce it. https://rt.cpan.org/Ticket/Display.html?id=30133 DBD::Oracle reports wrong data type for encrypted numeric columns Apparently Jared was looking at this. https://rt.cpan.org/Ticket/Display.html?id=69059 Build fails on AIX 5.3 against Oracle Client 10.2.0.1 with rtld: 0712-001 Symbol OCIPing was referenced I don't have access to AIX or an Oracle 10 and op gone quiet. https://rt.cpan.org/Ticket/Display.html?id=64206 Quoted table name breaks when rebinding LOBs I didn't write the code involved here, there are no comments and I've no idea what it is supposed to do. I've already spent quite a lot of time on this one. If you can lend a hand I'd be most grateful and will provide all the assistance I can. Martin
Re: DBD::Oracle v1.45_00 on its way to CPAN
On 12-06-22 12:15 PM, Jared Still wrote: Wow! Awesome effort by Martin. No kidding. He's a machine. Even possibly the answer to that age-old question: "what would be the result of downloading an OCI API to a T-800 memory dataset". Pure relentless awesomeness, that's what results. :-) Joy, `/anick
DBD::Oracle v1.45_00 on its way to CPAN
After a little bout of hibernation, a new trial version of DBD::Oracle has been churned out. This release is mostly about Martin J. Evans going all ninjawesome on minor bug fixes, as well as paving the way for an upcoming refactoring / speed boost of /ora_verbose/. As usual, the new version will be soaked for at least 2 weeks before it will turn into its fit-for-general-consumption v1.46 incarnation. Testers, please give this baby a whirl. And, also as usual, the full changelog follows for the curious minded. |1.45_00 2012-06-21| |||[CHANGE IN BEHAVIOUR]| |||- In future versions of DBD::Oracle ora_verbose will be changed| |||so that it is simply a switch to turn DBI's DBD tracing on or off.| |||A true value will turn it on and a false value will turn it off.| |||DBI's "DBD" tracing was not available when ora_verbose was created| |||and ora_verbose adds an additional test to every trace test.| |||[BUG FIXES]| |||- Fixed RT76695 - offset passed to ora_fetch_scroll should not affect| |||normal fetches (Martin J. Evans)| |||- Fixed RT76410 - fetch after fetch absolute always returns| |||the same row (Martin J. Evans);| |||- Fixed RT75721 - does not build with Oracle 9.2 (Martin J. Evans)| |||- Fixed RT71343 - Oracle 9i does not have OCI_ATTR_TAF_ENABLED| |||or OCI_ATTR_RESERVED_15/16 so cannot build (Martin J. Evans)| |||- skip 24implicit_utf8.t if chr set is not UTF-8 (Martin J. Evans)| |||- Fixed RT76268 - ora_taf_sleep was documented as taf_sleep by| |||accident. There was no way to stop the TAF reconnect attempts.| |||If you want to try another connect attempt in your taf handler you| |||now need to return OCI_FO_RETRY from it. (Martin J. Evans)| |||[MISCELLANEOUS]| |||- minor change to confusing debug output for input parameters| |||(Martin J. Evans)| |||- RT72989 - add note to trouble shooting guide re this RT and| |||Module::Runtime (Martin J. Evans)| Enjoy, `/anick -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- -- Try Pythian managed services risk-free for operational support, upgrades/migrations, special projects or increased performance.
DBD::Oracle trial version v1.43_00 in its way to CPAN
Hi all, A new trial version of DBD::Oracle is on its way to CPAN. The complete change delta is reported below, but the pièce de résistance of this release is Martin's hunting down of all uses of DBIS. While those changes are boosting DBD::Oracle's performance (mostly for threaded perls), which is awesome, they are also extensives. We therefore need as much exposure and testing on as many Oracle platforms as we can. If you have time, please consider giving this release a whirl. Pretty please. :-) Enjoy! `/anick 1.43_00 2012-03-30 [BUG FIXES] - Applied patch from Rafael Kitover (Caelum) to column_info to handle DEFAULT columns greater in length than the DBI default of 80. The DEFAULT column is a long and it is a PITA to have to set LongReadLen which you can only do on a connection handle in DBD::Oracle. The default maximum size is now 1Mb; above that you will still have to set LongReadLen (Martin J. Evans) - Fixed 70meta and rt74753-utf8-encoded to not die if you cannot connect to Oracle or you cannot install from CPAN if you have not set up a valid Oracle connection. - Fixed 75163. Bfile lobs were not being opened before fetching if ora_auto_lobs was disabled (Martin J. Evans). Note: this has a minor impact on non bfile lobs when ora_auto_lobs is not in force as an additional call to OCILobFileIsOpen will be made. - Removed all DBIS usage fixing and speeding up threaded Perls (Martin J. Evans). - Minor fix to avoid use of uninitialised variable in 31lob.t (Martin J. Evans) [DOCUMENTATION] - clarification of when StrictlyTyped/DiscardString can be used and LongReadLen (Martin J. Evans) - Documented the 3rd type of placeholder and rewrote the existing pod for placeholders (Martin J. Evans). -- Yanick Champoux, Senior Perl Developer The Pythian Group - love your data http://www.pythian.com -- -- Pythian proud winner of Oracle North America Titan Award for Exadata Solution...watch the video on pythian.com
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 12-03-16 10:18 AM, Martin J. Evans wrote: Last night I finished changing DBD::Oracle to eradicate all DBIS usage. Holy schmollee, you're a beast. I've synced the Git repo with your work (branch master with the raw goodness, branch DBIS-less for a version that can be directly be installed from the checkout). Joy, `/anick
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Fri, Mar 16, 2012 at 02:18:00PM +, Martin J. Evans wrote: > > Perl with threads: > 1.42 > read: 128 wallclock secs (86.11 usr + 5.41 sys = 91.52 CPU) @ 0.11/s > (n=10) > readperrow: 137 wallclock secs (95.33 usr + 4.86 sys = 100.19 CPU) @ > 0.10/s (n=10) > > subversion trunk: > read: 94 wallclock secs (52.55 usr + 5.68 sys = 58.23 CPU) @ 0.17/s (n=10) > readperrow: 104 wallclock secs (62.74 usr + 5.06 sys = 67.80 CPU) @ > 0.15/s (n=10) > > which only goes to remind me why I don't use a Perl with threads but if you > do, DBD::Oracle should be a fair bit faster now. So 92 reduced to 58 cpu, and 100 reduced to 68. Those are impressive gains! > BTW, this change is literally thousands of lines of code so if you depend on > DBD::Oracle I'd get a copy of the subversion trunk and try it. Thanks for doing the work Martin! Tim.
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 15/03/12 21:18, Tim Bunce wrote:
On Thu, Mar 15, 2012 at 10:33:43AM +, Martin J. Evans wrote:
Argh, DBD::Oracle tracing is a mess wrt to this discussion:
ocitrace.h:
#define DBD_OCI_TRACEON (DBIS->debug>= 6 || dbd_verbose>=6)
#define DBD_OCI_TRACEFP (DBILOGFP)
#define OCIServerRelease_log_stat(sc,errhp,b,bl,ht,ver,stat)\
stat =OCIServerRelease(sc,errhp,b,bl,ht,ver);\
(DBD_OCI_TRACEON) \
? PerlIO_printf(DBD_OCI_TRACEFP,\
"%sOCIServerRelease(%p)=%s\n",\
OciTp, sc,oci_status_name(stat)),stat \
: stat
Every single OCI call uses DBD_OCI_TRACEON which in turn uses
DBIS->debug and non have a imp_xxx handle so this is a very large
change. Ensuring the code at each point an OCI call is made has an
imp_xxh and getting the right one is going to be an awful job
especially when a load of funcs in oci8.c don't even have a handle. I
don't see an easy way to automate this change so I'm not sure I've got
the stomach for this. If I do this will I really "see" some speed up
as it is a lot of work.
Maybe just do the OCI* function calls that are used in the main fetch
code path, i.e., dbd_st_fetch. Add an imp parameter
-#define OCIServerRelease_log_stat(sc,errhp,b,bl,ht,ver,stat)
+#define OCIServerRelease_log_stat(imp,sc,errhp,b,bl,ht,ver,stat)
stat =OCIServerRelease(sc,errhp,b,bl,ht,ver);\
! (DBIc_TRACE(imp,...)) \
! ? PerlIO_printf(DBIc_LOGPIO(imp),\
"%sOCIServerRelease(%p)=%s\n",\
OciTp, sc,oci_status_name(stat)),stat \
: stat
Tim.
Last night I finished changing DBD::Oracle to eradicate all DBIS usage. I ran
into quite a few problems along the way but all DBIS usage is gone except for a
few calls in functions passed to Oracle. I've not moved to DBIc_TRACE yet but
when I get time I will do that and add the new DBD trace flag as well
(hopefully to replace ora_verbose which seems pointless to me simply adding yet
another test when no-one really uses it other than as on/off).
As a side note there is a phenomenal amount of tracing in DBD::Oracle which it
would be nice to noop the whole lot out for people who don't want the code
continually testing whether tracing is on - me.
A quick benchmark:
use DBI;
use strict;
use warnings;
use Benchmark;
my $h = DBI->connect("dbi:Oracle:host=xxx.easysoft.local;sid=test",
"xxx", "xxx", {RaiseError => 1});
if (@ARGV) {
eval {
$h->do(q/drop table dbis/);
};
setup($h);
}
timethese(10, {
'read' => sub {readit($h)},
'readperrow' => sub {readitperrow($h)}});
#readit($h);
sub setup {
$h->do(q/create table dbis (a int, b varchar(100))/);
$h->begin_work;
my $s = $h->prepare(q/insert into dbis values(?,?)/);
foreach (1..100) {
$s->execute($_, "the quick brown fox jumps over the lazy dog");
}
$h->commit;
print "Table populated\n";
}
sub readit {
my $h = shift;
my $s = $h->prepare(q/select * from dbis/);
$s->execute;
my $d = $s->fetchall_arrayref;
print "Read ", scalar(@$d), " rows\n";
}
sub readitperrow {
my $h = shift;
my $s = $h->prepare(q/select * from dbis/);
$s->execute;
my $rows = 0;
while(my $d = $s->fetchrow_arrayref) {
$rows++;
}
print "Read $rows rows\n";
}
perl 5.14.2
Perl without threads:
1.42:
read: 83 wallclock secs (37.55 usr + 5.77 sys = 43.32 CPU) @ 0.23/s (n=10)
readperrow 85 wallclock secs (39.53 usr + 4.98 sys = 44.51 CPU) @ 0.22/s
(n=10)
subversion trunk:
read: 85 wallclock secs (40.23 usr + 6.22 sys = 46.45 CPU) @ 0.22/s (n=10)
readperrow: 85 wallclock secs (40.06 usr + 5.32 sys = 45.38 CPU) @ 0.22/s
(n=10)
Perl with threads:
1.42
read: 128 wallclock secs (86.11 usr + 5.41 sys = 91.52 CPU) @ 0.11/s (n=10)
readperrow: 137 wallclock secs (95.33 usr + 4.86 sys = 100.19 CPU) @ 0.10/s
(n=10)
subversion trunk:
read: 94 wallclock secs (52.55 usr + 5.68 sys = 58.23 CPU) @ 0.17/s (n=10)
readperrow: 104 wallclock secs (62.74 usr + 5.06 sys = 67.80 CPU) @ 0.15/s
(n=10)
which only goes to remind me why I don't use a Perl with threads but if you do,
DBD::Oracle should be a fair bit faster now.
BTW, this change is literally thousands of lines of code so if you depend on
DBD::Oracle I'd get a copy of the subversion trunk and try it.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Thu, Mar 15, 2012 at 10:33:43AM +, Martin J. Evans wrote: > > Argh, DBD::Oracle tracing is a mess wrt to this discussion: > > ocitrace.h: > > #define DBD_OCI_TRACEON (DBIS->debug >= 6 || dbd_verbose>=6) > #define DBD_OCI_TRACEFP (DBILOGFP) > > #define OCIServerRelease_log_stat(sc,errhp,b,bl,ht,ver,stat)\ > stat =OCIServerRelease(sc,errhp,b,bl,ht,ver);\ > (DBD_OCI_TRACEON) \ > ? PerlIO_printf(DBD_OCI_TRACEFP,\ >"%sOCIServerRelease(%p)=%s\n",\ >OciTp, sc,oci_status_name(stat)),stat \ > : stat > > Every single OCI call uses DBD_OCI_TRACEON which in turn uses > DBIS->debug and non have a imp_xxx handle so this is a very large > change. Ensuring the code at each point an OCI call is made has an > imp_xxh and getting the right one is going to be an awful job > especially when a load of funcs in oci8.c don't even have a handle. I > don't see an easy way to automate this change so I'm not sure I've got > the stomach for this. If I do this will I really "see" some speed up > as it is a lot of work. Maybe just do the OCI* function calls that are used in the main fetch code path, i.e., dbd_st_fetch. Add an imp parameter -#define OCIServerRelease_log_stat(sc,errhp,b,bl,ht,ver,stat) +#define OCIServerRelease_log_stat(imp,sc,errhp,b,bl,ht,ver,stat) stat =OCIServerRelease(sc,errhp,b,bl,ht,ver);\ ! (DBIc_TRACE(imp,...)) \ ! ? PerlIO_printf(DBIc_LOGPIO(imp),\ "%sOCIServerRelease(%p)=%s\n",\ OciTp, sc,oci_status_name(stat)),stat \ : stat Tim.
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 15/03/12 10:16, Martin J. Evans wrote:
On 14/03/2012 10:20, Tim Bunce wrote:
On Wed, Mar 14, 2012 at 08:24:36AM +0100, H.Merijn Brand wrote:
On Tue, 13 Mar 2012 21:44:06 +, Tim Bunce
wrote:
On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote:
The second patch, which makes DBIS more efficient, is a lot more complex,
and more likely to break things (especially as it's changing a bunch of
macros that are directly #included by the DBD drivers. You may need to
bump API version numbers; I don't understand that bit.
I'm concerned that changing the API, and thus forcing all compiled
drivers to be recompiled at the same time the DBI is installed,
isn't worth the gain. Especially as drivers shouldn't be using DBIS in
any hot code anyway.
I finally got around to looking at DBD::Pg and was horrified to discover
the number of DBIS calls made by hot paths in the code. Most are hidden
behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields!
When hidden, it won't stand out to the maintainers.
How do we/I see where it happens? Do you have a (short) guide to check
if my/a DBD (CSV, Unify, File) uses those too?
The slowness of the DBIS macro is only relevant for compiled drivers.
The DBIS macro is used to get a pointer to the DBI's struct dbistate_st.
In non-threaded perls it's simply a static variable initialised once.
In threaded perls it's a macro that has to do more expensive work.
For many years now all DBI handles have had their own pointer to
dbistate_st. Since almost all code in the driver has access to a handle
that's the best way to get the dbistate_st struct pointer.
Essentially it means changing all instances of DBIS to DBIc_DBISTATE(imp_xxh)
(where imp_xxh can be any of the imp_dbh, imp_sth etc variables).
Looking at DBIXS.h I see these other macros that use DBIS and thus
should be avoided in hot code:
DBILOGFP => DBIc_LOGPIO(imp_xxh)
DBILOGMSG(...) => DBIc_DBISTATE(imp_xxh)->logmsg(...)
DBD::ODBC had none of the above.
neatsvpv(...) => DBIc_DBISTATE(imp_xxh)->neatsvpv(...)
DBD::ODBC had a number of these however, the suggested change does not work:
original:
if (DBIc_TRACE(imp_sth, DBD_TRACING, 0, 4)) {
TRACE2(imp_sth, " ODBC_CLEAR_RESULTS '%s' => %s\n",
key, neatsvpv(value,0));
}
new:
if (DBIc_TRACE(imp_sth, DBD_TRACING, 0, 4)) {
TRACE2(imp_sth, " ODBC_CLEAR_RESULTS '%s' => %s\n",
key, (DBIc_DBISTATE(imp_sth)->neatsvpv(value,0)));
}
compiler error:
dbdimp.c: In function 'odbc_clear_result_set':
dbdimp.c:233: error: expected identifier before '(' token
dbdimp.c: In function 'odbc_db_STORE_attrib':
dbdimp.c:4672: warning: cast to pointer from integer of different size
dbdimp.c:4677: warning: cast to pointer from integer of different size
dmake: Error code 129, while making 'dbdimp.o'
I've not really looked into it yet.
however, usually those are only called in tracing code so it may not be
worth the effort to change them.
ok, but I'm happy to do it in my case.
I've now changed DBD::ODBC to remove all unnecessary calls to D_imp_whatever.
The DBIh_COM(h) macro also uses DBIS but there's a chicken-and-egg
problem here since DBIh_COM is the underlying mechanism of the
D_imp_xxh(h) macros used to get the imp_xxh pointer. So it can't be
avoided. Yet more reason to apply Dave's changes.
Tim.
p.s. For the logic to control tracing I recommend the DBIc_TRACE macro
(or something driver-specific like it or built using it):
DBIc_TRACE(imp, flags, flag_level, fallback_level)
I will change DBD::Oracle to use DBIc_TRACE at the weekend. I've started
getting rid of DBIS from DBD::Oracle but as you said it is a bit of a PITA to
do although not difficult.
That's true if flags match the handle trace flags& handle trace
level>= flag_level, OR if handle trace_level> fallback_level
DBIc_TRACE(imp, 0, 0, 4) = if handle trace level>= 4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 4) = if tracing DBDf_TRACE_FOO& level>=2 OR
level>=4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 0) = as above but never trace just due to
level
For example:
if (DBIc_TRACE(imp_xxh, DBIf_TRACE_SQL|DBIf_TRACE_xxx, 3, 7)) {
PerlIO_printf(DBIc_LOGPIO(imp_sth), "\tThe %s wibbled the %s\n", ...);
}
Martin
Argh, DBD::Oracle tracing is a mess wrt to this discussion:
ocitrace.h:
#define DBD_OCI_TRACEON (DBIS->debug >= 6 || dbd_verbose>=6)
#define DBD_OCI_TRACEFP (DBILOGFP)
#define OCIServerRelease_log_stat(sc,errhp,b,bl,ht,ver,stat)\
stat =OCIServerRelease(sc,errhp,b,bl,ht,ver);\
(DBD_OCI_TRACEON) \
? PerlIO_printf(DBD_OCI_TRACEFP,\
"%sOCIServerRelease(%p)=%s\n",\
OciTp, sc,oci_status_name(stat)),stat \
: stat
Every single OCI call uses DBD_OCI_TRACEON which
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 14/03/2012 10:20, Tim Bunce wrote:
On Wed, Mar 14, 2012 at 08:24:36AM +0100, H.Merijn Brand wrote:
On Tue, 13 Mar 2012 21:44:06 +, Tim Bunce
wrote:
On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote:
The second patch, which makes DBIS more efficient, is a lot more complex,
and more likely to break things (especially as it's changing a bunch of
macros that are directly #included by the DBD drivers. You may need to
bump API version numbers; I don't understand that bit.
I'm concerned that changing the API, and thus forcing all compiled
drivers to be recompiled at the same time the DBI is installed,
isn't worth the gain. Especially as drivers shouldn't be using DBIS in
any hot code anyway.
I finally got around to looking at DBD::Pg and was horrified to discover
the number of DBIS calls made by hot paths in the code. Most are hidden
behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields!
When hidden, it won't stand out to the maintainers.
How do we/I see where it happens? Do you have a (short) guide to check
if my/a DBD (CSV, Unify, File) uses those too?
The slowness of the DBIS macro is only relevant for compiled drivers.
The DBIS macro is used to get a pointer to the DBI's struct dbistate_st.
In non-threaded perls it's simply a static variable initialised once.
In threaded perls it's a macro that has to do more expensive work.
For many years now all DBI handles have had their own pointer to
dbistate_st. Since almost all code in the driver has access to a handle
that's the best way to get the dbistate_st struct pointer.
Essentially it means changing all instances of DBIS to DBIc_DBISTATE(imp_xxh)
(where imp_xxh can be any of the imp_dbh, imp_sth etc variables).
Looking at DBIXS.h I see these other macros that use DBIS and thus
should be avoided in hot code:
DBILOGFP=> DBIc_LOGPIO(imp_xxh)
DBILOGMSG(...) => DBIc_DBISTATE(imp_xxh)->logmsg(...)
DBD::ODBC had none of the above.
neatsvpv(...) => DBIc_DBISTATE(imp_xxh)->neatsvpv(...)
DBD::ODBC had a number of these however, the suggested change does not work:
original:
if (DBIc_TRACE(imp_sth, DBD_TRACING, 0, 4)) {
TRACE2(imp_sth, "ODBC_CLEAR_RESULTS '%s' => %s\n",
key, neatsvpv(value,0));
}
new:
if (DBIc_TRACE(imp_sth, DBD_TRACING, 0, 4)) {
TRACE2(imp_sth, "ODBC_CLEAR_RESULTS '%s' => %s\n",
key, (DBIc_DBISTATE(imp_sth)->neatsvpv(value,0)));
}
compiler error:
dbdimp.c: In function 'odbc_clear_result_set':
dbdimp.c:233: error: expected identifier before '(' token
dbdimp.c: In function 'odbc_db_STORE_attrib':
dbdimp.c:4672: warning: cast to pointer from integer of different size
dbdimp.c:4677: warning: cast to pointer from integer of different size
dmake: Error code 129, while making 'dbdimp.o'
I've not really looked into it yet.
however, usually those are only called in tracing code so it may not be
worth the effort to change them.
ok, but I'm happy to do it in my case.
I've now changed DBD::ODBC to remove all unnecessary calls to D_imp_whatever.
The DBIh_COM(h) macro also uses DBIS but there's a chicken-and-egg
problem here since DBIh_COM is the underlying mechanism of the
D_imp_xxh(h) macros used to get the imp_xxh pointer. So it can't be
avoided. Yet more reason to apply Dave's changes.
Tim.
p.s. For the logic to control tracing I recommend the DBIc_TRACE macro
(or something driver-specific like it or built using it):
DBIc_TRACE(imp, flags, flag_level, fallback_level)
I will change DBD::Oracle to use DBIc_TRACE at the weekend. I've started
getting rid of DBIS from DBD::Oracle but as you said it is a bit of a PITA to
do although not difficult.
That's true if flags match the handle trace flags& handle trace
level>= flag_level, OR if handle trace_level> fallback_level
DBIc_TRACE(imp, 0, 0, 4) = if handle trace level>= 4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 4) = if tracing DBDf_TRACE_FOO& level>=2
OR level>=4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 0) = as above but never trace just due
to level
For example:
if (DBIc_TRACE(imp_xxh, DBIf_TRACE_SQL|DBIf_TRACE_xxx, 3, 7)) {
PerlIO_printf(DBIc_LOGPIO(imp_sth), "\tThe %s wibbled the %s\n", ...);
}
Martin
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Wed, Mar 14, 2012 at 02:00:19PM +, Martin J. Evans wrote: > > > >>There are cases where an imp_sth is passed as a parameter yet > >>D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh > >>pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for > >>example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in > >>the function to be imp_sth instead. There may be cases where the same > >>applies with imp_dbh. > > > >Yeah, thanks, I'll fix those. > > Those D_imp_xxh calls in dbd_st_fetch and dbd_bind_ph are simply there > because those fns call DBIh_SET_ERR_CHAR and that takes an imp_xxh_t. > I have removed them but then I need to cast imp_dbh/imp_sth to > imp_xxh_t before calling DBIh_SET_ERR_CHAR so that then makes we > wonder why imp_xxh_t is really required? just so you can pass an > imp_dbh_t or an imp_sth_t to it? > > The only places DBD::ODBC using imp_xxh_t is in calls to > DBIh_SET_ERR_CHAR and DBIc_TRACE (and a few calls to DBIc_TYPE). So > are you effectively saying imp_xxh_t exists for the simple reason it > could be either an imp_sth_t/imp_dbh_t and if that is so I presume I > can just delete all D_imp_xxh macros where the imp_xxh is passed to > DBIh_SET_ERR_CHAR/DBIc_TRACE, pass the real imp_*h and cast it and > avoid a call to dbih_getcom2? Yes. imp_xxh_t gives access to those struct elements that are common to all handles. It's always safe to cast a imp_??h_t to imp_xxh_t. Tim.
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 03/14/12 07:37, Martin J. Evans wrote: I'll try and find time to sort Oracle out unless Yanick steps in. I'll see if I can give it a go, but as of now that's more a pledge of goodwill than decent skills. The deep guts of DBI are still very murky to me. But I'll do my best. :-) Joy, `/anick
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 14/03/12 11:37, Martin J. Evans wrote: On 14/03/12 10:37, Tim Bunce wrote: On Wed, Mar 14, 2012 at 08:52:38AM +, Martin J. Evans wrote: On 13/03/12 21:44, Tim Bunce wrote: On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: The second patch, which makes DBIS more efficient, is a lot more complex, and more likely to break things (especially as it's changing a bunch of macros that are directly #included by the DBD drivers. You may need to bump API version numbers; I don't understand that bit. I'm concerned that changing the API, and thus forcing all compiled drivers to be recompiled at the same time the DBI is installed, isn't worth the gain. Especially as drivers shouldn't be using DBIS in any hot code anyway. On the other hand, I want whatever speed I can get so I am happy to recompile any DBDs to get it. Do people like me have to do without improvements for the sake of those who don't want to recompile their DBDs or can it be done in some other way or opt in. Per my recent message, implicit usage of DBIS is higher than I'd thought. The DBI will certain get Dave's improvements in some form, and yes, drivers will need to be recompiled. In fact they may *have* to be recompiled. Good. I don't think DBD::ODBC uses any DBIS stuff I had a (very) quick look and it loosk good. It's even using DBIc_TRACE() :) I thought I was pretty up to date. There are cases where an imp_sth is passed as a parameter yet D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in the function to be imp_sth instead. There may be cases where the same applies with imp_dbh. Yeah, thanks, I'll fix those. Those D_imp_xxh calls in dbd_st_fetch and dbd_bind_ph are simply there because those fns call DBIh_SET_ERR_CHAR and that takes an imp_xxh_t. I have removed them but then I need to cast imp_dbh/imp_sth to imp_xxh_t before calling DBIh_SET_ERR_CHAR so that then makes we wonder why imp_xxh_t is really required? just so you can pass an imp_dbh_t or an imp_sth_t to it? The only places DBD::ODBC using imp_xxh_t is in calls to DBIh_SET_ERR_CHAR and DBIc_TRACE (and a few calls to DBIc_TYPE). So are you effectively saying imp_xxh_t exists for the simple reason it could be either an imp_sth_t/imp_dbh_t and if that is so I presume I can just delete all D_imp_xxh macros where the imp_xxh is passed to DBIh_SET_ERR_CHAR/DBIc_TRACE, pass the real imp_*h and cast it and avoid a call to dbih_getcom2? There are other places where internal functions use the D_imp_xxh(h) initializer but that could be avoided by passing in imp_xxh from the caller. (And by *_xxh I mean _dbh, _sth - whichever is appropriate.) I'll do that too. That is a bigger job but one I've started. but to be sure I'd echo Merijn's reply; if you could point out what to look for and an approach I'd happily change any DBD I could run and provide patches for it (currently I have ODBC, Pg, Oracle, CSV, SQLite, mysql and all those you get with DBI). Let me know if my reply to Merijn wasn't clear or complete enough. It was fine. I'll try and find time to sort Oracle out unless Yanick steps in. I also meant to change Oracle to use DBD trace flag etc which gets rid of loads of ora_verbose code all over the place but I've not had time as yet as the level or rts reported for Oracle keeps me pretty busy. Martin Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 14/03/12 10:37, Tim Bunce wrote: On Wed, Mar 14, 2012 at 08:52:38AM +, Martin J. Evans wrote: On 13/03/12 21:44, Tim Bunce wrote: On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: The second patch, which makes DBIS more efficient, is a lot more complex, and more likely to break things (especially as it's changing a bunch of macros that are directly #included by the DBD drivers. You may need to bump API version numbers; I don't understand that bit. I'm concerned that changing the API, and thus forcing all compiled drivers to be recompiled at the same time the DBI is installed, isn't worth the gain. Especially as drivers shouldn't be using DBIS in any hot code anyway. On the other hand, I want whatever speed I can get so I am happy to recompile any DBDs to get it. Do people like me have to do without improvements for the sake of those who don't want to recompile their DBDs or can it be done in some other way or opt in. Per my recent message, implicit usage of DBIS is higher than I'd thought. The DBI will certain get Dave's improvements in some form, and yes, drivers will need to be recompiled. In fact they may *have* to be recompiled. I don't think DBD::ODBC uses any DBIS stuff I had a (very) quick look and it loosk good. It's even using DBIc_TRACE() :) I thought I was pretty up to date. There are cases where an imp_sth is passed as a parameter yet D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in the function to be imp_sth instead. There may be cases where the same applies with imp_dbh. Yeah, thanks, I'll fix those. There are other places where internal functions use the D_imp_xxh(h) initializer but that could be avoided by passing in imp_xxh from the caller. (And by *_xxh I mean _dbh, _sth - whichever is appropriate.) I'll do that too. but to be sure I'd echo Merijn's reply; if you could point out what to look for and an approach I'd happily change any DBD I could run and provide patches for it (currently I have ODBC, Pg, Oracle, CSV, SQLite, mysql and all those you get with DBI). Let me know if my reply to Merijn wasn't clear or complete enough. It was fine. I'll try and find time to sort Oracle out unless Yanick steps in. I also meant to change Oracle to use DBD trace flag etc which gets rid of loads of ora_verbose code all over the place but I've not had time as yet as the level or rts reported for Oracle keeps me pretty busy. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Wed, Mar 14, 2012 at 08:52:38AM +, Martin J. Evans wrote: > On 13/03/12 21:44, Tim Bunce wrote: > >On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: > >>> > >>>The second patch, which makes DBIS more efficient, is a lot more complex, > >>>and more likely to break things (especially as it's changing a bunch of > >>>macros that are directly #included by the DBD drivers. You may need to > >>>bump API version numbers; I don't understand that bit. > >> > >>I'm concerned that changing the API, and thus forcing all compiled > >>drivers to be recompiled at the same time the DBI is installed, > >>isn't worth the gain. Especially as drivers shouldn't be using DBIS in > >>any hot code anyway. > > On the other hand, I want whatever speed I can get so I am happy to > recompile any DBDs to get it. Do people like me have to do without > improvements for the sake of those who don't want to recompile their > DBDs or can it be done in some other way or opt in. Per my recent message, implicit usage of DBIS is higher than I'd thought. The DBI will certain get Dave's improvements in some form, and yes, drivers will need to be recompiled. In fact they may *have* to be recompiled. > I don't think DBD::ODBC uses any DBIS stuff I had a (very) quick look and it loosk good. It's even using DBIc_TRACE() :) There are cases where an imp_sth is passed as a parameter yet D_imp_xxh(sth) is being called. So you end up with imp_sth and imp_xxh pointers that point to the same thing. See dbd_st_fetch and dbd_bind_ph for example. Just delete the D_imp_xxh(sth); line and change all imp_xxh in the function to be imp_sth instead. There may be cases where the same applies with imp_dbh. There are other places where internal functions use the D_imp_xxh(h) initializer but that could be avoided by passing in imp_xxh from the caller. (And by *_xxh I mean _dbh, _sth - whichever is appropriate.) > but to be sure I'd echo > Merijn's reply; if you could point out what to look for and an > approach I'd happily change any DBD I could run and provide patches > for it (currently I have ODBC, Pg, Oracle, CSV, SQLite, mysql and all > those you get with DBI). Let me know if my reply to Merijn wasn't clear or complete enough. Tim.
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Wed, Mar 14, 2012 at 08:24:36AM +0100, H.Merijn Brand wrote:
> On Tue, 13 Mar 2012 21:44:06 +, Tim Bunce
> wrote:
>
> > On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote:
> > > >
> > > > The second patch, which makes DBIS more efficient, is a lot more
> > > > complex,
> > > > and more likely to break things (especially as it's changing a bunch of
> > > > macros that are directly #included by the DBD drivers. You may need to
> > > > bump API version numbers; I don't understand that bit.
> > >
> > > I'm concerned that changing the API, and thus forcing all compiled
> > > drivers to be recompiled at the same time the DBI is installed,
> > > isn't worth the gain. Especially as drivers shouldn't be using DBIS in
> > > any hot code anyway.
> >
> > I finally got around to looking at DBD::Pg and was horrified to discover
> > the number of DBIS calls made by hot paths in the code. Most are hidden
> > behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields!
>
> When hidden, it won't stand out to the maintainers.
>
> How do we/I see where it happens? Do you have a (short) guide to check
> if my/a DBD (CSV, Unify, File) uses those too?
The slowness of the DBIS macro is only relevant for compiled drivers.
The DBIS macro is used to get a pointer to the DBI's struct dbistate_st.
In non-threaded perls it's simply a static variable initialised once.
In threaded perls it's a macro that has to do more expensive work.
For many years now all DBI handles have had their own pointer to
dbistate_st. Since almost all code in the driver has access to a handle
that's the best way to get the dbistate_st struct pointer.
Essentially it means changing all instances of DBIS to DBIc_DBISTATE(imp_xxh)
(where imp_xxh can be any of the imp_dbh, imp_sth etc variables).
Looking at DBIXS.h I see these other macros that use DBIS and thus
should be avoided in hot code:
DBILOGFP=> DBIc_LOGPIO(imp_xxh)
DBILOGMSG(...) => DBIc_DBISTATE(imp_xxh)->logmsg(...)
neatsvpv(...) => DBIc_DBISTATE(imp_xxh)->neatsvpv(...)
however, usually those are only called in tracing code so it may not be
worth the effort to change them.
The DBIh_COM(h) macro also uses DBIS but there's a chicken-and-egg
problem here since DBIh_COM is the underlying mechanism of the
D_imp_xxh(h) macros used to get the imp_xxh pointer. So it can't be
avoided. Yet more reason to apply Dave's changes.
Tim.
p.s. For the logic to control tracing I recommend the DBIc_TRACE macro
(or something driver-specific like it or built using it):
DBIc_TRACE(imp, flags, flag_level, fallback_level)
That's true if flags match the handle trace flags & handle trace
level >= flag_level, OR if handle trace_level > fallback_level
DBIc_TRACE(imp, 0, 0, 4) = if handle trace level >= 4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 4) = if tracing DBDf_TRACE_FOO & level>=2
OR level>=4
DBIc_TRACE(imp, DBDf_TRACE_FOO, 2, 0) = as above but never trace just due to
level
For example:
if (DBIc_TRACE(imp_xxh, DBIf_TRACE_SQL|DBIf_TRACE_xxx, 3, 7)) {
PerlIO_printf(DBIc_LOGPIO(imp_sth), "\tThe %s wibbled the %s\n", ...);
}
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On 13/03/12 21:44, Tim Bunce wrote: On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: The second patch, which makes DBIS more efficient, is a lot more complex, and more likely to break things (especially as it's changing a bunch of macros that are directly #included by the DBD drivers. You may need to bump API version numbers; I don't understand that bit. I'm concerned that changing the API, and thus forcing all compiled drivers to be recompiled at the same time the DBI is installed, isn't worth the gain. Especially as drivers shouldn't be using DBIS in any hot code anyway. On the other hand, I want whatever speed I can get so I am happy to recompile any DBDs to get it. Do people like me have to do without improvements for the sake of those who don't want to recompile their DBDs or can it be done in some other way or opt in. I finally got around to looking at DBD::Pg and was horrified to discover the number of DBIS calls made by hot paths in the code. Most are hidden behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields! Then I looked at DBD::Oracle and discovered the same kind of thing. Which is particularly disappointing for me as I wrote the tracing mechanism it uses (though maybe that pre-dated thread support). I am happy to change DBD::Oracle or may be Yanick will. Anyway, the upshot is that getting DBIS calls out of major drivers will require a fair bit of work. It's just grunt-work really, nothing complicated. As you noted with DBD::mysql, Dave, the performance gains are worth it. Any volunteers? Naturally I'll be happy to suggest an approach I think will work well (basically an extension of that used by DBD::Oracle). Dave, I'll get back to you about the DBIS changes soon, I hope. Tim. I don't think DBD::ODBC uses any DBIS stuff but to be sure I'd echo Merijn's reply; if you could point out what to look for and an approach I'd happily change any DBD I could run and provide patches for it (currently I have ODBC, Pg, Oracle, CSV, SQLite, mysql and all those you get with DBI). Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Tue, 13 Mar 2012 21:44:06 +, Tim Bunce wrote: > On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: > > > > > > The second patch, which makes DBIS more efficient, is a lot more complex, > > > and more likely to break things (especially as it's changing a bunch of > > > macros that are directly #included by the DBD drivers. You may need to > > > bump API version numbers; I don't understand that bit. > > > > I'm concerned that changing the API, and thus forcing all compiled > > drivers to be recompiled at the same time the DBI is installed, > > isn't worth the gain. Especially as drivers shouldn't be using DBIS in > > any hot code anyway. > > I finally got around to looking at DBD::Pg and was horrified to discover > the number of DBIS calls made by hot paths in the code. Most are hidden > behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields! When hidden, it won't stand out to the maintainers. How do we/I see where it happens? Do you have a (short) guide to check if my/a DBD (CSV, Unify, File) uses those too? > Then I looked at DBD::Oracle and discovered the same kind of thing. > Which is particularly disappointing for me as I wrote the tracing > mechanism it uses (though maybe that pre-dated thread support). > > Anyway, the upshot is that getting DBIS calls out of major drivers will > require a fair bit of work. It's just grunt-work really, nothing complicated. > As you noted with DBD::mysql, Dave, the performance gains are worth it. > > Any volunteers? Naturally I'll be happy to suggest an approach I think > will work well (basically an extension of that used by DBD::Oracle). > > Dave, I'll get back to you about the DBIS changes soon, I hope. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
On Fri, Mar 02, 2012 at 03:11:17PM +, Tim Bunce wrote: > > > > The second patch, which makes DBIS more efficient, is a lot more complex, > > and more likely to break things (especially as it's changing a bunch of > > macros that are directly #included by the DBD drivers. You may need to > > bump API version numbers; I don't understand that bit. > > I'm concerned that changing the API, and thus forcing all compiled > drivers to be recompiled at the same time the DBI is installed, > isn't worth the gain. Especially as drivers shouldn't be using DBIS in > any hot code anyway. I finally got around to looking at DBD::Pg and was horrified to discover the number of DBIS calls made by hot paths in the code. Most are hidden behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields! Then I looked at DBD::Oracle and discovered the same kind of thing. Which is particularly disappointing for me as I wrote the tracing mechanism it uses (though maybe that pre-dated thread support). Anyway, the upshot is that getting DBIS calls out of major drivers will require a fair bit of work. It's just grunt-work really, nothing complicated. As you noted with DBD::mysql, Dave, the performance gains are worth it. Any volunteers? Naturally I'll be happy to suggest an approach I think will work well (basically an extension of that used by DBD::Oracle). Dave, I'll get back to you about the DBIS changes soon, I hope. Tim.
Re: DBD-Oracle 1.40
On Mon, 12 Mar 2012 16:02:46 -0400, Yanick Champoux wrote: > On 12-03-11 11:48 AM, H.Merijn Brand wrote: > > On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux > > wrote: > > > >> On 12-03-11 06:01 AM, H.Merijn Brand wrote: > >>> t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >>> Failed tests: 2-3 > >>> Non-zero exit status: 2 > >>> Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr > >>> 0.01 csys = 0.08 CPU) > >> > >>That's not good. I'll issue a patch Monday, and try to narrow down on > >> which versions of Oracle the fix for rt-74753 isn't working. > > > > Note these: > > > > t/23wide_db.t . skipped: Database character set is not Unicode > > t/23wide_db_8bit.t skipped: Database character set is not Unicode > > t/23wide_db_al32utf8.t skipped: Database character set is not Unicode > > I have a new trial version changing the test so that it doesn't run if > the db character set is not unicode. I'm at home today, so I can't run > my battery of tests before releasing, but if anyone feel like giving it > a whirl, the new version is at > > svn repo: > http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle-1.41_00 > > git repo: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 % git clone https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 DBD-Oracle Cloning into 'DBD-Oracle'... fatal: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41/info/refs not found: did you run git update-server-info on the server? % git clone https://github.com/yanick/DBD-Oracle DBD-Oracle Cloning into 'DBD-Oracle'... remote: Counting objects: 4891, done. remote: Compressing objects: 100% (1461/1461), done. remote: Total 4891 (delta 3470), reused 4763 (delta 3344) Receiving objects: 100% (4891/4891), 18.37 MiB | 1.07 MiB/s, done. Resolving deltas: 100% (3470/3470), done. % cd DBD-Oracle % git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/cand-v1.41 remotes/origin/cand_1.32 remotes/origin/candidate_1.31_00 remotes/origin/clean-changelog remotes/origin/cpan-changes remotes/origin/dist-zilla remotes/origin/doc-grooming remotes/origin/documentation-rt72252 remotes/origin/longdouble remotes/origin/master remotes/origin/oraperl-warning remotes/origin/pod-test remotes/origin/releases remotes/origin/rt-73206-ora_charset remotes/origin/rt13865 remotes/origin/rt30133 remotes/origin/rt71343-compile9i remotes/origin/rt74753 % git co remotes/origin/cand-v1.41 -b cand-v1.41 Branch cand-v1.41 set up to track remote branch cand-v1.41 from origin. Switched to a new branch 'cand-v1.41' % perl Makefile.PL Using DBI 1.618 (for perl 5.014001 on x86_64-linux-ld) installed in /pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI/ Configuring DBD::Oracle for perl 5.014001 on linux (x86_64-linux-ld) 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 : : % make : ccache cc -c -I/usr/include/oracle/11.2/client64 -I/pro/lib/perl5/site_perl/5.14.1/x86_64-linux-ld/auto/DBI -fPIC -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"undef\" -DXS_VERSION=\"undef\" -fPIC "-I/pro/lib/perl5/5.14.1/x86_64-linux-ld/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c dbdimp.c: In function ‘ora_db_login6’: dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 12 has type ‘size_t’ dbdimp.c:765:5: warning: format ‘%d’ expects type ‘int’, but argument 14 has type ‘size_t’ : % make test PERL_DL_NONLAZY=1 /pro/bin/perl5.14.1 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00versions.t Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Use of uninitialized value in subroutine entry at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Invalid version format (version required) at /pro/lib/perl5/5.14.1/x86_64-linux-ld/DynaLoader.pm line 213. Compilation failed in require at t/00versions.t line 10. BEGIN failed--compilation aborted at t/00versions.t line 10. # Looks like your test exited with 2 before it could output anything. t/00versions.t Dubious, test returned 2 (wstat 512, 0x200) Failed 2/2 subtests > > > FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 &
Re: DBD-Oracle 1.40
On 12-03-11 11:48 AM, H.Merijn Brand wrote: On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux wrote: On 12-03-11 06:01 AM, H.Merijn Brand wrote: t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) That's not good. I'll issue a patch Monday, and try to narrow down on which versions of Oracle the fix for rt-74753 isn't working. Note these: t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode I have a new trial version changing the test so that it doesn't run if the db character set is not unicode. I'm at home today, so I can't run my battery of tests before releasing, but if anyone feel like giving it a whirl, the new version is at svn repo: http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle-1.41_00 git repo: https://github.com/yanick/DBD-Oracle/tree/cand-v1.41 FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 All beyond 1.27 fail :-( I'll open a ticket on RT about that one. Joy, `/anick
Re: DBD-Oracle 1.40
On Sun, 11 Mar 2012 11:27:44 -0400, Yanick Champoux wrote: > On 12-03-11 06:01 AM, H.Merijn Brand wrote: > > t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) > >Failed tests: 2-3 > >Non-zero exit status: 2 > > Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 > > csys = 0.08 CPU) > > > That's not good. I'll issue a patch Monday, and try to narrow down on > which versions of Oracle the fix for rt-74753 isn't working. Note these: t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t .... skipped: Database character set is not Unicode FWIW, DBD::Oracle-1.27 is the last to work on Oracle-9.2.0.8 All beyond 1.27 fail -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD-Oracle 1.40
On 12-03-11 06:01 AM, H.Merijn Brand wrote: t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) That's not good. I'll issue a patch Monday, and try to narrow down on which versions of Oracle the fix for rt-74753 isn't working. Joy, `/anick
DBD-Oracle 1.40
PERL_DL_NONLAZY=1 /pro/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/000-report-versions.t ... # Testing with Perl 5.014001, /pro/bin/perl t/000-report-versions.t ... 1/? # Carp version is 1.25 # Config version is undefined # DBI version is 1.618 # Data::Dumper version is 2.131 # Devel::Peek version is 1.07 # DynaLoader version is 1.13 # Encode version is 2.44 # Exporter version is 5.66 # ExtUtils::MakeMaker version is 6.62 # Math::BigInt version is 1.997 # Oraperl version is 1.44 # Scalar::Util version is 1.23 # Test::More version is 0.98 # Thread::Semaphore version is 2.12 # strict version is 1.04 # utf8 version is 1.09 # vars version is 1.02 # warnings version is 1.12 t/000-report-versions.t ... ok t/00versions.t # OCI client library version: 11.2.0.2 t/00versions.t 1/2 # database version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production t/00versions.t ok t/01base.t ok t/10general.t . ok t/12impdata.t . ok t/14threads.t . skipped: this linux perl 5.014001 not configured to support iThreads t/15nls.t . ok t/20select.t .. ok t/21nchar.t ... ok t/22nchar_al32utf8.t .. ok t/22nchar_utf8.t .. ok t/23wide_db.t . skipped: Database character set is not Unicode t/23wide_db_8bit.t skipped: Database character set is not Unicode t/23wide_db_al32utf8.t skipped: Database character set is not Unicode t/24implicit_utf8.t ... ok t/25plsql.t ... ok t/26exe_array.t ... ok t/28array_bind.t .. ok t/30long.t ok t/31lob.t . skipped: see RT#69350 t/31lob_extended.t ok t/32xmltype.t . ok t/34pres_lobs.t ... ok t/36lob_leak.t ok t/38taf.t . ok t/40ph_type.t . ok t/50cursor.t .. ok t/51scroll.t .. ok t/55nested.t .. ok t/56embbeded.t ok t/58object.t .. ok t/60reauth.t .. skipped: ORACLE_USERID_2 not defined. t/70meta.t ok t/80ora_charset.t . skipped: Database is set up as US7ASCII t/rt13865.t ... ok t/rt74753-utf8-encoded.t .. 1/3 # Failed test 'utf8 encoded' # at t/rt74753-utf8-encoded.t line 58. # got: '' # expected: '1' # Failed test 'truncated, yet utf8 encoded' # at t/rt74753-utf8-encoded.t line 80. # got: '' # expected: '1' # Looks like you failed 2 tests of 3. t/rt74753-utf8-encoded.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report --- t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=36, Tests=2551, 113 wallclock secs ( 1.23 usr 0.10 sys + 5.07 cusr 1.04 csys = 7.44 CPU) Result: FAIL Failed 1/36 test programs. 2/2551 subtests failed. DBD-Oracle-1.40-mOxdTe > prove -vbw t/rt74753-utf8-encoded.t t/rt74753-utf8-encoded.t .. 1..3 ok 1 - utf8 encoded not ok 2 - utf8 encoded # Failed test 'utf8 encoded' # at t/rt74753-utf8-encoded.t line 58. # got: '' # expected: '1' not ok 3 - truncated, yet utf8 encoded # Failed test 'truncated, yet utf8 encoded' # at t/rt74753-utf8-encoded.t line 80. # got: '' # expected: '1' # Looks like you failed 2 tests of 3. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests Test Summary Report --- t/rt74753-utf8-encoded.t (Wstat: 512 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 2 Files=1, Tests=3, 1 wallclock secs ( 0.02 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.08 CPU) Result: FAIL This is perl 5, version 14, subversion 1 (v5.14.1) built for i686-linux-64int-ld LANG=en_US.utf8 -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.39_00 is out
On Mon, 27 Feb 2012 09:57:33 -0500, Yanick Champoux
wrote:
> On 02/27/12 02:02, H.Merijn Brand wrote:
> > On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
> > wrote:
> >
> > > [OTHERS]
> > > - change the shebang line of examples to the more modern '/usr/bin/env
> > > perl'
> >
> > Personally I really really hate this change
>
> Fair enough. This being said, I have to point out that the change
> is only on the scripts in the 'examples/' directory, which are not
> installed as part of the distro.
Understood, but IMHO we/you should not/never promote that usage
> > Perl has been configured to use $Config{startperl}. Use it!
>
> I'm not sure I understand how you would like me to use it. I know that,
> if we ask nicely, MakeMaker and Module::Build will change the shebang
> of scripts that are to be installed to the local location of perl, but
> typically things that are not to be installed are left alone.
In which case I wonder why this change was needed in the first place
> Do you propose that the example directory get munged as part of the
> 'perl Makefile.PL' stage?
No, only if these examples are installed as option from Makefile.PL
(many modules allow that)
> Or do you know of a static shebang that goes straight for
> $Config{startperl} ?
No. Maybe #!your_path_to_perl_here
would be the best option :)
Maybe I sounded too harsh in my previous mail, but in the end, that
ticket should just have been marked "rejected" with exactly the
explanation you just wrote here. If it does not install those scripts
from examples, *ANY* shebang line is valid
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.39_00 is out
On 02/27/12 02:02, H.Merijn Brand wrote:
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
wrote:
>[OTHERS]
>- change the shebang line of examples to the more modern '/usr/bin/env
> perl'
Personally I really really hate this change
Fair enough. This being said, I have to point out that the change
is only on the scripts in the 'examples/' directory, which are not
installed as part of the distro.
Perl has been configured to use $Config{startperl}. Use it!
I'm not sure I understand how you would like me to use it. I know
that, if we ask nicely, MakeMaker and Module::Build will change the shebang of
scripts that are to be installed to the local location of perl, but typically
things that are not to be installed are left alone. Do you propose that the
example directory get munged as part of the 'perl Makefile.PL' stage? Or do you
know of a static shebang that goes straight for $Config{startperl} ?
Joy,
`/anick
--
Yanick Champoux, Senior Perl Developer
The Pythian Group - love your data
http://www.pythian.com
--
--
Pythian proud winner of Oracle North America Titan Award for Exadata
Solution...watch the video on pythian.com
Re: DBD::Oracle v1.39_00 is out
On Fri, 24 Feb 2012 16:50:37 -0500, Yanick Champoux
wrote:
> [OTHERS]
> - change the shebang line of examples to the more modern '/usr/bin/env
> perl'
> [RT74001]
Personally I really really hate this change
App::Ack was the first I noted to make this horrid change and I always
revert the shebang line to reflect my production perl
I (very) often work on "other" perls than the one that is installed and
to make testing these with modules (like DBI, DBD::Oracle and many many
more, I temporary change my $PATH to have the perl I am testing first
In that perl, App::Ack is NOT (yet) installed.
For some/many scripts, it doesn't really matter if the script is
installed or not, but for all scripts that invoke modules it *does*
matter.
I certainly do NOT see this change as "more modern"
Perl has been configured to use $Config{startperl}. Use it!
$ perl -V:startperl
startperl='#!/pro/bin/perl';
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle v1.39_00 is out
A new DBD::Oracle trial version is out and on its way to CPAN. It's a maintenance release with fairly minor bug fixes (full changelog below). As usual, the trial version will be soaked for 2 weeks and, pending issues, will be promoted to v1.40 for general consumption. Joy, `/anick 1.39_00 2012-02-24 [BUG FIXES] - TAF supports now conditional to presence of OCI_ATTR_TAF_ENABLED [RT73798] - detect broken Win32::TieRegistry (patch by Rafael Kitover (Caelum)) [RT74544] - PL/SQL out values were not utf8 encoded [RT74753] (Steve Baldwin + Martin J. Evans) [DOCUMENTATION] - Mention the release of Oracle Instant Client 64 bit which does not work on Lion. (Martin J. Evans) - fix DBD::Oracle::GetInfo blurb (patch by Julián Moreno Patiño) [rt74000] - fix typos. (patch by Julián Moreno Patiño) [rt73999] - add troubleshoot doc and diag for error with bequeather. [rt75263] [OTHERS] - change the shebang line of examples to the more modern '/usr/bin/env perl' [RT74001] -- -- Pythian proud winner of Oracle North America Titan Award for Exadata Solution...watch the video on pythian.com
Re: DBD::Oracle
Yanick Champoux wrote: > And just to keep things interesting, I've noticed that I forgot the > ending semi-colon that is in the test. But surely that won't-- > > $ perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 > > --make a difference... Ah, I can explain what's going on there. If you give Perl `system` a single argument, it looks at the contents of that string, and decides whether it's a "trivial" command. Trivial commands in this sense are, roughly, those that contain no awkward punctuation characters — which would imply that the command needs to be executed by a shell. If Perl thinks no shell is needed, it optimises by executing the command directly, saving a shell process. Otherwise, it passes the command to the appropriate shell as desired. In this case, if you do `system "exit 1;"`, the semicolon forces `system` to pass the command to a shell, and everything works as expected. On the other hand, `system "exit 1"` with no semicolon is executed directly. But there's no command named `exit` — it's a shell builtin (and has to be). So `system` is giving you the behaviour you get in the "command not found" case, namely a negative return value. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: DBD::Oracle
On Fri, Feb 10, 2012 at 07:03:09PM +0100, H.Merijn Brand wrote: > On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine > wrote: > > > >> If this reproduces the problem, you have something nothing to do > > >> with databases to investigate. If it doesn't reproduce the problem, > > >> it may be that Oracle is messing with the SIGCHLD signal. > > >> > > >> Are you connecting directly to the database using the bequeather? > > > > > > I've never heard of anything called a "bequeather" :) > > > > If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. > > This is the bequeather, which is the adapter used to connect to > > a local database when ORACLE_HOME and ORACLE_SID are specified > > and TWO_TASK is not. The BEQ adapter is inconsistent with the > > with perl built-ins which use fork or popen unless you put > > 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this > > sqlnet.ora option is not the default. > > All tests then pass I'm sure a patch to the docs, expressing the above, would be welcome. Tim.
Re: DBD::Oracle
On Fri, 10 Feb 2012 17:28:11 +, Charles Jardine wrote: > >> If this reproduces the problem, you have something nothing to do > >> with databases to investigate. If it doesn't reproduce the problem, > >> it may be that Oracle is messing with the SIGCHLD signal. > >> > >> Are you connecting directly to the database using the bequeather? > > > > I've never heard of anything called a "bequeather" :) > > If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'. > This is the bequeather, which is the adapter used to connect to > a local database when ORACLE_HOME and ORACLE_SID are specified > and TWO_TASK is not. The BEQ adapter is inconsistent with the > with perl built-ins which use fork or popen unless you put > 'bequeath_detach = yes' in sqlnet.ora. It is a pity that this > sqlnet.ora option is not the default. All tests then pass -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On 10/02/12 14:56, H.Merijn Brand wrote:
> On Fri, 10 Feb 2012 14:30:03 +, Charles Jardine
> wrote:
>
>> On 10/02/12 13:32, H.Merijn Brand wrote:
>>> Preparing a new database machine ...
>>>
>>> Do I need to worry?
>>> t/10general.t 1/30
>>> # Failed test 'system exit 1 should return 256'
>>> # at t/10general.t line 41.
>>> # got: '-1'
>>> # expected: '256'
>>>
>>> # Failed test 'system exit 0 should return 0'
>>> # at t/10general.t line 42.
>>> # got: '-1'
>>> # expected: '0'
>>> t/10general.t 3/30 # Looks like you failed 2 tests of 30.
>>> t/10general.t Dubious, test returned 2 (wstat 512, 0x200)
>>
>> This symptom indicates that the system built-in function is not working.
>>
>> Try
>>
>> perl -e 'print system("exit 1;"), "\n"'
>
> $ perl -e 'print system("exit 1;"), "\n"'
> 256
>
>> If this reproduces the problem, you have something nothing to do
>> with databases to investigate. If it doesn't reproduce the problem,
>> it may be that Oracle is messing with the SIGCHLD signal.
>>
>> Are you connecting directly to the database using the bequeather?
>
> I've never heard of anything called a "bequeather" :)
If you call $ORACLE_HOME/bin/adapters, the list will include 'BEQ'.
This is the bequeather, which is the adapter used to connect to
a local database when ORACLE_HOME and ORACLE_SID are specified
and TWO_TASK is not. The BEQ adapter is inconsistent with the
with perl built-ins which use fork or popen unless you put
'bequeath_detach = yes' in sqlnet.ora. It is a pity that this
sqlnet.ora option is not the default.
>> If so, try connecting via SQL*Net instead. If avoiding the bequeather
>> fixes the problem, try putting 'bequeath_detach = yes' in your
>> sqlnet.ora file. This should allow you to use the bequeather and
>> system at the same time.
>
> above test was without TWO_TASK. Using the listener, I get
>
> All tests successful.
> Files=35, Tests=2008, 31 wallclock secs ( 0.40 usr 0.04 sys + 3.69 cusr
> 1.28 csys = 5.41 CPU)
> Result: PASS
> PERL_DL_NONLAZY=1 /pro/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
>
>
--
Charles Jardine - Computing Service, University of Cambridge
c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: DBD::Oracle
On Fri, Feb 10, 2012 at 04:29:07PM +0100, H.Merijn Brand wrote: > On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux > wrote: > > > On 02/10/12 09:56, Yanick Champoux wrote: > > > which should be okay, but I'm suddenly thinking: on some shells > > > 'exit' might not do what we would expect. Indeed, I just tried: > > > > > > $ perl -E'say system "exit 1"' > > > -1 > > > > And just to keep things interesting, I've noticed that I forgot the > > ending semi-colon that is in the test. But surely that won't-- > > > > $ perl -E'say system "exit 1"; say system "exit 1;"' > > -1 > > 256 > > % perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 > > > --make a difference... Uuuh, okay, I need to brush up my shell > > syntax skills. And should probably look into making that test slightly > > less shell-dependent. perldoc -f system says If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system’s command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. Note that it's always /bin/sh on unix systems (it does't use SHELL env var). Tim.
Re: DBD::Oracle
On Fri, 10 Feb 2012 10:22:20 -0500, Yanick Champoux wrote: > On 02/10/12 09:56, Yanick Champoux wrote: > > which should be okay, but I'm suddenly thinking: on some shells > > 'exit' might not do what we would expect. Indeed, I just tried: > > > > $ perl -E'say system "exit 1"' > > -1 > > And just to keep things interesting, I've noticed that I forgot the > ending semi-colon that is in the test. But surely that won't-- > > $ perl -E'say system "exit 1"; say system "exit 1;"' > -1 > 256 % perl -E'say system "exit 1"; say system "exit 1;"' -1 256 > --make a difference... Uuuh, okay, I need to brush up my shell > syntax skills. And should probably look into making that test slightly > less shell-dependent. > > Joy, > `/anick -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::Oracle
On 02/10/12 09:56, Yanick Champoux wrote: which should be okay, but I'm suddenly thinking: on some shells 'exit' might not do what we would expect. Indeed, I just tried: $ perl -E'say system "exit 1"' -1 And just to keep things interesting, I've noticed that I forgot the ending semi-colon that is in the test. But surely that won't-- $ perl -E'say system "exit 1"; say system "exit 1;"' -1 256 --make a difference... Uuuh, okay, I need to brush up my shell syntax skills. And should probably look into making that test slightly less shell-dependent. Joy, `/anick
