diff --git a/err_bind/err_bind_param_inout_overrun_bug.msg b/err_bind/err_bind_param_inout_overrun_bug.msg new file mode 100644 index 00000000..83d9001f --- /dev/null +++ b/err_bind/err_bind_param_inout_overrun_bug.msg @@ -0,0 +1,108 @@ +From dbi-users-return-215-Tim.Bunce=ig.co.uk@perl.org Mon Feb 5 23:03:29 2001 +Return-Path: +Received: from oink by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id XAA01289; Mon, 5 Feb 2001 23:03:27 GMT +Received: from tele-punt-22.mail.demon.net by oink with SMTP (PP) + id <06769-16@oink>; Fri, 6 Feb 1970 00:01:15 +0100 +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 981413584:20:24069:0; Mon, 05 Feb 2001 22:53:04 GMT +Received: from tmtowtdi.perl.org ([209.85.3.25]) by punt-2.mail.demon.net + id aa2024004; 5 Feb 2001 22:53 GMT +Received: (qmail 6267 invoked by uid 508); 5 Feb 2001 22:52:23 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 6247 invoked from network); 5 Feb 2001 22:52:22 -0000 +Received: from seeme.dare.feddata.com (38.186.101.66) by tmtowtdi.perl.org + with SMTP; 5 Feb 2001 22:52:22 -0000 +Received: by seeme.dare.feddata.com; id OAA05466; + Mon, 5 Feb 2001 14:55:56 -0800 (PST) +Received: from ifyou.dare.feddata.com(38.186.101.111) by seeme.dare.feddata.com + via smap (4.1) id xma005448; Mon, 5 Feb 01 14:55:39 -0800 +Sender: oscar@dare.feddata.com +Message-ID: <3A7F2FB0.A1507582@pasadena.feddata.com> +Date: Mon, 05 Feb 2001 14:56:48 -0800 +From: Oscar DeMartino +Organization: Federal Data Corporation +X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) +X-Accept-Language: en +MIME-Version: 1.0 +To: dbi-users@perl.org +Subject: Undetected error - Binding and Stored Procedures +Content-Type: multipart/alternative; + boundary="------------E1028F7A8304BE268EB8F67B" +Status: RO +Content-Length: 2042 +Lines: 66 + +--------------E1028F7A8304BE268EB8F67B +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit + +I am running Oracle 8.1.5 and am using many stored procedures. We +use returned cursors, and individual values. The problem is, when +a stored procedure is executed and the specified bound variable has not +be declared large enough to hold the returned value subsequent +bound variables do not get set and I cannot find any way to +automatically detect this. + +Example: + +The stored procedure takes 1-input value and returns three string +values. + +the stored procedure is prepared , so I get the statement handle. + +I bind the input variable, and then bind the three output variables (1, +2, & 3) +as 100 character strings. + +I then execute the statment handle. + +There do not appear to be any errors, after checking the returned value +(for the execute call), +and ->err and ->errstr are clean. + +variable 1 has the correct returned value. +BUT, output variable 2 & 3, have no value. + +------ +Executing the stored procedure using sqlplus (sql command line +interface) indicated: + +What really occured is that the returned output variables 1 & 3 were +under 100 characters long +output variable 2 was 120 characters long + +--------- + +I know I could make all output variables the max size allowed in the +database field +but this would seem to waste space in the perl code. Since the field in + +the database +is simply defined as a varchar2 with no size limitation (upto 32767). + +----- +Am I missing something about detecting that variables 2 & 3 did not get +stored correctly +by DBI::Oracle?? + + + +-- +Oscar "Fred" DeMartino FFFFF DDDD CCC +320 N. Halstead Ave. Ste #160 F D D C C +Pasadena, CA 91107 FFF D D C +e-mail: Oscar.DeMartino@pasadena.feddata.com F D D C +Phone: (626)306-6649 F D D C C +Federal Data Corporation F DDDD CCC + + + +--------------E1028F7A8304BE268EB8F67B-- + diff --git a/err_bind/err_bindarrays.msg b/err_bind/err_bindarrays.msg new file mode 100644 index 00000000..8ca7a5d3 --- /dev/null +++ b/err_bind/err_bindarrays.msg @@ -0,0 +1,241 @@ +From cturner@redhat.com Tue Mar 27 06:01:56 2001 +Return-Path: +Received: from oink by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id GAA19714; Tue, 27 Mar 2001 06:01:56 +0100 (BST) +Received: from 194.217.242.7 by oink with SMTP (PP) id <13771-3@oink>; + Fri, 27 Mar 1970 06:00:50 +0100 +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 985668014:20:27605:3; Tue, 27 Mar 2001 04:40:14 GMT +Received: from host154.207-175-42.redhat.com ([207.175.42.154]) + by punt-2.mail.demon.net id ab2125244; 27 Mar 2001 4:39 GMT +Received: from japh.meridian.redhat.com (IDENT:root@japh.meridian.redhat.com [207.175.42.27]) + by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id XAA32289 + for ; Mon, 26 Mar 2001 23:39:38 -0500 +Received: (from cturner@localhost) by japh.meridian.redhat.com (8.11.0/8.11.0) + id f2R4bvT12929; Mon, 26 Mar 2001 23:37:57 -0500 +Sender: cturner@redhat.com +To: Tim.Bunce@ig.co.uk +Subject: DBD::Oracle and OCI bound arrays +From: Chip Turner +Date: 26 Mar 2001 23:37:57 -0500 +Message-ID: +User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Status: A +Content-Length: 980 +Lines: 29 + + +Hey Tim, + +The need to have true OCI bound arrays for DBD::Oracle has come up, +and it looks like I get the fun job of implementing them. Basically, +this will allow DBD::Oracle to do something the DCOracle python +library does. The idea is: + +my $sth = $dbh->prepare("INSERT INTO FooBar (c1, c2) VALUES (?, ?)"); +my @c1 = 'aa' .. 'zz'; +my @c2 = 'aaa' .. 'azz'; +$sth->execute(\@c1, \@c2); + +In other words, it populates the table with a single execute call, +passing two (or more) equally sized arrays in as references for bound +parameters. This has the potential to save a good amount of time, +especially for large datasets. + +This would pretty much be a proprietary extension for Oracle, though +similar uses could be done in other DBD's. + +Just thought I'd let you know what I was intending to do, and to see +if you had any interest in receiving it as a patch after I'm done. + +Chip + +-- +Chip Turner cturner@redhat.com + RHN Web Engineer + +From timbo Tue Mar 27 09:29:48 2001 +Return-Path: +Received: by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id JAA20809; Tue, 27 Mar 2001 09:29:42 +0100 (BST) +Date: Tue, 27 Mar 2001 09:29:41 +0100 +From: Tim Bunce +To: Chip Turner +Cc: Tim.Bunce@ig.co.uk, dbi-dev@perl.org +Subject: Re: DBD::Oracle and OCI bound arrays +Message-ID: <20010327092941.D20616@ig.co.uk> +References: +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Mailer: Mutt 0.95.3i +In-Reply-To: ; from Chip Turner on Mon, Mar 26, 2001 at 11:37:57PM -0500 +Content-Length: 1570 +Lines: 39 + +On Mon, Mar 26, 2001 at 11:37:57PM -0500, Chip Turner wrote: +> +> Hey Tim, +> +> The need to have true OCI bound arrays for DBD::Oracle has come up, +> and it looks like I get the fun job of implementing them. Basically, +> this will allow DBD::Oracle to do something the DCOracle python +> library does. The idea is: +> +> my $sth = $dbh->prepare("INSERT INTO FooBar (c1, c2) VALUES (?, ?)"); +> my @c1 = 'aa' .. 'zz'; +> my @c2 = 'aaa' .. 'azz'; +> $sth->execute(\@c1, \@c2); +> +> In other words, it populates the table with a single execute call, +> passing two (or more) equally sized arrays in as references for bound +> parameters. This has the potential to save a good amount of time, +> especially for large datasets. +> +> This would pretty much be a proprietary extension for Oracle, though +> similar uses could be done in other DBD's. +> +> Just thought I'd let you know what I was intending to do, and to see +> if you had any interest in receiving it as a patch after I'm done. + +I would *urge* you to discuss the implementation with me *before* +you get very far cutting code. + +And anyway, I think someone's already done much or all of the work. +Dig around in the dbi-dev archives. If you can't find the discussion +let me know. If you do, then ask them (via the dbi-dev list) what +the status is. + +I'm planning to make a DBI release next week and, hopefully, a +DBD::Oracle release the week after to cleare a backlog of patches I +have queued up. After that I'll be looking to add in the work of the +other guy (whose also implemented it for DBD::DB2 and DBD::ODBC). + +Tim. + +From cturner@redhat.com Wed Mar 28 02:01:21 2001 +Return-Path: +Received: from oink by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id CAA27336; Wed, 28 Mar 2001 02:01:21 +0100 (BST) +Received: from 194.217.242.7 by oink with SMTP (PP) id <17151-9@oink>; + Sat, 28 Mar 1970 01:59:47 +0100 +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 985739868:20:27318:0; Wed, 28 Mar 2001 00:37:48 GMT +Received: from host154.207-175-42.redhat.com ([207.175.42.154]) + by punt-2.mail.demon.net id ac2119835; 28 Mar 2001 0:37 GMT +Received: from japh.meridian.redhat.com (IDENT:root@japh.meridian.redhat.com [207.175.42.27]) + by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id TAA10445 + for ; Tue, 27 Mar 2001 19:37:35 -0500 +Received: (from cturner@localhost) by japh.meridian.redhat.com (8.11.0/8.11.0) + id f2S0ZoJ20115; Tue, 27 Mar 2001 19:35:50 -0500 +Sender: cturner@redhat.com +To: Tim Bunce +Subject: Re: DBD::Oracle and OCI bound arrays +References: <20010327092941.D20616@ig.co.uk> +From: Chip Turner +Date: 27 Mar 2001 19:35:50 -0500 +In-Reply-To: <20010327092941.D20616@ig.co.uk> +Message-ID: +User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Status: A +Content-Length: 1495 +Lines: 35 + +Tim Bunce writes: + +> I would *urge* you to discuss the implementation with me *before* +> you get very far cutting code. + +Unfortunately, it's a little late for this; I've mostly finished the +change (at least, enough for our needs), except for some review and +cleanups. It seems to work quite well (400 times faster than repeated +looping over a dataset) and passes all of DBD::Oracle's test suite. + +> And anyway, I think someone's already done much or all of the work. +> Dig around in the dbi-dev archives. If you can't find the discussion +> let me know. If you do, then ask them (via the dbi-dev list) what +> the status is. + +I checked as you suggest, but couldn't find any code, just discussion +of it. I'll check again, but it didn't seem that the person had put +it anywhere I could get at it. + +> I'm planning to make a DBI release next week and, hopefully, a +> DBD::Oracle release the week after to cleare a backlog of patches I +> have queued up. After that I'll be looking to add in the work of the +> other guy (whose also implemented it for DBD::DB2 and DBD::ODBC). + +If you would like, the patch will probably be suitable for inclusion +by then, if you want it in by the next release. Should there be any +problems with it or its implementation, I'd be glad to clean it up if +you have interest in it (if not, that's cool too; we need it soon, +though, either way). + +Chip + +-- +Chip Turner cturner@redhat.com + RHN Web Engineer + +From timbo Wed Mar 28 11:51:58 2001 +Return-Path: +Received: by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id LAA00444; Wed, 28 Mar 2001 11:51:51 +0100 (BST) +Date: Wed, 28 Mar 2001 11:51:51 +0100 +From: Tim Bunce +To: Chip Turner +Cc: Tim Bunce +Subject: Re: DBD::Oracle and OCI bound arrays +Message-ID: <20010328115151.D29769@ig.co.uk> +References: <20010327092941.D20616@ig.co.uk> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Mailer: Mutt 0.95.3i +In-Reply-To: ; from Chip Turner on Tue, Mar 27, 2001 at 07:35:50PM -0500 +Content-Length: 1786 +Lines: 40 + +On Tue, Mar 27, 2001 at 07:35:50PM -0500, Chip Turner wrote: +> Tim Bunce writes: +> +> > I would *urge* you to discuss the implementation with me *before* +> > you get very far cutting code. +> +> Unfortunately, it's a little late for this; I've mostly finished the +> change (at least, enough for our needs), except for some review and +> cleanups. It seems to work quite well (400 times faster than repeated +> looping over a dataset) and passes all of DBD::Oracle's test suite. + +I trust you've added some more tests for your new functionality! + +> > And anyway, I think someone's already done much or all of the work. +> > Dig around in the dbi-dev archives. If you can't find the discussion +> > let me know. If you do, then ask them (via the dbi-dev list) what +> > the status is. +> +> I checked as you suggest, but couldn't find any code, just discussion +> of it. I'll check again, but it didn't seem that the person had put +> it anywhere I could get at it. + +You could always ask them (CC me). + +> > I'm planning to make a DBI release next week and, hopefully, a +> > DBD::Oracle release the week after to cleare a backlog of patches I +> > have queued up. After that I'll be looking to add in the work of the +> > other guy (whose also implemented it for DBD::DB2 and DBD::ODBC). +> +> If you would like, the patch will probably be suitable for inclusion +> by then, if you want it in by the next release. Should there be any +> problems with it or its implementation, I'd be glad to clean it up if +> you have interest in it (if not, that's cool too; we need it soon, +> though, either way). + +Thanks for the clean-up offer. Send it to me after I make the next +DBD::Oracle release (as a fresh patch over that version please - but +there shouldn't be too many changes). + +Tim. + diff --git a/err_bind/err_bindclobleak.msg b/err_bind/err_bindclobleak.msg new file mode 100644 index 00000000..1a31c760 --- /dev/null +++ b/err_bind/err_bindclobleak.msg @@ -0,0 +1,58 @@ +From PGWeiss@arity.com Thu Mar 9 09:51:45 2000 +Return-Path: +Received: from oink by toad.ig.co.uk (SMI-8.6/SMI-SVR4) + id JAA14948; Thu, 9 Mar 2000 09:51:43 GMT +Received: from tele-punt-22.mail.demon.net by oink with SMTP (PP) + id <27566-0@oink>; Mon, 9 Mar 1970 10:51:10 +0100 +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 952595299:20:10439:68; Thu, 09 Mar 2000 09:48:19 GMT +Received: from image.arity.com ([140.239.104.130]) by punt-2.mail.demon.net + id aa2010598; 9 Mar 2000 9:47 GMT +Received: by image.arity.com with Internet Mail Service (5.5.2650.21) + id ; Thu, 9 Mar 2000 04:51:44 -0500 +Message-ID: +From: "Paul G. Weiss" +To: Perl-Win32-Database Mailing List , + "'Tim Bunce'" +Subject: Another CLOB related DBD::Oracle bug +Date: Thu, 9 Mar 2000 04:51:41 -0500 +MIME-Version: 1.0 +X-Mailer: Internet Mail Service (5.5.2650.21) +Content-Type: text/plain; charset="iso-8859-1" +Status: RO +Content-Length: 689 +Lines: 32 + +Binding a parameter to type ORA_CLOB causes a leak. +Consider: + +for (1..10000) +{ + for (1..100) + { + my $sth = $db->prepare('update item set descr = ? where id = ?'); + if ($leak) + { + $sth->bind_param(1, $descr, {ora_type => ORA_CLOB, +ora_field=>'DESCR'}); + $sth->bind_param(2, 12); + $sth->execute; + } + else + { + $sth->execute($descr,12); + } + } + sleep 1; +} + + +With $leak set to 1, i.e. binding the parameters explicitly the +program leaks. With $leak set to 0 it does not (but then I can't +set descr to anything greater than 4K nor can I set it to the +empty string). + +Is there a patch? + +-P + diff --git a/err_bind/err_bindnullhash.msg b/err_bind/err_bindnullhash.msg new file mode 100644 index 00000000..d9a98b9a --- /dev/null +++ b/err_bind/err_bindnullhash.msg @@ -0,0 +1,77 @@ +From dbi-users-return-12580-Tim.Bunce=pobox.com@perl.org Thu Jul 11 17:49:35 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g6BGnYH11008 + for ; Thu, 11 Jul 2002 17:49:34 +0100 (BST) + (envelope-from dbi-users-return-12580-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.59] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 11 Jul 2002 17:49:34 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1026401921:10:09249:41; Thu, 11 Jul 2002 15:38:41 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1124337; 11 Jul 2002 15:38 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id B567C2BF65 + for ; Thu, 11 Jul 2002 11:38:05 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [64.70.54.95]) + by dolly1.pobox.com (Postfix) with SMTP id 347792BF62 + for ; Thu, 11 Jul 2002 11:38:05 -0400 (EDT) +Received: (qmail 95914 invoked by uid 1005); 11 Jul 2002 15:38:04 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 95896 invoked by uid 76); 11 Jul 2002 15:38:04 -0000 +Received: from ironmail1.cc.lehigh.edu (HELO ironmail1.cc.lehigh.edu) (128.180.39.26) + by onion.perl.org (qpsmtpd/0.07b) with SMTP; Thu Jul 11 15:38:04 2002 -0000 +Received: from ([128.180.39.20]) + by ironmail1.cc.lehigh.edu with ESMTP with TLS; + Thu, 11 Jul 2002 11:35:06 -0400 (EDT) +Received: from lawrencework (pc-lfn0.dept.Lehigh.EDU [128.180.52.51]) + by rain.CC.Lehigh.EDU (8.12.4/8.12.4) with SMTP id g6BFZ6rr022463 + for ; Thu, 11 Jul 2002 11:35:06 -0400 +Message-ID: <0a0401c228f0$93feda10$3334b480@lawrencework> +From: "Phil R Lawrence" +To: +References: <083b01c22824$70357340$3334b480@lawrencework> <20020711140937.A568@dansat.data-plan.com> +Subject: Re: error msg suggestion +Date: Thu, 11 Jul 2002 11:35:20 -0400 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 6.00.2600.0000 +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 +Status: RO +X-Status: A +Content-Length: 636 +Lines: 21 + +Tim Bunce wrote: +> Binding an undef should work and be treated as a NULL. +> +> Probably a bug in your code or the driver. But you didn't +> say which driver. + +Hmmm. quite right, undefs do bind as NULL. However, in this case I am +binding $hash{non-existent-key}, which autoinstantiates to an undef, and looks +like this in the trace: + undef (magic-sg:y) + +Of course it was my dumb fault for having the wrong key for lookup, but +nonetheless, perhaps this should work the same as a normal undef. + +# $DBI::VERSION = "1.14"; +# $DBD::ODBC::VERSION = '0.28'; +$DSN = 'driver=Microsoft Access Driver (*.mdb);dbq=StudyManager.mdb'; + +Thanks, +Phil + + diff --git a/err_bind/err_trailingblank.msg b/err_bind/err_trailingblank.msg new file mode 100644 index 00000000..cdf34a32 --- /dev/null +++ b/err_bind/err_trailingblank.msg @@ -0,0 +1,345 @@ +From dbi-users-bounce@isc.org Mon May 1 21:12:02 2000 +Return-Path: +Received: from oink by toad.ig.co.uk (SMI-8.6/SMI-SVR4) + id VAA16051; Mon, 1 May 2000 21:12:00 +0100 +Received: from finch-punt-12.mail.demon.net by oink with SMTP (PP) + id <14295-42@oink>; Fri, 1 May 1970 21:06:08 +0100 +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 957208278:10:19133:4; Mon, 01 May 2000 19:11:18 GMT +Received: from pub3.rc.vix.com ([204.152.186.34]) by punt-1.mail.demon.net + id aa1123094; 1 May 2000 19:11 GMT +Received: from pub3.rc.vix.com (pub3.rc.vix.com [204.152.186.34]) + by pub3.rc.vix.com (Postfix) with ESMTP id B3CCF3FAA; + Mon, 1 May 2000 12:10:53 -0700 (PDT) +Received: with LISTAR (v0.129a; list dbi-users); + Mon, 01 May 2000 12:05:42 -0700 (PDT) +Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.87]) + by pub3.rc.vix.com (Postfix) with ESMTP id A70763E34 + for ; Mon, 1 May 2000 12:05:30 -0700 (PDT) +Received: from scotth.emsphone.com (scotth.emsphone.com [199.67.51.179]) + by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id MAA25897 + for ; + Mon, 1 May 2000 12:05:30 -0700 (PDT) env-from (shildret@scotth.emsphone.com) +Received: (from shildret@localhost) by scotth.emsphone.com (8.9.3/8.9.3) + id OAA50011 for dbi-users@isc.org; + Mon, 1 May 2000 14:05:48 -0500 (CDT) (envelope-from shildret) +Message-ID: +X-Mailer: XFMail 1.4.0 on FreeBSD +X-Priority: 3 (Normal) +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 8bit +MIME-Version: 1.0 +Resent-Date: Thu, 29 Jul 1999 22:07:08 +0100 +Resent-Message-Id: <19990729220708.G17723@ig.co.uk> +Resent-From: Tim Bunce +Resent-To: Tim Bunce +Date: Mon, 01 May 2000 14:05:48 -0500 (CDT) +Sender: shildret@scotth.emsphone.com +From: "Scott T. Hildreth" +To: "dbi-users@isc.org" +Subject: FW: Oracle & Trailing Blanks - possible change in DBD::Oracle +Resent-Sender: shildret@scotth.emsphone.com +Sender: dbi-users-bounce@isc.org +Errors-To: dbi-users-bounce@isc.org +X-original-sender: Tim.Bunce@ig.co.uk +Precedence: bulk +List-unsubscribe: +X-List-ID: +List-owner: +List-post: +Status: RO +Content-Length: 3885 +Lines: 94 + + +Here is the help, I got regarding the trailing spaces. + +-----FW: <19990729220708.G17723@ig.co.uk>----- + +Date: Thu, 29 Jul 1999 22:07:08 +0100 +From: Tim Bunce +To: Tim Bunce +Subject: Oracle & Trailing Blanks - possible change in DBD::Oracle +Cc: "Scott T. HIldreth" , + dbi-users@isc.org + + *** From dbi-users -- To unsubscribe, see the end of this message. *** + +On Thu, Jul 29, 1999 at 09:49:38PM +0100, Tim Bunce wrote: +> *** From dbi-users -- To unsubscribe, see the end of this message. *** +> +> On Thu, Jul 29, 1999 at 09:33:55AM -0500, Scott T. HIldreth wrote: +> > +> > Hi all, I wonder if someone can let me know if I got this right. +> > I have a key to match which can contain trailing blanks. The +> > field in the database is CHAR(18). If I match the key with +> > sqlplus, Oracle finds a match, with or without the trailing +> > blank. When I do an sth->execute( $key ), the key is not +> > found. I abstract the key with substr, so the trailing blank +> > is in the key, but no match is found. Do I need to place qoutes +> > around the value in $key? +> +> Somewhat hiddedn in the Oraperl.pm docs it says this: +> +> --- +> B Substitution variables are now bound as type 1 (VARCHAR2) +> and not type 5 (STRING) by default. This can alter the behaviour of +> SQL code which compares a char field with a substitution variable. +> See the String Comparison section in the Datatypes chapter of the +> Oracle OCI manual for more details. +> +> You can work around this by using DBD::Oracle's ability to specify +> the Oracle type to be used on a per field basis: +> +> $char_attrib = { ora_type => 5 }; # 5 = STRING (ala oraperl2.4) +> $csr = ora_open($dbh, "select foo from bar where x=:1 and y=:2"); +> $csr->bind_param(1, $value_x, $char_attrib); +> $csr->bind_param(2, $value_y, $char_attrib); +> ora_bind($csr); # bind with no parameters since we've done bind_param()'s +> --- +> +> Ignoring the Oraperl specifics there the key point is to use +> +> $csr->bind_param($idx, $value, { ora_type => 5 }); +> +> I'll add something to the DBD::Oracle docs. + +[You'll still need to blank-pad the string.] + +Looking at this issue again I've discovered that the key issue is that +type 1 strips trailing blanks whilst type 5 doesn't. + +I'rather m concerned by this. Since I'm against the DBI changing the +data in any way on principle and since Oraperl used to use type 5 +I'm strongly considering changing DBD::Oracle 'back' to using type 5. + +This would only affect anyone who relies on placeholders having +trailing blanks stripped off. (I'll provide a way to alter the +default with a single statement and/or env var for anyone affected). + +If that's you - speak up now! + +Tim. + +------------------------------------------------------------------------------ +To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html +If you are without web access, or if you are having trouble with the web page, +please send mail to dbi-users-request@isc.org with the subject line of +'unsubscribe'. +------------------------------------------------------------------------------ + + +--------------End of forwarded message------------------------- + +---------------------------------- +E-Mail: Scott T. Hildreth +Date: 01-May-00 +Time: 14:04:41 +---------------------------------- + + +------------------------------------------------------------------------------ +DBI HOME PAGE AND ARCHIVES: http://www.symbolstone.org/technology/perl/DBI/ +To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html +If you are without web access, or if you are having trouble with the web page, +please send mail to dbi-users-request@isc.org with the subject line of: +'unsubscribe'. +------------------------------------------------------------------------------ + +From joshua.horton@mail.tju.edu Fri May 23 07:43:09 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.6/8.12.6) with ESMTP id h4N6UY7T061880 + for ; Fri, 23 May 2003 07:43:09 +0100 (BST) + (envelope-from joshua.horton@mail.tju.edu) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 23 May 2003 07:43:09 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1053631164:10:02298:54; Thu, 22 May 2003 19:19:24 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1116141; 22 May 2003 19:19 GMT +Received: from dolly1.pobox.com (localhost [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id BD31E21C13C + for ; Thu, 22 May 2003 15:18:30 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail.tju.edu (fw-tr16.tju.edu [147.140.233.16]) + by dolly1.pobox.com (Postfix) with ESMTP id 615A521C06D + for ; Thu, 22 May 2003 15:18:22 -0400 (EDT) +Received: from PCSE447.tjh.tju.edu by mail.tju.edu for Tim.Bunce@pobox.com; Thu, 22 May 2003 15:17:54 -0400 +Message-Id: <031301c32096$de68f6f0$2310ae0a@PCSE447> +From: "Joshua Horton" +To: +Subject: Re: :Oracle and Oracle 9.2? +Date: Thu, 22 May 2003 15:18:03 -0400 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 5.50.4807.1700 +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 3511 +Lines: 99 + +Re: :Oracle and Oracle 9.2? + +---------------------------------------------------------------------------- +---- + + a.. From: Tim Bunce + b.. Subject: Re: :Oracle and Oracle 9.2? + c.. Date: Tue, 15 Apr 2003 07:36:55 -0700 + +---------------------------------------------------------------------------- +---- + +I'd appreciate it if other people with Oracle 9.2.x could let me +know if it passed or failed for them and what their exact oracle +version (four digits) and platform (operating system) is. + +Thanks. + +Tim. + +On Fri, Apr 04, 2003 at 01:48:36PM +0200, Smejkal Petr wrote: +> I have the same experience on Linux however on Windows all tests passes +(I'm not +> sure if it is related to different Oracle version - test of windows Perl +against +> Linux Oracle is OK). +> +> Linux Oracle: 9.2.0.2 +> Windows Oracle: 9.2.0.1 +> DBI: 1.35 +> DBD::Oracle: 1.14 +> +> -- Petr Smejkal +> -- Business Systems Analyst / Country IT Cz/Sk +> -- +420 284 059 639 +> +> > -----Original Message----- +> > From: Tom Malaher [mailto:[EMAIL PROTECTED] +> > Sent: Friday, April 04, 2003 1:35 AM +> > To: [EMAIL PROTECTED] +> > Subject: DBD::Oracle and Oracle 9.2? +> > +> > +> > My sysadmin is trying to install DBD::Oracle on a Solaris box running +> > Oracle 9.2. +> > +> > The ph_type.t test is failing with +> > +> > PERL_DL_NONLAZY=1 ./perl "-MExtUtils::Command::MM" "-e" +> > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t +> > t/base.......ok +> > t/cursor.....ok +> > t/general....ok +> > t/long.......ok +> > t/meta.......ok +> > t/ph_type....NOK 12 expected 'trailing' but got 'trailing ' +> > for VARCHAR2 +> > t/ph_type....FAILED test 12 +> > Failed 1/19 tests, 94.74% okay +> > t/plsql......ok +> > t/reauth.....skipped +> > all skipped: no reason given +> > t/select.....ok +> > Failed Test Stat Wstat Total Fail Failed List of Failed +> > -------------------------------------------------------------- +> > ----------------- +> > t/ph_type.t 19 1 5.26% 12 +> > 1 test skipped. +> > Failed 1/9 test scripts, 88.89% okay. 1/314 subtests failed, +> > 99.68% okay. +> > *** Error code 29 +> > make: Fatal error: Command failed for target `test_static' +> > +> > Is there a known problem with DBD::Oracle and Oracle 9.x? +> > Has Oracle changed the behavior of trailing spaces in VARCHAR2 fields? +> > +> > I've run the same test script on an oracle 8 installation +> > using DBD::Oracle 1.06 and DBI 1.14, and it works fine (no trailing +> > space is returned). +> > +> > Tom +> > +My config:HP-UX 11.11 (64-bit) on rp5470 2x733 5GB RAMOracle 9.2.0.2.0 +Enterprise Edition (64-bit)Perl 5.8.0 custom compiled with +./Configure -Duse64bitall -Ubincompat5005 -Duselargefiles -Dprefix=/opt/perl +5 ; all other options defaultDBI-1.32 all passed some skippedDBD-Oracle-1.14 +: PERL_DL_NONLAZY=1 /opt/perl5/bin/perl "-MExtUtils::Command::MM" +"-e" "test_harness(0, 'blib/lib', 'blib/arch')" +t/*.tt/base.......okt/cursor.....okt/general....okt/long.......okt/meta..... +..okt/ph_type....ok 11/19 expected 'trailing' but got 'trailing ' for +VARCHAR2t/ph_type....FAILED test 12 Failed 1/19 tests, 94.74% +okayt/plsql......okt/reauth.....skipped all skipped: no reason +givent/select.....okFailed Test Stat Wstat Total Fail Failed List of +Failed---------------------------------------------------------------------- +-------------------------------------------------------t/ph_type.t +19 1 5.26% 121 test skipped.Failed 1/9 test scripts, 88.89% okay. +1/314 subtests failed, 99.68% okay.*** Error exit code 2Stop.Thanks,Josh +Horton + + +From nobody@fsck.com Tue Dec 30 14:33:50 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id hBUEWNnP026077 + for ; Tue, 30 Dec 2003 14:33:50 GMT + (envelope-from nobody@fsck.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 30 Dec 2003 14:33:50 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AbJwa-0003ua-H6; + Tue, 30 Dec 2003 13:29:56 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by punt-3.mail.demon.net with esmtp id 1AbJwa-0003ua-H6 + for pobox@dbi.demon.co.uk; Tue, 30 Dec 2003 13:29:56 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 56DAD4C6 + for ; Tue, 30 Dec 2003 08:29:55 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 3B3564C8 + for ; Tue, 30 Dec 2003 08:29:55 -0500 (EST) +Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) + by boggle.pobox.com (Postfix) with SMTP + for ; Tue, 30 Dec 2003 08:29:54 -0500 (EST) +Received: (qmail 10988 invoked by uid 225); 30 Dec 2003 13:29:53 -0000 +Delivered-To: TIMB@cpan.org +Received: (qmail 10984 invoked by alias); 30 Dec 2003 13:29:52 -0000 +Received: from pallas.eruditorum.org (HELO pallas.eruditorum.org) (63.251.136.85) by la.mx.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Tue, 30 Dec 2003 05:29:41 -0800 +Received: by pallas.eruditorum.org (Postfix, from userid 65534) id 8760D11153; Tue, 30 Dec 2003 08:29:37 -0500 (EST) +Subject: [cpan #4786] Oracle 9.2.0.0 fails a test in ph_types.t +From: "Guest via RT" +Reply-To: bug-DBD-Oracle@rt.cpan.org +In-Reply-To: +Message-ID: +Precedence: bulk +X-RT-Loop-Prevention: cpan +RT-Ticket: cpan #4786 +Managed-by: RT 2.0.15 (http://bestpractical.com/rt/) +RT-Originator: +To: "AdminCc of cpan Ticket #4786": ; +Date: Tue, 30 Dec 2003 08:29:37 -0500 (EST) +X-Spam-Check-By: la.mx.develooper.com +X-Spam-Status: No, hits=2.1 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_HAS_SPACES,TO_MALFORMED version=2.44 +Status: RO +Content-Length: 888 +Lines: 11 + + +This message about DBD-Oracle was sent to you by guest <> via rt.cpan.org + +Full context and any attached attachments can be found at: + + +Assuming that ORA_OCI() gets set correctly when compiling against 9.2, the attached patch will work. I also tried this in SQL*Plus and was able to insert a trailing space into a VARCHAR2. (I replicated the test in ph_types.t). + +I did not test my patch as I installed DBD::Oracle 1.14 by setting the chops_spaces value in %test_info to 0. When I did that, everything installed fine. However, I didn't think that my solution was the best for the module, so I figured ORA_OCI should do the trick. + +I'm running Perl5.8.0 for Solaris2.9 going against the full Oracle build for 9.2. (I did not run into this issue, surprisingly, on Redhat9 running Perl 5.8.2, but I built against Oracle 9.1 there ...) + diff --git a/err_build/err_aix64.msg b/err_build/err_aix64.msg new file mode 100644 index 00000000..f952e29e --- /dev/null +++ b/err_build/err_aix64.msg @@ -0,0 +1,142 @@ +From SRS0=KVnF=PW=perl.org=dbi-users-return-25388-Tim.Bunce=pobox.com@bounce2.pobox.com Fri Jan 7 16:11:33 2005 +Received: from localhost (localhost [IPv6:::1]) + by dansat.data-plan.com (8.13.1/8.13.1) with ESMTP id j07GAqfa044155 + for ; Fri, 7 Jan 2005 16:11:32 GMT + (envelope-from SRS0=KVnF=PW=perl.org=dbi-users-return-25388-Tim.Bunce=pobox.com@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Fri, 07 Jan 2005 16:11:32 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CmvQB-0003Po-Kf; + Fri, 07 Jan 2005 14:48:59 +0000 +Received: from [194.217.242.77] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CmvQB-0003Po-Kf + for pobox@data-plan.com; Fri, 07 Jan 2005 14:48:59 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1CmvQA-0002zW-VM + for pobox@data-plan.com; Fri, 07 Jan 2005 14:48:59 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 49778102ACC; + Fri, 7 Jan 2005 09:48:58 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from boggle (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 384E5FF808 + for ; Fri, 7 Jan 2005 09:48:58 -0500 (EST) +Received-SPF: pass (boggle.pobox.com: domain of dbi-users-return-25388-Tim.Bunce=pobox.com@perl.org designates 63.251.223.186 as permitted sender) +X-SPF-Guess: pass (seems reasonable for dbi-users-return-25388-Tim.Bunce=pobox.com@perl.org to mail through 63.251.223.186) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 63.251.223.186(x6.develooper.com) +Received: from lists.develooper.com (x6.develooper.com [63.251.223.186]) + by boggle.pobox.com (Postfix) with SMTP id A74B8F4090 + for ; Fri, 7 Jan 2005 09:48:57 -0500 (EST) +Received: (qmail 2690 invoked by uid 514); 7 Jan 2005 14:48:56 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 2622 invoked from network); 7 Jan 2005 14:48:55 -0000 +Received: from x1.develooper.com (63.251.223.170) + by lists.develooper.com with SMTP; 7 Jan 2005 14:48:55 -0000 +Received: (qmail 13078 invoked by uid 225); 7 Jan 2005 14:48:54 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 13048 invoked by alias); 7 Jan 2005 14:48:51 -0000 +X-Spam-Status: No, hits=-4.6 required=8.0 + tests=BAYES_00,HTML_MESSAGE,NO_REAL_NAME +X-Spam-Check-By: la.mx.develooper.com +Received-SPF: neutral (x1.develooper.com: local policy) +Received: from outmx020.isp.belgacom.be (HELO outmx020.isp.belgacom.be) (195.238.2.201) + by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 07 Jan 2005 06:48:38 -0800 +Received: from outmx020.isp.belgacom.be (localhost [127.0.0.1]) + by outmx020.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j07EmOgS020070 + for ; Fri, 7 Jan 2005 15:48:24 +0100 + (envelope-from ) +Received: from relaytwo.roularta.be (smtprelaytwo.roularta.be [194.78.177.23]) + by outmx020.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j07EmMDA020034 + for ; Fri, 7 Jan 2005 15:48:22 +0100 + (envelope-from ) +Received: from rmgexch01.RMG.be ([89.0.35.150]) by roesfront3.RMG.be with Microsoft SMTPSVC(5.0.2195.6713); + Fri, 7 Jan 2005 15:47:50 +0100 +X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 +Content-class: urn:content-classes:message +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----_=_NextPart_001_01C4F4C7.EE810087" +Subject: A succesfull 64-bit build of Perl-DBI-DBD:Oracle on IBM AIX 5.2 +Date: Fri, 7 Jan 2005 15:48:21 +0100 +Message-ID: +X-MS-Has-Attach: +X-MS-TNEF-Correlator: +Thread-Topic: A succesfull 64-bit build of Perl-DBI-DBD:Oracle on IBM AIX 5.2 +Thread-Index: AcT0x+Y4G1R3vbX6Rh+QdPyNy/10eQ== +From: +To: +X-OriginalArrivalTime: 07 Jan 2005 14:47:50.0598 (UTC) FILETIME=[DC5D2E60:01C4F4C7] +Status: RO +Content-Length: 1678 +Lines: 62 + +------_=_NextPart_001_01C4F4C7.EE810087 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: quoted-printable + +Hi,=20 +=20 +I finally succeeded in installing a 64bit build of Perl and its modules +for Oracle 64-bit. We were running in 32bit but integrating Proc and +cobols in our perl scripts only worked when we changed environments to +64bit causing problems for the oracle connections in perl. It's nothing +special, no editing of makefiles ... I can't believe I lost so much time +on this one ;) ( Now that I look back to my problems, they were probably +caused by using a wrong perl build for compiling the modules, Aix has +its default perl now under /bin.. stupid me )=20 +=20 +perl 5.8.6 64bit +---------------- +./Configure -de -Dcc=3Dgcc -Duse64bitall=20 +make +make test +make install +=20 +DBI 1.46 +-------- +!!Make sure you are using the newly installed perl!! + check with perl -v it should show :=20 + This is perl, v5.8.6 built for aix-64all +perl Makefile.PL +make +make test +make install=20 +=20 +DBD-Oracle 1.16 +--------------- +!!Use correct perl like above mentioned!!=20 +export ORACLE_HOME=3D=20 +export LIBPATH=3D$ORACLE_HOME/lib +export LD_LIBRARY_PATH=3D$ORACLE_HOME/lib +=20 +perl Makefile.PL=20 +make +make test ( some test may still fail, I had 85% success on tests )=20 +make install=20 +=20 +Test +----=20 +=20 +test with :=20 + use DBI; + $dbh=3DDBI->connect("dbi:Oracle:","system","manager")|| die +$DBI::errstr; + $stmt=3D$dbh->prepare("select * from tab"); + $rc=3D$stmt->execute() || die $DBI::errstr; + while (my($record)=3D$stmt->fetchrow()) + { + print $record; + } +=20 +Happy 64-bit perling ;)=20 + +------_=_NextPart_001_01C4F4C7.EE810087-- + diff --git a/err_build/err_hpux_ld.msg b/err_build/err_hpux_ld.msg new file mode 100644 index 00000000..27f9cd07 --- /dev/null +++ b/err_build/err_hpux_ld.msg @@ -0,0 +1,89 @@ +From SRS0=JbZc=U3=lincolnbaxter.com=lab@bounce2.pobox.com Tue Jun 21 05:02:19 2005 +Return-Path: +X-Original-To: timbo@localhost +Delivered-To: timbo@localhost.data-plan.com +Received: from localhost (localhost [127.0.0.1]) + by timac.data-plan.com (Postfix) with ESMTP id B016F2A3D98 + for ; Tue, 21 Jun 2005 05:02:19 +0100 (IST) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Tue, 21 Jun 2005 05:02:19 +0100 (IST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1DkYXK-0003m5-Mr; + Tue, 21 Jun 2005 02:30:50 +0000 +Received: from [194.217.242.223] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1DkYXK-0003m5-Mr + for pobox@data-plan.com; Tue, 21 Jun 2005 02:30:50 +0000 +Received: from [208.210.124.73] (helo=gold.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1DkYXJ-00006n-QE + for pobox@data-plan.com; Tue, 21 Jun 2005 02:30:50 +0000 +Received: from gold.pobox.com (localhost [127.0.0.1]) + by gold.pobox.com (Postfix) with ESMTP id AF60172691; + Mon, 20 Jun 2005 22:29:36 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) + by gold.pobox.com (Postfix) with ESMTP id A3C1E7272E + for ; Mon, 20 Jun 2005 22:29:11 -0400 (EDT) +Received: from lincolnbaxter.com (cpe-069-132-010-126.carolina.res.rr.com [69.132.10.126]) + by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j5L2TIL4001864 + for ; Mon, 20 Jun 2005 22:29:18 -0400 (EDT) +Received: (qmail 5171 invoked from network); 20 Jun 2005 22:29:07 -0400 +Received: from lws (192.168.0.25) + by lws with SMTP; 20 Jun 2005 22:29:07 -0400 +Subject: Re: gcc options when building DBD:Oracle +From: "Lincoln A. Baxter" +Reply-To: lab@lincolnbaxter.com +To: jriekenberg@everestkc.net +Cc: Tim Bunce +In-Reply-To: +References: +Content-Type: text/plain +Date: Mon, 20 Jun 2005 22:29:07 -0400 +Message-Id: <1119320947.17452.484.camel@lws> +Mime-Version: 1.0 +X-Mailer: Evolution 2.2.1.1 +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: Symantec AntiVirus Scan Engine +Status: RO +Content-Length: 2011 +Lines: 38 + +Hi Jan, + +This looks like something that might be relatively easy to fix in +Makefile.PL. But I no longer have access to HPUX systems, and never +built DBD-Oracle with gcc on that platform. I could add your message to +the README.hpux file, but it is becoming less and less necessary to read +this file with newer versions of DBD-Oracle, in which Makefile.PL has +been made much smarter. + +Would you consider sending Tim or me a patch to Makefile.PL that +generates the right $(LD) command (only on HP rp8400, and only for your +version of gcc or later? + +Lincoln + +On Mon, 2005-06-20 at 15:36 -0500, jriekenberg@everestkc.net wrote: +> Lincoln, +> +> I recently built DBD:Oracle on an HP rp8400. Everything worked as expected until I actually issued the "make" command. Make proceeded as expected until it reached "MakeMaker dynamic_lib" section. The gcc line in that section failed with the error in the attached text file. Apparently gcc was not correctly passing the "+b" option to ld. Instead, it was attempting to interpret the option itself. It assumed the "+b" was a filename, and that failed because gcc could not find the file. I ended up adding the "-Xlinker" option before the "+b" and before the "$(LD_RUN_PATH)" in the line in Makefile. The line now looks like this: +> +> $(LD) -Xlinker +b -Xlinker "$(LD_RUN_PATH)" $(LDDLFLAGS) $(LDFROM) $(OTHERLDFLAGS) -o $@ $(MYEXTLIB) $(PERL_ARCHIVE) $(LDLOADLIBS) $(PERL_ARCHIVE_AFTER) $(EXPORT_LIST) +> +> Running "make" now works correctly. +> +> Also, "make test" returned the following error when attempting to build the various tests: +> +> /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2 +> +> Setting LD_PRELOAD with "export LD_PRELOAD=/usr/lib/libcl.2" corrected this problem, and "make test" worked correctly. +> +> +> I didn't see DBD::Oracle documentation on exactly this, so I'm sending this to you. You may be aware of these items already. If so, please disregard this. +> +> Jon Riekenberg +> +> +> + + diff --git a/err_build/err_hpuxsuccess.msg b/err_build/err_hpuxsuccess.msg new file mode 100644 index 00000000..c6edd79f --- /dev/null +++ b/err_build/err_hpuxsuccess.msg @@ -0,0 +1,279 @@ +From dbi-users-return-22430-Tim.Bunce=pobox.com@perl.org Tue Mar 23 17:00:25 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i2NGvAxX021862 + for ; Tue, 23 Mar 2004 17:00:23 GMT + (envelope-from dbi-users-return-22430-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 23 Mar 2004 17:00:23 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1B5oND-0000Ba-LH; + Tue, 23 Mar 2004 16:03:27 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1B5oND-0000Ba-LH + for pobox@dbi.demon.co.uk; Tue, 23 Mar 2004 16:03:27 +0000 +Received: from [208.210.124.70] (helo=majesty.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1B5oNC-00001d-92 + for pobox@dbi.demon.co.uk; Tue, 23 Mar 2004 16:03:26 +0000 +Received: from majesty.pobox.com (localhost [127.0.0.1]) + by majesty.pobox.com (Postfix) with ESMTP id 18033954B4 + for ; Tue, 23 Mar 2004 11:03:24 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by majesty.pobox.com (Postfix) with ESMTP id 3577D954BE + for ; Tue, 23 Mar 2004 11:03:21 -0500 (EST) +Received: from onion.perl.org (onion.develooper.com [63.251.223.166]) + by majesty.pobox.com (Postfix) with SMTP + for ; Tue, 23 Mar 2004 11:02:41 -0500 (EST) +Received: (qmail 6527 invoked by uid 1005); 23 Mar 2004 16:02:21 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 6510 invoked by uid 76); 23 Mar 2004 16:02:20 -0000 +Received: from x1.develooper.com (HELO x1.develooper.com) (63.251.223.170) + by onion.perl.org (qpsmtpd/0.27.1) with SMTP; Tue, 23 Mar 2004 08:02:20 -0800 +Received: (qmail 1985 invoked by uid 225); 23 Mar 2004 16:02:15 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 1893 invoked by alias); 23 Mar 2004 16:02:00 -0000 +X-Spam-Status: No, hits=0.0 required=7.0 + tests= +X-Spam-Check-By: la.mx.develooper.com +Received: from Unknown (HELO dundee.fpcc.net) (204.144.241.120) + by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Tue, 23 Mar 2004 08:01:44 -0800 +Received: from aberdeen.fpcc.net (aberdeen.fpcc.net [204.144.241.125]) + by dundee.fpcc.net (8.11.6/8.11.6) with ESMTP id i2NG1f111241; + Tue, 23 Mar 2004 09:01:41 -0700 +Received: from aberdeen.fpcc.net (localhost.localdomain [127.0.0.1]) + by aberdeen.fpcc.net (8.12.8/8.12.8) with ESMTP id i2NFrNOv024637; + Tue, 23 Mar 2004 08:53:23 -0700 +Received: (from laubster@localhost) + by aberdeen.fpcc.net (8.12.8/8.12.8/Submit) id i2NFrMOx024635; + Tue, 23 Mar 2004 08:53:22 -0700 +X-Authentication-Warning: aberdeen.fpcc.net: laubster set sender to dbiusers@laubster.org using -f +Date: Tue, 23 Mar 2004 08:53:22 -0700 +From: "J.D. Laub" +To: dbi-users@perl.org +Cc: lbaxter@fleetcc.com +Subject: SUCCESS: DBD::Oracle 1.15 on HP-UX 11.11 +Message-ID: <20040323155322.GA24576@aberdeen.fpcc.net> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.4.1i +Organization: The Psychiatric Ward of Terrors +X-Virus-Checked: Checked +Status: RO +Content-Length: 9105 +Lines: 206 + +I've just had success building DBD::Oracle 1.15 on HP-UX 11.11 +(against both oracle 8.1.7 & oracle 9.2.0) & thought I'd share my +experience. + +Disclaimer: these instructions relate to our environment. It may be +that our sysadmins/dbas chose to configure/install things a certain +way (i.e., our install of $ORACLE_HOME/bin/sqlplus was *chosen* +to be 1.1/32), and/or that we're running old versions of software +(i.e., perhaps later releases of gcc don't ignore -mpa-risc-1-1). +In fact, there are probably some mistruths in here; rest assured +they're not intentional. :-) + +I'm unsure how (if?) I should go about getting this information into +the DBD::Oracle README.hpux. Lincoln, please contact me with any +thoughts you have. + + +### The summary ################################ + +Use the ansic compiler (~US$800/cpu). + +Shell variables I used: + PATH=/bin:$PATH # use 32bit ar & nm since using a 32bit cc + PERLDEST=/opt/perl_ora8 # or "perl_ora9" for an ora9 build + PATH=$PERLDEST/bin:$PATH # for build of DBI, pick up new perl + export LDLOADLIBS='+b : +s' # handy for ORACLE_SID connections to ora7 + unset PERLLIB # important to avoid outdated cruft + export ORACLE_USERID=scott/tiger # insecure - consider using "/" + ORACLE_SID=orcl + ORAENV_ASK=NO + . oraenv # sets LD_LIBRARY_PATH and SHLIB_PATH + +For ora8: + sh ./Configure -d -e -Dprefix=$PERLDEST \ + -A prepend:libswanted='cl pthread ' \ + -A prepend:ccflags='+z +DAportable ' \ + -A prepend:ldflags='+z +DAportable ' + +For ora9: + sh ./Configure -d -e -Dprefix=$PERLDEST \ + -A prepend:libswanted='cl pthread ' \ + -A prepend:ccflags='+z +DA2.0W ' \ + -A prepend:ldflags='+z +DA2.0W ' \ + -Dlibpth='/usr/lib/pa20_64 /usr/local/pa20_64/lib' + +After you use the above to install perl, DBI & DBD::Oracle will +build in the normal fashion. + + +### General Notes ################################ + +* During "make test", I received 1 failure (on +lib/ExtUtils/t/Constant) for ora8, and 3 failures (on +lib/ExtUtils/t/Constant, lib/ExtUtils/t/recurs, and t/op/write) for +ora9. Nevertheless, things seem mostly OK. + +* These are the various combinations possible for a given compiled +file on HP-UX 11.11 (the quoted description is what gets kicked out +by the "file" command): + + PA-RISC1.1/32bit ("PA-RISC1.1 relocatable object") + (I'll call this 1.1/32) + PA-RISC2.0/32bit ("PA-RISC2.0 relocatable object") + (I'll call this 2.0/32) + PA-RISC2.0/64bit ("ELF 64-bit MSB relocatable, PA-RISC 2.0 (LP64)") + (I'll call this 2.0/64) + +* "perl -v" lies about the RISC level: +$ file ./perl +./perl: PA-RISC1.1 shared executable dynamically linked -not stripped +$ ./perl -v | grep RISC +This is perl, v5.8.3 built for PA-RISC2.0 + +* If you'll be linking against 2.0/64 libraries, you'll have to +build all your object modules that way. I've not yet found a way +to link 32bit executables to 64bit libraries (and vice versa). Run +the "file" command on your Oracle libraries to find out which path +you'll have to take. + +* Two environment variables control where libraries are +searched. LD_LIBRARY_PATH and SHLIB_PATH (in that order) are +used for 64bit executables, while SHLIB_PATH is used for 32bit +executables. + +* I tried attempts using aCC as well as the default (free) cc that +comes with hpux; both avenues were too problematic to continue +pursuing. + +* The format of compiled objects is specified by compiler options. +According to the ansic compiler docs, the options are "+DAportable" +(for 1.1/32), "+DA2.0" (for 2.0/32), and "+DA2.0W" (for 2.0/64). +For gcc, the corresponding switches are -mpa-risc-1-1 (for 1.1/32) +and -mpa-risc-2-0 (for 2.0/64), but I've found that -mpa-risc-1-1 +is ineffective. (According to the "file" command, you *always* get +2.0/64.) + +* Our gcc displays the behavior described at +http://sources.redhat.com/ml/binutils/2002-10/msg00586.html and +http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/1641238 +, so is therefore unusable anytime '-lcl' is to be specified. +Unfortunately, that library is required for DBD::Oracle builds. +(The workaround of adding the 3 declarations does seem to work, +but littering those throughout perl's Configure, main.c, etc. +seems a big task.) Attempts to get gcc to use the hp ld instead +of the gnu ld (by specifying -mno-gnu-ld and -fno-gnu-linker) were +unsuccessful. The first html link shown above indicates you have +to rebuild gcc to use the hp linker, and that was not an incredibly +desirable path to pursue. + +* Our default PATH was set to put /usr/local/pa20_64/bin ahead of +/bin. This caused problems because (I think) the 64bit versions +of either ar (the archiver) or nm (the symbol lister) do not play +well with /bin/cc (the 32bit compiler). The tweak to put /bin at +the head of PATH, so we get the 32bit versions, takes care of the +problem. + +* I ran into an intermittent quirk during the build of perl in which +typing "make" (just after the Configure) did nothing. It turns out +that only dependencies were being written to "makefile", and that +removing "makefile" (so it could be automatically rebuilt) solved +the problem. + +* Most of my research on finding the right compiler/linker switches +was done with a "hello world" C program, trying the various +compilers and options, and trying to link it with the oracle +libraries. This proved to be a good choice, as trying to test +compilers/switches against the perl source distribution would have +proved quite difficult. + + +### DBD::Oracle specific ################################ + +* ora8 delivers its libraries in 2 formats: 1.1/32 (under +$ORACLE_HOME/lib) and 2.0/64 (under $ORACLE_HOME/lib64). ora7 +delivers only 1.1/32, while ora9 delivers only 2.0/64. It may seem +a bit inconsistent considering the ora8 setup, but ora9 libraries +are found under $ORACLE_HOME/lib and not $ORACLE_HOME/lib64. + +* Under ora8, oraenv incorrectly sets LD_LIBRARY_PATH to include +$ORACLE_HOME/lib instead of $ORACLE_HOME/lib64, so you've got to +make an override in oraenv_local if you want to use 2.0/64. It +doesn't harm anything, but oraenv unnecessarily sets LD_LIBRARY_PATH +for ora7 (a 64bit environment variable for a 32bit application). + +* If you use shared libraries AND you'll be upgrading Oracle, you +should expect you'll need to rebuild DBD::Oracle unless you'll keep +the old Oracle libraries available. + +* If you're building against ora8, the setting of LDLOADLIBS +is recommended so that when oraenv set SHLIB_PATH to the +$ORACLE_HOME/lib for ora7, the code will still find the ora8 +libraries. + +* We expect to need local (ORACLE_SID) connections for ora8 & +ora9. We could have gone with a single 2.0/64 perl coupled with +2 DBD::Oracle installs and PERLLIB twiddling in oraenv_local to +get to the right one. Instead, we chose to do 2 perl installs +(/opt/perl_ora8 and /opt/perl_ora9) because we can also connect +locally to ora7 by using the 1.1/32 ora8 version, something that +isn't possible with a 2.0/64 version. Also, we've some older 1.1/32 +machines into which we'd like to plop a tarball of the perl stuff, +so a 1.1/32 executable was desirable. + +* Some tests I ran were hinting that with 2.0/64, specifying "+b :" +on the build of DBD::Oracle correctly configured Oracle.sl as far as +the chatr program is concerned, but it seemed that LD_LIBRARY_PATH +*always* needed to be set correctly. (I.e., the embedded path in +the library seemed to be ignored.) I didn't pursue researching this +since there's no way to get the ora9 compiled code to connect to +ora8, meaning LD_LIBRARY_PATH had to be set correctly anyway. + +Testing local (ORACLE_SID) connections: +builds against 1.1/32 ora8 can connect to ora7 +builds against 1.1/32 ora8 cannot connect to ora9: "ERROR OCIEnvInit" +builds against 2.0/64 ora8 cannot connect to ora9: "ERROR OCIEnvInit" +builds against 2.0/64 ora9 cannot connect to ora8 or ora7: "UNKNOWN + OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and NLS + settings etc." + +Testing remote (sqlnet) connections: +builds against 1.1/32 ora8 can connect to ora7 +builds against 1.1/32 ora8 can connect to ora9 +builds against 2.0/64 ora9 can connect to ora8 +builds against 2.0/64 ora9 cannot connect to ora7: "OCI-21500: internal + error code" + + +### Versions ################################ + +perl: 5.8.3 +dbi: 1.41 +dbd-oracle: 1.15 +$ strings /bin/cc | grep Compiler +HP92453-01 B.11.11.08 HP C Compiler +$ strings /bin/ld | grep linker +$Revision: 92453-07 linker linker crt0.o B.11.16 000601 $ +@(#)92453-07 linker command s800.sgs ld PA64 B.11.18 REL 000922 +$ gcc -v +Reading specs from /usr/local/pa20_64/lib/gcc-lib/hppa64-hp-hpux11.11/3.3.1/specs +Configured with: ../src/configure --enable-languages=c,c++ --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls --host=hppa64-hp-hpux11.11 +Thread model: single +gcc version 3.3.1 + +-- +J.D. Laub (Laubster) |"Your leg's too long / Your skull's too strong / +dbiusers@laubster.org| Suppose your nose is wrong." - Renaldo & the Loaf + diff --git a/err_build/err_instantclient.msg b/err_build/err_instantclient.msg new file mode 100644 index 00000000..f0e549eb --- /dev/null +++ b/err_build/err_instantclient.msg @@ -0,0 +1,207 @@ +From SRS0=8E1j=QQ=perl.org=dbi-users-return-25638-Tim.Bunce=pobox.com@bounce2.pobox.com Wed Feb 2 10:11:05 2005 +Received: from localhost (localhost [IPv6:::1]) + by dansat.data-plan.com (8.13.1/8.13.1) with ESMTP id j12AAUZ6055956 + for ; Wed, 2 Feb 2005 10:11:05 GMT + (envelope-from SRS0=8E1j=QQ=perl.org=dbi-users-return-25638-Tim.Bunce=pobox.com@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Wed, 02 Feb 2005 10:11:05 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CwGaQ-0002Bn-H6; + Wed, 02 Feb 2005 09:14:10 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CwGaQ-0002Bn-H6 + for pobox@data-plan.com; Wed, 02 Feb 2005 09:14:10 +0000 +Received: from [207.8.226.2] (helo=kelvin.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1CwGaP-00042G-Vb + for pobox@data-plan.com; Wed, 02 Feb 2005 09:14:10 +0000 +Received: from kelvin.pobox.com (localhost [127.0.0.1]) + by kelvin.pobox.com (Postfix) with ESMTP id 9C3FB1E3946; + Wed, 2 Feb 2005 04:14:09 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from kelvin (localhost [127.0.0.1]) + by kelvin.pobox.com (Postfix) with ESMTP id 879981E3958 + for ; Wed, 2 Feb 2005 04:14:09 -0500 (EST) +Received-SPF: pass (kelvin.pobox.com: domain of dbi-users-return-25638-Tim.Bunce=pobox.com@perl.org designates 63.251.223.186 as permitted sender) +X-SPF-Guess: pass (seems reasonable for dbi-users-return-25638-Tim.Bunce=pobox.com@perl.org to mail through 63.251.223.186) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 63.251.223.186(x6.develooper.com) +Received: from lists.develooper.com (x6.develooper.com [63.251.223.186]) + by kelvin.pobox.com (Postfix) with SMTP id D0B001E3946 + for ; Wed, 2 Feb 2005 04:14:08 -0500 (EST) +Received: (qmail 7188 invoked by uid 514); 2 Feb 2005 09:14:05 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +List-Id: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 2531 invoked from network); 2 Feb 2005 04:10:16 -0000 +Delivered-To: dbi-users@perl.org +X-Spam-Status: No, hits=-2.6 required=8.0 + tests=BAYES_00,NO_REAL_NAME +X-Spam-Check-By: la.mx.develooper.com +Received-SPF: pass (x1.develooper.com: local policy) +From: snisim@sankyo.co.jp +X-Authentication-Warning: mailgw.shina.sankyo.co.jp: iscan owned process doing -bs +X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 +Content-class: urn:content-classes:message +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-2022-jp" +Content-Transfer-Encoding: 7bit +Subject: Making DBD::Oracle with Instant Client 10.1.0.3 +Date: Wed, 2 Feb 2005 13:09:58 +0900 +Message-ID: <7C6FBEDC782B5642BEAF9C9FDF3F431D83CBE9@EVS001.sankyo.co.jp> +X-MS-Has-Attach: +X-MS-TNEF-Correlator: +Thread-Topic: Making DBD::Oracle with Instant Client 10.1.0.3 +Thread-Index: AcUI3Q64h9ykph8RSl6pF0OpBbTqJA== +To: +X-OriginalArrivalTime: 02 Feb 2005 04:09:59.0005 (UTC) FILETIME=[0F7508D0:01C508DD] +Status: RO +X-Status: A +Content-Length: 1692 +Lines: 44 + +Hi all, + +Thanks to the devel package, I've got succeeded in making DBD::Oracle +with the Oracle Instant Client 10.1.0.3, no *.mk files, in my linux box. +My recipe is: + +1) install both basic- and devel-10.1.0.3 rpm packages +2) export ORALCE_HOME="/usr/lib/oracle/10.1.0.3/client" +3) export LD_LIBRARY_PATH="$ORACLE_HOME/lib:$LD_LIBRARY_PATH" +4) modify the Makefile.PL file to bypass the find_headers() routine and + to pass a correct -I flag to cc (the attached dirty patch is FYI) +5) execute the Makefile.PL * with the -l option *, perl Makefile.PL -l +6) make && make test && make install +# I got many errors in t/30long.t (retrieving blobs ?) +# but it seems to work fairly. + +I hope this could help those who are annoyed with the "Unable to locate an +oracle.mk,..." error. + +Happy DBing, + +Satoshi + +--- Makefile.PL.orig 2004-10-22 18:07:04.000000000 +0900 ++++ Makefile.PL 2005-02-02 12:39:56.703125000 +0900 +@@ -276,7 +276,7 @@ + print "Oracle sysliblist: $syslibs\n"; + my $libdir = ora_libdir(); + $opts{dynamic_lib} = { OTHERLDFLAGS => "$::opt_g" }; +- my @h_dirs = find_headers(); ++# my @h_dirs = find_headers(); + if ($client_version_full =~ /^8.0.6/ && $os eq 'hpux') { + $linkwith_msg = "-lextp -l$lib."; + $opts{LIBS} = [ "-L$OH/$libdir -lextp -l$lib $syslibs" ]; +@@ -286,7 +286,8 @@ + $linkwith_msg = "-l$lib."; + $opts{LIBS} = [ "-L$OH/$libdir -l$lib $syslibs" ]; + } +- my $inc = join " ", map { "-I$OH/$_" } @h_dirs; ++# my $inc = join " ", map { "-I$OH/$_" } @h_dirs; ++ my $inc = "-I/usr/include/oracle/10.1.0.3/client"; + $opts{INC} = "$inc -I$dbi_arch_dir"; + } + else { # --- trawl the guts of Oracle's make files looking the how it wants to link + +From SRS0=Kn57=QR=sankyo.co.jp=snisim@bounce2.pobox.com Thu Feb 3 08:10:48 2005 +Received: from localhost (localhost [IPv6:::1]) + by dansat.data-plan.com (8.13.1/8.13.1) with ESMTP id j138AMOi093146 + for ; Thu, 3 Feb 2005 08:10:48 GMT + (envelope-from SRS0=Kn57=QR=sankyo.co.jp=snisim@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Thu, 03 Feb 2005 08:10:48 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CwboD-0005ug-LV; + Thu, 03 Feb 2005 07:53:49 +0000 +Received: from [194.217.242.223] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CwboD-0005ug-LV + for pobox@data-plan.com; Thu, 03 Feb 2005 07:53:49 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1CwboD-0000Wn-82 + for pobox@data-plan.com; Thu, 03 Feb 2005 07:53:49 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 70999102D9F; + Thu, 3 Feb 2005 02:53:48 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from boggle (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 5F45E102DCC + for ; Thu, 3 Feb 2005 02:53:48 -0500 (EST) +X-Pobox-Antispam: Require PTR Record returned DENY: 210.81.52.253 has no PTR record +X-Pobox-Antispam: country/Japan returned DENY: sender address snisim@sankyo.co.jp matches TLD .jp (Japan) +Received-SPF: none (boggle.pobox.com: domain of snisim@sankyo.co.jp does not designate permitted sender hosts) +X-SPF-Guess: pass (seems reasonable for snisim@sankyo.co.jp to mail through 210.81.52.253) +Received: from mailgws.shina.sankyo.co.jp (unknown [210.81.52.253]) + by boggle.pobox.com (Postfix) with ESMTP id A38A5102E20 + for ; Thu, 3 Feb 2005 02:53:46 -0500 (EST) +Received: from es007.sankyo.co.jp (localhost [127.0.0.1]) + by mailgws.shina.sankyo.co.jp (8.9.3p2/3.7W) with ESMTP id LAA15117 + for ; Thu, 3 Feb 2005 11:45:39 +0900 (JST) +From: snisim@sankyo.co.jp +X-Authentication-Warning: mailgws.shina.sankyo.co.jp: iscan owned process doing -bs +Received: from EVS001.sankyo.co.jp ([10.14.121.200]) by es007.sankyo.co.jp with Microsoft SMTPSVC(6.0.3790.0); + Thu, 3 Feb 2005 11:45:39 +0900 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-2022-jp" +Content-Transfer-Encoding: 7bit +Subject: RE: Making DBD::Oracle with Instant Client 10.1.0.3 +Content-class: urn:content-classes:message +X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 +Date: Thu, 3 Feb 2005 11:46:07 +0900 +Message-ID: <7C6FBEDC782B5642BEAF9C9FDF3F431D83CBEC@EVS001.sankyo.co.jp> +X-MS-Has-Attach: +X-MS-TNEF-Correlator: +Thread-Topic: Making DBD::Oracle with Instant Client 10.1.0.3 +Thread-Index: AcUJEc1pQuIX++g2S8y4AE9WqWRYtQAhsK+Q +To: +X-OriginalArrivalTime: 03 Feb 2005 02:45:39.0123 (UTC) FILETIME=[71F21030:01C5099A] +Status: RO +Content-Length: 1192 +Lines: 36 + +Hi Tim, + +Thank you for your kind reply. + +I found my patch will cause a compilation error for the local variable +@h_dirs gets into undefined after commenting out the line 279. +It should be corrected as following: + +--- Makefile.PL.orig 2004-10-22 18:07:04.000000000 +0900 ++++ Makefile.PL 2005-02-02 12:39:56.703125000 +0900 +@@ -276,7 +276,7 @@ + print "Oracle sysliblist: $syslibs\n"; + my $libdir = ora_libdir(); + $opts{dynamic_lib} = { OTHERLDFLAGS => "$::opt_g" }; +- my @h_dirs = find_headers(); ++ my @h_dirs; + if ($client_version_full =~ /^8.0.6/ && $os eq 'hpux') { + $linkwith_msg = "-lextp -l$lib."; + $opts{LIBS} = [ "-L$OH/$libdir -lextp -l$lib $syslibs" ]; +@@ -286,7 +286,8 @@ + $linkwith_msg = "-l$lib."; + $opts{LIBS} = [ "-L$OH/$libdir -l$lib $syslibs" ]; + } +- my $inc = join " ", map { "-I$OH/$_" } @h_dirs; ++# my $inc = join " ", map { "-I$OH/$_" } @h_dirs; ++ my $inc = "-I/usr/include/oracle/10.1.0.3/client" + $opts{INC} = "$inc -I$dbi_arch_dir"; + } + else { # --- trawl the guts of Oracle's make files looking the how it wants to link + +I'm not a dbi-users member so I can't reply my post... I wonder if you can do it. + +Thanks, + +Satoshi + + diff --git a/err_build/err_makefileundef.msg b/err_build/err_makefileundef.msg new file mode 100644 index 00000000..b98d782a --- /dev/null +++ b/err_build/err_makefileundef.msg @@ -0,0 +1,87 @@ +From timbo Tue Apr 26 09:19:54 2005 +Return-path: +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Tue, 26 Apr 2005 09:19:54 -0700 (PDT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1DQSgy-0006AU-4c; + Tue, 26 Apr 2005 16:13:44 +0000 +Received: from [194.217.242.72] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1DQSgy-0006AU-4c + for pobox@data-plan.com; Tue, 26 Apr 2005 16:13:44 +0000 +Received: from [207.8.226.2] (helo=kelvin.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1DQSgy-0003uM-1T + for pobox@data-plan.com; Tue, 26 Apr 2005 16:13:44 +0000 +Received: from kelvin.pobox.com (localhost [127.0.0.1]) + by kelvin.pobox.com (Postfix) with ESMTP id 759703B902A; + Tue, 26 Apr 2005 12:13:43 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from kelvin (localhost [127.0.0.1]) + by kelvin.pobox.com (Postfix) with ESMTP id 80C0A39F279 + for ; Tue, 26 Apr 2005 12:13:42 -0400 (EDT) +Received-SPF: none (kelvin.pobox.com: domain of lembark@wrkhors.com does not designate permitted sender hosts) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 66.246.154.128(mail-out.pilosoft.net) +Received: from mail.pilosoft.net (mail-out.pilosoft.net [66.246.154.128]) + by kelvin.pobox.com (Postfix) with ESMTP id 2ED743AB75B + for ; Tue, 26 Apr 2005 12:12:30 -0400 (EDT) +Received: from [192.168.1.2] (dsl-69-31-90-94.pilosoft.com [69.31.90.94]) + by mail.pilosoft.net (8.12.8/8.12.8) with ESMTP id j3QGA3u1014203 + for ; Tue, 26 Apr 2005 12:10:03 -0400 +Date: Tue, 26 Apr 2005 12:14:22 -0400 +From: Steven Lembark +Reply-To: lembark@wrkhors.com +To: Tim Bunce +Subject: Possible glitch in DBD::Oracle-1.48 Makefile.pl +Message-ID: <269F0144DC99100E7C80975F@[192.168.1.2]> +X-Mailer: Mulberry/3.1.3 (Linux/x86) +X-Workhorse: lembark 1.1 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii; format=flowed +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on mail.pilosoft.net +X-Virus-Status: Clean +X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.2 +X-Spam-Level: 0.0 +X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheeta.pilosoft.net +X-Status: A +Content-Length: 1342 +Lines: 36 + +Linking with OTHERLDFLAGS = -L/opt/oracle/product/9.2/lib/ +-L/opt/oracle/product/9.2/rdbms/lib/ -lclntsh `cat +/opt/oracle/product/9.2/lib/sysliblist` -ldl -lm [from 'build' rule] + +Checking if your kit is complete... +Looks good +Use of uninitialized value in substitution (s///) at Makefile.PL line 1446. +LD_RUN_PATH=/opt/oracle/product/9.2/lib:/opt/oracle/product/9.2/rdbms/lib +Using DBD::Oracle 1.16. + + + sub const_loadlibs { + my $self = shift; + local($_) = $self->SUPER::const_loadlibs(@_); + # edit LD_RUN_PATH ... + my ($ldrp) = m/^LD_RUN_PATH\s*=\s*(.*)/m; + # remove redundant /lib or /usr/lib as it can cause problems +-> $ldrp =~ s!:(/usr)?/lib$!!; + # if it's empty then set it manually + #Lincoln: if pick the right library path + my $libdir = main::ora_libdir(); + $ldrp ||= "$OH/$libdir:$OH/rdbms/$libdir"; + #print "ldrp=$ldrp\n"; + + # stitch it back in + s/^LD_RUN_PATH\s*=\s*(.*)/LD_RUN_PATH=$ldrp/m; + my $env = $ENV{LD_RUN_PATH}; + print "Ignoring LD_RUN_PATH='$env' in environment\n" if $env; + print "LD_RUN_PATH=$ldrp\n"; + return $_; + } + +-- +Steven Lembark 85-09 90th Street +Workhorse Computing Woodhaven, NY 11421 +lembark@wrkhors.com 1 888 359 3508 + diff --git a/err_build/err_memleak.msg b/err_build/err_memleak.msg new file mode 100644 index 00000000..d40913d7 --- /dev/null +++ b/err_build/err_memleak.msg @@ -0,0 +1,95 @@ +From SRS0=Dwok=LW=pallas.eruditorum.org=www-data@bounce2.pobox.com Wed Sep 1 16:31:37 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i81FRlpg021884 + for ; Wed, 1 Sep 2004 16:31:37 +0100 (BST) + (envelope-from SRS0=Dwok=LW=pallas.eruditorum.org=www-data@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 01 Sep 2004 16:31:37 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1C2WYO-00034m-M1; + Wed, 01 Sep 2004 14:57:40 +0000 +Received: from [194.217.242.72] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1C2WYO-00034m-M1 + for pobox@data-plan.com; Wed, 01 Sep 2004 14:57:40 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1C2WYO-0005CR-FY + for pobox@data-plan.com; Wed, 01 Sep 2004 14:57:40 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 1C1D6A758C; + Wed, 1 Sep 2004 10:57:36 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from boggle (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 184C8A7214 + for ; Wed, 1 Sep 2004 10:57:32 -0400 (EDT) +Received-SPF: fail (boggle.pobox.com: domain of www-data@pallas.eruditorum.org does not designate 63.251.223.170 as permitted sender) +X-SPF-Override: pass (client 63.251.223.170 was found in trusted-forwarder.org, overrides regular SPF fail) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 63.251.223.170(x1.develooper.com) +Received: from x1.develooper.com (x1.develooper.com [63.251.223.170]) + by boggle.pobox.com (Postfix) with SMTP id 7A6C9A7555 + for ; Wed, 1 Sep 2004 10:57:06 -0400 (EDT) +Received: (qmail 5427 invoked by uid 225); 1 Sep 2004 14:57:04 -0000 +Delivered-To: TIMB@cpan.org +Received: (qmail 5403 invoked by alias); 1 Sep 2004 14:57:02 -0000 +X-Spam-Status: No, hits=-4.9 required=8.0 + tests=BAYES_00 +X-Spam-Check-By: la.mx.develooper.com +Received: from pallas.eruditorum.org (HELO pallas.eruditorum.org) (63.251.136.85) + by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 01 Sep 2004 07:56:59 -0700 +Received: by pallas.eruditorum.org (Postfix, from userid 33) + id 1FDD784C0F5; Wed, 1 Sep 2004 10:56:41 -0400 (EDT) +Subject: [cpan #6245] Confirmed memory leak +From: "Guest via RT" +Reply-To: bug-DBD-Oracle@rt.cpan.org +In-Reply-To: +Message-ID: +Precedence: bulk +X-RT-Loop-Prevention: cpan +RT-Ticket: cpan #6245 +Managed-by: RT 2.0.15 (http://bestpractical.com/rt/) +RT-Originator: +Date: Wed, 1 Sep 2004 10:56:41 -0400 (EDT) +To: undisclosed-recipients: ; +Status: RO +Content-Length: 937 +Lines: 38 + + +This message about DBD-Oracle was sent to you by guest <> via rt.cpan.org + +Full context and any attached attachments can be found at: + + +I Using : +1. SunOS 5.6 Generic_105181-33 sun4u sparc SUNW,Ultra-Enterprise + Perl 5.005_03 + DBI 1.37 + DBD-Oracle 1.14 + Oracle Release 8.1.5.0.0 + + +2. Linux 2.4.18-17.7.xsmp #1 SMP i686 + Perl 5.6.1 + DBI 1.41 + DBD-Oracle 1.16 + Oracle Release 8.1.6.0.0 + +II The following code: + +use strict; +use DBI; + +foreach ( 1 .. 100 ) { + my $dbh = DBI->connect( 'dbi:Oracle:host=****', '***', '***' ); + $dbh->disconnect(); + sleep(1) +} + +III Leak about 4K every 10 seconds + + PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND +24927 aldo 15 0 8724 8720 2760 S 1.3 3.4 0:01 perl + + PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND +24927 aldo 15 0 8736 8732 2760 S 0.7 3.4 0:01 perl + diff --git a/err_build/err_solarisnotes.msg b/err_build/err_solarisnotes.msg new file mode 100644 index 00000000..eaddc475 --- /dev/null +++ b/err_build/err_solarisnotes.msg @@ -0,0 +1,482 @@ +From SRS0=uAXy=PG=zorranlabs.com=alexzar@bounce2.pobox.com Wed Dec 22 08:11:00 2004 +Received: from localhost (localhost [IPv6:::1]) + by dansat.data-plan.com (8.13.1/8.13.1) with ESMTP id iBM8Aog0091816 + for ; Wed, 22 Dec 2004 08:11:00 GMT + (envelope-from SRS0=uAXy=PG=zorranlabs.com=alexzar@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-6.2.5) + for timbo@localhost (single-drop); Wed, 22 Dec 2004 08:11:00 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1Ch0it-0001A5-Rv; + Wed, 22 Dec 2004 07:15:51 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1Ch0it-0001A5-Rv + for pobox@data-plan.com; Wed, 22 Dec 2004 07:15:51 +0000 +Received: from [208.58.1.198] (helo=lime.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1Ch0is-0000To-R8 + for pobox@data-plan.com; Wed, 22 Dec 2004 07:15:51 +0000 +Received: from lime.pobox.com (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id F0F0DFE10C; + Wed, 22 Dec 2004 02:15:49 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from lime (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id 8B2AAFE1C3 + for ; Wed, 22 Dec 2004 02:15:49 -0500 (EST) +Received-SPF: none (lime.pobox.com: domain of alexzar@zorranlabs.com does not designate permitted sender hosts) +Received: from penguin.nocdirect.com (penguin.nocdirect.com [69.73.160.206]) + by lime.pobox.com (Postfix) with ESMTP id 2B41BFE159 + for ; Wed, 22 Dec 2004 02:13:17 -0500 (EST) +Received: from localhost ([127.0.0.1]) + by penguin.nocdirect.com with esmtps (TLSv1:DES-CBC3-SHA:168) + (Exim 4.43) + id 1Cgz53-0000fj-Bx; Tue, 21 Dec 2004 23:30:37 -0600 +Date: Tue, 21 Dec 2004 23:30:35 -0600 (CST) +From: Alex Zarutin +X-X-Sender: zorranla@penguin.nocdirect.com +To: Tim Bunce +Cc: dbi-users-help@perl.org +Subject: Step-by-Step installation manual of DBD-Oracle-1.16 on Sparc Solaris + 9 with Oracle 9.2.0.1.0 client. +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-AntiAbuse: This header was added to track abuse, please include it with any abuse report +X-AntiAbuse: Primary Hostname - penguin.nocdirect.com +X-AntiAbuse: Original Domain - pobox.com +X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] +X-AntiAbuse: Sender Address Domain - zorranlabs.com +X-Source: +X-Source-Args: +X-Source-Dir: +Status: RO +X-Status: A +Content-Length: 15603 +Lines: 426 + + +Hi Tim, + +I have spent a couple days trying to install DBD-Oracle-1.16 (all +required stuff, such as GCC, DBI, etc has been installed before ) on +Sun-Fire v240 running Spark Solaris 9 with the Oracle 9.2.0.1.0 client +installed. The installation takes a couple minutes ONLY after you spend +days trying to make it workable. + +I wrote the log of what I do, in order to do not waste my time in +future. I am pretty sure that this log will be very useful for people +installing DBD-Oracle on Solaris. I published it on my log page, and left +link on it at http://cpanratings.perl.org/d/DBD-Oracle review page. I +would recommend you to add this log to the readme file of your next +releases. Log is written very detailed (step-by-step) with highlighted +typical mistakes. + +Environment: +Hardware/OS: bash-2.05# uname -a +SunOS qadmz41 5.9 Generic_117171-08 sun4u sparc SUNW,Sun-Fire-V240 +OS is actually "standard" Solaris 9 installation came on the box from +SUN + +Oracle Client: Oracle 9.2.0.1.0 +GCC: gcc version 3.3.2, installed to /usr/local/bin as a package from +http://www.sunfreeware.com/programlistsparc9.html +PERL: perl v5.8.5 built for sun4-solaris, installed to /usr/local/bin as +a package from http://www.sunfreeware.com/programlistsparc9.html +DBI: DBI-1.45, installed from http://search.cpan.org/~timb/DBI-1.45/ + +Step-by-Step Manual: + +Step 1: In order to install "DBD-Oracle-1.16" you need to download it, +set all appropriate environment variables (see readme for details) and +run <>. +I got an error that is mostly typical for Solaris installation: + +// ************************ Error 1 ***********************/ + +.... +Found header files in rdbms/demo. + +********************************************************* +I can't find the header files I need in your Oracle installation. +You probably need to install some more Oracle components. +I'll keep going, but the compile will probably fail. +See README.clients for more information. +********************************************************* +Checking for functioning wait.ph + +System: perl5.008005 sunos 5.9 generic sun4u sparc sunw,ultra-5_10 +solaris +Compiler: gcc -B/usr/ccs/bin/ -O -fno-strict-aliasing -pipe +-I/usr/local/include -I/opt/gnu/include -D_LARGEFILE_SOURCE +-D_FILE_OFFSET_BITS=64 + +.... +// *****************************************************/ + +Investigating this problem, I found that error message is thrown by the +"find_headers" sub of Makefile.PL, especially in this "if +(!$h_file{'oratypes.h'} || !$h_file{'ocidfn.h'})" evaluation. +So I checked these files to make sure that they are installed, but did +not find them under $ORACLE_HOME/rdbms +In the same time, I found an article saying about the similar problem +with DBD-Oracle on Linux, +http://baroti.homedns.org/steve/lost+found/cpan-install-DBD-Oracle-9-2-l +inux.html +They mentioned about two files, and since I was not sure about second +one, ociapr.h I copied both files. You should find its public.1.1.jar +file on the Disk3 of Oracle 9i installation set. + +bash-2.05# pwd +/ora_orig/Disk3/stage/Components/oracle.rdbms.oci/9.2.0.1.0/1/DataFiles + +bash-2.05# ls -al +total 970 +drwxr-xr-x 2 2840 42424 512 Aug 21 2002 . +drwxr-xr-x 3 2840 42424 512 Aug 21 2002 .. +-rwxr-xr-x 1 2840 42424 2047 May 9 2002 bin.1.1.jar +-rwxr-xr-x 1 2840 42424 206 May 9 2002 build.1.1.jar +-rwxr-xr-x 1 2840 42424 135034 May 9 2002 demo.1.1.jar +-rwxr-xr-x 1 2840 42424 329814 May 9 2002 public.1.1.jar + +You should just (as dba:oracle) to create the directory called public, +copy public.1.1.jar there and extract all files, since I would not guess +if the rest of them are used or not + +bash-2.05# mkdir $ORACLE_HOME/rdbms/public + +bash-2.05# ls -al $ORACLE_HOME/rdbms/public +total 3404 +drwxr-xr-x 2 oracle dba 512 Dec 21 12:12 . +drwxr-xr-x 10 oracle dba 512 Dec 21 12:05 .. +... +-rw-r--r-- 1 oracle dba 6055 Mar 9 2002 ociapr.h +-rw-r--r-- 1 oracle dba 10694 Jun 29 2000 ocidfn.h +... + +After that run <> again, and I hope process passes +fine. At least, it was fine in my case + +Step 2: You should <> the module, and as it appears on Solaris, +you will get typical problem. See my error log: + +// ************************ Error 2 ***********************/ +.... +rm -f blib/arch/auto/DBD/Oracle/Oracle.so +LD_RUN_PATH="/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32: +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/rdbms/lib32" gcc +-B/usr/ccs/bin/ -G -L/usr/local/lib -L/opt/gnu/lib Oracle.o dbdimp.o +oci8.o -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib -laio +-lposix4 -lm -lthread -o blib/arch/auto/DBD/Oracle/Oracle.so +ld: fatal: file +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib//libclntsh.so: +wrong ELF class: ELFCLASS64 +ld: fatal: File processing errors. No output written to +blib/arch/auto/DBD/Oracle/Oracle.so +collect2: ld returned 1 exit status +*** Error code 1 +make: Fatal error: Command failed for target +`blib/arch/auto/DBD/Oracle/Oracle.so' + +// *****************************************************/ + +So, as another set on Google' posts showed that it is a possibility of +missing libraries compiled with 64 bits and same libraries compiled with +32 bits suppoert. As I understood, all components of installation, such +as Oracle client, Perl, GCC should support only one type of libraries, +either 32 or 64 bits. I found that having all as 32 bits is easier to me +than recompile perl, gcc as 64 (may be I am wrong in this assumption). +In order to have all of them as 32 bits, I changed lib to lib32 in +Manifest file (not Manifest.PL). + +You should replace the following lines in the "MakeMaker const_loadlibs +section": + +EXTRALIBS = -L$(LIBHOME) -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib -laio +-lposix4 -lm -lthread +LD_RUN_PATH=/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32:/ +export/home/oracle/u01/app/oracle/product/9.2.0.1.0/rdbms/lib32 + +By their lib32 clones: + +EXTRALIBS = -L$(LIBHOME) -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32 -laio +-lposix4 -lm -lthread +LD_RUN_PATH=/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32:/ +export/home/oracle/u01/app/oracle/product/9.2.0.1.0/rdbms/lib32 + +And replace this line in "MakeMaker dynamic_lib section" (~~ line 491) + +OTHERLDFLAGS = -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib -laio +-lposix4 -lm -lthread + +By its lib32 clone: + +OTHERLDFLAGS = -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32 -laio +-lposix4 -lm -lthread + +I hope, that after that process passes without any errors. Here is last +part, that I got during <>: + +..... +rm -f blib/arch/auto/DBD/Oracle/Oracle.so +LD_RUN_PATH="/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32: +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/rdbms/lib32" gcc +-B/usr/ccs/bin/ -G -L/usr/local/lib -L/opt/gnu/lib Oracle.o dbdimp.o +oci8.o -xarch=v9 +-L/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ -lclntsh +`cat /export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/ldflags` +`cat +/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32/sysliblist` +-R/export/home/oracle/u01/app/oracle/product/9.2.0.1.0/lib32 -laio +-lposix4 -lm -lthread -o blib/arch/auto/DBD/Oracle/Oracle.so +chmod 755 blib/arch/auto/DBD/Oracle/Oracle.so +cp Oracle.bs blib/arch/auto/DBD/Oracle/Oracle.bs +chmod 644 blib/arch/auto/DBD/Oracle/Oracle.bs +/usr/local/bin/perl "-Iblib/arch" "-Iblib/lib" ora_explain.PL +ora_explain +Extracted ora_explain from ora_explain.PL with variable substitutions. +cp ora_explain blib/script/ora_explain +/usr/local/bin/perl "-MExtUtils::MY" -e "MY->fixin(shift)" +blib/script/ora_explain +Manifying blib/man1/ora_explain.1 +Manifying blib/man3/DBD::Oracle.3 +Manifying blib/man3/DBD::Oraperl.3 + +III. Once we build the module, we should test it, to make sure that it +works fine. You should run <> to do it: + +Check that you have ORACLE_HOME, ORACLE_USERID, ORACLE_SID environment +variables set, like this: + +ORACLE_HOME=="/export/home/oracle/u01/app/oracle/product/9.2.0.1.0 +ORACLE_USERID=STARSHIP/STARSHIP +ORACLE_SID=COLORADO + +When you run <>, you will probably get this errors: + +// ************************ Error 3 ***********************/ + +bash-2.05# make test +PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" +"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t +t/01base................ok +t/10general.............DBI connect('','STARSHIP/STARSHIP',...) failed: +ORA-12545: Connect failed because target host or object does not exist +(DBD ERROR: OCIServerAttach) at t/10general.t line 12 +Undefined subroutine &main::BAILOUT called at t/10general.t line 15. +# Looks like your test died before it could output anything. +t/10general.............dubious + Test returned status 255 (wstat 65280, 0xff00) +DIED. FAILED tests 1-31 + Failed 31/31 tests, 0.00% okay +..... + +// *****************************************************/ + +One more brainstorm, and I figured out another way to set ORACLE_USERID: + +ORACLE_USERID=STARSHIP/STARSHIP@COLORADO +ORACLE_SID=COLORADO + +Later, when tests finished, I was confirmed that it was probably +preferred way of setting ORACLE_USERID. +Tests did found correct settings, and "main" set of them returned the +following report: + +All tests successful, 1 test and 122 subtests skipped. +Files=18, Tests=1020, 24 wallclock secs (11.27 cusr + 1.34 csys = 12.61 +CPU) + +For the Extra test, less formal, but test anyway, I just commented these +two lines in test.pl file + +$dbname = $ARGV[0] || ''; # if '' it'll use TWO_TASK/ORACLE_SID +$dbuser = $ENV{ORACLE_USERID} || 'scott/tiger'; + +and set the same values in the same form to the $dbuser as it was in +ORACLE_USERID , and +left $dbname empty, + +$dbname = ''; +$dbuser = 'STARSHIP/STARSHIP@COLORADO'; + +and got pretty good report: + +Connecting + to '' (from command line, else uses ORACLE_SID or TWO_TASK - +recommended) + as 'STARSHIP/STARSHIP@COLORADO' (via ORACLE_USERID env var or default - +recommend name/passwd@dbname) +(ORACLE_SID='', TWO_TASK='') +Fields: 6 +Names: 'NUM_T' 'DATE_T' 'CHAR_T' 'ROWID_T' +'RAW_T' 'NULL_T' +Lengths: 172 76 121 21 3 1 +OraTypes: 2 12 1 104 23 1 +SQLTypes: 8 93 12 -9104 -2 12 +Scale: 0 0 0 0 0 0 +Precision: 126 75 120 20 2 0 +Nullable: 1 1 1 1 1 1 +Est row width: 32 +Data rows: + fetch: '7.2', '21-DEC-04', 'STARSHIP', 'AAAADeAABAAAAZSAAA', '7D', +undef + +ora_logoff... +lda out of scope... + +Testing repetitive connect/open/close/disconnect: +If this test hangs then read the README.help file. +Expect sequence of digits, no other messages: +1 2 3 4 5 + +Test interaction of explicit close/logoff and implicit DESTROYs +Expect just 'done.', no other messages: +done. + +Testing row cache (5). +Test completed in 0 seconds. + +Test complete (0 seconds). +If the tests above have produced the 'expected' output then they have +passed. + +IV. The last part is actually target of all steps above, installing +build module. < did not surprise me, and it it passed +smoothly. + +bash-2.05# make install +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/dbdimp +.h +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/ocitra +ce.h +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/Oracle +.h +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/mk.pm +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/Oracle +.so +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/Oracle +.bs +Files found in blib/arch: installing files in blib/lib into architecture +dependent library tree +Installing /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/oraperl.ph +Installing /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/Oraperl.pm +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/DBD/Oracle.pm +Installing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/DBD/Oracle/GetInfo.pm +Installing /usr/local/share/man/man1/ora_explain.1 +Installing /usr/local/share/man/man3/DBD::Oracle.3 +Installing /usr/local/share/man/man3/DBD::Oraperl.3 +Installing /usr/local/bin/ora_explain +Writing +/usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris/auto/DBD/Oracle/.packl +ist +Appending installation info to +/usr/local/lib/perl5/5.8.5/sun4-solaris/perllocal.pod + +V. This is actually it, and you do not need to do anything else. But +investigating different errors during the various steps, I found the +very simple "independent sanity" testdbi perl script written by Jeff +Hunter. This script is not related to standard process of +making/buildin/testing/installation. It just verifies that you can +access DB and run a couple queries against it. The code itself, +testdbi.pl can be found at +http://www.idevelopment.info/data/Oracle/DBA_tips/Programming/PROGRAMMIN +G_2.shtml + +You just should set connection information, similar to how I did it, + + $ORACLE_SID = "COLORADO"; + $ORACLE_USERID = "STARSHIP"; + $ORACLE_PASSWORD = "STARSHIP"; + + $ENV{'ORACLE_SID'} = "$ORACLE_SID"; + $ENV{'ORACLE_HOME'} = /u01/app/oracle/product/9.2.0.1.0"; + +run it as any perl script, <>, and see result: + +bash-2.05# perl testdbi.pl + +Running testdbi.pl... + + (*) Attempting Oracle Login ... + OK + (*) Creating table TEST_DBI ... + OK + (*) Insert into TEST_DBI ... + 1 rows inserted. + 1 rows inserted. + 1 rows inserted. + OK + (*) Select from TEST_DBI ... + + --> TEST_DBI_INTR_NO : 1000 + --> TEST_DBI_NAME : Jeff Hunter + + --> TEST_DBI_INTR_NO : 1001 + --> TEST_DBI_NAME : Melody Hunter + + --> TEST_DBI_INTR_NO : 1002 + --> TEST_DBI_NAME : Alex Hunter + OK + + (*) Delete from TEST_DBI ... + 3 rows deleted. + OK + + (*) Drop table TEST_DBI ... + OK + + (*) Select USER and SYSTEM ... + + --> USER : STARSHIP + --> SYSDATE : 21-DEC-2004 16:49:59 + OK + + (*) Attempting Oracle Logoff ... + OK + +Ending testdbi.pl... + +With the best regards, + +Alex Zarutin + +Software Engineer +4thpass A Motorola Company +Seattle, WA +www.4thpass.com + + + + diff --git a/err_build/err_testfailnotable.msg b/err_build/err_testfailnotable.msg new file mode 100644 index 00000000..687d5ed7 --- /dev/null +++ b/err_build/err_testfailnotable.msg @@ -0,0 +1,97 @@ +From SRS0=RhpE=NO=perl.org=dbi-dev-return-3750-Tim.Bunce=pobox.com@bounce2.pobox.com Wed Oct 27 18:10:51 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i9RHAOAK026067 + for ; Wed, 27 Oct 2004 18:10:51 +0100 (BST) + (envelope-from SRS0=RhpE=NO=perl.org=dbi-dev-return-3750-Tim.Bunce=pobox.com@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 27 Oct 2004 18:10:51 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CMp30-0000e2-Hh; + Wed, 27 Oct 2004 14:45:10 +0000 +Received: from [194.217.242.77] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CMp30-0000e2-Hh + for pobox@data-plan.com; Wed, 27 Oct 2004 14:45:10 +0000 +Received: from [208.210.124.73] (helo=gold.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1CMp30-0001QS-2p + for pobox@data-plan.com; Wed, 27 Oct 2004 14:45:10 +0000 +Received: from gold.pobox.com (localhost [127.0.0.1]) + by gold.pobox.com (Postfix) with ESMTP id 87C155A7D; + Wed, 27 Oct 2004 10:45:09 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from gold (localhost [127.0.0.1]) + by gold.pobox.com (Postfix) with ESMTP id 7779A59A1 + for ; Wed, 27 Oct 2004 10:45:09 -0400 (EDT) +Received-SPF: pass (gold.pobox.com: domain of dbi-dev-return-3750-Tim.Bunce=pobox.com@perl.org designates 63.251.223.186 as permitted sender) +X-SPF-Guess: pass (seems reasonable for dbi-dev-return-3750-Tim.Bunce=pobox.com@perl.org to mail through 63.251.223.186) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 63.251.223.186(x6.develooper.com) +Received: from lists.develooper.com (x6.develooper.com [63.251.223.186]) + by gold.pobox.com (Postfix) with SMTP id DC5795A4A + for ; Wed, 27 Oct 2004 10:45:07 -0400 (EDT) +Received: (qmail 18140 invoked by uid 514); 27 Oct 2004 14:45:04 -0000 +Mailing-List: contact dbi-dev-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-dev@perl.org +Received: (qmail 18131 invoked from network); 27 Oct 2004 14:45:04 -0000 +Received: from x1.develooper.com (63.251.223.170) + by lists.develooper.com with SMTP; 27 Oct 2004 14:45:04 -0000 +Received: (qmail 8663 invoked by uid 225); 27 Oct 2004 14:45:03 -0000 +Delivered-To: dbi-dev@perl.org +Received: (qmail 8659 invoked by alias); 27 Oct 2004 14:45:03 -0000 +X-Spam-Status: No, hits=-4.9 required=8.0 + tests=BAYES_00 +X-Spam-Check-By: la.mx.develooper.com +Received: from ns2.aramiska.net (HELO dmzms01.aramiska.net) (80.242.32.2) + by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 27 Oct 2004 07:45:01 -0700 +Received: from ip-80-242-36-115.aramiska-arc.aramiska.net (ip-80-242-36-115.aramiska-arc.aramiska.net [80.242.36.115]) + by dmzms01.aramiska.net (Postfix) with ESMTP + id 9F21E1100D9; Wed, 27 Oct 2004 14:44:55 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by ip-80-242-36-115.aramiska-arc.aramiska.net (Postfix) with ESMTP + id E558E7C; Wed, 27 Oct 2004 14:44:52 +0000 (UTC) +Received: from dansat.data-plan.com (ip-192-168-0-3.internal.data-plan.aramiska.net [192.168.0.3]) + by ip-80-242-36-115.aramiska-arc.aramiska.net (Postfix) with ESMTP + id D8A5E71; Wed, 27 Oct 2004 14:44:50 +0000 (UTC) +Received: from dansat.data-plan.com (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i9REioAA023212; + Wed, 27 Oct 2004 15:44:50 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: (from timbo@localhost) + by dansat.data-plan.com (8.12.9/8.12.9/Submit) id i9REinmW023211; + Wed, 27 Oct 2004 15:44:49 +0100 (BST) +Date: Wed, 27 Oct 2004 15:44:49 +0100 +From: Tim Bunce +To: "H.Merijn Brand" +Cc: Tim Bunce , DBI developers +Subject: Re: ANNOUNCE: DBD::Oracle 1.16 +Message-ID: <20041027144449.GB19991@dansat.data-plan.com> +References: <20041022213625.GA22377@dansat.data-plan.com> <20041027093516.D001.H.M.BRAND@hccnet.nl> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <20041027093516.D001.H.M.BRAND@hccnet.nl> +User-Agent: Mutt/1.4i +X-Virus-Scanned: by Aramiska Arc +Status: RO +Content-Length: 634 +Lines: 14 + +On Wed, Oct 27, 2004 at 09:39:33AM +0200, H.Merijn Brand wrote: +> On Fri 22 Oct 2004 23:36, Tim Bunce wrote: +> > file: $CPAN/authors/id/T/TI/TIMB/DBD-Oracle-1.16.tar.gz +> > size: 235224 bytes +> > md5: 9711550ed0ebfc743920a6a357ed717c +> +> I know you can't blame the test for not being able to create a table for the +> reason this failure shows, but there might be a more user-friendly way to fail ... + +Yeap. Some tests behave better in that situation. Looks like those +two need improving. Patches welcome! (I'd happily not touch DBD::Oracle +for a few months after the pain of the last few months :) + +Tim. + diff --git a/err_docs/err_trace.msg b/err_docs/err_trace.msg new file mode 100644 index 00000000..3d7500fb --- /dev/null +++ b/err_docs/err_trace.msg @@ -0,0 +1,14 @@ +Add this to the DBD::Oracle docs as a handy note: + +$dbh->do(q{alter session set events '65285 trace name errorstack level 3'}); + +A trace file should then be generated. + +Trace files are generated in the 'user_dump_destination' specified in init.ora. + +Try $ORACLE_BASE/admin/$ORACLE_SID/udump. + +or the location returned by +select value +from v$parameter +where name like '%user_dump%' diff --git a/err_executearray.msg b/err_executearray.msg new file mode 100644 index 00000000..f80c4980 --- /dev/null +++ b/err_executearray.msg @@ -0,0 +1,129 @@ +From kn@sifira.dk Mon Mar 1 07:12:20 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i217CIwY019357 + for ; Mon, 1 Mar 2004 07:12:20 GMT + (envelope-from kn@sifira.dk) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Mon, 01 Mar 2004 07:12:20 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AxXyq-00025R-43; + Sun, 29 Feb 2004 20:56:08 +0000 +Received: from [194.217.242.71] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1AxXyq-00025R-43 + for pobox@dbi.demon.co.uk; Sun, 29 Feb 2004 20:56:08 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1AxXyp-0007In-Tg + for pobox@dbi.demon.co.uk; Sun, 29 Feb 2004 20:56:08 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 082DD53C0A + for ; Sun, 29 Feb 2004 15:56:07 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 7412553CFB + for ; Sun, 29 Feb 2004 15:56:06 -0500 (EST) +Received: from mail.int.sifira.dk (stone.sifira.dk [217.157.24.2]) + by boggle.pobox.com (Postfix) with ESMTP + for ; Sun, 29 Feb 2004 15:56:03 -0500 (EST) +Received: from ash.int.sifira.dk (ash.int.sifira.dk [192.168.1.7]) + by mail.int.sifira.dk (Postfix) with ESMTP id 1C16974F58 + for ; Sun, 29 Feb 2004 21:55:36 +0100 (MET) +Sender: kn@sifira.dk +To: Tim Bunce +Subject: Re: Theory/Algorithm question +References: <48FB76BF31A47C4B9893827DEDF7DF2A03A08CF7@sacexch01.lan.towerrecords.com> + <7sfzjdrkv2.fsf@ash.int.sifira.dk> + <20030905085909.GR12308@dansat.data-plan.com> + <7ssmnbr44t.fsf@ash.int.sifira.dk> + <20040228153840.GA9857@dansat.data-plan.com> +From: Kristian Nielsen +Date: 29 Feb 2004 21:56:00 +0100 +In-Reply-To: <20040228153840.GA9857@dansat.data-plan.com> +Message-ID: <7sd67xk3kv.fsf@ash.int.sifira.dk> +User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Status: RO +Content-Length: 3630 +Lines: 78 + +Hi Tim, + +Tim Bunce writes: + +> Where did we get to with this? + +> > Ok, I will merge it into the new DBD::Oracle when that is out. It really +> > needs to be made to fit better into the execute_for_fetch() and stuff in +> > the new DBI, and I will be happy to modify it to whatever preferences + +What I have is a patch for DBD::Oracle 1.14. This patch contains its own +implementation of execute_array(), based on the one in DBI 1.30. + +The problem with this is of course that DBD::Oracle should not implement +execute_array itself. The way I understand it is that currently drivers +are supposed to implement execute_for_fetch(), and DBI will use that to +implement the higher-level execute_array() functionality. I see three +possibilities: + +1. As you may remember, the count of bind values must be known up-front +before calling into OCI because of OCI limitations. So to switch to the +execute_for_fetch() approach DBD::Oracle must buffer bind tuples in +chunks that are passed to OCI individually. This introduces the annoying +requirement to think about the chunk size. It also introduces some +inefficiencies in the array->tuple_fetch_sub->array conversion. However +if this is what you prefer it would be simple for me to adapt the patch. + +2. A better way might be to add an optional third parameter to +execute_for_fetch(): the number of bind tuples. If this parameter is +supplied, DBD::Oracle should be able to implement execute_for_fetch() +without buffering in chunks; this would be utilised by DBI in +execute_array() by passing the third parameter in the cases where an +array is supplied by the programmer. If the count parameter is not +supplied, DBD::Oracle would fall-back to buffering in chunks. The +disadvantage of this is that I would probably have to do some work to +adapt the patch to implement this, but I would be willing to take a shot +if you feel this is the best solution (I think it probably is). + +3. The final option would be for DBI to be extended so that it could +somehow detect both native array execute and native execute_for_fetch() +in the driver. It would thus detect that DBD::Oracle supports array +execute directly, but not execute_for_fetch(). DBI would then implement +the bind_param_array() version of execute_array() using the DBD::Oracle +array exec functionality, but would emulate execute_for_fetch() by +buffering tuples. Another driver might implement only execute_for_fetch(), +and DBI would emulate bind_param_array() using that (as it currently +does). + +So I would like to hear your opinion on which approach to settle on. If +you have no strong opinions I guess we should go for method 1 since it +needs no changes to DBI and requires the least amount of work for me... + + +A couple of other issues: + +I think there should be added to DBI an easy way to supply a row-wise +array of bind tuples to execute_array(). In my patch I implemented this +with an ArrayTuple attribute for execute_array(). + +There is also the issue that this will only work for Oracle >= 8.1.5. +Any thoughts on the need to fall back to default DBI behaviour for early +Oracle 8.x.y (this would require detecting server version)? And what +about OCI 7, is support for that going out? + +Currently this doesn't work for returning results. I will want to add +that later; while SELECT is maybe not so useful, it will be needed for +stuff like + + INSERT INTO mytable(a,b) VALUES(mysequence.nextval, ?) RETURNING a + +Maybe there will be some issues here for the interface to DBI similar to +the issues with drivers permitting multiple result sets? + + - Kristian. + +-- +Kristian Nielsen kn@sifira.dk +Development Manager, Sifira A/S + + diff --git a/err_lob/err_csr_clob.msg b/err_lob/err_csr_clob.msg new file mode 100644 index 00000000..397d53b3 --- /dev/null +++ b/err_lob/err_csr_clob.msg @@ -0,0 +1,65 @@ +From dbi-users-bounce@isc.org Thu Sep 21 20:27:21 2000 +Return-Path: +Received: from oink by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id UAA18945; Thu, 21 Sep 2000 20:27:20 +0100 (BST) +Received: from tele-punt-22.mail.demon.net by oink with SMTP (PP) + id <02709-1@oink>; Mon, 21 Sep 1970 20:26:40 +0100 +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 969564156:20:26825:1; Thu, 21 Sep 2000 19:22:36 GMT +Received: from pub3.rc.vix.com ([204.152.186.34]) by punt-2.mail.demon.net + id aa2026778; 21 Sep 2000 19:22 GMT +Received: from pub3.rc.vix.com (pub3.rc.vix.com [204.152.186.34]) + by pub3.rc.vix.com (Postfix) with ESMTP id 28A613E5D; + Thu, 21 Sep 2000 12:22:17 -0700 (PDT) +Received: with LISTAR (v1.0.0; list dbi-users); + Thu, 21 Sep 2000 12:17:37 -0700 (PDT) +Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.87]) + by pub3.rc.vix.com (Postfix) with ESMTP id A59853E42 + for ; + Thu, 21 Sep 2000 12:17:32 -0700 (PDT) +Received: from wheel.cs.wisc.edu (wheel.cs.wisc.edu [128.105.121.12]) + by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id MAA00855 + for ; + Thu, 21 Sep 2000 12:17:32 -0700 (PDT) env-from (horn@wheel.cs.wisc.edu) +Received: (from horn@localhost) by wheel.cs.wisc.edu (8.9.2/8.9.2) id OAA16413 + for dbi-users@isc.org; Thu, 21 Sep 2000 14:17:28 -0500 (CDT) +Date: Thu, 21 Sep 2000 14:17:28 -0500 (CDT) +From: Jeffrey Horn +Message-Id: <200009211917.OAA16413@wheel.cs.wisc.edu> +To: dbi-users@isc.org +Subject: Setting ORA_TYPE after the fact... +Sender: horn@wheel.cs.wisc.edu +Sender: dbi-users-bounce@isc.org +Errors-To: dbi-users-bounce@isc.org +X-original-sender: horn@cs.wisc.edu +Precedence: bulk +List-unsubscribe: +X-List-ID: +List-owner: +List-post: +Status: RO +X-Status: A +Content-Length: 969 +Lines: 20 + +I have a situation where I would like to return a cursor that contains a +CLOB as one of it's attributes from a PL/SQL procedure. What I get back is +a LOB locator and DBD doesn't actually read the CLOB but instead returns an +error. + +If I go through a bind/prepare/execute/fetch on a similar SQL statement all +is well. Is there any way that I can tell DBD that a given attribute of +a cursor is a CLOB once the cursor is already opened so that DBD will do the +right thing? + +-- Jeff Horn + + +------------------------------------------------------------------------------ +DBI HOME PAGE AND ARCHIVES: http://www.symbolstone.org/technology/perl/DBI/ +To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html +If you are without web access, or if you are having trouble with the web page, +please send mail to dbi-users-request@isc.org with the subject line of: +'unsubscribe'. +------------------------------------------------------------------------------ + diff --git a/err_lob/err_loblenwide.msg b/err_lob/err_loblenwide.msg new file mode 100644 index 00000000..08023e97 --- /dev/null +++ b/err_lob/err_loblenwide.msg @@ -0,0 +1,95 @@ +From nobody@fsck.com Thu Dec 4 07:36:20 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id hB47Y2nE066844 + for ; Thu, 4 Dec 2003 07:36:20 GMT + (envelope-from nobody@fsck.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 04 Dec 2003 07:36:20 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1ARgrA-0005O4-5M; + Wed, 03 Dec 2003 23:56:32 +0000 +Received: from [207.8.214.2] (helo=icicle.pobox.com) + by punt-3.mail.demon.net with esmtp id 1ARgrA-0005O4-5M + for pobox@dbi.demon.co.uk; Wed, 03 Dec 2003 23:56:32 +0000 +Received: from icicle.pobox.com (localhost[127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 314AB9A28F + for ; Wed, 3 Dec 2003 18:56:32 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost[127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 188369A287 + for ; Wed, 3 Dec 2003 18:56:32 -0500 (EST) +Received: from x1.develooper.com (x1.develooper.com[63.251.223.170]) + by icicle.pobox.com (Postfix) with SMTP + for ; Wed, 3 Dec 2003 18:56:31 -0500 (EST) +Received: (qmail 3178 invoked by uid 225); 3 Dec 2003 23:56:30 -0000 +Delivered-To: TIMB@cpan.org +Received: (qmail 3174 invoked by alias); 3 Dec 2003 23:56:29 -0000 +Received: from pallas.eruditorum.org (HELO pallas.eruditorum.org) (63.251.136.85) by la.mx.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Wed, 03 Dec 2003 15:56:18 -0800 +Received: by pallas.eruditorum.org (Postfix, from userid 65534) id 91512114F1; Wed, 3 Dec 2003 18:56:07 -0500 (EST) +Subject: [cpan #4564] Perl DBI bug handling CLOBs +From: "Jay Turner via RT" +Reply-To: bug-DBI@rt.cpan.org +In-Reply-To: +Message-ID: +Precedence: bulk +X-RT-Loop-Prevention: cpan +RT-Ticket: cpan #4564 +Managed-by: RT 2.0.15 (http://bestpractical.com/rt/) +RT-Originator: J.Turner@mdl.com +To: "AdminCc of cpan Ticket #4564": ; +Date: Wed, 3 Dec 2003 18:56:07 -0500 (EST) +X-Spam-Check-By: la.mx.develooper.com +X-Spam-Status: No, hits=2.1 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,SPAM_PHRASE_01_02,TO_HAS_SPACES,TO_MALFORMED version=2.44 +Status: RO +X-Status: A +Content-Length: 1853 +Lines: 46 + + +This message about DBI was sent to you by J.Turner@mdl.com via rt.cpan.org + +Full context and any attached attachments can be found at: + + + +Date: Fri, 28 Feb 2003 16:55:28 -0800 + +It has come to my attention that PERL DBI counts on OCILobGetLength +returning BYTES. It returns CHARACTERS instead, which is the count of +variable-width characters. For multi-byte character sets this results +in errors such as: + +DBD::Oracle::st fetch failed: ORA-03130: the buffer for the next piece +to be fetched is required (DBD ERROR: OCILobGetLength) at id rmsc01.pl +line 294. + +The correct way to read CLOBs is + +1) Query the LOB locator for the CSID and CSFRM (character set ID and +form). A character set >= 800 is a mulitbyte character set and csfrm +<> 0 is CLOB. + +2) Pass the CSID and CSFRM to OCILobRead with AMT=0 and pass your +buffer address and size. + +3) Your callback routine must either be capable of completing the I/O +by allocating additional buffers, or it must notify the caller of +OCILobRead to free the lob locator, since an incomplete read jams the +locator-you can't use it for anything else without finishing the read +(attempts to reuse the locator will result in errors). + +Likewise, with OCILobWrite, you have to pass the CSID and CSFRM, with +AMT=0 and the buffer size in bytes. The callback can just say it has +zero bytes and set piece=OCI_LAST_PIECE. + +You cannot use the return value of OCILobGetLength as the size of the +data that is being read. The actual size of the data is unknown for +variable-width characters, and the buffer has to be big enough to +accomplish the translation, so you can't just double or triple the +return value from OCILobGetLength (I have seen that approach fail). + +You can simulate the effects of a foreign character set by + +$ export NLS_LANG=Japanese + diff --git a/err_lob/err_lobtesttblfail.msg b/err_lob/err_lobtesttblfail.msg new file mode 100644 index 00000000..1333ee88 --- /dev/null +++ b/err_lob/err_lobtesttblfail.msg @@ -0,0 +1,208 @@ +From SRS0=sbeK=NO=perl.org=dbi-dev-return-3749-Tim.Bunce=pobox.com@bounce2.pobox.com Wed Oct 27 15:22:22 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i9RELAAO018624 + for ; Wed, 27 Oct 2004 15:22:22 +0100 (BST) + (envelope-from SRS0=sbeK=NO=perl.org=dbi-dev-return-3749-Tim.Bunce=pobox.com@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 27 Oct 2004 15:22:22 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CMiQ8-0000Eo-FG; + Wed, 27 Oct 2004 07:40:36 +0000 +Received: from [194.217.242.72] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CMiQ8-0000Eo-FG + for pobox@data-plan.com; Wed, 27 Oct 2004 07:40:36 +0000 +Received: from [207.8.226.3] (helo=icicle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1CMiQ8-0006dS-9n + for pobox@data-plan.com; Wed, 27 Oct 2004 07:40:36 +0000 +Received: from icicle.pobox.com (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id B3BB911C325; + Wed, 27 Oct 2004 03:40:35 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from icicle (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 9947911C2CE + for ; Wed, 27 Oct 2004 03:40:35 -0400 (EDT) +Received-SPF: pass (icicle.pobox.com: domain of dbi-dev-return-3749-Tim.Bunce=pobox.com@perl.org designates 63.251.223.186 as permitted sender) +X-SPF-Guess: pass (seems reasonable for dbi-dev-return-3749-Tim.Bunce=pobox.com@perl.org to mail through 63.251.223.186) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 63.251.223.186(x6.develooper.com) +Received: from lists.develooper.com (x6.develooper.com [63.251.223.186]) + by icicle.pobox.com (Postfix) with SMTP id 5033611C34F + for ; Wed, 27 Oct 2004 03:39:46 -0400 (EDT) +Received: (qmail 12004 invoked by uid 514); 27 Oct 2004 07:39:43 -0000 +Mailing-List: contact dbi-dev-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-dev@perl.org +Received: (qmail 11995 invoked from network); 27 Oct 2004 07:39:43 -0000 +Received: from x1.develooper.com (63.251.223.170) + by lists.develooper.com with SMTP; 27 Oct 2004 07:39:43 -0000 +Received: (qmail 13565 invoked by uid 225); 27 Oct 2004 07:39:43 -0000 +Delivered-To: dbi-dev@perl.org +Received: (qmail 13560 invoked by alias); 27 Oct 2004 07:39:42 -0000 +X-Spam-Status: No, hits=-3.7 required=8.0 + tests=BAYES_00,LARGE_HEX +X-Spam-Check-By: la.mx.develooper.com +Received: from smtp-vbr15.xs4all.nl (HELO smtp-vbr15.xs4all.nl) (194.109.24.35) + by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Wed, 27 Oct 2004 00:39:40 -0700 +Received: from [127.0.0.1] (procura.xs4all.nl [213.84.163.145]) + by smtp-vbr15.xs4all.nl (8.12.11/8.12.11) with ESMTP id i9R7dWHI013040; + Wed, 27 Oct 2004 09:39:34 +0200 (CEST) + (envelope-from h.m.brand@hccnet.nl) +Date: Wed, 27 Oct 2004 09:39:33 +0200 +From: "H.Merijn Brand" +To: Tim Bunce +Subject: Re: ANNOUNCE: DBD::Oracle 1.16 +Cc: DBI developers +In-Reply-To: <20041022213625.GA22377@dansat.data-plan.com> +References: <20041022213625.GA22377@dansat.data-plan.com> +Message-Id: <20041027093516.D001.H.M.BRAND@hccnet.nl> +MIME-Version: 1.0 +Content-Type: text/plain; charset="US-ASCII" +X-Mailer: Becky! ver. 2.11.02 [en] +X-Virus-Scanned: by XS4ALL Virus Scanner +X-Virus-Checked: Checked +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by dansat.data-plan.com id i9RELAAO018624 +Status: RO +X-Status: A +Content-Length: 7175 +Lines: 134 + +On Fri 22 Oct 2004 23:36, Tim Bunce wrote: +> file: $CPAN/authors/id/T/TI/TIMB/DBD-Oracle-1.16.tar.gz +> size: 235224 bytes +> md5: 9711550ed0ebfc743920a6a357ed717c + +I know you can't blame the test for not being able to create a table for the +reason this failure shows, but there might be a more user-friendly way to fail ... + +I'll report back when the DBA has fixed the tablespace + +HP-UX 11.11/64 (11i) + Oracle-9.2.0/64 + perl-5.8.5-dor/64 + +PERL_DL_NONLAZY=1 /pro/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, +'blib/lib', 'blib/arch')" t/*.t +t/01base................ok +t/10general.............ok +t/15nls.................ok +t/20select..............ok +t/21nchar............... Database and client versions and character sets: +Database 9.2.0.1.0 CHAR set is US7ASCII (Non-Unicode), NCHAR set is AL16UTF16 ( +nicode) +Client 9.2.0.1 NLS_LANG is '', NLS_NCHAR is '' +t/21nchar...............ok +t/22nchar_al32utf8......ok +t/22nchar_utf8..........ok +t/23wide_db.............skipped + all skipped: Database character set is not Unicode +t/23wide_db_8bit........skipped + all skipped: Database character set is not Unicode +t/23wide_db_al32utf8....skipped + all skipped: Database character set is not Unicode +t/24implicit_utf8.......ok +t/25plsql...............ok +t/30long................ok 188/470DBD::Oracle::db do failed: ORA-03237: Initial +Extent of specified size cannot be allocated in tablespace (PROBEV) (DBD ERROR: +OCIStmtExecute) [for Statement "create table dbd_ora__drop_me ( idx integer, ln + NCLOB, dt date )"] at t/nchar_test_lib.pl line 356. +t/30long................ok 189/470DBD::Oracle::st execute failed: ORA-00942: ta +le or view does not exist (DBD ERROR: error possibly near <*> indicator at char +12 in 'insert into <*>dbd_ora__drop_me values (:p1, :p2, SYSDATE)') [for Statem +nt "insert into dbd_ora__drop_me values (?, ?, SYSDATE)" with ParamValues: :p1= +0, :p2='0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0 +x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0 +x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0 +x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0 +x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0.x.X0 +x.X...'] at t/30long.t line 153. +# Failed test (t/30long.t at line 153) +t/30long................NOK 190DBD::Oracle::st execute failed: ORA-00942: table +or view does not exist (DBD ERROR: error possibly near <*> indicator at char 12 +in 'insert into <*>dbd_ora__drop_me values (:p1, :p2, SYSDATE)') [for Statement +"insert into dbd_ora__drop_me values (?, ?, SYSDATE)" with ParamValues: :p1=41, +:p2='12345678901234567890123456789012345678901234567890123456789012345678901234 +6789012345678901234567890123456789012345678901234567890123456789012345678901234 +6789012345678901234567890123456789012345678901234567890123456789012345678901234 +6789012345678901234567890123456789012345678901234567890123456789012345678901234 +6789012345678901234567890123456789012345678901234567890123456789012345678901234 +...'] at t/30long.t line 154. +# Failed test (t/30long.t at line 154) +t/30long................NOK 191DBD::Oracle::st execute failed: ORA-00942: table +or view does not exist (DBD ERROR: error possibly near <*> indicator at char 12 +in 'insert into <*>dbd_ora__drop_me values (:p1, :p2, SYSDATE)') [for Statement +"insert into dbd_ora__drop_me values (?, ?, SYSDATE)" with ParamValues: :p1=42, +:p2='2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcd +fabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcd +fabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcd +fabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcd +fabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcdefabcd2bcd +...'] at t/30long.t line 155. +t/30long................NOK 192# Failed test (t/30long.t at line 155) +DBD::Oracle::st execute failed: ORA-00942: table or view does not exist (DBD ER +OR: error possibly near <*> indicator at char 12 in 'insert into <*>dbd_ora__dr +p_me values (:p1, :p2, SYSDATE)') [for Statement "insert into dbd_ora__drop_me +alues (?, ?, SYSDATE)" with ParamValues: :p1=43, :p2=undef] at t/30long.t line +56. +# Failed test (t/30long.t at line 156) +t/30long................NOK 193DBD::Oracle::db prepare failed: ORA-00942: table +or view does not exist (DBD ERROR: error possibly near <*> indicator at char 14 +in 'select * from <*>dbd_ora__drop_me order by idx') [for Statement "select * f +om dbd_ora__drop_me order by idx"] at t/30long.t line 170. +# Failed test (t/30long.t at line 170) +Can't call method "trace" on an undefined value at t/30long.t line 171. +t/30long................NOK 194# Looks like you planned 470 tests but only ran +94. +# Looks like your test died just after 194. +t/30long................dubious + Test returned status 255 (wstat 65280, 0xff00) +DIED. FAILED tests 190-470 + Failed 281/470 tests, 40.21% okay (less 122 skipped tests: 67 okay, 14. +6%) +t/31lob.................DBD::Oracle::db do failed: ORA-03237: Initial Extent of +specified size cannot be allocated in tablespace (PROBEV) (DBD ERROR: OCIStmtEx +cute) [for Statement " + CREATE TABLE dbd_ora__drop_me ( + id INTEGER NOT NULL, + data BLOB + ) + "] at t/31lob.t line 21. +DBD::Oracle::db do failed: ORA-00942: table or view does not exist (DBD ERROR: +rror possibly near <*> indicator at char 12 in 'INSERT INTO <*>dbd_ora__drop_me +(id,data) VALUES (1, EMPTY_BLOB())') [for Statement "INSERT INTO dbd_ora__drop_ +e (id,data) VALUES (1, EMPTY_BLOB())"] at t/31lob.t line 31. +DBD::Oracle::db prepare failed: ORA-00942: table or view does not exist (DBD ER +OR: error possibly near <*> indicator at char 17 in 'SELECT data FROM <*>dbd_or +__drop_me WHERE id = :p1') [for Statement "SELECT data FROM dbd_ora__drop_me WH +RE id = ?"] at t/31lob.t line 34. +Can't call method "bind_param" on an undefined value at t/31lob.t line 36. +# Looks like your test died before it could output anything. +t/31lob.................dubious + Test returned status 255 (wstat 65280, 0xff00) +DIED. FAILED tests 1-2 + Failed 2/2 tests, 0.00% okay +t/40ph_type.............ok +t/50cursor..............ok +t/60reauth..............ORACLE_USERID_2 not defined. Tests skipped. +skipped + all skipped: no reason given +t/70meta................ok +Failed Test Stat Wstat Total Fail Failed List of Failed +------------------------------------------------------------------------------- +t/30long.t 255 65280 470 557 118.51% 190-470 +t/31lob.t 255 65280 2 4 200.00% 1-2 +4 tests and 122 subtests skipped. +Failed 2/18 test scripts, 88.89% okay. 283/1883 subtests failed, 84.97% okay. +make: *** [test_dynamic] Error 255 + +-- +H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) +using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, + WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify +ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ + + + + diff --git a/err_lob/err_nclob_form.msg b/err_lob/err_nclob_form.msg new file mode 100644 index 00000000..05587693 --- /dev/null +++ b/err_lob/err_nclob_form.msg @@ -0,0 +1,189 @@ +From dbi-users-return-19548-Tim.Bunce=pobox.com@perl.org Tue Jul 22 07:40:59 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id h6M6UUD7096422 + for ; Tue, 22 Jul 2003 07:40:58 +0100 (BST) + (envelope-from dbi-users-return-19548-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 22 Jul 2003 07:40:58 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1058814697:11:26523:33; Mon, 21 Jul 2003 19:11:37 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1126786; 21 Jul 2003 19:11 GMT +Received: from dolly1.pobox.com (localhost [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id E855B21C37F + for ; Mon, 21 Jul 2003 15:11:18 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [64.70.54.95]) + by dolly1.pobox.com (Postfix) with SMTP id 9010121C236 + for ; Mon, 21 Jul 2003 15:11:17 -0400 (EDT) +Received: (qmail 66848 invoked by uid 1005); 21 Jul 2003 19:11:15 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 66832 invoked by uid 76); 21 Jul 2003 19:11:15 -0000 +Received: from qmailr@one.develooper.com (HELO ran-out.mx.develooper.com) (64.81.84.115) by onion.perl.org (qpsmtpd/0.26) with SMTP; Mon, 21 Jul 2003 12:11:15 -0700 +Received: (qmail 559 invoked by uid 225); 21 Jul 2003 19:11:08 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 552 invoked by uid 507); 21 Jul 2003 19:11:07 -0000 +Received-SPF: unknown +Received: from sneakemail.com (HELO monkey.sneakemail.com) (207.106.87.13) by one.develooper.com (qpsmtpd/0.27-dev) with SMTP; Mon, 21 Jul 2003 12:11:03 -0700 +Received: (qmail 22505 invoked by uid 501); 21 Jul 2003 19:10:57 -0000 +Received: (sneakemail censored 13502-46198 #3); 21 Jul 2003 19:10:57 -0000 +Received: (sneakemail censored 13502-46198 #2); 21 Jul 2003 19:10:57 -0000 +Received: (sneakemail censored 13502-46198 #1); 21 Jul 2003 19:10:57 -0000 +Date: Mon, 21 Jul 2003 21:10:53 +0200 +From: "Wolfgang Weisselberg" +To: dbi-users@perl.org +Subject: DBD::Oracle and unicode-NCLOBs leads to ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) +Message-ID: <13502-46198@sneakemail.com> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.4.1i +X-SMTPD: qpsmtpd/0.27-dev, http://develooper.com/code/qpsmtpd/ +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=0.6 required=7.0 tests=CARRIAGE_RETURNS,FROM_ENDS_IN_NUMS,FROM_HAS_MIXED_NUMS,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Status: RO +X-Status: A +Content-Length: 6055 +Lines: 132 + +Hello all! + +Even after extensive googling and looking through the docs I fail +to fetch NCLOBs from an Oracle 9.2i database where the national +character set is unicode. + +I believe it has been done before, but I could not find anything ... +I would be grateful for any pointers. + + +NCLOBs work like CLOBs when the national character set is not +unicode, even with the old DBI 1.21 and DBD::Oracle 1.12 on an +Oracle 8 client. NVarchar2 and NChar work OK even with unicode. + +Setting NSL_LANG to AMERICAN_AMERICA.UTF8 or .AL32UTF8 does not +help, as I suspected. + +I tried using Oracle 9.2i (the DB is using 9.2i) on a Debian +Linux box. I upgraded DBI to 1.37 and DBD::Oracle to 1.14 (the +newest versions according to CPAN). I got zero errors on make +test with both. Perl is Debian's normal "perl5 (revision 5.0 +version 6 subversion 1)". + +A simple + select memo from unicode_test +(memo being the NCLOB field) fails (again, only with the national +charset being unicode). + +The relevant code snippet (RaiseError being set, of course): + +| $| = 1; +| print "DBI: $DBI::VERSION\n", +| "DBD::Oracle $DBD::Oracle::VERSION\n"; +| my $sth = $dbh->prepare("select memo from unicode_test"); +| $sth->execute(); +| +| while ( my ($memo) = $sth->fetchrow_array() ) { +| print Dumper $memo; +| } +| exit; + + +The output: + +| DBI: 1.37 +| DBD::Oracle 1.14 +| $VAR1 = ''; +| $VAR1 = ''; +| DBD::Oracle::st fetchrow_array failed: ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) [for statement ``select memo from unicode_test'' with params: ]) at nclobtest.pl line 77. +| DBD::Oracle::st fetchrow_array failed: ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) [for statement ``select memo from unicode_test'' with params: ]) at nclobtest.pl line 77. + + + +Running with tracelevel 3: + [...] +| dbd_st_prepare'd sql SELECT +| dbd_describe SELECT (EXPLICIT, lb 99999999)... +| fbh 1: 'MEMO' NO null , otype 112->112, dbsize 4000/4000, p0.s0 +| dbd_describe'd 1 columns (row bytes: 4000 max, 4000 est avg, cache: 6) +| <- prepare= DBI::st=HASH(0x831643c) at nclobtest.pl line 78 via nclobtest.pl line 60 +| -> execute for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +| dbd_st_execute SELECT (out0, lob0)... +| dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) +| <- execute= '0E0' at nclobtest.pl line 79 via nclobtest.pl line 60 +| -> fetchrow_array for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +| dbd_st_fetch 1 fields... +| dbih_setup_fbav for 1 fields => 0x82f8e34 +| dbd_st_fetch 1 fields SUCCESS +| OCILobRead field 2 SKIPPED: LOBlen 0, LongReadLen 99999999, BufLen 0, Got 0 +| <- fetchrow_array= ( '' ) [1 items] row1 at nclobtest.pl line 81 via nclobtest.pl line 60 +| $VAR1 = ''; +[EXACTLY the same "-> fetchrow_array" to "<- fetchrow_array" again] +| $VAR1 = ''; +| -> fetchrow_array for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +| dbd_st_fetch 1 fields... +| dbd_st_fetch 1 fields SUCCESS +| OCILobRead field 2 ERROR: LOBlen 6c, LongReadLen 99999999c, BufLen 24b, Got 6c +| !! ERROR: 24806 'ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead)' +| <- fetchrow_array= ( ) [0 items] row3 at nclobtest.pl line 81 via nclobtest.pl line 60 +| 1 -> FETCH for DBD::Oracle::st (DBI::st=HASH(0x82f8e28)~INNER 'ParamValues') +| error: 24806 'ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead)' +| 1 <- FETCH= HASH(0x831661c)0keys at nclobtest.pl line 81 via nclobtest.pl line 60 +| DBD::Oracle::st fetchrow_array failed: ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) [for statement ``select memo from unicode_test'' with params: ]) at nclobtest.pl line 81. +| DBD::Oracle::st fetchrow_array failed: ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead) [for statement ``select memo from unicode_test'' with params: ]) at nclobtest.pl line 81. + + + +Tracelevel 9 (yes, it's a bit verbose :-/ ) + +[...] +| OCIDescriptorAlloc(0x831c058,0x8395228,OCI_DTYPE_LOB,0,0) +| fbh 1: 'MEMO' NO null , otype 112->112, dbsize 4000/4000, p0.s0 +| OCIAttrSet(0x8335b34,OCI_HTYPE_STMT,0xbffff30c,4,11,0x832d5a4)=SUCCESS +| OCIDefineByPos(0x8335b34,0x8395224,0x832d5a4,1,0x8395228,-1,112,0x83414e0,0x83414f0,0x8341500,0)=SUCCESS +| dbd_describe'd 1 columns (row bytes: 4000 max, 4000 est avg, cache: 6) +| <- prepare= DBI::st=HASH(0x831643c) at nclobtest.pl line 78 via nclobtest.pl line 60 +| -> execute for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +[...] +| -> fetchrow_array for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +| dbd_st_fetch 1 fields... +| OCIStmtFetch(0x8335b34,0x832d5a4,1,2,0)=SUCCESS +| dbih_setup_fbav for 1 fields => 0x82f8e34 +| dbd_st_fetch 1 fields SUCCESS +| OCILobGetLength(0x832d530,0x832d5a4,0x832c69c,0xbffff31c)=SUCCESS +| OCILobRead field 2 SKIPPED: LOBlen 0, LongReadLen 99999999, BufLen 0, Got 0 +| 0 (rc=0): '' +| <- fetchrow_array= ( '' ) [1 items] row1 at nclobtest.pl line 81 via nclobtest.pl line 60 +| $VAR1 = ''; +[EXACTLY the same "-> fetchrow_array" to "<- fetchrow_array" again] +| $VAR1 = ''; +| -> fetchrow_array for DBD::Oracle::st (DBI::st=HASH(0x831643c)~0x82f8e28) +| dbd_st_fetch 1 fields... +| OCIStmtFetch(0x8335b34,0x832d5a4,1,2,0)=SUCCESS +| dbd_st_fetch 1 fields SUCCESS +| OCILobGetLength(0x832d530,0x832d5a4,0x832c69c,0xbffff31c)=SUCCESS +| OCILobRead(0x832d530,0x832d5a4,0x832c69c,0xbffff318,1,0x8394da0,24,(nil),(nil),0,1)=ERROR +| OCILobRead field 2 ERROR: LOBlen 6c, LongReadLen 99999999c, BufLen 24b, Got 6c +| OCIErrorGet(0x832d5a4,1,"",0xbfffee88,"ORA-24806: LOB form mismatch +| ",1024,2)=SUCCESS +| OCIErrorGet after OCILobRead (er1:ok): -1, 24806: ORA-24806: LOB form mismatch +| +| OCIErrorGet(0x832d5a4,2,"",0xbfffee88,"ORA-24806: LOB form mismatch +| ",1024,2)=NO_DATA +| 0 (rc=0): undef +| !! ERROR: 24806 'ORA-24806: LOB form mismatch (DBD ERROR: OCILobRead)' +| <- fetchrow_array= ( ) [0 items] row3 at nclobtest.pl line 81 via nclobtest.pl line 60 +[gets and prints error message] + + +Any ideas anyone? + +-Wolfgang + diff --git a/err_lob/err_nulllobsegv.msg b/err_lob/err_nulllobsegv.msg new file mode 100644 index 00000000..6de3c99b --- /dev/null +++ b/err_lob/err_nulllobsegv.msg @@ -0,0 +1,93 @@ +From dbi-users-return-1743-Tim.Bunce=ig.co.uk@perl.org Wed Apr 11 04:00:48 2001 +Return-Path: +Received: from oink by toad.ig.co.uk (8.8.8+Sun/SMI-SVR4) + id EAA17912; Wed, 11 Apr 2001 04:00:48 +0100 (BST) +Received: from 194.217.242.36 by oink with SMTP (PP) id <02579-1@oink>; + Sat, 11 Apr 1970 04:00:28 +0100 +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 986956750:10:04398:0; Wed, 11 Apr 2001 02:39:10 GMT +Received: from tmtowtdi.perl.org ([209.85.3.25]) by punt-1.mail.demon.net + id aa1106187; 11 Apr 2001 2:39 GMT +Received: (qmail 32618 invoked by uid 508); 11 Apr 2001 02:39:06 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 32603 invoked from network); 11 Apr 2001 02:39:05 -0000 +Received: from owns.warpcore.org (216.81.249.18) by tmtowtdi.perl.org with SMTP; + 11 Apr 2001 02:39:05 -0000 +Received: (from thebrain@localhost) by owns.warpcore.org (8.11.1/8.11.1) + id f3B2cxH06298 for dbi-users@perl.org; + Tue, 10 Apr 2001 21:38:59 -0500 +Date: Tue, 10 Apr 2001 21:38:59 -0500 +From: Stephen Clouse +To: dbi-users@perl.org +Subject: Bizarre DBD::Oracle Segfault +Message-ID: <20010410213859.B2766@owns.warpcore.org> +Mail-Followup-To: dbi-users@perl.org +Mime-Version: 1.0 +Content-Type: text/plain +Content-Disposition: inline; filename="msg.pgp" +User-Agent: Mutt/1.2.5i +Status: RO +Content-Length: 1918 +Lines: 54 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +I sent an email to the dbi-users list about a number of DBD::Oracle CLOB +handling problems waaaaaaaaaaaaaaay back (end of January or so) that today +someone dug up and inquired if I had ever found fixes for what I had pointed +out. + +The problems outlined that day turned out to be the test script itself, which +was doing so much bizarre stuff on one statement that DBD::Oracle just went to +sleep instead (and so was the actual program that instigated the writing of the +test script). + +Well, all but one problem was the script. This, the most serious one, continues +to linger: + +my $st = $db->prepare('INSERT INTO foo (col1, col2, col3) VALUES (?,?,?)'); +$st->bind_param(3,undef,{ ora_type => ORA_CLOB }); +$st->execute('A','A',undef); + +On Linux, DBI 1.15, Oracle 8.1.6, and DBD::Oracle 1.06, this segfaults on the +execute. Unfortunately this manifests itself too deep in Oracle for me to +debug. + +The bizarre part is, either of the two snippets below will work: + +my $st = $db->prepare('INSERT INTO foo (col1, col2, col3) VALUES (?,?,?)'); +$st->bind_param(3,undef,{ ora_type => ORA_CLOB }); +$st->execute('A','A',''); +$st->execute('B','B',undef); + +my $st = $db->prepare('INSERT INTO foo (col1, col2, col3) VALUES (?,?,?)'); +$st->bind_param(3,undef,{ ora_type => ORA_CLOB }); +$st->execute('A','A',$lobvalue); +$st->execute('B','B',undef); + +It's only when binding undef as the LOB value in the very first execute of a +statement that the segfault occurs. At any other time, it's kosher. That +qualifies as bizarre in my book. + +Your guess is better than mine. + +- -- +Stephen Clouse +Senior Programmer, IQ Coordinator Project Lead +The IQ Group, Inc. + +-----BEGIN PGP SIGNATURE----- +Version: PGP 6.5.8 + +iQA+AwUBOtPDwgOGqGs0PadnEQLmtgCeJHTStLu8Q8oFb9UQ4995f8vhZH8Al1p6 +RD5m0FEJH2tQiY0+b6542mQ= +=L0M+ +-----END PGP SIGNATURE----- + diff --git a/err_lob/err_tmplobfree.msg b/err_lob/err_tmplobfree.msg new file mode 100644 index 00000000..0ec8f940 --- /dev/null +++ b/err_lob/err_tmplobfree.msg @@ -0,0 +1,537 @@ +From SRS0=VEIf=LP=genericom.de=pl@bounce2.pobox.com Wed Aug 25 17:53:58 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7PGpkpQ033405 + for ; Wed, 25 Aug 2004 17:53:57 +0100 (BST) + (envelope-from SRS0=VEIf=LP=genericom.de=pl@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 25 Aug 2004 17:53:57 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1Bzyve-0007kY-Gp; + Wed, 25 Aug 2004 14:39:10 +0000 +Received: from [194.217.242.223] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1Bzyve-0007kY-Gp + for pobox@data-plan.com; Wed, 25 Aug 2004 14:39:10 +0000 +Received: from [208.58.1.198] (helo=lime.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1Bzyvd-0000zb-Lg + for pobox@data-plan.com; Wed, 25 Aug 2004 14:39:10 +0000 +Received: from lime.pobox.com (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id AA6D8B0635; + Wed, 25 Aug 2004 10:39:08 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from lime (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id 9B2A1B0BB0 + for ; Wed, 25 Aug 2004 10:39:08 -0400 (EDT) +Received-SPF: none (lime.pobox.com: domain of pl@genericom.de does not designate permitted sender hosts) +Received: from natnoddy.rzone.de (natnoddy.rzone.de [81.169.145.166]) + by lime.pobox.com (Postfix) with ESMTP id 2AAB1B0635 + for ; Wed, 25 Aug 2004 10:39:06 -0400 (EDT) +Received: from genericom.de (pD95195AC.dip.t-dialin.net [217.81.149.172]) + by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i7PEc05w018990 + for ; Wed, 25 Aug 2004 16:38:01 +0200 (MEST) +Sender: pl@post.webmailer.de +Message-ID: <412CA445.FC2F9EF2@genericom.de> +Date: Wed, 25 Aug 2004 16:37:57 +0200 +From: Philipp Lang +Organization: Genericom Software +X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.24 i686) +X-Accept-Language: de, en +MIME-Version: 1.0 +To: Tim.Bunce@pobox.com +Subject: DBD::Oracle: Freeing a temporary blob +Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4BC2D4519D41A502BB06559C" +Status: RO +X-Status: A +Content-Length: 4985 +Lines: 122 + +This is a cryptographically signed message in MIME format. + +--------------ms4BC2D4519D41A502BB06559C +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit + +Dear Tim, + +first, I would really like to thank you for the great work you have done +with your DBI/DBD work. We are using it extensively in several projects +and we are highly pleased. + +Unfortunately I have now encountered a problem we need to fix urgently, +since our customer's production is seriously affected. + +We tried for many days to find a solution (google, newsgroups, +trial-and-error...), without luck. So my last chance is to contact you +directly, although I assume you have a lot work yourself. + +--- + +The problem: + +Our database contains a stored function "ReadUnitBlob()" that returns a +temporary blob: + +function ReadUnitBlob(UnitID_IN in integer) return blob +is +... +begin + ... + dbms_lob.createtemporary(retBlob, false, dbms_lob.call); + dbms_lob.loadfromfile(retBlob, bfileIn, fileLen); + ... + return retBlob; +end; + +We call this function in Perl in a big loop to fetch a lot of blobs (~ +100000) using something like: + +my $sth = $DBH->prepare("select ReadUnitBlob(:unitID) from dual", { +ora_auto_lob => 0 }); +$sth->bind_param(":unitID", $unitID); +$sth->execute(); +my ($loc) = $sth->fetchrow_array(); +$sth->finish(); +... +while(my $data = $DBH->ora_lob_read($loc, $offset, $chunk_size)) + ... + +Although this works, it has a big disadvantage: Oracle does not +automaticaly free the temporary blob, so it shortly runs out of temp. +space. (confirmed with "select * from v$temporary_lobs"). + +Acording to the Oracle docs this can be we solved by implicitly freeing +the temp. blob, e.g. by calling the PLSQL method +"dbms_lob.freetemporary()". I tried differnt ways to do this with +DBD::Oracle, but never succeeded. I just did not manage to fetch the LOB +locator from the my stored procedure and to pass it to a call of +"dbms_lob.freetemporary()": + +my $sth = $dbh->prepare("begin :bloc := ReadUnitBlob(:unitID); end;", { +ora_auto_lob => 0 }); +my $bloc; +$sth->bind_param_inout( ":bloc", \$bloc, ORA_BLOB); +$sth->bind_param(":unitID", $unitID); +$sth->execute(); + +obviously the "ORA_BLOB" type for bind_param_inout() is wrong here ;) + +Can you help me??? Do you know a way how to free the temp. blob using +DBD::Oracle (using Oracle::OCI is not possible, since the customer is +strinctly refusing to install it). + +Otherwise, would it be possible include an additional DBD::Oracle LOB +Locator Method "ora_lob_freetemporary()" that warps +"OCILobFreeTemporary" ? + +Any help is really appreciated! + +Greeting from Germany, + + Philipp + +-- +Dipl. Inf. Philipp Lang Genericom Software GmbH +Tel. +49 (0)7031/8739-26 Tilsiter Str. 4-6 +Fax +49 (0)7031/8739-11 71065 Sindelfingen +pl@genericom.de www.genericom.de +--------------ms4BC2D4519D41A502BB06559C +Content-Type: application/x-pkcs7-signature; name="smime.p7s" +Content-Transfer-Encoding: base64 +Content-Disposition: attachment; filename="smime.p7s" +Content-Description: S/MIME Cryptographic Signature + +MIIFLgYJKoZIhvcNAQcCoIIFHzCCBRsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC +Aw0wggMJMIICcqADAgECAg4WKgAAAALXCfeUwksXHjANBgkqhkiG9w0BAQQFADCBvDELMAkG +A1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoT +MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAg +BgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp +ZmljYXRlQHRydXN0Y2VudGVyLmRlMB4XDTAzMTIwODA5NTQyNFoXDTA1MDEzMDA5NTQyNFow +RDELMAkGA1UEBhMCREUxFTATBgNVBAMTDFBoaWxpcHAgTGFuZzEeMBwGCSqGSIb3DQEJARYP +cGxAZ2VuZXJpY29tLmRlMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJqCn5ZXevTm3KgAKlKk +tOMzn1utWbcKoyrjuUSUOk9hwKXqjCtlBrNUDfVCtJIFWTU/2diijqormxUCXYr60F8CAwEA +AaOByDCBxTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYk +aHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIF +oDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9j +aGVjay1yZXYuY2dpLzE2MkEwMDAwMDAwMkQ3MDlGNzk0QzI0QjE3MUU/MA0GCSqGSIb3DQEB +BAUAA4GBAI4bC7MGQQTY9Cp09FYwPychOQs8yFNKHrqYwFhXOirqVTqwo1wgxuSO5/fYWbcs +neWGio3swv0y+jn7o0gkrr/pHNbbm/YmCMuiGuwciH2y4GU2BOukFFP4Otke5UL9Yc9l13eG +Aoaf9ApqRrckhbhLhjz3+gyUM5XRYpoOZX0LMYIB6TCCAeUCAQEwgc8wgbwxCzAJBgNVBAYT +AkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBU +cnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQL +ExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0 +ZUB0cnVzdGNlbnRlci5kZQIOFioAAAAC1wn3lMJLFx4wCQYFKw4DAhoFAKCBsTAYBgkqhkiG +9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MjUxNDM3NThaMCMGCSqG +SIb3DQEJBDEWBBS+u38esQAv19TdNkv4jgxlzsRqSzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG +SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG +9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAJQgoN5ASnyjnB7bgrv1+V7Cu4ULKe1CkHs0IEZaB +KuJcm98U7kskRyC5g6YNopuJxFbr19K3q5rrJGoUscKjiw== +--------------ms4BC2D4519D41A502BB06559C-- + + +From SRS0=SXka=LP=dansat.data-plan.com=timbo@bounce2.pobox.com Wed Aug 25 22:47:05 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7PLjxpJ037568 + for ; Wed, 25 Aug 2004 22:47:04 +0100 (BST) + (envelope-from SRS0=SXka=LP=dansat.data-plan.com=timbo@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 25 Aug 2004 22:47:04 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1C04j1-00038v-Pz; + Wed, 25 Aug 2004 20:50:31 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1C04j1-00038v-Pz + for pobox@data-plan.com; Wed, 25 Aug 2004 20:50:31 +0000 +Received: from [208.210.124.73] (helo=gold.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1C04j0-00002I-FU + for pobox@data-plan.com; Wed, 25 Aug 2004 20:50:30 +0000 +Received: from gold.pobox.com (localhost [127.0.0.1]) + by gold.pobox.com (Postfix) with ESMTP id AD1815463; + Wed, 25 Aug 2004 16:50:29 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from gold (localhost [127.0.0.1]) + by gold.pobox.com (Postfix) with ESMTP id 85FFF55E7 + for ; Wed, 25 Aug 2004 16:50:29 -0400 (EDT) +Received-SPF: none (gold.pobox.com: domain of timbo@dansat.data-plan.com does not designate permitted sender hosts) +Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) + by gold.pobox.com (Postfix) with SMTP id 14C005463 + for ; Wed, 25 Aug 2004 16:50:25 -0400 (EDT) +Received: (qmail 5678 messnum 5046341 invoked from network[213.94.228.233/unknown]); 25 Aug 2004 20:50:23 -0000 +Received: from unknown (HELO dansat.data-plan.com) (213.94.228.233) + by mail04.svc.cra.dublin.eircom.net (qp 5678) with SMTP; 25 Aug 2004 20:50:23 -0000 +Received: from dansat.data-plan.com (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7PKsrof034865; + Wed, 25 Aug 2004 21:54:53 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: (from timbo@localhost) + by dansat.data-plan.com (8.12.9/8.12.9/Submit) id i7PKsqas034864; + Wed, 25 Aug 2004 21:54:52 +0100 (BST) +Date: Wed, 25 Aug 2004 21:54:52 +0100 +From: Tim Bunce +To: Philipp Lang +Cc: Tim.Bunce@pobox.com +Subject: Re: DBD::Oracle: Freeing a temporary blob +Message-ID: <20040825205452.GC34655@dansat.data-plan.com> +References: <412CA445.FC2F9EF2@genericom.de> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <412CA445.FC2F9EF2@genericom.de> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 4674 +Lines: 124 + +On Wed, Aug 25, 2004 at 04:37:57PM +0200, Philipp Lang wrote: +> Dear Tim, +> +> first, I would really like to thank you for the great work you have done +> with your DBI/DBD work. We are using it extensively in several projects +> and we are highly pleased. + +Thanks Philipp! + +> Unfortunately I have now encountered a problem we need to fix urgently, +> since our customer's production is seriously affected. +> +> We tried for many days to find a solution (google, newsgroups, +> trial-and-error...), without luck. So my last chance is to contact you +> directly, although I assume you have a lot work yourself. + +I am very busy and what little spare time I have for DBD::Oracle +is going into trying to get 1.16 released (which is proving to be +hard as we're tripping over Oracle bugs when an Oracle 8 client +talks to an Oracle 9+ server.) It's a major release that will help +many people so I need to give that priority. + +Separately I am exploring ways to fund DBI and DBD::Oracle development +so I can devote more time to it. There's is much that needs to be +done and much more that could be done beyond that. + +The Perl Foundation (TPF) have setup a way for people and companies +to make donations for DBI development [as yet unannounced so please +keep to yourself]. A note on the contribution could indicate that the +donor would like it used for a particular purpose, such as DBD::Oracle. + +Anyway, to cut a long story short, it would be much easier to devote +time to this if it could be funded in some way. + +I think the TPF setup is working so it could be done that way. +Alternatively you could contract me to do the work for you. +That would be quicker and simpler for you as TPF's non-profit +status doesn't make a difference to European donors. + +My standard daily rate for add-hoc consulting is 1600 Euro. +I'd expect to be able to sort this out inside a day, and prefer +fixed-price quotes anyway, so would 1600 Euro be okay? + +Of course, if you feel your company would like to either +make a general contribution to DBI/DBD::Oracle development beyond +that, or to fund the development of specific functionality that +would be of extra value to you then I'd be happy to talk about that. + +I hate asking for money, and would much rather dig into the code and +reply with a patch, but it's just not practical for me now. Sorry. + +Tim. + +> --- +> +> The problem: +> +> Our database contains a stored function "ReadUnitBlob()" that returns a +> temporary blob: +> +> function ReadUnitBlob(UnitID_IN in integer) return blob +> is +> ... +> begin +> ... +> dbms_lob.createtemporary(retBlob, false, dbms_lob.call); +> dbms_lob.loadfromfile(retBlob, bfileIn, fileLen); +> ... +> return retBlob; +> end; +> +> We call this function in Perl in a big loop to fetch a lot of blobs (~ +> 100000) using something like: +> +> my $sth = $DBH->prepare("select ReadUnitBlob(:unitID) from dual", { +> ora_auto_lob => 0 }); +> $sth->bind_param(":unitID", $unitID); +> $sth->execute(); +> my ($loc) = $sth->fetchrow_array(); +> $sth->finish(); +> ... +> while(my $data = $DBH->ora_lob_read($loc, $offset, $chunk_size)) +> ... +> +> Although this works, it has a big disadvantage: Oracle does not +> automaticaly free the temporary blob, so it shortly runs out of temp. +> space. (confirmed with "select * from v$temporary_lobs"). +> +> Acording to the Oracle docs this can be we solved by implicitly freeing +> the temp. blob, e.g. by calling the PLSQL method +> "dbms_lob.freetemporary()". I tried differnt ways to do this with +> DBD::Oracle, but never succeeded. I just did not manage to fetch the LOB +> locator from the my stored procedure and to pass it to a call of +> "dbms_lob.freetemporary()": +> +> my $sth = $dbh->prepare("begin :bloc := ReadUnitBlob(:unitID); end;", { +> ora_auto_lob => 0 }); +> my $bloc; +> $sth->bind_param_inout( ":bloc", \$bloc, ORA_BLOB); +> $sth->bind_param(":unitID", $unitID); +> $sth->execute(); +> +> obviously the "ORA_BLOB" type for bind_param_inout() is wrong here ;) +> +> Can you help me??? Do you know a way how to free the temp. blob using +> DBD::Oracle (using Oracle::OCI is not possible, since the customer is +> strinctly refusing to install it). +> +> Otherwise, would it be possible include an additional DBD::Oracle LOB +> Locator Method "ora_lob_freetemporary()" that warps +> "OCILobFreeTemporary" ? +> +> Any help is really appreciated! +> +> Greeting from Germany, +> +> Philipp +> +> -- +> Dipl. Inf. Philipp Lang Genericom Software GmbH +> Tel. +49 (0)7031/8739-26 Tilsiter Str. 4-6 +> Fax +49 (0)7031/8739-11 71065 Sindelfingen +> pl@genericom.de www.genericom.de + + +From SRS0=eIh3=LQ=genericom.de=pl@bounce2.pobox.com Thu Aug 26 14:06:45 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7QD6Som051890 + for ; Thu, 26 Aug 2004 14:06:45 +0100 (BST) + (envelope-from SRS0=eIh3=LQ=genericom.de=pl@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 26 Aug 2004 14:06:45 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1C0HX2-0003PB-Sd; + Thu, 26 Aug 2004 10:31:00 +0000 +Received: from [194.217.242.223] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1C0HX2-0003PB-Sd + for pobox@data-plan.com; Thu, 26 Aug 2004 10:31:00 +0000 +Received: from [208.58.1.198] (helo=lime.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1C0HX2-0003BR-F8 + for pobox@data-plan.com; Thu, 26 Aug 2004 10:31:00 +0000 +Received: from lime.pobox.com (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id DC4BFB0D27; + Thu, 26 Aug 2004 06:30:59 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from lime (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id CE95AB0D7D + for ; Thu, 26 Aug 2004 06:30:59 -0400 (EDT) +Received-SPF: none (lime.pobox.com: domain of pl@genericom.de does not designate permitted sender hosts) +X-Pobox-Antispam: dnsbl/blackholes.five-ten-sg.com returned DENY: for 81.169.145.165(natsmtp00.rzone.de) +Received: from natsmtp00.rzone.de (natsmtp00.rzone.de [81.169.145.165]) + by lime.pobox.com (Postfix) with ESMTP id 71107B0D27 + for ; Thu, 26 Aug 2004 06:30:56 -0400 (EDT) +Received: from genericom.de (pD9E61E09.dip.t-dialin.net [217.230.30.9]) + by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i7QAUoTY009695 + for ; Thu, 26 Aug 2004 12:30:51 +0200 (MEST) +Sender: pl@post.webmailer.de +Message-ID: <412DBBD7.2C124831@genericom.de> +Date: Thu, 26 Aug 2004 12:30:47 +0200 +From: Philipp Lang +Organization: Genericom Software +X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.24 i686) +X-Accept-Language: de, en +MIME-Version: 1.0 +To: Tim Bunce +Subject: Re: DBD::Oracle: Freeing a temporary blob +References: <412CA445.FC2F9EF2@genericom.de> <20040825205452.GC34655@dansat.data-plan.com> +Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB92907D67E7D4C0121D50420" +Status: O +X-Status: A +Content-Length: 3040 +Lines: 58 + +This is a cryptographically signed message in MIME format. + +--------------msB92907D67E7D4C0121D50420 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit + +Tim Bunce wrote: +> +> I hate asking for money, and would much rather dig into the code and +> reply with a patch, but it's just not practical for me now. Sorry. + +Thanks for your quick reply. I can fully understand your position in +this issue. We will need to submit this issue to our customer, and +eventually it will be their decision, since a) the problem technically +originates in external components +and b) our work is payed on a time and material basis. + +Thanks again, + Philipp + +-- +Dipl. Inf. Philipp Lang Genericom Software GmbH +Tel. +49 (0)7031/8739-26 Tilsiter Str. 4-6 +Fax +49 (0)7031/8739-11 71065 Sindelfingen +pl@genericom.de www.genericom.de +--------------msB92907D67E7D4C0121D50420 +Content-Type: application/x-pkcs7-signature; name="smime.p7s" +Content-Transfer-Encoding: base64 +Content-Disposition: attachment; filename="smime.p7s" +Content-Description: S/MIME Cryptographic Signature + +MIIFLgYJKoZIhvcNAQcCoIIFHzCCBRsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC +Aw0wggMJMIICcqADAgECAg4WKgAAAALXCfeUwksXHjANBgkqhkiG9w0BAQQFADCBvDELMAkG +A1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoT +MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAg +BgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp +ZmljYXRlQHRydXN0Y2VudGVyLmRlMB4XDTAzMTIwODA5NTQyNFoXDTA1MDEzMDA5NTQyNFow +RDELMAkGA1UEBhMCREUxFTATBgNVBAMTDFBoaWxpcHAgTGFuZzEeMBwGCSqGSIb3DQEJARYP +cGxAZ2VuZXJpY29tLmRlMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJqCn5ZXevTm3KgAKlKk +tOMzn1utWbcKoyrjuUSUOk9hwKXqjCtlBrNUDfVCtJIFWTU/2diijqormxUCXYr60F8CAwEA +AaOByDCBxTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYk +aHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIF +oDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9j +aGVjay1yZXYuY2dpLzE2MkEwMDAwMDAwMkQ3MDlGNzk0QzI0QjE3MUU/MA0GCSqGSIb3DQEB +BAUAA4GBAI4bC7MGQQTY9Cp09FYwPychOQs8yFNKHrqYwFhXOirqVTqwo1wgxuSO5/fYWbcs +neWGio3swv0y+jn7o0gkrr/pHNbbm/YmCMuiGuwciH2y4GU2BOukFFP4Otke5UL9Yc9l13eG +Aoaf9ApqRrckhbhLhjz3+gyUM5XRYpoOZX0LMYIB6TCCAeUCAQEwgc8wgbwxCzAJBgNVBAYT +AkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFUQyBU +cnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMSIwIAYDVQQL +ExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0aWZpY2F0 +ZUB0cnVzdGNlbnRlci5kZQIOFioAAAAC1wn3lMJLFx4wCQYFKw4DAhoFAKCBsTAYBgkqhkiG +9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA4MjYxMDMwNDhaMCMGCSqG +SIb3DQEJBDEWBBQbWUdl+peoD/lHpzCOnuQfzAsbJzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG +SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG +9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAXzFame8ymLqgf+7nZ4V7L9e9J+aG6z5ipa+iv76v +EFAg5QObdHdvTnq5QEAjEnLKgeUGvdgpS6PA0h+beEIeIA== +--------------msB92907D67E7D4C0121D50420-- + + +From SRS0=T6ya=LQ=dansat.data-plan.com=timbo@bounce2.pobox.com Thu Aug 26 16:42:55 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7QFgKp1054926 + for ; Thu, 26 Aug 2004 16:42:55 +0100 (BST) + (envelope-from SRS0=T6ya=LQ=dansat.data-plan.com=timbo@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 26 Aug 2004 16:42:55 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1C0L1E-0005sL-5Z; + Thu, 26 Aug 2004 14:14:24 +0000 +Received: from [194.217.242.211] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1C0L1E-0005sL-5Z + for pobox@data-plan.com; Thu, 26 Aug 2004 14:14:24 +0000 +Received: from [208.58.1.198] (helo=lime.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1C0L1E-0001t1-Cm + for pobox@data-plan.com; Thu, 26 Aug 2004 14:14:24 +0000 +Received: from lime.pobox.com (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id 541E8AFAD6; + Thu, 26 Aug 2004 10:14:23 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from lime (localhost [127.0.0.1]) + by lime.pobox.com (Postfix) with ESMTP id 1C39FB0747 + for ; Thu, 26 Aug 2004 10:14:23 -0400 (EDT) +Received-SPF: none (lime.pobox.com: domain of timbo@dansat.data-plan.com does not designate permitted sender hosts) +Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) + by lime.pobox.com (Postfix) with SMTP id BFBB5AFAD6 + for ; Thu, 26 Aug 2004 10:14:19 -0400 (EDT) +Received: (qmail 12246 messnum 7731352 invoked from network[213.94.228.233/unknown]); 26 Aug 2004 14:14:17 -0000 +Received: from unknown (HELO dansat.data-plan.com) (213.94.228.233) + by mail01.svc.cra.dublin.eircom.net (qp 12246) with SMTP; 26 Aug 2004 14:14:17 -0000 +Received: from dansat.data-plan.com (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i7QEItof052863; + Thu, 26 Aug 2004 15:18:55 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: (from timbo@localhost) + by dansat.data-plan.com (8.12.9/8.12.9/Submit) id i7QEItr3052862; + Thu, 26 Aug 2004 15:18:55 +0100 (BST) +Date: Thu, 26 Aug 2004 15:18:55 +0100 +From: Tim Bunce +To: Philipp Lang +Cc: Tim Bunce +Subject: Re: DBD::Oracle: Freeing a temporary blob +Message-ID: <20040826141855.GC52359@dansat.data-plan.com> +References: <412CA445.FC2F9EF2@genericom.de> <20040825205452.GC34655@dansat.data-plan.com> <412DBBD7.2C124831@genericom.de> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <412DBBD7.2C124831@genericom.de> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 926 +Lines: 25 + +Okay. Thanks. Let me know how it turns out. + +Tim. + +On Thu, Aug 26, 2004 at 12:30:47PM +0200, Philipp Lang wrote: +> Tim Bunce wrote: +> > +> > I hate asking for money, and would much rather dig into the code and +> > reply with a patch, but it's just not practical for me now. Sorry. +> +> Thanks for your quick reply. I can fully understand your position in +> this issue. We will need to submit this issue to our customer, and +> eventually it will be their decision, since a) the problem technically +> originates in external components +> and b) our work is payed on a time and material basis. +> +> Thanks again, +> Philipp +> +> -- +> Dipl. Inf. Philipp Lang Genericom Software GmbH +> Tel. +49 (0)7031/8739-26 Tilsiter Str. 4-6 +> Fax +49 (0)7031/8739-11 71065 Sindelfingen +> pl@genericom.de www.genericom.de + + diff --git a/err_unicode/err_char.msg b/err_unicode/err_char.msg new file mode 100644 index 00000000..d2a7a4a3 --- /dev/null +++ b/err_unicode/err_char.msg @@ -0,0 +1,129 @@ +From dbi-users-return-11724-Tim.Bunce=pobox.com@perl.org Fri May 31 15:39:50 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g4VEdno73229 + for ; Fri, 31 May 2002 15:39:49 +0100 (BST) + (envelope-from dbi-users-return-11724-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.22] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 31 May 2002 15:39:49 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1022854157:20:06570:1; Fri, 31 May 2002 14:09:17 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-2.mail.demon.net + id aa2005972; 31 May 2002 14:08 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 210F42BF43 + for ; Fri, 31 May 2002 10:08:39 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (unknown [64.70.54.95]) + by dolly1.pobox.com (Postfix) with SMTP id 8D88B2BF11 + for ; Fri, 31 May 2002 10:08:38 -0400 (EDT) +Received: (qmail 47355 invoked by uid 1005); 31 May 2002 14:07:42 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 47340 invoked by uid 76); 31 May 2002 14:07:41 -0000 +Received: from wsrgeh.wsr.ac.at (HELO wsrgeh.wsr.ac.at) (143.130.16.2) + by onion.perl.org (qpsmtpd/0.07b) with SMTP; Fri May 31 14:07:41 2002 -0000 +Received: from dialog.wsr.ac.at (dialog.wsr.ac.at [143.130.50.66]) + by wsrgeh.wsr.ac.at (8.11.6/8.11.6) with ESMTP id g4VE8Or11772 + for ; Fri, 31 May 2002 16:08:24 +0200 +Received: (from hjp@localhost) + by dialog.wsr.ac.at (8.11.6/8.11.6) id g4VE8Nf12538 + for dbi-users@perl.org; Fri, 31 May 2002 16:08:23 +0200 +Date: Fri, 31 May 2002 16:08:23 +0200 +From: "Peter J. Holzer" +To: dbi-users@perl.org +Subject: Re: Insert a blank value into Oracle +Message-ID: <20020531160823.F28779@wsr.ac.at> +Mail-Followup-To: "Peter J. Holzer" , + dbi-users@perl.org +References: <1797C3D07B8BD311BC9200A0C9C85E0F0369DCCF@mail.gss.com.tw> +Mime-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-md5; + protocol="application/pgp-signature"; boundary="aZoGpuMECXJckB41" +Content-Disposition: inline +User-Agent: Mutt/1.2.5.1i +In-Reply-To: <1797C3D07B8BD311BC9200A0C9C85E0F0369DCCF@mail.gss.com.tw>; from larry_wu@mail.gss.com.tw on Fri, May 31, 2002 at 06:38:45PM +0800 +Status: RO +Content-Length: 2819 +Lines: 74 + +--aZoGpuMECXJckB41 +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On 2002-05-31 18:38:45 +0800, Larry Wu (=A7d=A4l=B7=D3) wrote: +> I encountered a problem to insert a space value ( like ' ' ) into Oracle +> database. +[...] +> Unfortunately, I have a table A contained a not allow null column +> NotNullCol. Now I want to insert a row like below: +>=20 +> $sth =3D $dbh->prepare( qq{ insert into A ( KeyCol, NotNullCol ) +> values (?,?)} ); +> $sth->bind_param(1, '1'); +> $sth->bind_param(2, ' '); +> $sth->execute; +>=20 +> When I executed this file I got an error from Oracle: Can't insert NULL +> value into ( "A"."NotNullCol") (DBD ERROR: OCIStmtExecute). +> I think the space value was truncated in the process. Could any one tell = +me +> how to keep a blank space in my bind_param ? + +use DBD::Oracle qw(:ora_types); +[...] +$sth->bind_param(2, ' ', { ora_type =3D> ORA_CHAR }); + +This is a frequently asked question here. The default type for strings, +ORA_VARCHAR2, strips trailing blanks from strings. A few months ago, +during one of the diskussuions about this feature, Tim said that he +might add a way to change the default in a future version of +DBD::Oracle. If he doesn't, maybe a paragraph like the following should +be added to the doc (not sure where - it fits below "Using DBD::Oracle +with Oracle 8 - Features and Issues" but it isn't Oracle 8 specific): + + =3Dhead2 Inserting strings with trailing spaces + + OCI provides several string types which behave differently. + Unfortunately, none of them can store arbitrary perl strings. + By default, DBD::Oracle binds string variables as ORA_VARCHAR2, + which allows embedded NUL characters but strips trailing spaces. If + you need trailing spaces, but don't need embedded NUL characters, + you can explicetly bind the param to type ORA_CHAR with: + + $sth->bind_param(($field_num, $string_value, + { ora_type =3D> ORA_CHAR }); + + =20 + hp + +--=20 + _ | Peter J. Holzer | Aeltere Sources (also solche, die schon +|_|_) | Sysadmin WSR / LUGA | aelter als 12 Stunden sind) sollte man +| | | hjp@wsr.ac.at | bei Linux generell nicht einsetzen - +__/ | http://www.hjp.at/ | Real Time Linux?? -- Gerhard Schneider + +--aZoGpuMECXJckB41 +Content-Type: application/pgp-signature +Content-Disposition: inline + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.0.6 (GNU/Linux) +Comment: For info see http://www.gnupg.org + +iQDQAwUBPPeD11LjemazOuKpAQEtNAXUC6rFL0C0v6MNW/K5ggXcSDY7Xvrj6Ed/ +jqjHq2Dx+h2rIMWXCDIGZVphSG74u4FL41AQF/rzGR/e56qH7aAxVmaiLdQE/DRi +zzsoOHoPEg96FhHljDtCZyxHzsz9sRJ1dfW1PELn5r2OSYPPsVzMoeR4iEXnVjvV +ZYH/OfbKRKhysIHjcNYKcyQL87GXdjzCEas3Xz+jyxW2vqzGAwUfTim4ySY9rF37 +c5vopwrTFCsi58r1LccFhQqEfw== +=Xe8d +-----END PGP SIGNATURE----- + +--aZoGpuMECXJckB41-- + diff --git a/err_unicode/err_twolongstr.msg b/err_unicode/err_twolongstr.msg new file mode 100644 index 00000000..5d6c357d --- /dev/null +++ b/err_unicode/err_twolongstr.msg @@ -0,0 +1,1256 @@ +From SRS0=YmHr=OD=systransoft.com=cassidy@bounce2.pobox.com Wed Nov 17 19:08:49 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id iAHJ8F8P027204 + for ; Wed, 17 Nov 2004 19:08:48 GMT + (envelope-from SRS0=YmHr=OD=systransoft.com=cassidy@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 17 Nov 2004 19:08:48 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CUUU6-0001mQ-FU; + Wed, 17 Nov 2004 18:24:50 +0000 +Received: from [194.217.242.71] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CUUU6-0001mQ-FU + for pobox@data-plan.com; Wed, 17 Nov 2004 18:24:50 +0000 +Received: from [207.8.226.3] (helo=icicle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1CUUU6-0000DF-68 + for pobox@data-plan.com; Wed, 17 Nov 2004 18:24:50 +0000 +Received: from icicle.pobox.com (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 9D10A120BFA; + Wed, 17 Nov 2004 13:24:49 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from icicle (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 8C898120BEF + for ; Wed, 17 Nov 2004 13:24:49 -0500 (EST) +Received-SPF: none (icicle.pobox.com: domain of cassidy@systransoft.com does not designate permitted sender hosts) +X-SPF-Guess: pass (seems reasonable for cassidy@systransoft.com to mail through 66.185.164.3) +Received: from mailhost.systransoft.com (mailhost.systransoft.com [66.185.164.3]) + by icicle.pobox.com (Postfix) with ESMTP id 362C6120BEC + for ; Wed, 17 Nov 2004 13:24:46 -0500 (EST) +Received: from localhost (localhost [127.0.0.1]) + by mailhost.systransoft.com (Postfix) with ESMTP id 9C0CC244379 + for ; Wed, 17 Nov 2004 10:24:44 -0800 (PST) +Received: from mailhost.systransoft.com ([127.0.0.1]) + by localhost (mailhost.systransoft.com [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 17196-06 for ; + Wed, 17 Nov 2004 10:24:44 -0800 (PST) +Received: from hapax (hapax [192.168.2.186]) + by mailhost.systransoft.com (Postfix) with ESMTP id 3131324406F + for ; Wed, 17 Nov 2004 10:24:44 -0800 (PST) +From: "Susan Cassidy" +To: "'Tim Bunce'" +Subject: RE: FW: DBD::Oracle and strange problem with Oracle error 'ORA-01461: can bind a LONG value only for insert into a LONG column' when data not LONG +Date: Wed, 17 Nov 2004 10:22:44 -0800 +Organization: SYSTRAN Software, Inc. +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_NextPart_000_006A_01C4CC8F.60A4F6F0" +X-Mailer: Microsoft Office Outlook, Build 11.0.5510 +In-Reply-To: <20041117173321.GA6272@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 +Thread-Index: AcTMy6HoelzJHh9WSPaTpCdfuF1C4gABpsZg +Message-Id: <20041117182444.3131324406F@mailhost.systransoft.com> +X-Virus-Scanned: by amavisd-new at systransoft.com +Status: RO +Content-Length: 16865 +Lines: 527 + +This is a multi-part message in MIME format. + +------=_NextPart_000_006A_01C4CC8F.60A4F6F0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit + +I did - it is attached to the posting. However, I will attach it again +here. + +Thanks, +Susan + +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Wednesday, November 17, 2004 9:33 AM +> To: Susan Cassidy +> Cc: dbi-users@perl.org +> Subject: Re: FW: DBD::Oracle and strange problem with Oracle error 'ORA- +> 01461: can bind a LONG value only for insert into a LONG column' when data +> not LONG +> +> If you can post a small self-contained example that demonstrates +> the problem then I'll take a look. +> +> Tim. +> +> On Wed, Nov 17, 2004 at 09:15:52AM -0800, Susan Cassidy wrote: +> > I never got any response to my question about this problem. I +> thought I'd try again. +> > +> > +> > +> > This is DBD::Oracle 1.16, DBI 1.45, Oracle 9i (9.2), Linux, Perl +> 5.8.5. +> > +> > +> > +> > Thanks, +> > +> > Susan +> > +> > +> > +> > --------------------------------------------------------------------- +> ----------------------------------- +> > +> > From: Susan Cassidy [mailto:cassidy@systransoft.com] +> > Sent: Friday, November 05, 2004 10:23 AM +> > To: 'dbi-users@perl.org' +> > Subject: DBD::Oracle and strange problem with Oracle error 'ORA- +> 01461: can bind a LONG value only for +> > insert into a LONG column' when data not LONG +> > +> > +> > +> > I had an application that was processing a bunch of xml and inserting +> into a table with a bunch of +> > VARCHAR2(4000) columns. +> > +> > +> > +> > A couple of the entries I was processing caused the 'ORA-01461: can +> bind a LONG value only for insert +> > into a LONG column' error. +> > +> > +> > +> > I put checks in for the length of the data, and nothing approached +> 4000 bytes in length. +> > +> > +> > +> > I tracked down some of the entries causing problems, and on certain +> specific data, if 2 columns +> > containing specific data are inserted together, I get this error. If +> only one of the 2 is inserted, I +> > do not get the error, regardless of which one of the two I insert. +> > +> > +> > +> > The lengths of the pieces of data are 1399 and 1397 characters. +> > +> > +> > +> > The data is somewhat odd-looking (we suspect some odd data is in this +> file), but there is no reason for +> > the error message to appear. +> > +> > +> > +> > Trace shows nothing helpful - it thinks the data is the right length. +> > +> > +> > +> > We've successfully inserted thousands of other, similar entries with +> no trouble. +> > +> > +> > +> > The basics are: +> > +> > #create table test_table (item1 varchar2(4000), item2 +> varchar2(4000)); +> > +> > +> > +> > my $statement="INSERT INTO test_table (item1,item2) VALUES (?, ?)"; +> > +> > +> > +> > $sth=$dbh->prepare($statement) || +> > +> > errexit("bad prepare for stmt $statement, error: $DBI::errstr"); +> > +> > my $rc=$sth->execute(@vals) || +> > +> > errexit("can't execute statement: error: $DBI::errstr\n"); +> > +> > +> > +> > Trace shows: +> > +> > +> > +> > DBI 1.45-ithread default trace level set to 0x0/2 (pid 6230) +> > +> > -> prepare for DBD::Oracle::db (DBI::db=HASH(0x82d4178)~0x82d6580 +> 'INSERT INTO test_table +> > (item1,item2) VALUES (?, ?) +> > +> > ') thr#8148ff0 +> > +> > dbd_preparse scanned 2 distinct placeholders +> > +> > <- prepare= DBI::st=HASH(0x82d6640) at test_insert_large.pl line +> 40 +> > +> > -> execute for DBD::Oracle::st (DBI::st=HASH(0x82d6640)~0x8149dcc +> 'version 11.2no service +> > password-encryptionservice +> > +> > udp-small-serversservice tcp-small-servers!hostname router1!!no ip +> domain-lookupip inspect name mysite +> > ftpip inspect name +> > +> > mysite smtpip inspect name mysite tcp!interface Ethernet0ip address +> 10.10.10.2 255.255.255.0ip +> > access-group 101 inip ins +> > +> > pect mysite inip inspect mysite outno keepalive!interface Serial0no +> ip addressencapsulation +> > frame-relay...' 'version 11.2 +> > +> > no service password-encryptionservice udp-small-serversservice tcp- +> small-servers!hostname router1!!no ip +> > domain-lookupip +> > +> > inspect name mysite ftpip inspect name mysite smtpip inspect name +> mysite tcp!interface Ethernet0ip +> > address 10.10.10.2 255 +> > +> > .255.255.0ip access-group 101 inip inspect mysiteinip inspect mysite +> outno keepalive!interface Serial0no +> > ip addressencaps +> > +> > ulation frame-relayn...') thr#8148ff0 +> > +> > bind :p1 <== 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostnam +> > +> > e router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface E +> > +> > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysite inip inspect mysite +> > outno keepalive!in +> > +> > terface Serial0no ip addressencapsulation frame-relay...' (type 0) +> > +> > bind :p1 <== 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostnam +> > +> > e router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface E +> > +> > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysite inip inspect mysite +> > outno keepalive!in +> > +> > terface Serial0no ip addressencapsulation frame-relay...' (size +> 1399/1400/0, ptype 4, otype 1) +> > +> > bind :p2 <== 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostnam +> > +> > e router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface E +> > +> > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysiteinip inspect mysite +> > outno keepalive!int +> > +> > erface Serial0no ip addressencapsulation frame-relayn...' (type 0) +> > +> > bind :p2 <== 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostnam +> > +> > e router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface E +> > +> > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysiteinip inspect mysite +> > outno keepalive!int +> > +> > erface Serial0no ip addressencapsulation frame-relayn...' (size +> 1397/1398/0, ptype 4, otype 1) +> > +> > dbd_st_execute INSERT (out0, lob0)... +> > +> > !! ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> insert into a LONG column (DBD ERROR: +> > OCIStmtExecute)' (e +> > +> > rr#1) +> > +> > <- execute= undef at test_insert_large.pl line 42 +> > +> > 1 -> FETCH for DBD::Oracle::st (DBI::st=HASH(0x8149dcc)~INNER +> 'ParamValues') thr#8148ff0 +> > +> > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> insert into a LONG column (DBD ERROR: +> > OCIStmtExecute)' (e +> > +> > rr#1) +> > +> > 1 <- FETCH= HASH(0x83487e0)2keys at test_insert_large.pl line 42 +> > +> > -> $DBI::errstr (&) FETCH from lasth=HASH +> > +> > >> DBD::Oracle::st::errstr +> > +> > <- $DBI::errstr= 'ORA-01461: can bind a LONG value only for +> insert into a LONG column (DBD ERROR: +> > OCIStmtExecute)' +> > +> > -- DBI::END +> > +> > -> disconnect_all for DBD::Oracle::dr +> (DBI::dr=HASH(0x824771c)~0x82d419c) thr#8148ff0 +> > +> > <- disconnect_all= (not implemented) at DBI.pm line 673 +> > +> > Connect done +> > +> > stmt: INSERT INTO test_table (item1,item2) VALUES (?, ?) +> > +> > Size of vals is 2 +> > +> > val 1 size 1399, is: 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostna +> > +> > me router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface +> > +> > Ethernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysite inip inspect mysite +> > outno keepalive!i +> > +> > nterface Serial0no ip addressencapsulation frame-relayno fair- +> queue!interface Serial0.1 point-to-pointip +> > address 10.10.11 +> > +> > .2 255.255.255.252ip access-group 102 inframe-relay interface-dlci +> 200 IETF!router eigrp 69network +> > 10.0.0.0no auto-summar +> > +> > y!ip default-gateway 10.10.11.1no ip classlessip route 0.0.0.0 +> 0.0.0.0 10.10.11.1access-list 101 permit +> > tcp 10.10.10.0 0. +> > +> > 0.0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 anyaccess- +> list 101 permit icmp 10.10.10.0 +> > 0.0.0.255 anyaccess- +> > +> > list 101 deny ip any anyaccess-list 102 permit eigrp any anyaccess- +> list 102 permit icmp any 10.10.10.0 +> > 0.0.0.255 echo-rep +> > +> > lyaccess-list 102 permit icmp any 10.10.10.0 0.0.0.255 +> unreachableaccess-list 102 permit icmp any +> > 10.10.10.0 0.0.0.255 ad +> > +> > ministratively-prohibitedaccess-list 102 permit icmp any 10.10.10.0 +> 0.0.0.255 packet-too-bigaccess-list +> > 102 permit icmp a +> > +> > ny 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any +> 10.10.10.0 0.0.0.255 +> > time-exceededaccess-list 102 permit tcp +> > +> > any host 10.10.10.1 eq smtpaccess-list 102 deny ip any any!line con +> 0line vty 0 4login!end' +> > +> > val 2 size 1397, is: 'version 11.2no service password- +> encryptionservice udp-small-serversservice +> > tcp-small-servers!hostna +> > +> > me router1!!no ip domain-lookupip inspect name mysite ftpip inspect +> name mysite smtpip inspect name +> > mysite tcp!interface +> > +> > Ethernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 inip +> inspect mysiteinip inspect mysite +> > outno keepalive!in +> > +> > terface Serial0no ip addressencapsulation frame-relayno fair- +> queue!interface Serial0.1 point-to-pointip +> > address 10.10.11. +> > +> > 2 255.255.255.252ip access-group 102 inframe-relay interface-dlci 200 +> IETF!router eigrp 69network +> > 10.0.0.0no auto-summary +> > +> > !ip default-gateway 10.10.11.1no ip classlessip route 0.0.0.0 0.0.0.0 +> 10.10.11.1access-list 101 permit +> > tcp 10.10.10.0 0.0 +> > +> > .0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 anyaccess- +> list 101 permiticmp 10.10.10.0 +> > 0.0.0.255 anyaccess-li +> > +> > st 101 deny ip any anyaccess-list 102 permit eigrp any anyaccess-list +> 102 permit icmp any 10.10.10.0 +> > 0.0.0.255 echo-reply +> > +> > access-list 102 permit icmp any 10.10.10.0 0.0.0.255 +> unreachableaccess-list 102 permit icmp any +> > 10.10.10.0 0.0.0.255 admi +> > +> > nistratively-prohibitedaccess-list 102 permit icmp any 10.10.10.0 +> 0.0.0.255 packet-too-bigaccess-list +> > 102 permit icmp any +> > +> > 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any 10.10.10.0 +> 0.0.0.255 time-exceededaccess-list +> > 102 permit tcp an +> > +> > y host 10.10.10.1 eq smtpaccess-list 102 deny ip any any!line con +> 0line vty 0 4login!end' +> > +> > can't execute statement: error: ORA-01461: can bind a LONG value only +> for insert into a LONG column (DBD +> > ERROR: OCIStmtEx +> > +> > ecute) +> > +> > +> > +> > ! -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x82d6580)~INNER) +> thr#8148ff0 +> > +> > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> insert into a LONG column (DBD ERROR: +> > OCIStmtExecute)' (e +> > +> > rr#0) +> > +> > ! <- DESTROY= undef during global destruction +> > +> > ! -> DESTROY in DBD::_::common for DBD::Oracle::dr +> (DBI::dr=HASH(0x82d419c)~INNER) thr#8148ff0 +> > +> > ! <- DESTROY= undef during global destruction +> > +> > ! -> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x8149dcc)~INNER) +> thr#8148ff0 +> > +> > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> insert into a LONG column (DBD ERROR: +> > OCIStmtExecute)' (e +> > +> > rr#1) +> > +> > ! <- DESTROY= undef during global destruction +> > +> > +> > +> > I will attach the test program. Somehow it seems to think the +> datatype is LONG instead of VARCHAR. +> > +> > +> > +> > +> > +> > Anyone with ideas? +> > +> > +> > +> > +> > +> > Thanks, +> > +> > Susan +> + + +------=_NextPart_000_006A_01C4CC8F.60A4F6F0 +Content-Type: application/octet-stream; + name="test_insert_large.pl" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="test_insert_large.pl" + +#!/usr/local/bin/perl -w=0A= +=0A= +use DBI;=0A= +=0A= +our $dbh;=0A= +our $sth;=0A= +=0A= +$dbuser=3D"proj1";=0A= +$dbpasswd=3D"proj1";=0A= +=0A= +$dbserver=3D'oracledev';=0A= +$db_sid=3D'AL32UTF8';=0A= +=0A= +##=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D connect to database = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=0A= +=0A= +$dbh=3D DBI->connect("dbi:Oracle:host=3D$dbserver;sid=3D$db_sid", = +$dbuser, $dbpasswd,=0A= + {PrintError =3D> 0, AutoCommit =3D> 1}) or=0A= + errexit( "Unable to connect to $dbserver: $DBI::errstr");=0A= +print "Connect done\n";=0A= +=0A= +#create table test_table (item1 varchar2(4000), item2 varchar2(4000));=0A= +=0A= +=0A= +my $statement=3D"INSERT INTO test_table (item1,item2) VALUES (?, ?)";=0A= +print "stmt: $statement\n";=0A= +=0A= +@vals=3D(=0A= + 'version 11.2no service password-encryptionservice = +udp-small-serversservice tcp-small-servers!hostname router1!!no ip = +domain-lookupip inspect name mysite ftpip inspect name mysite smtpip = +inspect name mysite tcp!interface Ethernet0ip address 10.10.10.2 = +255.255.255.0ip access-group 101 inip inspect mysite inip inspect mysite = +outno keepalive!interface Serial0no ip addressencapsulation = +frame-relayno fair-queue!interface Serial0.1 point-to-pointip address = +10.10.11.2 255.255.255.252ip access-group 102 inframe-relay = +interface-dlci 200 IETF!router eigrp 69network 10.0.0.0no = +auto-summary!ip default-gateway 10.10.11.1no ip classlessip route = +0.0.0.0 0.0.0.0 10.10.11.1access-list 101 permit tcp 10.10.10.0 = +0.0.0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 = +anyaccess-list 101 permit icmp 10.10.10.0 0.0.0.255 anyaccess-list 101 = +deny ip any anyaccess-list 102 permit eigrp any anyaccess-list 102 = +permit icmp any 10.10.10.0 0.0.0.255 echo-replyaccess-list 102 permit = +icmp any 10.10.10.0 0.0.0.255 unreachableaccess-list 102 permit icmp any = +10.10.10.0 0.0.0.255 administratively-prohibitedaccess-list 102 permit = +icmp any 10.10.10.0 0.0.0.255 packet-too-bigaccess-list 102 permit icmp = +any 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any 10.10.10.0 = +0.0.0.255 time-exceededaccess-list 102 permit tcp any host 10.10.10.1 eq = +smtpaccess-list 102 deny ip any any!line con 0line vty 0 4login!end',=0A= + 'version 11.2no service password-encryptionservice = +udp-small-serversservice tcp-small-servers!hostname router1!!no ip = +domain-lookupip inspect name mysite ftpip inspect name mysite smtpip = +inspect name mysite tcp!interface Ethernet0ip address 10.10.10.2 = +255.255.255.0ip access-group 101 inip inspect mysiteinip inspect mysite = +outno keepalive!interface Serial0no ip addressencapsulation = +frame-relayno fair-queue!interface Serial0.1 point-to-pointip address = +10.10.11.2 255.255.255.252ip access-group 102 inframe-relay = +interface-dlci 200 IETF!router eigrp 69network 10.0.0.0no = +auto-summary!ip default-gateway 10.10.11.1no ip classlessip route = +0.0.0.0 0.0.0.0 10.10.11.1access-list 101 permit tcp 10.10.10.0 = +0.0.0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 = +anyaccess-list 101 permiticmp 10.10.10.0 0.0.0.255 anyaccess-list 101 = +deny ip any anyaccess-list 102 permit eigrp any anyaccess-list 102 = +permit icmp any 10.10.10.0 0.0.0.255 echo-replyaccess-list 102 permit = +icmp any 10.10.10.0 0.0.0.255 unreachableaccess-list 102 permit icmp any = +10.10.10.0 0.0.0.255 administratively-prohibitedaccess-list 102 permit = +icmp any 10.10.10.0 0.0.0.255 packet-too-bigaccess-list 102 permit icmp = +any 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any 10.10.10.0 = +0.0.0.255 time-exceededaccess-list 102 permit tcp any host 10.10.10.1 eq = +smtpaccess-list 102 deny ip any any!line con 0line vty 0 4login!end',=0A= +);=0A= +=0A= +print "Size of vals is ",scalar @vals,"\n";=0A= +my $z=3D0;=0A= +foreach my $x (@vals) {=0A= + my $len=3Dlength($x);=0A= + print "val ",++$z, " size $len, is: '$x'\n";=0A= +}=0A= +=0A= +DBI->trace(2);=0A= + $sth=3D$dbh->prepare($statement) ||=0A= + errexit("bad prepare for stmt $statement, error: $DBI::errstr");=0A= + my $rc=3D$sth->execute(@vals) ||=0A= + errexit("can't execute statement: error: $DBI::errstr\n");=0A= +=0A= +print "Done\n";=0A= +exit;=0A= +=0A= +=0A= +sub errexit {=0A= + my (@msg)=3D@_;=0A= + print @msg,"\n";=0A= + exit 1;=0A= +}=0A= +=0A= +=0A= +=0A= + +------=_NextPart_000_006A_01C4CC8F.60A4F6F0-- + + +From SRS0=YmHr=OD=systransoft.com=cassidy@bounce2.pobox.com Thu Nov 18 00:15:21 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id iAI0FC8G049539 + for ; Thu, 18 Nov 2004 00:15:21 GMT + (envelope-from SRS0=YmHr=OD=systransoft.com=cassidy@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 18 Nov 2004 00:15:21 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CUVdd-0002Nv-CF; + Wed, 17 Nov 2004 19:38:45 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CUVdd-0002Nv-CF + for pobox@data-plan.com; Wed, 17 Nov 2004 19:38:45 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1CUVdc-0005lu-Rs + for pobox@data-plan.com; Wed, 17 Nov 2004 19:38:45 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 4A256ADD6F; + Wed, 17 Nov 2004 14:38:44 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from boggle (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 3D82CADD64 + for ; Wed, 17 Nov 2004 14:38:44 -0500 (EST) +Received-SPF: none (boggle.pobox.com: domain of cassidy@systransoft.com does not designate permitted sender hosts) +X-SPF-Guess: pass (seems reasonable for cassidy@systransoft.com to mail through 66.185.164.3) +Received: from mailhost.systransoft.com (mailhost.systransoft.com [66.185.164.3]) + by boggle.pobox.com (Postfix) with ESMTP id B23D4ADCF6 + for ; Wed, 17 Nov 2004 14:38:15 -0500 (EST) +Received: from localhost (localhost [127.0.0.1]) + by mailhost.systransoft.com (Postfix) with ESMTP id 0C9DF24435B + for ; Wed, 17 Nov 2004 11:38:14 -0800 (PST) +Received: from mailhost.systransoft.com ([127.0.0.1]) + by localhost (mailhost.systransoft.com [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 18475-01 for ; + Wed, 17 Nov 2004 11:38:13 -0800 (PST) +Received: from hapax (hapax [192.168.2.186]) + by mailhost.systransoft.com (Postfix) with ESMTP id ACF0424406F + for ; Wed, 17 Nov 2004 11:38:13 -0800 (PST) +From: "Susan Cassidy" +To: "'Tim Bunce'" +Subject: RE: FW: DBD::Oracle and strange problem with Oracle error 'ORA-01461: can bind a LONG value only for insert into a LONG column' when data not LONG +Date: Wed, 17 Nov 2004 11:36:14 -0800 +Organization: SYSTRAN Software, Inc. +MIME-Version: 1.0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +X-Mailer: Microsoft Office Outlook, Build 11.0.5510 +In-Reply-To: <20041117192902.GA31595@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 +Thread-Index: AcTM27+9yfJDVs3WQIWAKc6DR3EgdQAAKfgw +Message-Id: <20041117193813.ACF0424406F@mailhost.systransoft.com> +X-Virus-Scanned: by amavisd-new at systransoft.com +Status: RO +X-Status: A +Content-Length: 14671 +Lines: 489 + +NLS_LANG=.UTF8 +ORA_NLS33=/home/oracle/product/9.2.0/ocommon/nls/admin/data +ORA_NLS33=/home/oracle/product/9.2.0/ocommon/nls/admin/data +ORACLE_HOME=/home/oracle/product/9.2.0 +ORACLE_SID=AL32UTF8 +ORACLE_BASE=/home/oracle + +NLS_NCHAR is not set, because we are not using any NVARCHAR data item, and +haven't needed it. + +Susan + +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Wednesday, November 17, 2004 11:29 AM +> To: Susan Cassidy +> Cc: 'Tim Bunce' +> Subject: Re: FW: DBD::Oracle and strange problem with Oracle error 'ORA- +> 01461: can bind a LONG value only for insert into a LONG column' when data +> not LONG +> +> Thanks. What are your client side NLS_LANG and NLS_NCHAR settings? +> +> Tim. +> +> On Wed, Nov 17, 2004 at 10:22:44AM -0800, Susan Cassidy wrote: +> > I did - it is attached to the posting. However, I will attach it again +> > here. +> > +> > Thanks, +> > Susan +> > +> > > -----Original Message----- +> > > From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> > > Sent: Wednesday, November 17, 2004 9:33 AM +> > > To: Susan Cassidy +> > > Cc: dbi-users@perl.org +> > > Subject: Re: FW: DBD::Oracle and strange problem with Oracle error +> 'ORA- +> > > 01461: can bind a LONG value only for insert into a LONG column' when +> data +> > > not LONG +> > > +> > > If you can post a small self-contained example that demonstrates +> > > the problem then I'll take a look. +> > > +> > > Tim. +> > > +> > > On Wed, Nov 17, 2004 at 09:15:52AM -0800, Susan Cassidy wrote: +> > > > I never got any response to my question about this problem. I +> > > thought I'd try again. +> > > > +> > > > +> > > > +> > > > This is DBD::Oracle 1.16, DBI 1.45, Oracle 9i (9.2), Linux, Perl +> > > 5.8.5. +> > > > +> > > > +> > > > +> > > > Thanks, +> > > > +> > > > Susan +> > > > +> > > > +> > > > +> > > > ----------------------------------------------------------------- +> ---- +> > > ----------------------------------- +> > > > +> > > > From: Susan Cassidy [mailto:cassidy@systransoft.com] +> > > > Sent: Friday, November 05, 2004 10:23 AM +> > > > To: 'dbi-users@perl.org' +> > > > Subject: DBD::Oracle and strange problem with Oracle error 'ORA- +> > > 01461: can bind a LONG value only for +> > > > insert into a LONG column' when data not LONG +> > > > +> > > > +> > > > +> > > > I had an application that was processing a bunch of xml and +> inserting +> > > into a table with a bunch of +> > > > VARCHAR2(4000) columns. +> > > > +> > > > +> > > > +> > > > A couple of the entries I was processing caused the 'ORA-01461: +> can +> > > bind a LONG value only for insert +> > > > into a LONG column' error. +> > > > +> > > > +> > > > +> > > > I put checks in for the length of the data, and nothing +> approached +> > > 4000 bytes in length. +> > > > +> > > > +> > > > +> > > > I tracked down some of the entries causing problems, and on +> certain +> > > specific data, if 2 columns +> > > > containing specific data are inserted together, I get this error. +> If +> > > only one of the 2 is inserted, I +> > > > do not get the error, regardless of which one of the two I +> insert. +> > > > +> > > > +> > > > +> > > > The lengths of the pieces of data are 1399 and 1397 characters. +> > > > +> > > > +> > > > +> > > > The data is somewhat odd-looking (we suspect some odd data is in +> this +> > > file), but there is no reason for +> > > > the error message to appear. +> > > > +> > > > +> > > > +> > > > Trace shows nothing helpful - it thinks the data is the right +> length. +> > > > +> > > > +> > > > +> > > > We've successfully inserted thousands of other, similar entries +> with +> > > no trouble. +> > > > +> > > > +> > > > +> > > > The basics are: +> > > > +> > > > #create table test_table (item1 varchar2(4000), item2 +> > > varchar2(4000)); +> > > > +> > > > +> > > > +> > > > my $statement="INSERT INTO test_table (item1,item2) VALUES (?, +> ?)"; +> > > > +> > > > +> > > > +> > > > $sth=$dbh->prepare($statement) || +> > > > +> > > > errexit("bad prepare for stmt $statement, error: +> $DBI::errstr"); +> > > > +> > > > my $rc=$sth->execute(@vals) || +> > > > +> > > > errexit("can't execute statement: error: $DBI::errstr\n"); +> > > > +> > > > +> > > > +> > > > Trace shows: +> > > > +> > > > +> > > > +> > > > DBI 1.45-ithread default trace level set to 0x0/2 (pid 6230) +> > > > +> > > > -> prepare for DBD::Oracle::db +> (DBI::db=HASH(0x82d4178)~0x82d6580 +> > > 'INSERT INTO test_table +> > > > (item1,item2) VALUES (?, ?) +> > > > +> > > > ') thr#8148ff0 +> > > > +> > > > dbd_preparse scanned 2 distinct placeholders +> > > > +> > > > <- prepare= DBI::st=HASH(0x82d6640) at test_insert_large.pl +> line +> > > 40 +> > > > +> > > > -> execute for DBD::Oracle::st +> (DBI::st=HASH(0x82d6640)~0x8149dcc +> > > 'version 11.2no service +> > > > password-encryptionservice +> > > > +> > > > udp-small-serversservice tcp-small-servers!hostname router1!!no +> ip +> > > domain-lookupip inspect name mysite +> > > > ftpip inspect name +> > > > +> > > > mysite smtpip inspect name mysite tcp!interface Ethernet0ip +> address +> > > 10.10.10.2 255.255.255.0ip +> > > > access-group 101 inip ins +> > > > +> > > > pect mysite inip inspect mysite outno keepalive!interface +> Serial0no +> > > ip addressencapsulation +> > > > frame-relay...' 'version 11.2 +> > > > +> > > > no service password-encryptionservice udp-small-serversservice +> tcp- +> > > small-servers!hostname router1!!no ip +> > > > domain-lookupip +> > > > +> > > > inspect name mysite ftpip inspect name mysite smtpip inspect name +> > > mysite tcp!interface Ethernet0ip +> > > > address 10.10.10.2 255 +> > > > +> > > > .255.255.0ip access-group 101 inip inspect mysiteinip inspect +> mysite +> > > outno keepalive!interface Serial0no +> > > > ip addressencaps +> > > > +> > > > ulation frame-relayn...') thr#8148ff0 +> > > > +> > > > bind :p1 <== 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostnam +> > > > +> > > > e router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface E +> > > > +> > > > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysite inip inspect mysite +> > > > outno keepalive!in +> > > > +> > > > terface Serial0no ip addressencapsulation frame-relay...' (type +> 0) +> > > > +> > > > bind :p1 <== 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostnam +> > > > +> > > > e router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface E +> > > > +> > > > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysite inip inspect mysite +> > > > outno keepalive!in +> > > > +> > > > terface Serial0no ip addressencapsulation frame-relay...' (size +> > > 1399/1400/0, ptype 4, otype 1) +> > > > +> > > > bind :p2 <== 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostnam +> > > > +> > > > e router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface E +> > > > +> > > > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysiteinip inspect mysite +> > > > outno keepalive!int +> > > > +> > > > erface Serial0no ip addressencapsulation frame-relayn...' (type +> 0) +> > > > +> > > > bind :p2 <== 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostnam +> > > > +> > > > e router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface E +> > > > +> > > > thernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysiteinip inspect mysite +> > > > outno keepalive!int +> > > > +> > > > erface Serial0no ip addressencapsulation frame-relayn...' (size +> > > 1397/1398/0, ptype 4, otype 1) +> > > > +> > > > dbd_st_execute INSERT (out0, lob0)... +> > > > +> > > > !! ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> > > insert into a LONG column (DBD ERROR: +> > > > OCIStmtExecute)' (e +> > > > +> > > > rr#1) +> > > > +> > > > <- execute= undef at test_insert_large.pl line 42 +> > > > +> > > > 1 -> FETCH for DBD::Oracle::st (DBI::st=HASH(0x8149dcc)~INNER +> > > 'ParamValues') thr#8148ff0 +> > > > +> > > > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> > > insert into a LONG column (DBD ERROR: +> > > > OCIStmtExecute)' (e +> > > > +> > > > rr#1) +> > > > +> > > > 1 <- FETCH= HASH(0x83487e0)2keys at test_insert_large.pl line +> 42 +> > > > +> > > > -> $DBI::errstr (&) FETCH from lasth=HASH +> > > > +> > > > >> DBD::Oracle::st::errstr +> > > > +> > > > <- $DBI::errstr= 'ORA-01461: can bind a LONG value only for +> > > insert into a LONG column (DBD ERROR: +> > > > OCIStmtExecute)' +> > > > +> > > > -- DBI::END +> > > > +> > > > -> disconnect_all for DBD::Oracle::dr +> > > (DBI::dr=HASH(0x824771c)~0x82d419c) thr#8148ff0 +> > > > +> > > > <- disconnect_all= (not implemented) at DBI.pm line 673 +> > > > +> > > > Connect done +> > > > +> > > > stmt: INSERT INTO test_table (item1,item2) VALUES (?, ?) +> > > > +> > > > Size of vals is 2 +> > > > +> > > > val 1 size 1399, is: 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostna +> > > > +> > > > me router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface +> > > > +> > > > Ethernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysite inip inspect mysite +> > > > outno keepalive!i +> > > > +> > > > nterface Serial0no ip addressencapsulation frame-relayno fair- +> > > queue!interface Serial0.1 point-to-pointip +> > > > address 10.10.11 +> > > > +> > > > .2 255.255.255.252ip access-group 102 inframe-relay interface- +> dlci +> > > 200 IETF!router eigrp 69network +> > > > 10.0.0.0no auto-summar +> > > > +> > > > y!ip default-gateway 10.10.11.1no ip classlessip route 0.0.0.0 +> > > 0.0.0.0 10.10.11.1access-list 101 permit +> > > > tcp 10.10.10.0 0. +> > > > +> > > > 0.0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 +> anyaccess- +> > > list 101 permit icmp 10.10.10.0 +> > > > 0.0.0.255 anyaccess- +> > > > +> > > > list 101 deny ip any anyaccess-list 102 permit eigrp any +> anyaccess- +> > > list 102 permit icmp any 10.10.10.0 +> > > > 0.0.0.255 echo-rep +> > > > +> > > > lyaccess-list 102 permit icmp any 10.10.10.0 0.0.0.255 +> > > unreachableaccess-list 102 permit icmp any +> > > > 10.10.10.0 0.0.0.255 ad +> > > > +> > > > ministratively-prohibitedaccess-list 102 permit icmp any +> 10.10.10.0 +> > > 0.0.0.255 packet-too-bigaccess-list +> > > > 102 permit icmp a +> > > > +> > > > ny 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any +> > > 10.10.10.0 0.0.0.255 +> > > > time-exceededaccess-list 102 permit tcp +> > > > +> > > > any host 10.10.10.1 eq smtpaccess-list 102 deny ip any any!line +> con +> > > 0line vty 0 4login!end' +> > > > +> > > > val 2 size 1397, is: 'version 11.2no service password- +> > > encryptionservice udp-small-serversservice +> > > > tcp-small-servers!hostna +> > > > +> > > > me router1!!no ip domain-lookupip inspect name mysite ftpip +> inspect +> > > name mysite smtpip inspect name +> > > > mysite tcp!interface +> > > > +> > > > Ethernet0ip address 10.10.10.2 255.255.255.0ip access-group 101 +> inip +> > > inspect mysiteinip inspect mysite +> > > > outno keepalive!in +> > > > +> > > > terface Serial0no ip addressencapsulation frame-relayno fair- +> > > queue!interface Serial0.1 point-to-pointip +> > > > address 10.10.11. +> > > > +> > > > 2 255.255.255.252ip access-group 102 inframe-relay interface-dlci +> 200 +> > > IETF!router eigrp 69network +> > > > 10.0.0.0no auto-summary +> > > > +> > > > !ip default-gateway 10.10.11.1no ip classlessip route 0.0.0.0 +> 0.0.0.0 +> > > 10.10.11.1access-list 101 permit +> > > > tcp 10.10.10.0 0.0 +> > > > +> > > > .0.255 anyaccess-list 101 permit udp 10.10.10.0 0.0.0.255 +> anyaccess- +> > > list 101 permiticmp 10.10.10.0 +> > > > 0.0.0.255 anyaccess-li +> > > > +> > > > st 101 deny ip any anyaccess-list 102 permit eigrp any anyaccess- +> list +> > > 102 permit icmp any 10.10.10.0 +> > > > 0.0.0.255 echo-reply +> > > > +> > > > access-list 102 permit icmp any 10.10.10.0 0.0.0.255 +> > > unreachableaccess-list 102 permit icmp any +> > > > 10.10.10.0 0.0.0.255 admi +> > > > +> > > > nistratively-prohibitedaccess-list 102 permit icmp any 10.10.10.0 +> > > 0.0.0.255 packet-too-bigaccess-list +> > > > 102 permit icmp any +> > > > +> > > > 10.10.10.0 0.0.0.255 echoaccess-list 102 permit icmp any +> 10.10.10.0 +> > > 0.0.0.255 time-exceededaccess-list +> > > > 102 permit tcp an +> > > > +> > > > y host 10.10.10.1 eq smtpaccess-list 102 deny ip any any!line con +> > > 0line vty 0 4login!end' +> > > > +> > > > can't execute statement: error: ORA-01461: can bind a LONG value +> only +> > > for insert into a LONG column (DBD +> > > > ERROR: OCIStmtEx +> > > > +> > > > ecute) +> > > > +> > > > +> > > > +> > > > ! -> DESTROY for DBD::Oracle::db +> (DBI::db=HASH(0x82d6580)~INNER) +> > > thr#8148ff0 +> > > > +> > > > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> > > insert into a LONG column (DBD ERROR: +> > > > OCIStmtExecute)' (e +> > > > +> > > > rr#0) +> > > > +> > > > ! <- DESTROY= undef during global destruction +> > > > +> > > > ! -> DESTROY in DBD::_::common for DBD::Oracle::dr +> > > (DBI::dr=HASH(0x82d419c)~INNER) thr#8148ff0 +> > > > +> > > > ! <- DESTROY= undef during global destruction +> > > > +> > > > ! -> DESTROY for DBD::Oracle::st +> (DBI::st=HASH(0x8149dcc)~INNER) +> > > thr#8148ff0 +> > > > +> > > > ERROR: '1461' 'ORA-01461: can bind a LONG value only for +> > > insert into a LONG column (DBD ERROR: +> > > > OCIStmtExecute)' (e +> > > > +> > > > rr#1) +> > > > +> > > > ! <- DESTROY= undef during global destruction +> > > > +> > > > +> > > > +> > > > I will attach the test program. Somehow it seems to think the +> > > datatype is LONG instead of VARCHAR. +> > > > +> > > > +> > > > +> > > > +> > > > +> > > > Anyone with ideas? +> > > > +> > > > +> > > > +> > > > +> > > > +> > > > Thanks, +> > > > +> > > > Susan +> > > +> > +> + + + +From SRS0=xs68=OE=systransoft.com=cassidy@bounce2.pobox.com Thu Nov 18 07:11:03 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id iAI7Ar8G057950 + for ; Thu, 18 Nov 2004 07:11:03 GMT + (envelope-from SRS0=xs68=OE=systransoft.com=cassidy@bounce2.pobox.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 18 Nov 2004 07:11:03 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@data-plan.com id 1CUaCR-0002mS-7P; + Thu, 18 Nov 2004 00:30:59 +0000 +Received: from [194.217.242.72] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1CUaCR-0002mS-7P + for pobox@data-plan.com; Thu, 18 Nov 2004 00:30:59 +0000 +Received: from [208.58.1.194] (helo=integer.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1CUaCQ-0004JQ-R5 + for pobox@data-plan.com; Thu, 18 Nov 2004 00:30:59 +0000 +Received: from integer.pobox.com (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id 17ACAA3F35; + Wed, 17 Nov 2004 19:30:58 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from integer (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id 04F8DA3EAC + for ; Wed, 17 Nov 2004 19:30:58 -0500 (EST) +Received-SPF: none (integer.pobox.com: domain of cassidy@systransoft.com does not designate permitted sender hosts) +X-SPF-Guess: pass (seems reasonable for cassidy@systransoft.com to mail through 66.185.164.3) +Received: from mailhost.systransoft.com (mailhost.systransoft.com [66.185.164.3]) + by integer.pobox.com (Postfix) with ESMTP id A9FC6A3F4D + for ; Wed, 17 Nov 2004 19:30:43 -0500 (EST) +Received: from localhost (localhost [127.0.0.1]) + by mailhost.systransoft.com (Postfix) with ESMTP id DEA102441A9 + for ; Wed, 17 Nov 2004 16:30:41 -0800 (PST) +Received: from mailhost.systransoft.com ([127.0.0.1]) + by localhost (mailhost.systransoft.com [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 22204-10 for ; + Wed, 17 Nov 2004 16:30:41 -0800 (PST) +Received: from hapax (hapax [192.168.2.186]) + by mailhost.systransoft.com (Postfix) with ESMTP id 7AD52244370 + for ; Wed, 17 Nov 2004 16:30:40 -0800 (PST) +From: "Susan Cassidy" +To: "'Tim Bunce'" +Subject: RE: FW: DBD::Oracle and strange problem with Oracle error 'ORA-01461: can bind a LONG value only for insert into a LONG column' when data not LONG +Date: Wed, 17 Nov 2004 16:28:41 -0800 +Organization: SYSTRAN Software, Inc. +MIME-Version: 1.0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +X-Mailer: Microsoft Office Outlook, Build 11.0.5510 +In-Reply-To: <20041118001712.GB49519@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 +Thread-Index: AcTNA/o7HZXghXaJRbyz8M5kVQMQmwAAUBjg +Message-Id: <20041118003040.7AD52244370@mailhost.systransoft.com> +X-Virus-Scanned: by amavisd-new at systransoft.com +Status: RO +Content-Length: 1789 +Lines: 63 + +Hi, + +I set NLS_LANG to .US7ASCII, ran it again, and I get the same error. + +Of course, I could not use that in production. + +The really strange part, to me, was that if I just insert one of the 2 +problematic columns, it worked, but both together failed. + +Thanks, +Susan + +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Wednesday, November 17, 2004 4:17 PM +> To: Susan Cassidy +> Cc: 'Tim Bunce' +> Subject: Re: FW: DBD::Oracle and strange problem with Oracle error 'ORA- +> 01461: can bind a LONG value only for insert into a LONG column' when data +> not LONG +> +> And does the problem go away if NLS_LANG is set to a non-unicode charset? +> +> Tim. +> +> On Wed, Nov 17, 2004 at 11:36:14AM -0800, Susan Cassidy wrote: +> > NLS_LANG=.UTF8 +> > ORA_NLS33=/home/oracle/product/9.2.0/ocommon/nls/admin/data +> > ORA_NLS33=/home/oracle/product/9.2.0/ocommon/nls/admin/data +> > ORACLE_HOME=/home/oracle/product/9.2.0 +> > ORACLE_SID=AL32UTF8 +> > ORACLE_BASE=/home/oracle +> > +> > NLS_NCHAR is not set, because we are not using any NVARCHAR data item, +> and +> > haven't needed it. +> > +> > Susan +> > +> > > -----Original Message----- +> > > From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> > > Sent: Wednesday, November 17, 2004 11:29 AM +> > > To: Susan Cassidy +> > > Cc: 'Tim Bunce' +> > > Subject: Re: FW: DBD::Oracle and strange problem with Oracle error +> 'ORA- +> > > 01461: can bind a LONG value only for insert into a LONG column' when +> data +> > > not LONG +> > > +> > > Thanks. What are your client side NLS_LANG and NLS_NCHAR settings? +> > > +> > > Tim. +> > > +> > > On Wed, Nov 17, 2004 at 10:22:44AM -0800, Susan Cassidy wrote: +> > > > I did - it is attached to the posting. However, I will attach it +> again +> > > > here. +> > > > +> > > > Thanks, +> > > > Susan +> > > > + + diff --git a/err_unsorted/err_etherreal.msg b/err_unsorted/err_etherreal.msg new file mode 100644 index 00000000..1ad5c78e --- /dev/null +++ b/err_unsorted/err_etherreal.msg @@ -0,0 +1,90 @@ +From dbi-users-return-11185-Tim.Bunce=pobox.com@perl.org Tue Apr 30 14:47:44 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3UDliR22576 + for ; Tue, 30 Apr 2002 14:47:44 +0100 (BST) + (envelope-from dbi-users-return-11185-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.23] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 30 Apr 2002 14:47:44 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020172466:10:24548:59; Tue, 30 Apr 2002 13:14:26 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1023391; 30 Apr 2002 13:13 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id A94562C075 + for ; Tue, 30 Apr 2002 09:12:33 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [209.85.157.220]) + by dolly1.pobox.com (Postfix) with SMTP id F24B22BFBE + for ; Tue, 30 Apr 2002 09:12:32 -0400 (EDT) +Received: (qmail 36589 invoked by uid 1005); 30 Apr 2002 13:12:28 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 36168 invoked by uid 76); 30 Apr 2002 13:10:41 -0000 +Content-Type: text/plain; + charset="iso-8859-1" +From: Calin Medianu +To: Tim Bunce +Subject: Re: DBD::Oracle Slow cursors +Date: Tue, 30 Apr 2002 16:04:47 +0300 +X-Mailer: KMail [version 1.3.2] +References: <20020429201853.52283.qmail@web10007.mail.yahoo.com> <20020429233138.E16831@dansat.data-plan.com> +In-Reply-To: <20020429233138.E16831@dansat.data-plan.com> +Cc: dbi-users@perl.org +MIME-Version: 1.0 +Message-Id: <20020430131233.F24B22BFBE@dolly1.pobox.com> +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by dansat.data-plan.com id g3UDliR22576 +Status: RO +X-Status: A +Content-Length: 1213 +Lines: 38 + +[Add note to DBD::Oracle docs about using ethereal to sniff Oracle packets] +[Not sure if this bug got fixed yet. Maybe not.] + +Me again with the slow cursors. + +I modified both queries to only return 10 rows. +I ran a sniffer (ethereal) on the NIC. It is pretty cool, it also decodes TNS. + +when I am using the SQL, it works like this, there are about 7 packets +received by my workstation to set up the session, then all 10 rows are in the +same packet, then there is another packet probably saying goodbye. + +When I am using the REF cursor, each row comes in it's own TNS packet, that +is why it is so slow! + +Any idea how to fix it? + +thanks a lot, + +Calin + +> On Mon, Apr 29, 2002 at 01:18:53PM -0700, Calin Medianu wrote: +> > Hello, +> > +> > I did the following. Wrote a perl script that retreves +> > data via a straight select from the database. Then I +> > wrote a stored procedure returning a ref cursor open +> > on the same select statement and retrieved the data as +> > well. Using the REF CURSOR/ sotred procedure was about +> > 3 time slower, that is 40 seconds instead of around +> > 10. +> > +> > Is this normal? Is this a problem with oracle or with +> > DBD::Oracle? +> +> DBD::Oracle. It probably isn't setting up a row cache for the ref cursor. +> +> Get a level 3 trace and look for the "dbd_describe'd" line for the +> ref cursor. +> +> Tim. + diff --git a/err_unsorted/err_memleak2.msg b/err_unsorted/err_memleak2.msg new file mode 100644 index 00000000..97501852 --- /dev/null +++ b/err_unsorted/err_memleak2.msg @@ -0,0 +1,476 @@ +From mike@boom.net Fri Nov 28 22:23:33 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id hASMLLnY018698 + for ; Fri, 28 Nov 2003 22:23:33 GMT + (envelope-from mike@boom.net) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 28 Nov 2003 22:23:33 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1APmgW-0006iM-9g; + Fri, 28 Nov 2003 17:45:40 +0000 +Received: from [207.8.214.2] (helo=icicle.pobox.com) + by punt-3.mail.demon.net with esmtp id 1APmgW-0006iM-9g + for pobox@dbi.demon.co.uk; Fri, 28 Nov 2003 17:45:40 +0000 +Received: from icicle.pobox.com (localhost[127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id E82CD95E03 + for ; Fri, 28 Nov 2003 12:45:38 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost[127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id B1EE595DFB + for ; Fri, 28 Nov 2003 12:45:38 -0500 (EST) +Received: from abort.boom.net (abort.boom.net[69.36.241.24]) + by icicle.pobox.com (Postfix) with ESMTP + for ; Fri, 28 Nov 2003 12:45:38 -0500 (EST) +Received: by abort.boom.net (Postfix, from userid 530) + id E3C8B8517A; Fri, 28 Nov 2003 09:45:36 -0800 (PST) +Date: Fri, 28 Nov 2003 09:45:36 -0800 +From: Mike Hedlund +To: dbi-users@perl.org +Cc: Tim.Bunce@pobox.com +Subject: Memory leak in DBD::Oracle 1.14 ... ? +Message-ID: <20031128174536.GJ10609@boom.net> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.5.4i +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by dansat.data-plan.com id hASMLLnY018698 +Content-Length: 24309 +Lines: 434 + +I've attached a little script which replicates the problem on my machine as well as the build session log for DBD::Oracle 1.14. + +I've tested it using DBI 1.38 and DBI 1.28 with both DBD::Oracle 1.12 and 1.14. + +Regardless of the DBI version, DBD::Oracle 1.14 leaks on my system and DBD::Oracle 1.12 does not. I've noticed the leak when calling connect_cached(), do() (or prepare()/execute()/commit/finish). + +-mike + + +-------------------- script --------------- +#!/usr/bin/perl +use strict; +use DBI; + +my($dbp) = "dbi:Oracle:host=weirdo.com;port=1521;sid=SID"; +my($dbu) = "username"; +my($dbpass) = "password"; + +while (1) { + my($sth); + my(@row); + my($dbh) = DBI->connect_cached($dbp,$dbu,$dbpass) || die "Couldn't connect to oracle db: $DBI::errstr\n"; + +## +## uncomment these and it just leaks faster. +## +# $sth = $dbh->prepare("SELECT * from FROM_STATS"); +# $sth->execute; +# while(@row = $sth->fetchrow_array) { + ##print "row: @row\n"; +# } +# $sth->finish; +} +exit; +------------------------ end script -------------------- + + +------------ log --------------------------------------- +Script started on Fri 28 Nov 2003 09:11:15 AM PST +[mike@commando DBD-Oracle-1.14]$ setenv ORACLE_HOME /home/orahome +[mike@commando DBD-Oracle-1.14]$ make realclean +rm -f blib/script/ora_explain +rm -rf Oracle.c Oracle.xsi dll.base dll.exp sqlnet.log libOracle.def ora_explain mk.pm ./blib Makefile.aperl blib/arch/auto/DBD/Oracle/extralibs.all perlmain.c tmon.out mon.out so_locations pm_to_blib *.o *.a perl.exe perl perl Oracle.bs Oracle.bso Oracle.def libOracle.def Oracle.exp Oracle.x core core.*perl.*.? *perl.core +mv Makefile Makefile.old > /dev/null 2>&1 +rm -rf blib/lib/auto/DBD/Oracle blib/arch/auto/DBD/Oracle +rm -rf DBD-Oracle-1.14 +rm -f blib/arch/auto/DBD/Oracle/Oracle.so blib/arch/auto/DBD/Oracle/Oracle.bs +rm -f blib/arch/auto/DBD/Oracle/Oracle.a +rm -f blib/lib/DBD/Oracle.pm blib/arch/auto/DBD/Oracle/dbdimp.h blib/lib/oraperl.ph +rm -f blib/arch/auto/DBD/Oracle/ocitrace.h blib/lib/Oraperl.pm +rm -f blib/arch/auto/DBD/Oracle/Oracle.h blib/arch/auto/DBD/Oracle/mk.pm +rm -f blib/lib/DBD/Oracle/GetInfo.pm +rm -rf Makefile Makefile.old +[mike@commando DBD-Oracle-1.14]$ perl Makefile.PL -v +Using DBI 1.38 installed in /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI + + Configuring DBD::Oracle ... + +>>> Remember to actually *READ* the README file! + Especially if you have any problems. + +Using Oracle in /home/orahome + +WARNING: could not decode oracle version from +/home/orahome/orainst/inspdver, or /home/orahome/install/unix.rgs +or from ORACLE_HOME path /home/orahome. +Oracle version based logic in Makefile.PL may produce erroneous results. + +Found header files in rdbms/public rdbms/demo. +Found /home/orahome/rdbms/demo/demo_rdbms.mk +Found /home/orahome/otrace/demo/atmoci.mk +Found /home/orahome/precomp/demo/proc/demo_proc.mk +Using /home/orahome/rdbms/demo/demo_rdbms.mk +Reading /home/orahome/rdbms/demo/demo_rdbms.mk +Reading /home/orahome/rdbms/lib/env_rdbms.mk +Read a total of 2202 lines from /home/orahome/rdbms/lib/env_rdbms.mk (including inclusions) +Read a total of 2493 lines from /home/orahome/rdbms/demo/demo_rdbms.mk (including inclusions) +Deleted SHELL definition: SHELL=/bin/sh +Deleted LIB_EXT definition: LIB_EXT=a +Deleted OBJ_EXT definition: OBJ_EXT=o +Deleted AR definition: AR=ar +Deleted AS definition: AS=as +Deleted CC definition: CC=cc +Deleted CHMOD definition: CHMOD=chmod +Deleted CPP definition: CPP=cpp +Deleted ECHO definition: ECHO=echo +Deleted LD definition: LD=ld +Deleted PERL definition: PERL=perl +Deleted CFLAGS definition: CFLAGS=$(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ + $(SHARED_CFLAG) $(USRFLAGS) +Deleted LDFLAGS definition: LDFLAGS=-o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) +Deleted LDFLAGS definition: LDFLAGS=-o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) $(LDPATHFLAG)$(LIBHOME)stubs/ +Deleted OPTIMIZE definition: OPTIMIZE=$(OPTIMIZE3) +Deleted AR definition: AR=/usr/bin/ar +Deleted AS definition: AS=/usr/bin/as +Deleted LD definition: LD=/usr/bin/ld +Deleted CPP definition: CPP=/lib/cpp +Deleted CHMOD definition: CHMOD=/bin/chmod +Deleted ASFLAGS definition: ASFLAGS= +Deleting ORA_NLS = $(ORACLE_HOME)/ocommon/nls/admin/data/ + because it is not already set in the environment + and it can cause ORA-01019 errors. +Deleted ORA_NLS definition: ORA_NLS = $(ORACLE_HOME)/ocommon/nls/admin/data/ +Deleting ORA_NLS33 = $(ORACLE_HOME)/ocommon/nls/admin/data/ + because it is not already set in the environment + and it can cause ORA-01019 errors. +Deleted ORA_NLS33 definition: ORA_NLS33 = $(ORACLE_HOME)/ocommon/nls/admin/data/ +Appending '/home/orahome/rdbms/lib/libskgxpd.a /home/orahome/rdbms/lib/libskgxpu.a /home/orahome/rdbms/lib/libskgxpt.a' to EXTRALIBS +Appending '$(LIBHOME)libskgxp9.so' to SHLIBS +Appending '/home/orahome/rdbms/lib/libskgxp9.a' to LIBS +Appending '/home/orahome/rdbms/lib/libskgxns.a /home/orahome/rdbms/lib/libskgxnd.a /home/orahome/rdbms/lib/libskgxnr.a' to EXTRALIBS +Appending '$(LIBHOME)libskgxn9.so' to SHLIBS +Appending '/home/orahome/rdbms/lib/libskgxn9.a' to LIBS +Evaluating `cat $(LIBHOME)sysliblist` + expanded `cat /home/orahome/lib/sysliblist` + returned '-ldl -lm -lpthread -lnsl ' + +Attempting to discover Oracle OCI build rules +gcc -c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c +by executing: (make -f /home/orahome/rdbms/demo/demo_rdbms.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=echo OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o) +returned: +[echo -L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh `cat /home/orahome/lib/sysliblist` -ldl -lm + +[-L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm +] +reduced to: +[-L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm +] +Oracle oci build command: + + -L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm + + + +System: perl5.008 linux stripples.devel.redhat.com 2.4.21-1.1931.2.382.entsmp #1 smp wed aug 6 17:18:52 edt 2003 i686 i686 i386 gnulinux +Compiler: gcc -O2 -g -pipe -march=i386 -mcpu=i686 -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm +Linker: /usr/bin/ld +Sysliblist: -ldl -lm -lpthread -lnsl +Oracle makefiles would have used these definitions but we override them: + CC: cc + + CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ + $(SHARED_CFLAG) $(USRFLAGS) + [$(GFLAG) -O3 $(CDEBUG) $(CCFLAGS) -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -DLINUX -D_GNU_SOURCE -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 -DSLTS_ENABLE -DSLMXMX_ENABLE -D_REENTRANT -DNS_THREADS $(LPFLAGS) $(USRFLAGS)] + + LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) $(LDPATHFLAG)$(LIBHOME)stubs/ + [-o $@ -L/home/orahome/rdbms/lib/ -L$(LIBHOME) -L$(LIBHOME)stubs/] + + +Linking with OTHERLDFLAGS = -L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm + [from 'build' rule] + + +MakeMaker (v6.03) +Checking if your kit is complete... +Looks good + ABSTRACT_FROM => q[Oracle.pm] + AUTHOR => q[Tim Bunce (dbi-users@perl.org)] + DEFINE => q[ -DUTF8_SUPPORT] + DIR => [] + EXE_FILES => [q[ora_explain]] + INC => q[-I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/rdbms/demo -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI] + NAME => q[DBD::Oracle] + OBJECT => q[$(O_FILES)] + PREREQ_PM => { DBI=>q[0] } + VERSION_FROM => q[Oracle.pm] + clean => { FILES=>q[Oracle.xsi dll.base dll.exp sqlnet.log libOracle.def ora_explain mk.pm] } + dist => { DIST_DEFAULT=>q[clean distcheck disttest ci tardist], COMPRESS=>q[gzip -v9], PREOP=>q[$(MAKE) -f Makefile.old distdir], SUFFIX=>q[gz] } + dynamic_lib => { OTHERLDFLAGS=>q[ -L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm +] } +Using PERL=/usr/bin/perl +LD_RUN_PATH=/home/orahome/lib:/home/orahome/rdbms/lib +Using DBD::Oracle 1.14. +Using DBD::Oracle 1.14. +Using DBI 1.38 installed in /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI +Writing Makefile for DBD::Oracle + +*** If you have problems... + read all the log printed above, and the README and README.help files. + (Of course, you have read README by now anyway, haven't you?) + +[mike@commando DBD-Oracle-1.14]$ make +cp Oracle.pm blib/lib/DBD/Oracle.pm +cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h +cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h +cp oraperl.ph blib/lib/oraperl.ph +cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h +cp Oraperl.pm blib/lib/Oraperl.pm +cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm +cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm +/usr/bin/perl -p -e "s/~DRIVER~/Oracle/g" /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI/Driver.xst > Oracle.xsi +/usr/bin/perl /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typemap Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c +gcc -c -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/rdbms/demo -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686 -DVERSION=\"1.14\" -DXS_VERSION=\"1.14\" -fPIC "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" -DUTF8_SUPPORT Oracle.c +gcc -c -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/rdbms/demo -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686 -DVERSION=\"1.14\" -DXS_VERSION=\"1.14\" -fPIC "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" -DUTF8_SUPPORT dbdimp.c +gcc -c -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/rdbms/demo -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686 -DVERSION=\"1.14\" -DXS_VERSION=\"1.14\" -fPIC "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" -DUTF8_SUPPORT oci7.c +gcc -c -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/plsql/public -I/home/orahome/network/public -I/home/orahome/rdbms/demo -I/home/orahome/rdbms/public -I/home/orahome/rdbms/demo -I/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686 -DVERSION=\"1.14\" -DXS_VERSION=\"1.14\" -fPIC "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" -DUTF8_SUPPORT oci8.c +Running Mkbootstrap for DBD::Oracle () +chmod 644 Oracle.bs +rm -f blib/arch/auto/DBD/Oracle/Oracle.so +LD_RUN_PATH="/home/orahome/lib:/home/orahome/rdbms/lib" gcc -shared -L/usr/local/lib Oracle.o dbdimp.o oci7.o oci8.o -L/home/orahome/lib/ -L/home/orahome/rdbms/lib/ -lclntsh -ldl -lm -lpthread -lnsl -ldl -lm -o blib/arch/auto/DBD/Oracle/Oracle.so +chmod 755 blib/arch/auto/DBD/Oracle/Oracle.so +cp Oracle.bs blib/arch/auto/DBD/Oracle/Oracle.bs +chmod 644 blib/arch/auto/DBD/Oracle/Oracle.bs +/usr/bin/perl "-Iblib/arch" "-Iblib/lib" ora_explain.PL ora_explain +Extracted ora_explain from ora_explain.PL with variable substitutions. +cp ora_explain blib/script/ora_explain +/usr/bin/perl "-MExtUtils::MY" -e "MY->fixin(shift)" blib/script/ora_explain +Manifying blib/man3/DBD::Oracle.3pm +Manifying blib/man1/ora_explain.1 +Manifying blib/man3/DBD::Oraperl.3pm +[mike@commando DBD-Oracle-1.14]$ make test +PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t +t/base....... t/base.......ok 1/5 t/base.......ok 2/5 t/base.......ok 3/5 t/base.......ok 4/5 t/base.......ok 5/5 t/base.......ok +t/cursor.....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle as scott/tiger (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +skipped + all skipped: no reason given +t/general....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at t/general.t line 20 +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +skipped + all skipped: no reason given +t/long.......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +skipped + all skipped: no reason given +t/meta.......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle as scott/tiger (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +skipped + all skipped: no reason given +t/ph_type....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at t/ph_type.t line 26 +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +skipped + all skipped: no reason given +t/plsql......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +skipped + all skipped: no reason given +t/reauth.....skipped + all skipped: no reason given +t/select.....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +skipped + all skipped: no reason given +All tests successful, 8 tests skipped. +Files=9, Tests=5, 7 wallclock secs ( 3.82 cusr + 0.33 csys = 4.15 CPU) +PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl +Oraperl test application $Revision: 1.7 $ + + +Extra tests. These are less formal and you need to read the output +to see if it looks reasonable and matches what the tests says is expected. + +Oraperl emulation interface version 1.43 +DBD::Oracle 1.14 using OCI8 by Tim Bunce +DBI 1.38 by Tim Bunce + +Data sources: + + + +Connecting + to '' (from command line, else uses ORACLE_SID or TWO_TASK - recommended) + as 'scott/tiger' (via ORACLE_USERID env var or default - recommend name/passwd@dbname) +(ORACLE_SID='', TWO_TASK='') +oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at /home/mike/tmp/DBD-Oracle-1.14/blib/lib/Oraperl.pm line 104 +ora_login: 12547: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) + +Generally set TWO_TASK or ORACLE_SID but not both at the same time. +Try to connect to the database using an oracle tool like sqlplus +only if that works should you suspect problems with DBD::Oracle. +Try leaving dbname value empty and set dbuser to name/passwd@dbname. + +Test aborted. +make: *** [test_dynamic] Error 255 +[mike@commando DBD-Oracle-1.14]$ make test TEST_VERBOSE=1 +PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(1, 'blib/lib', 'blib/arch')" t/*.t +t/base.......1..5 +ok 1 +ok 2 +ok 3 +ok 4 +ok 5 +ok +t/cursor.....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle as scott/tiger (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +1..0 +skipped + all skipped: no reason given +t/general....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at t/general.t line 20 +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +1..0 +skipped + all skipped: no reason given +t/long.......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +1..0 +skipped + all skipped: no reason given +t/meta.......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle as scott/tiger (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +1..0 +skipped + all skipped: no reason given +t/ph_type....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at t/ph_type.t line 26 +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skipped. +1..0 +skipped + all skipped: no reason given +t/plsql......oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +1..0 +skipped + all skipped: no reason given +t/reauth.....ORACLE_USERID_2 not defined. +Tests skiped. +1..0 +skipped + all skipped: no reason given +t/select.....oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +Unable to connect to Oracle (ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)) +Tests skiped. +1..0 +skipped + all skipped: no reason given +All tests successful, 8 tests skipped. +Files=9, Tests=5, 7 wallclock secs ( 3.85 cusr + 0.32 csys = 4.17 CPU) +PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl +Oraperl test application $Revision: 1.7 $ + + +Extra tests. These are less formal and you need to read the output +to see if it looks reasonable and matches what the tests says is expected. + +Oraperl emulation interface version 1.43 +DBD::Oracle 1.14 using OCI8 by Tim Bunce +DBI 1.38 by Tim Bunce + +Data sources: + + + +Connecting + to '' (from command line, else uses ORACLE_SID or TWO_TASK - recommended) + as 'scott/tiger' (via ORACLE_USERID env var or default - recommend name/passwd@dbname) +(ORACLE_SID='', TWO_TASK='') +oracle: error while loading shared libraries: libodm9.so: cannot open shared object file: No such file or directory +DBI connect('','scott/tiger',...) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) at /home/mike/tmp/DBD-Oracle-1.14/blib/lib/Oraperl.pm line 104 +ora_login: 12547: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach) + +Generally set TWO_TASK or ORACLE_SID but not both at the same time. +Try to connect to the database using an oracle tool like sqlplus +only if that works should you suspect problems with DBD::Oracle. +Try leaving dbname value empty and set dbuser to name/passwd@dbname. + +Test aborted. +make: *** [test_dynamic] Error 255 +[mike@commando DBD-Oracle-1.14]$ perl _V-V +Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: + Platform: + osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi + uname='linux str' + config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' + hint=recommended, useposix=true, d_sigaction=define + usethreads=define use5005threads=undef' + useithreads=define usemultiplicity= + useperlio= d_sfio=undef uselargefiles=define usesocks=undef + use64bitint=undef use64bitall=un uselongdouble= + usemymalloc=, bincompat5005=undef + Compiler: + cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', + optimize='', + cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' + ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers='' +gccversion='3.2.2 200302' + intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234 + d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 + ivtype='long' +k', ivsize=4' +ivtype='l, nvtype='double' +o_nonbl', nvsize=, Off_t='', lseeksize=8 + alignbytes=4, prototype=define + Linker and Libraries: + ld='gcc' +l', ldflags =' -L/u' + libpth=/usr/local/lib /lib /usr/lib + libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil + perllibs= + libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper + gnulibc_version='2.3.2' + Dynamic Linking: + dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' + cccdlflags='-fPIC' +ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s Unicode/Normalize XS/A' + + +Characteristics of this binary (from libperl): + Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT + Locally applied patches: + MAINT18379 + Built under linux + Compiled at Aug 13 2003 11:47:58 + @INC: + /usr/lib/perl5/5.8.0/i386-linux-thread-multi + /usr/lib/perl5/5.8.0 + /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi + /usr/lib/perl5/site_perl/5.8.0 + /usr/lib/perl5/site_perl + /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi + /usr/lib/perl5/vendor_perl/5.8.0 + /usr/lib/perl5/vendor_perl + /usr/lib/perl5/5.8.0/i386-linux-thread-multi + /usr/lib/perl5/5.8.0 + . +[mike@commando DBD-Oracle-1.14]$ ^D +Script done on Fri 28 Nov 2003 09:16:43 AM PST +------------ end log ----------------------------------- + + diff --git a/err_unsorted/err_multiora.msg b/err_unsorted/err_multiora.msg new file mode 100644 index 00000000..9f7bcf6c --- /dev/null +++ b/err_unsorted/err_multiora.msg @@ -0,0 +1,470 @@ +From dbi-users-return-21438-Tim.Bunce=pobox.com@perl.org Mon Jan 5 10:12:58 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i05ACYn1063537 + for ; Mon, 5 Jan 2004 10:12:58 GMT + (envelope-from dbi-users-return-21438-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Mon, 05 Jan 2004 10:12:58 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AdQXY-0007a7-IO; + Mon, 05 Jan 2004 09:18:18 +0000 +Received: from [208.58.1.194] (helo=integer.pobox.com) + by punt-3.mail.demon.net with esmtp id 1AdQXY-0007a7-IO + for pobox@dbi.demon.co.uk; Mon, 05 Jan 2004 08:56:48 +0000 +Received: from integer.pobox.com (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id C92F0282F + for ; Mon, 5 Jan 2004 03:56:45 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id B344B2B84 + for ; Mon, 5 Jan 2004 03:56:45 -0500 (EST) +Received: from onion.perl.org (onion.develooper.com [63.251.223.166]) + by integer.pobox.com (Postfix) with SMTP + for ; Mon, 5 Jan 2004 03:56:45 -0500 (EST) +Received: (qmail 58691 invoked by uid 1005); 5 Jan 2004 08:56:38 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 58674 invoked by uid 76); 5 Jan 2004 08:56:38 -0000 +Received: from qmailr@one.develooper.com (HELO ran-out.mx.develooper.com) (64.81.84.115) by onion.perl.org (qpsmtpd/0.26) with SMTP; Mon, 05 Jan 2004 00:56:38 -0800 +Received: (qmail 17937 invoked by uid 225); 5 Jan 2004 08:56:36 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 17930 invoked by uid 507); 5 Jan 2004 08:56:36 -0000 +Received: from stone.sifira.dk (HELO mail.int.sifira.dk) (217.157.24.2) by one.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Mon, 05 Jan 2004 00:56:05 -0800 +Received: from ash.int.sifira.dk (ash.int.sifira.dk [192.168.1.7]) by mail.int.sifira.dk (Postfix) with ESMTP id F127674F58; Mon, 5 Jan 2004 09:55:58 +0100 (MET) +Sender: kn@sifira.dk +To: "Anniballi, Fran" +Cc: +Subject: Re: Help - multiple Oracle versions +References: <6B003D25ADBDE347B5542AFE6A55B42E03227831@tayexc13.americas.cpqcorp.net> +From: Kristian Nielsen +Date: 05 Jan 2004 09:55:59 +0100 +In-Reply-To: <6B003D25ADBDE347B5542AFE6A55B42E03227831@tayexc13.americas.cpqcorp.net> +Message-ID: <7sllomsrj4.fsf@ash.int.sifira.dk> +User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=-2.5 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Status: RO +Content-Length: 1223 +Lines: 40 + +[Add notes to docs covering what's in this thread] + +"Anniballi, Fran" writes: + +> For option two, if I have two versions of DBD:Oracle, how do I tell +> Perl which one to use? My scripts just say "/usr/bin/perl" in the +> first line. + +Basically, when you compile you use the PREFIX option: + + export ORACLE_HOME=/usr/local/oracle8 + perl Makefile.PL PREFIX=/usr/local/oracle8-perl + make + make install + + export ORACLE_HOME=/usr/local/oracle9 + perl Makefile.PL PREFIX=/usr/local/oracle9-perl + make + make install + +Then before running the perl script you should set the PERLLIB +environment variable to point to the correct location for the proper +version of DBD::Oracle. Alternatively, you could have the perl script +select the proper DBD::Oracle location based on the value of +ORACLE_HOME: + + #! /usr/bin/perl + BEGIN { + if($ENV{ORACLE_HOME} =~ /8/) { + use lib '/usr/local/oracle8-perl/REST/OF/PATH'; + } else { + use lib '/usr/local/oracle9-perl/REST/OF/PATH'; + } + } + use DBI; + +This is all from the top of my head; you will need to fiddle a bit to +get the details right (like the correct path etc). Also, I think this +has been covered in greater detail before; you might want to try +searching the archives. + + - Kristian. + + +From dbi-users-return-21441-Tim.Bunce=pobox.com@perl.org Mon Jan 5 14:47:30 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i05Ejvo1064760 + for ; Mon, 5 Jan 2004 14:47:30 GMT + (envelope-from dbi-users-return-21441-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Mon, 05 Jan 2004 14:47:30 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AdVCS-0004w0-Is; + Mon, 05 Jan 2004 13:55:22 +0000 +Received: from [208.58.1.194] (helo=integer.pobox.com) + by punt-3.mail.demon.net with esmtp id 1AdVCS-0004w0-Is + for pobox@dbi.demon.co.uk; Mon, 05 Jan 2004 13:55:21 +0000 +Received: from integer.pobox.com (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id 548DE2C87 + for ; Mon, 5 Jan 2004 08:55:20 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id 417692C81 + for ; Mon, 5 Jan 2004 08:55:20 -0500 (EST) +Received: from onion.perl.org (onion.develooper.com [63.251.223.166]) + by integer.pobox.com (Postfix) with SMTP + for ; Mon, 5 Jan 2004 08:55:19 -0500 (EST) +Received: (qmail 91728 invoked by uid 1005); 5 Jan 2004 13:55:17 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 48614 invoked by uid 76); 5 Jan 2004 12:24:01 -0000 +Delivered-To: dbi-users@perl.org +X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 +content-class: urn:content-classes:message +MIME-Version: 1.0 +Content-Type: text/plain; charset="iso-8859-1" +Subject: RE: Help - multiple Oracle versions +Date: Mon, 5 Jan 2004 07:23:23 -0500 +Message-ID: <6B003D25ADBDE347B5542AFE6A55B42E04537A09@tayexc13.americas.cpqcorp.net> +X-MS-Has-Attach: +X-MS-TNEF-Correlator: +Thread-Topic: Help - multiple Oracle versions +Thread-Index: AcPTac0nADA1C8LsTdSTxpcvyeSNCgAHQWGQ +From: "Anniballi, Fran" +To: +Cc: +X-OriginalArrivalTime: 05 Jan 2004 12:23:24.0525 (UTC) FILETIME=[B6F761D0:01C3D386] +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=0.3 required=7.0 tests=CARRIAGE_RETURNS,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by dansat.data-plan.com id i05Ejvo1064760 +Status: RO +Content-Length: 1465 +Lines: 52 + +Thanks. Looks like this is what I'll need. + +-----Original Message----- +From: kn@sifira.dk [mailto:kn@sifira.dk] +Sent: Monday, January 05, 2004 3:56 AM +To: Anniballi, Fran +Cc: dbi-users@perl.org +Subject: Re: Help - multiple Oracle versions + + +"Anniballi, Fran" writes: + +> For option two, if I have two versions of DBD:Oracle, how do I tell +> Perl which one to use? My scripts just say "/usr/bin/perl" in the +> first line. + +Basically, when you compile you use the PREFIX option: + + export ORACLE_HOME=/usr/local/oracle8 + perl Makefile.PL PREFIX=/usr/local/oracle8-perl + make + make install + + export ORACLE_HOME=/usr/local/oracle9 + perl Makefile.PL PREFIX=/usr/local/oracle9-perl + make + make install + +Then before running the perl script you should set the PERLLIB +environment variable to point to the correct location for the proper +version of DBD::Oracle. Alternatively, you could have the perl script +select the proper DBD::Oracle location based on the value of +ORACLE_HOME: + + #! /usr/bin/perl + BEGIN { + if($ENV{ORACLE_HOME} =~ /8/) { + use lib '/usr/local/oracle8-perl/REST/OF/PATH'; + } else { + use lib '/usr/local/oracle9-perl/REST/OF/PATH'; + } + } + use DBI; + +This is all from the top of my head; you will need to fiddle a bit to +get the details right (like the correct path etc). Also, I think this +has been covered in greater detail before; you might want to try +searching the archives. + + - Kristian. + + + +From dbi-users-return-21449-Tim.Bunce=pobox.com@perl.org Tue Jan 6 17:00:29 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i06GxrnC075337 + for ; Tue, 6 Jan 2004 17:00:29 GMT + (envelope-from dbi-users-return-21449-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 06 Jan 2004 17:00:29 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1Adu0c-0004RW-9d; + Tue, 06 Jan 2004 16:24:47 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by punt-3.mail.demon.net with esmtp id 1Adu0c-0004RW-9d + for pobox@dbi.demon.co.uk; Tue, 06 Jan 2004 16:24:47 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 21A79495C + for ; Tue, 6 Jan 2004 11:24:46 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 08B12494B + for ; Tue, 6 Jan 2004 11:24:46 -0500 (EST) +Received: from onion.perl.org (onion.develooper.com [63.251.223.166]) + by boggle.pobox.com (Postfix) with SMTP + for ; Tue, 6 Jan 2004 11:24:45 -0500 (EST) +Received: (qmail 25114 invoked by uid 1005); 6 Jan 2004 16:24:42 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 25095 invoked by uid 76); 6 Jan 2004 16:24:42 -0000 +Received: from qmailr@one.develooper.com (HELO ran-out.mx.develooper.com) (64.81.84.115) by onion.perl.org (qpsmtpd/0.26) with SMTP; Tue, 06 Jan 2004 08:24:42 -0800 +Received: (qmail 16535 invoked by uid 225); 6 Jan 2004 16:24:39 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 16527 invoked by uid 507); 6 Jan 2004 16:24:39 -0000 +Received: from mail.cybcon.com (HELO mail.cybcon.com) (216.190.188.5) by one.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Tue, 06 Jan 2004 08:24:08 -0800 +Received: from poirot (dsl2-6.cybcon.com [208.186.116.6]) by mail.cybcon.com (8.11.6/8.11.6) with ESMTP id i06GNhn08916; Tue, 6 Jan 2004 08:23:43 -0800 +Subject: RE: Help - multiple Oracle versions +From: Jared Still +To: "Anniballi, Fran" +Cc: DBI List +In-Reply-To: <6B003D25ADBDE347B5542AFE6A55B42E03227831@tayexc13.americas.cpqcorp.net> +References: <6B003D25ADBDE347B5542AFE6A55B42E03227831@tayexc13.americas.cpqcorp.net> +Content-Type: text/plain +Content-Transfer-Encoding: 7bit +X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) +Date: 06 Jan 2004 08:25:59 -0800 +Message-Id: <1073406359.324.244.camel@poirot.jks.com> +Mime-Version: 1.0 +X-CyberConnectics-MailScanner2-Information: Spam/Virus Scanned at CyberConnectics +X-CyberConnectics-MailScanner2: Found to be clean +X-CyberConnectics-MailScanner2-SpamCheck: +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=-0.2 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08,SUPERLONG_LINE version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Status: RO +Content-Length: 4050 +Lines: 102 + +I read quickly through this thread, so my apologies if someone +already pointed this out. + +It doesn't matter which version of Oracle you compiled DBD with, +you can connect to all your 8i/9i databases on any platform with it. + +Assume you compiled with 9i libs, and you can connect to 9i db's with +no problem, but are unable to connect to 8i, getting the error you +mentioned previously. + +It appears that you are changing your Oracle environment via the +oraenv shell script to change your ORACLE_HOME to the 8i version +of Oracle. + +If so, stop doing that. Just leave your environment at 9i, and +connect to your 8i database. It will be fine. This is the way +my linux server is setup, and DBD is used to connect to Oracle +versions 7.3, 8.1.6, 8.1.7 and 9.2.0 every day. + +At our site DBD is compiled with 8i libs so that we can still +connect to the version 7 databases. If you compile with 9i libs, +you will be unable to connect to version 7 databases. + +HTH + +Jared + + +On Sun, 2004-01-04 at 05:12, Anniballi, Fran wrote: +> This is all done on one UNIX box. +> +> If I try option one, it doesn't work. I can't access an oracle8 instance with oracle9 sqlplus (or the other way around). That is the real problem. Since I can't do this I have to reassign the pointers before I access it. I can do this fine with sqlplus but with dbi/dbd I have to compile with one or the other. +> +> For option two, if I have two versions of DBD:Oracle, how do I tell Perl which one to use? My scripts just say "/usr/bin/perl" in the first line. +> +> -----Original Message----- +> From: kn@sifira.dk [mailto:kn@sifira.dk] +> Sent: Saturday, January 03, 2004 1:04 PM +> To: dbi-users@perl.org +> Cc: Anniballi, Fran +> Subject: Re: Help - multiple Oracle versions +> +> +> "Anniballi, Fran" writes: +> +> > As soon as I recompile the same DBI/DBD with it pointing to Oracle 9 +> > environment (libraries), it doesn't work. It is looking for Oracle9 +> > library files and I obviously don't have it pointing to oracle9 +> > libraries when I access an Oracle 8 instance. Oracle 9 is not +> > compatible with Oracle 8 so I have to redirect the environment +> > variables at run time. +> +> It sounds like you are confusing the Oracle client version and the +> Oracle server version. +> +> Eg. if you set ORACLE_HOME to /usr/local/oracle8 (or whatever) and use +> /usr/local/oracle8/bin/sqlplus you are using the Oracle 8 client, while +> if you set it to /usr/local/oracle9 and call +> /usr/local/oracle9/bin/sqlplus, you are using the Oracle 9 client. +> +> Which Oracle instance you access is selected by the connection string; +> for example "sqlplus scott/tiger@DB8" might access the Oracle 8 +> instance, and "scott/tiger@DB9" might access the Oracle 9 instance. +> +> What people are telling you is that you can choose client version +> independently of the server version. For example, it is possible to set +> ORACLE_HOME to /usr/local/oracle9 and call +> +> /usr/local/oracle9/bin/sqlplus scott/tiger@DB8 +> +> to access the Oracle 8 instance with the Oracle 9 client. This of course +> requires that the definition for DB8 is present in the file +> /usr/local/oracle-9.2/network/admin/tnsnames.ora. +> +> So you should either +> +> 1. Use only the Oracle 9 client, not change ORACLE_HOME, and access both +> instances with Oracle 9 sqlplus and DBD::Oracle compiled against +> Oracle 9 libraries. +> +> or +> +> 2. Compile DBD::Oracle twice (once against Oracle 8 libraries, once +> against Oracle 9 libraries, just as you have two versions of sqlplus) +> and use each one with the proper ORACLE_HOME setting. +> +> My guess is that you will find possibility 1. the easiest. +> +> > The tnsnames.ora are all set. I did what you said already. +> > +> > Example: DBI/DBD will work fine if I compile the DBI/DBD pointing to +> > Oracle 8 environment(libraries) and access an Oracle 8 instance. I +> > didn't have to change tnsnames.ora +> +> Yes you do: You need to have BOTH Oracle instances defined in EACH +> tnsnames.ora. +> +> Hope this helps, +> +> - Kristian. + + + +From andy@andyh.co.uk Wed Jan 7 07:31:57 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i077VPn8081048 + for ; Wed, 7 Jan 2004 07:31:57 GMT + (envelope-from andy@andyh.co.uk) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 07 Jan 2004 07:31:57 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1Ae0Yb-0002lT-IA; + Tue, 06 Jan 2004 23:24:17 +0000 +Received: from [208.58.1.194] (helo=integer.pobox.com) + by punt-3.mail.demon.net with esmtp id 1Ae0Yb-0002lT-IA + for pobox@dbi.demon.co.uk; Tue, 06 Jan 2004 23:24:17 +0000 +Received: from integer.pobox.com (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id 00D7C3C15 + for ; Tue, 6 Jan 2004 18:24:16 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by integer.pobox.com (Postfix) with ESMTP id CB5813BEA + for ; Tue, 6 Jan 2004 18:24:16 -0500 (EST) +Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) + by integer.pobox.com (Postfix) with ESMTP + for ; Tue, 6 Jan 2004 18:24:16 -0500 (EST) +Received: from excession ([80.2.244.47]) by mta03-svc.ntlworld.com + (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP + id <20040106232403.NEKJ9852.mta03-svc.ntlworld.com@excession>; + Tue, 6 Jan 2004 23:24:03 +0000 +Message-ID: <00bd01c3d4ac$e5713190$6564a8c0@excession> +From: "Andy Hassall" +To: "Eric Lenio" , "Tim Bunce" +Cc: +References: <20040102143310.GC27273@lenio.net> <20040104204914.GB60357@dansat.data-plan.com> <20040105123653.GA31473@lenio.net> <20040105223121.GG66760@dansat.data-plan.com> <20040106222634.GG11531@lenio.net> <20040106223845.GE78360@dansat.data-plan.com> <20040106225722.GI11531@lenio.net> +Subject: Re: DBI primary_key tests fail: oracle 8 +Date: Tue, 6 Jan 2004 23:29:14 -0000 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 6.00.2800.1158 +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 +Status: RO +X-Status: A +Content-Length: 1692 +Lines: 43 + +Eric Lenio wrote: +> OK Tim. One other note -- after reading through oracle docs, I think +> you might want to substitute 'session_user' for 'current_schema' in +> 'select sys_context(...)'. The definition of session_user is +> "returns the database +> user name by which the current user is authenticated" while +> current_schema is "returns the name of the default schema being used +> in the current session". +> Maybe it doesn't matter, I'm not an oracle guru by any stretch of the +> imagination. + +There's several usernames in the USERENV context: + +CURRENT_SCHEMA + +The schema/user used for unqualified object name resolution; by default the +user you logged in as, but alterable with 'alter session set +current_schema=x'. Useful for avoiding having to maintain loads of synonyms. + +CURRENT_USER + +The user you're currently authenticated as. Doesn't change in SQL and +anonymous PL/SQL, but changes within definer-rights PL/SQL stored procedures +to the owner of the stored procedure, since stored procs by default run with +the privileges of the owner, not the invoker. + +SESSION_USER + +Who you originally logged in as, and never changes (but see below). Looks +like the appropriate one to use. + +PROXY_USER + +I don't think DBD::Oracle supports proxy authentication so don't need to +worry about that one yet. Possibly a bit of a grey area if it does support +it in the future, since this would hold the username in the DSN, but it'd +reauthenticate and change the SESSION_USER on connect (which would probably +have to be specified as an attribute to the $dbh). + +-- +Andy Hassall (andy@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk) +Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space) + + diff --git a/err_unsorted/err_ora9ir2oci.msg b/err_unsorted/err_ora9ir2oci.msg new file mode 100644 index 00000000..7ed476e4 --- /dev/null +++ b/err_unsorted/err_ora9ir2oci.msg @@ -0,0 +1,27 @@ +http://otn.oracle.com/tech/oci/htdocs/oci9ir2_new_features + +OCI Session Pooling +Session Pooling is a new feature in Oracle 9i Database Release 2. +An application can now maintain a pool of sessions and use a session +from the pool when it needs it. This saves the time consuming process +of initiating a connection and authentication every time the process +needs a new session. Session Pooling is useful, especially when a +large number of stateless sessions are required for a very short +time. In a web scenario, where many users are connected for a short +time, and the primary operation is accessing data, it is a costly +operation to start up a new session every time. In such a scenario, +session pooling could boost up the performance. + +OCI Statement caching +Client-side statement caching is also introduced in Oracle9i Database +Release 2. This feature can be enabled at the time of session +creation. It allows users to have a cache of statements per session. +On the server, this means having cursors that ready to be used, +without the need to parse the statements again, and thus improving +performance significantly. With this feature enabled, applications +do not have to keep a track of the statements themselves, as the +OCI layer will do it for them. In addition, a tagging feature is +provided, which users can use as a key to save and search for +statements. + + diff --git a/err_unsorted/err_ref_type.msg b/err_unsorted/err_ref_type.msg new file mode 100644 index 00000000..26d86e14 --- /dev/null +++ b/err_unsorted/err_ref_type.msg @@ -0,0 +1,115 @@ +From dbi-users-return-19574-Tim.Bunce=pobox.com@perl.org Wed Jul 23 18:40:02 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id h6NHUUA0010501 + for ; Wed, 23 Jul 2003 18:40:02 +0100 (BST) + (envelope-from dbi-users-return-19574-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 23 Jul 2003 18:40:02 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1058948095:10:09585:8; Wed, 23 Jul 2003 08:14:55 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1116163; 23 Jul 2003 8:14 GMT +Received: from dolly1.pobox.com (localhost [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 88C1B21C024 + for ; Wed, 23 Jul 2003 04:13:51 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [64.70.54.95]) + by dolly1.pobox.com (Postfix) with SMTP id AA89B21C082 + for ; Wed, 23 Jul 2003 04:13:50 -0400 (EDT) +Received: (qmail 26606 invoked by uid 1005); 23 Jul 2003 08:13:44 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 26590 invoked by uid 76); 23 Jul 2003 08:13:43 -0000 +Received: from qmailr@one.develooper.com (HELO ran-out.mx.develooper.com) (64.81.84.115) by onion.perl.org (qpsmtpd/0.26) with SMTP; Wed, 23 Jul 2003 01:13:43 -0700 +Received: (qmail 16360 invoked by uid 225); 23 Jul 2003 08:13:41 -0000 +Delivered-To: dbi-users@perl.org +Received: (qmail 16355 invoked by uid 507); 23 Jul 2003 08:13:41 -0000 +Received-SPF: unknown +Received: from [212.89.121.1] (HELO babel.morphochem.de) (212.89.121.1) by one.develooper.com (qpsmtpd/0.27-dev) with SMTP; Wed, 23 Jul 2003 01:13:41 -0700 +Received: (qmail 5378 invoked from network); 23 Jul 2003 08:54:08 -0000 +Received: from unknown (HELO mail.morphochem.de) (10.1.15.5) by 212.89.121.1 with SMTP; 23 Jul 2003 08:54:08 -0000 +Received: (qmail 8984 invoked from network); 23 Jul 2003 08:13:49 -0000 +Received: from localhost.morphochem.de (HELO mail) ([127.0.0.1]) (envelope-sender ) by localhost.morphochem.de (qmail-ldap-1.03) with SMTP for ; 23 Jul 2003 08:13:49 -0000 +Received: from mars.MORPHOCHEM.de ([10.1.8.130]) by mail.morphochem.de (MailMonitor for SMTP v1.2.1 ) ; Wed, 23 Jul 2003 10:13:49 +0200 (CEST) +Subject: Re: binding to parameters of type REF +From: Hendrik =?ISO-8859-1?Q?Fu=DF?= +To: dbi-users@perl.org +In-Reply-To: <1058865345.1241.56.camel@mars> +References: <1058865345.1241.56.camel@mars> +Content-Type: text/plain +Content-Transfer-Encoding: 7bit +X-Mailer: Ximian Evolution 1.0.8 +Date: 23 Jul 2003 10:11:49 +0200 +Message-Id: <1058947909.6353.5.camel@mars> +Mime-Version: 1.0 +X-SMTPD: qpsmtpd/0.27-dev, http://develooper.com/code/qpsmtpd/ +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=-0.3 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,LARGE_HEX,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Status: RO +Content-Length: 1354 +Lines: 56 + +I've also found out, that DBD::Oracle does not support type SQL_REF: +When not using DBD::Proxy I get: + + SQL type 20 for ':p1' is not fully supported, + bound as SQL_VARCHAR instead + +I even get segmentation faults when trying to fetch REF columns. :-( + +Any ideas? + +> Hi, +> +> I'm trying to bind a perl variable to an Oracle table reference with +> Oracle 9.2.0.3, DBD::Proxy and Perl::DBI 1.37 without success. I +> could'nt find help on this in the docs or list archives. I hope this is +> the right place to post. +> +> In SQL*Plus: +> +> SQL> desc getReference +> FUNCTION getReference RETURNS REF OF TABLETYPE +> +> SQL> select getReference() from dual; +> +> GETREFERENCE() +> ---------------------------------------------------------------------- +> 0000280209C229D2216EF6A5F4E030010A8D086AD3C204FC6EE0E46501E030010A8D08 +> 2CE703C0000E0000 +> +> +> My code: +> +> my $ref = undef; +> my $sth = $dbh->prepare('BEGIN ? := getReference(); END;'); +> $sth->bind_param_inout(1, \$ref, 128, SQL_REF ); +> $sth->execute(); +> +> yields: +> +> PLS-00382: expression is of wrong type +> +> +> Even fetching a reference does not work: +> +> my $sth = $dbh->prepare('SELECT getReference() FROM DUAL'); +> $sth->execute(); +> ($ref) = $sth->fetchrow_array(); +> +> yields undef in $ref. +> +> I'd very much appreciate your help. +> cheers, +> Hendrik + + + + diff --git a/err_unsorted/err_refcsr_rowcache.msg b/err_unsorted/err_refcsr_rowcache.msg new file mode 100644 index 00000000..5101d2ae --- /dev/null +++ b/err_unsorted/err_refcsr_rowcache.msg @@ -0,0 +1,85 @@ +From dbi-users-bounce@isc.org Tue May 16 22:53:12 2000 +Return-Path: +Received: from oink by toad.ig.co.uk (SMI-8.6/SMI-SVR4) + id WAA29547; Tue, 16 May 2000 22:53:11 +0100 +Received: from finch-punt-12.mail.demon.net by oink with SMTP (PP) + id <04730-2@oink>; Sat, 16 May 1970 22:51:48 +0100 +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@ig.co.uk + id 958512876:10:15786:0; Tue, 16 May 2000 21:34:36 GMT +Received: from pub3.rc.vix.com ([204.152.186.34]) by punt-1.mail.demon.net + id aa1122388; 16 May 2000 21:33 GMT +Received: from pub3.rc.vix.com (pub3.rc.vix.com [204.152.186.34]) + by pub3.rc.vix.com (Postfix) with ESMTP id 661E53EC8; + Tue, 16 May 2000 14:33:38 -0700 (PDT) +Received: with LISTAR (v0.129a; list dbi-users); + Tue, 16 May 2000 14:28:31 -0700 (PDT) +Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.87]) + by pub3.rc.vix.com (Postfix) with ESMTP id 7192F3E20 + for ; + Tue, 16 May 2000 14:28:27 -0700 (PDT) +Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) + by isrv3.isc.org (8.9.1/8.9.1) via ESMTP id OAA27204 + for ; + Tue, 16 May 2000 14:28:26 -0700 (PDT) env-from (Tim.Bunce@ig.co.uk) +Received: from ignite.demon.co.uk ([158.152.8.99] helo=oink) + by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) + id 12rot7-000Mp4-0Y; Tue, 16 May 2000 22:28:25 +0100 +Received: from toad by oink with SMTP (PP) id <04650-0@oink>; + Sat, 16 May 1970 22:23:55 +0100 +Received: by toad.ig.co.uk (SMI-8.6/SMI-SVR4) id WAA29289; + Tue, 16 May 2000 22:23:50 +0100 +Date: Tue, 16 May 2000 22:23:50 +0100 +From: Tim Bunce +To: peter_dev@talk21.com +Cc: dbi-users@isc.org +Subject: Re: Oracle Stored Procs take longer than embedded SQL +Message-ID: <20000516222350.F28435@ig.co.uk> +References: <20000516174946.QLKD22548.t21mta02-app.talk21.com@t21mtaV-lrs> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Mailer: Mutt 0.95.3i +In-Reply-To: <20000516174946.QLKD22548.t21mta02-app.talk21.com@t21mtaV-lrs>; from peter_dev@talk21.com on Tue, May 16, 2000 at 06:48:22PM +0100 +Organization: Paul Ingram Group, Software Systems, +44 1 483 862800 +Sender: dbi-users-bounce@isc.org +Errors-To: dbi-users-bounce@isc.org +X-original-sender: Tim.Bunce@ig.co.uk +Precedence: bulk +List-unsubscribe: +X-List-ID: +List-owner: +List-post: +Status: RO +Content-Length: 1372 +Lines: 30 + +On Tue, May 16, 2000 at 06:48:22PM +0100, peter_dev@talk21.com wrote: +> I have a problem with the fetching of data from an Oracle Ref Cursor taking longer than the same query in Embeded SQL. +> +> $ get_sp.pl +> Fetched in 0.00774896144866943 seconds +> Completed in 0.106827020645142 seconds +> +> $ get_sql.pl +> Fetched in 0.00138604640960693 seconds +> Completed in 0.380790948867798 seconds +> +> In this example (Using the SCOTT/TIGER tables), while the Stored Procedure completed first, the actual fetch of the data took considerably longer. In a real situation (e.g. bigger tables ), this is easily the longest part of the task and causes the overall execution time to increase hugely. +> +> Any Help would be appreciated +> thanks + +Possibly related to the lack of a row cache on that statement handle. +You, or some kind volunteer, could probably hack that in without too +much work. + +Tim. + + +------------------------------------------------------------------------------ +DBI HOME PAGE AND ARCHIVES: http://www.symbolstone.org/technology/perl/DBI/ +To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html +If you are without web access, or if you are having trouble with the web page, +please send mail to dbi-users-request@isc.org with the subject line of: +'unsubscribe'. +------------------------------------------------------------------------------ + diff --git a/err_unsorted/err_refcsr_slow.msg b/err_unsorted/err_refcsr_slow.msg new file mode 100644 index 00000000..790d267d --- /dev/null +++ b/err_unsorted/err_refcsr_slow.msg @@ -0,0 +1,347 @@ +From dbi-users-return-11175-Tim.Bunce=pobox.com@perl.org Mon Apr 29 23:12:51 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3TMCpR17212 + for ; Mon, 29 Apr 2002 23:12:51 +0100 (BST) + (envelope-from dbi-users-return-11175-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.22] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Mon, 29 Apr 2002 23:12:51 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020117986:10:17770:92; Mon, 29 Apr 2002 22:06:26 GMT +Received: from wormwood.pobox.com ([208.210.125.20]) by punt-1.mail.demon.net + id aa1017591; 29 Apr 2002 22:06 GMT +Received: from wormwood.pobox.com (localhost.pobox.com [127.0.0.1]) + by wormwood.pobox.com (Postfix) with ESMTP id 975037274A + for ; Mon, 29 Apr 2002 18:01:37 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [209.85.157.220]) + by wormwood.pobox.com (Postfix) with SMTP id ED2897273F + for ; Mon, 29 Apr 2002 18:01:34 -0400 (EDT) +Received: (qmail 70462 invoked by uid 1005); 29 Apr 2002 21:59:33 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 20335 invoked by uid 76); 29 Apr 2002 20:18:55 -0000 +Message-ID: <20020429201853.52283.qmail@web10007.mail.yahoo.com> +Date: Mon, 29 Apr 2002 13:18:53 -0700 (PDT) +From: Calin Medianu +Reply-To: cmedianu@sfu.ca +Subject: DBD::Oracle Slow cursors +To: dbi-users@perl.org +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Status: RO +X-Status: A +Content-Length: 568 +Lines: 21 + +Hello, + +I did the following. Wrote a perl script that retreves +data via a straight select from the database. Then I +wrote a stored procedure returning a ref cursor open +on the same select statement and retrieved the data as +well. Using the REF CURSOR/ sotred procedure was about +3 time slower, that is 40 seconds instead of around +10. + +Is this normal? Is this a problem with oracle or with +DBD::Oracle? + +Thanks, + +Calin Medianu + +__________________________________________________ +Do You Yahoo!? +Yahoo! Health - your guide to health and wellness +http://health.yahoo.com + +From dbi-users-return-11177-Tim.Bunce=pobox.com@perl.org Tue Apr 30 00:06:36 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3TN6aR17980 + for ; Tue, 30 Apr 2002 00:06:36 +0100 (BST) + (envelope-from dbi-users-return-11177-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 30 Apr 2002 00:06:36 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020119533:20:05733:4; Mon, 29 Apr 2002 22:32:13 GMT +Received: from cali-1.pobox.com ([64.71.166.114]) by punt-2.mail.demon.net + id aa2005393; 29 Apr 2002 22:32 GMT +Received: from cali-1.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-1.pobox.com (Postfix) with ESMTP id 4E6B73E6BF + for ; Mon, 29 Apr 2002 18:32:00 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [209.85.157.220]) + by cali-1.pobox.com (Postfix) with SMTP id BF79C3E6A0 + for ; Mon, 29 Apr 2002 18:31:59 -0400 (EDT) +Received: (qmail 87860 invoked by uid 1005); 29 Apr 2002 22:31:59 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Received: (qmail 87844 invoked by uid 76); 29 Apr 2002 22:31:58 -0000 +Received: from mail01.svc.cra.dublin.eircom.net (HELO mail01.svc.cra.dublin.eircom.net) (159.134.118.17) + by onion.perl.org (qpsmtpd/0.07) with SMTP; Mon Apr 29 22:31:58 2002 -0000 +Received: (qmail 21911 messnum 119827 invoked from network[159.134.167.97/p865.as1.limerick1.eircom.net]); 29 Apr 2002 22:31:29 -0000 +Received: from p865.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.167.97) + by mail01.svc.cra.dublin.eircom.net (qp 21911) with SMTP; 29 Apr 2002 22:31:29 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g3TMVcR17579; + Mon, 29 Apr 2002 23:31:38 +0100 (BST) + (envelope-from timbo) +Date: Mon, 29 Apr 2002 23:31:38 +0100 +From: Tim Bunce +To: cmedianu@sfu.ca +Cc: dbi-users@perl.org +Subject: Re: DBD::Oracle Slow cursors +Message-ID: <20020429233138.E16831@dansat.data-plan.com> +References: <20020429201853.52283.qmail@web10007.mail.yahoo.com> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5i +In-Reply-To: <20020429201853.52283.qmail@web10007.mail.yahoo.com>; from calinm@yahoo.com on Mon, Apr 29, 2002 at 01:18:53PM -0700 +Content-Length: 651 +Lines: 20 + +On Mon, Apr 29, 2002 at 01:18:53PM -0700, Calin Medianu wrote: +> Hello, +> +> I did the following. Wrote a perl script that retreves +> data via a straight select from the database. Then I +> wrote a stored procedure returning a ref cursor open +> on the same select statement and retrieved the data as +> well. Using the REF CURSOR/ sotred procedure was about +> 3 time slower, that is 40 seconds instead of around +> 10. +> +> Is this normal? Is this a problem with oracle or with +> DBD::Oracle? + +DBD::Oracle. It probably isn't setting up a row cache for the ref cursor. + +Get a level 3 trace and look for the "dbd_describe'd" line for the +ref cursor. + +Tim. + +From calinm@yahoo.com Tue Apr 30 22:02:56 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3UL2tR26878 + for ; Tue, 30 Apr 2002 22:02:55 +0100 (BST) + (envelope-from calinm@yahoo.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 30 Apr 2002 22:02:55 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020198219:10:21718:114; Tue, 30 Apr 2002 20:23:39 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1101732; 30 Apr 2002 20:23 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id C6B4A2BFB4 + for ; Tue, 30 Apr 2002 16:23:25 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) + by dolly1.pobox.com (Postfix) with SMTP id 527BD2BF3D + for ; Tue, 30 Apr 2002 16:23:25 -0400 (EDT) +Message-ID: <20020430202321.54825.qmail@web10004.mail.yahoo.com> +Received: from [213.157.171.169] by web10004.mail.yahoo.com via HTTP; Tue, 30 Apr 2002 13:23:20 PDT +Date: Tue, 30 Apr 2002 13:23:20 -0700 (PDT) +From: Calin Medianu +Subject: Re: DBD::Oracle Slow cursors +To: Tim Bunce +Cc: dbi-users@perl.org +In-Reply-To: <20020430140517.P16831@dansat.data-plan.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Status: RO +X-Status: A +Content-Length: 425 +Lines: 18 + +I "Solved" the problem. For Now.. I did +perl Makefile.PL -8 + +hoping that the buggy code would be recently added, +and it was. Now both the select and the cursor return +the data at the same speed, meaning fast.. + +Am I am missing much by not using the code for Oracle +8? + +Thanks, + +Calin + +__________________________________________________ +Do You Yahoo!? +Yahoo! Health - your guide to health and wellness +http://health.yahoo.com + +From timbo@dansat.data-plan.com Wed May 1 16:49:55 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g41FnsR33994 + for ; Wed, 1 May 2002 16:49:54 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.22] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 01 May 2002 16:49:54 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020265865:20:10671:66; Wed, 01 May 2002 15:11:05 GMT +Received: from silk.pobox.com ([208.210.125.70]) by punt-2.mail.demon.net + id aa2122069; 1 May 2002 15:10 GMT +Received: from cali-3.pobox.com (cali-3.pobox.com [64.71.166.116]) + by silk.pobox.com (Postfix) with ESMTP id F29CC3FDF2 + for ; Wed, 1 May 2002 11:09:52 -0400 (EDT) +Received: from cali-3.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-3.pobox.com (Postfix) with ESMTP id E3A943E689 + for ; Wed, 1 May 2002 10:57:15 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) + by cali-3.pobox.com (Postfix) with SMTP id D1F523E688 + for ; Wed, 1 May 2002 10:57:14 -0400 (EDT) +Received: (qmail 96042 messnum 564683 invoked from network[159.134.166.63/p575.as1.limerick1.eircom.net]); 1 May 2002 14:57:13 -0000 +Received: from p575.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.166.63) + by mail03.svc.cra.dublin.eircom.net (qp 96042) with SMTP; 1 May 2002 14:57:13 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g41EvIh33626; + Wed, 1 May 2002 15:57:18 +0100 (BST) + (envelope-from timbo) +Date: Wed, 1 May 2002 15:57:18 +0100 +From: Tim Bunce +To: Calin Medianu +Cc: Tim Bunce +Subject: Re: DBD::Oracle Slow cursors +Message-ID: <20020501155718.S16831@dansat.data-plan.com> +References: <20020430151126.Q16831@dansat.data-plan.com> <20020430183429.33340.qmail@web10005.mail.yahoo.com> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5i +In-Reply-To: <20020430183429.33340.qmail@web10005.mail.yahoo.com>; from calinm@yahoo.com on Tue, Apr 30, 2002 at 11:34:29AM -0700 +Status: RO +Content-Length: 3111 +Lines: 111 + +Thanks. I'll take a look when I get to DBD::Oracle again. + +I think the last row of that table applies and it doesn't refer to OCIBindObject(): + REF CURSOR variables + SQLT_RSET + Allocate a statement handle, OCIStmt, and then bind its address + (OCIStmt **) using the SQLT_RSET datatype. +Note that SQLT_REF isn't the same as SQLT_RSET. + +You could always try patching it yourself! + +Tim. + + +On Tue, Apr 30, 2002 at 11:34:29AM -0700, Calin Medianu wrote: +> It says here: +> http://technet.oracle.com/doc/oracle8i_816/appdev.816/a76975/oci05bnd.htm#421007 +> +> that 2 calls are neede to bind a ref , the second is +> to OCIBindObject() which I don't see in dbdimp.c. +> +> Could this be a reason? +> +> Cheers, +> +> Calin +> +> --- Tim Bunce wrote: +> > On Tue, Apr 30, 2002 at 04:04:47PM +0300, Calin +> > Medianu wrote: +> > > Me again with the slow cursors. +> > > +> > > I modified both queries to only return 10 rows. +> > > I ran a sniffer (ethereal) on the NIC. It is +> > pretty cool, it also decodes TNS. +> > > +> > > when I am using the SQL, it works like this, there +> > are about 7 packets +> > > received by my workstation to set up the session, +> > then all 10 rows are in the +> > > same packet, then there is another packet probably +> > saying goodbye. +> > > +> > > When I am using the REF cursor, each row comes in +> > it's own TNS packet, that +> > > is why it is so slow! +> > > +> > > Any idea how to fix it? +> > +> > Do a level 9 trace to get a log of the OCI calls and +> > confirm that +> > the fragment I posted is being called (may be +> > helpful to also +> > add an extra print statement into that code since +> > parsing the +> > OCI trace can be painful). +> > +> > Assuming the code is being called then as far as I +> > can see the code is +> > doing the right thing and it's probably an Oracle +> > OCI issue. +> > +> > You'd need to talk to Oracle support. No need to +> > mention perl etc. +> > Just talk about your OCI application and provide the +> > OCI call trace. +> > +> > Let me know what you find out! +> > +> > Tim. +> > +> > > thanks a lot, +> > > +> > > Calin +> > > +> > > > On Mon, Apr 29, 2002 at 01:18:53PM -0700, Calin +> > Medianu wrote: +> > > > > Hello, +> > > > > +> > > > > I did the following. Wrote a perl script that +> > retreves +> > > > > data via a straight select from the database. +> > Then I +> > > > > wrote a stored procedure returning a ref +> > cursor open +> > > > > on the same select statement and retrieved the +> > data as +> > > > > well. Using the REF CURSOR/ sotred procedure +> > was about +> > > > > 3 time slower, that is 40 seconds instead of +> > around +> > > > > 10. +> > > > > +> > > > > Is this normal? Is this a problem with oracle +> > or with +> > > > > DBD::Oracle? +> > > > +> > > > DBD::Oracle. It probably isn't setting up a row +> > cache for the ref cursor. +> > > > +> > > > Get a level 3 trace and look for the +> > "dbd_describe'd" line for the +> > > > ref cursor. +> > > > +> > > > Tim. +> +> +> __________________________________________________ +> Do You Yahoo!? +> Yahoo! Health - your guide to health and wellness +> http://health.yahoo.com + diff --git a/err_unsorted/err_slowcsr.msg b/err_unsorted/err_slowcsr.msg new file mode 100644 index 00000000..80c43350 --- /dev/null +++ b/err_unsorted/err_slowcsr.msg @@ -0,0 +1,316 @@ +From calinm@yahoo.com Tue Apr 30 22:03:11 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3UL3AR27018 + for ; Tue, 30 Apr 2002 22:03:10 +0100 (BST) + (envelope-from calinm@yahoo.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Tue, 30 Apr 2002 22:03:10 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020196981:10:23493:39; Tue, 30 Apr 2002 20:03:01 GMT +Received: from silk.pobox.com ([208.210.125.70]) by punt-1.mail.demon.net + id aa1108477; 30 Apr 2002 20:02 GMT +Received: from dolly1.pobox.com (dolly1.pobox.com [207.106.49.22]) + by silk.pobox.com (Postfix) with ESMTP id 915563FCE8 + for ; Tue, 30 Apr 2002 14:35:38 -0400 (EDT) +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 343702BFDD + for ; Tue, 30 Apr 2002 14:34:38 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from web10005.mail.yahoo.com (web10005.mail.yahoo.com [216.136.130.41]) + by dolly1.pobox.com (Postfix) with SMTP id 6AA822BFA3 + for ; Tue, 30 Apr 2002 14:34:37 -0400 (EDT) +Message-ID: <20020430183429.33340.qmail@web10005.mail.yahoo.com> +Received: from [213.157.171.169] by web10005.mail.yahoo.com via HTTP; Tue, 30 Apr 2002 11:34:29 PDT +Date: Tue, 30 Apr 2002 11:34:29 -0700 (PDT) +From: Calin Medianu +Subject: Re: DBD::Oracle Slow cursors +To: Tim Bunce +In-Reply-To: <20020430151126.Q16831@dansat.data-plan.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Status: RO +X-Status: A +Content-Length: 2457 +Lines: 96 + +It says here: +http://technet.oracle.com/doc/oracle8i_816/appdev.816/a76975/oci05bnd.htm#421007 + +that 2 calls are neede to bind a ref , the second is +to OCIBindObject() which I don't see in dbdimp.c. + +Could this be a reason? + +Cheers, + +Calin + +--- Tim Bunce wrote: +> On Tue, Apr 30, 2002 at 04:04:47PM +0300, Calin +> Medianu wrote: +> > Me again with the slow cursors. +> > +> > I modified both queries to only return 10 rows. +> > I ran a sniffer (ethereal) on the NIC. It is +> pretty cool, it also decodes TNS. +> > +> > when I am using the SQL, it works like this, there +> are about 7 packets +> > received by my workstation to set up the session, +> then all 10 rows are in the +> > same packet, then there is another packet probably +> saying goodbye. +> > +> > When I am using the REF cursor, each row comes in +> it's own TNS packet, that +> > is why it is so slow! +> > +> > Any idea how to fix it? +> +> Do a level 9 trace to get a log of the OCI calls and +> confirm that +> the fragment I posted is being called (may be +> helpful to also +> add an extra print statement into that code since +> parsing the +> OCI trace can be painful). +> +> Assuming the code is being called then as far as I +> can see the code is +> doing the right thing and it's probably an Oracle +> OCI issue. +> +> You'd need to talk to Oracle support. No need to +> mention perl etc. +> Just talk about your OCI application and provide the +> OCI call trace. +> +> Let me know what you find out! +> +> Tim. +> +> > thanks a lot, +> > +> > Calin +> > +> > > On Mon, Apr 29, 2002 at 01:18:53PM -0700, Calin +> Medianu wrote: +> > > > Hello, +> > > > +> > > > I did the following. Wrote a perl script that +> retreves +> > > > data via a straight select from the database. +> Then I +> > > > wrote a stored procedure returning a ref +> cursor open +> > > > on the same select statement and retrieved the +> data as +> > > > well. Using the REF CURSOR/ sotred procedure +> was about +> > > > 3 time slower, that is 40 seconds instead of +> around +> > > > 10. +> > > > +> > > > Is this normal? Is this a problem with oracle +> or with +> > > > DBD::Oracle? +> > > +> > > DBD::Oracle. It probably isn't setting up a row +> cache for the ref cursor. +> > > +> > > Get a level 3 trace and look for the +> "dbd_describe'd" line for the +> > > ref cursor. +> > > +> > > Tim. + + +__________________________________________________ +Do You Yahoo!? +Yahoo! Health - your guide to health and wellness +http://health.yahoo.com + +From calinm@yahoo.com Fri May 3 13:48:06 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g43Cm5R50489 + for ; Fri, 3 May 2002 13:48:05 +0100 (BST) + (envelope-from calinm@yahoo.com) +Received: from pop3.mail.demon.net [194.217.242.59] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 03 May 2002 13:48:05 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020429421:10:02019:143; Fri, 03 May 2002 12:37:01 GMT +Received: from wormwood.pobox.com ([208.210.125.20]) by punt-1.mail.demon.net + id aa1123562; 3 May 2002 12:36 GMT +Received: from wormwood.pobox.com (localhost.pobox.com [127.0.0.1]) + by wormwood.pobox.com (Postfix) with ESMTP id D7BD1725A1 + for ; Fri, 3 May 2002 08:36:41 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from web10008.mail.yahoo.com (web10008.mail.yahoo.com [216.136.130.44]) + by wormwood.pobox.com (Postfix) with SMTP id 3088772674 + for ; Fri, 3 May 2002 08:36:41 -0400 (EDT) +Message-ID: <20020503123640.19648.qmail@web10008.mail.yahoo.com> +Received: from [213.157.171.169] by web10008.mail.yahoo.com via HTTP; Fri, 03 May 2002 05:36:40 PDT +Date: Fri, 3 May 2002 05:36:40 -0700 (PDT) +From: Calin Medianu +Subject: Re: DBD::Oracle Slow cursors +To: Tim Bunce +In-Reply-To: <20020501155718.S16831@dansat.data-plan.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Status: RO +Content-Length: 3619 +Lines: 150 + +Sure, + +I'll give it a try next week. + +Cheers, + +Calin +--- Tim Bunce wrote: +> Thanks. I'll take a look when I get to DBD::Oracle +> again. +> +> I think the last row of that table applies and it +> doesn't refer to OCIBindObject(): +> REF CURSOR variables +> SQLT_RSET +> Allocate a statement handle, OCIStmt, and then +> bind its address +> (OCIStmt **) using the SQLT_RSET datatype. +> Note that SQLT_REF isn't the same as SQLT_RSET. +> +> You could always try patching it yourself! +> +> Tim. +> +> +> On Tue, Apr 30, 2002 at 11:34:29AM -0700, Calin +> Medianu wrote: +> > It says here: +> > +> +http://technet.oracle.com/doc/oracle8i_816/appdev.816/a76975/oci05bnd.htm#421007 +> > +> > that 2 calls are neede to bind a ref , the second +> is +> > to OCIBindObject() which I don't see in dbdimp.c. +> > +> > Could this be a reason? +> > +> > Cheers, +> > +> > Calin +> > +> > --- Tim Bunce wrote: +> > > On Tue, Apr 30, 2002 at 04:04:47PM +0300, Calin +> > > Medianu wrote: +> > > > Me again with the slow cursors. +> > > > +> > > > I modified both queries to only return 10 +> rows. +> > > > I ran a sniffer (ethereal) on the NIC. It is +> > > pretty cool, it also decodes TNS. +> > > > +> > > > when I am using the SQL, it works like this, +> there +> > > are about 7 packets +> > > > received by my workstation to set up the +> session, +> > > then all 10 rows are in the +> > > > same packet, then there is another packet +> probably +> > > saying goodbye. +> > > > +> > > > When I am using the REF cursor, each row comes +> in +> > > it's own TNS packet, that +> > > > is why it is so slow! +> > > > +> > > > Any idea how to fix it? +> > > +> > > Do a level 9 trace to get a log of the OCI calls +> and +> > > confirm that +> > > the fragment I posted is being called (may be +> > > helpful to also +> > > add an extra print statement into that code +> since +> > > parsing the +> > > OCI trace can be painful). +> > > +> > > Assuming the code is being called then as far as +> I +> > > can see the code is +> > > doing the right thing and it's probably an +> Oracle +> > > OCI issue. +> > > +> > > You'd need to talk to Oracle support. No need to +> > > mention perl etc. +> > > Just talk about your OCI application and provide +> the +> > > OCI call trace. +> > > +> > > Let me know what you find out! +> > > +> > > Tim. +> > > +> > > > thanks a lot, +> > > > +> > > > Calin +> > > > +> > > > > On Mon, Apr 29, 2002 at 01:18:53PM -0700, +> Calin +> > > Medianu wrote: +> > > > > > Hello, +> > > > > > +> > > > > > I did the following. Wrote a perl script +> that +> > > retreves +> > > > > > data via a straight select from the +> database. +> > > Then I +> > > > > > wrote a stored procedure returning a ref +> > > cursor open +> > > > > > on the same select statement and retrieved +> the +> > > data as +> > > > > > well. Using the REF CURSOR/ sotred +> procedure +> > > was about +> > > > > > 3 time slower, that is 40 seconds instead +> of +> > > around +> > > > > > 10. +> > > > > > +> > > > > > Is this normal? Is this a problem with +> oracle +> > > or with +> > > > > > DBD::Oracle? +> > > > > +> > > > > DBD::Oracle. It probably isn't setting up a +> row +> > > cache for the ref cursor. +> > > > > +> > > > > Get a level 3 trace and look for the +> > > "dbd_describe'd" line for the +> > > > > ref cursor. +> > > > > +> > > > > Tim. +> > +> > +> > __________________________________________________ +> > Do You Yahoo!? +> > Yahoo! Health - your guide to health and wellness +> > http://health.yahoo.com + + +__________________________________________________ +Do You Yahoo!? +Yahoo! Health - your guide to health and wellness +http://health.yahoo.com + diff --git a/err_unsorted/err_svrparse.msg b/err_unsorted/err_svrparse.msg new file mode 100644 index 00000000..16886ca8 --- /dev/null +++ b/err_unsorted/err_svrparse.msg @@ -0,0 +1,4717 @@ +From cary.millsap@hotsos.com Thu Sep 12 23:38:20 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8CMbgC02618 + for ; Thu, 12 Sep 2002 23:38:03 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.22] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 12 Sep 2002 23:38:03 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031869308:20:16258:30; Thu, 12 Sep 2002 22:21:48 GMT +Received: from cali-3.pobox.com ([64.71.166.116]) by punt-2.mail.demon.net + id aa2108888; 12 Sep 2002 22:21 GMT +Received: from cali-3.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-3.pobox.com (Postfix) with ESMTP id A32132F05C9 + for ; Thu, 12 Sep 2002 18:21:34 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by cali-3.pobox.com (Postfix) with ESMTP id D71F62F056D + for ; Thu, 12 Sep 2002 18:21:31 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8CMLQn17849; + Thu, 12 Sep 2002 17:21:26 -0500 +From: "Cary Millsap" +To: +Subject: +Date: Thu, 12 Sep 2002 17:21:17 -0500 +Message-ID: <016901c25aaa$ba287930$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_NextPart_000_016A_01C25A80.D1527130" +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 64884 +Lines: 2025 + +This is a multi-part message in MIME format. + +------=_NextPart_000_016A_01C25A80.D1527130 +Content-Type: multipart/alternative; + boundary="----=_NextPart_001_016B_01C25A80.D1557E70" + + +------=_NextPart_001_016B_01C25A80.D1557E70 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit + +Tim, + + + +How are you doing? I hope you've had a good two years since I saw you on +the Oracle Geek Cruise event. + + + +I've been working on a project this year to construct a book about +optimizing Oracle response time. In my research, I've discovered +something about the DBI that I didn't expect: it executes two Oracle +parse calls for every one that I would expect an efficient DBI layer to +make. I've included my Perl source (below), the Oracle level-12 trace +data that shows the sequence of calls it's receiving from the Perl +application (below), a level-9 DBI trace from the application +(attached), and our version information (below). + + + +The reason I'm bringing this to your attention in this way is that I'm +relying pretty heavily upon Perl for performance measurement tools, +examples, and simulators in the text. I love the language and I want for +the book to be an encouragement for more people to use Perl. However, +this extra-parse behavior is one of the things that the book highlights +as an important scalability barrier (some other tools do it too, +unfortunately). Of course, this is a speed bump on the road to my goal +of helping to promote Perl. + + + +I was hoping that by showing you this specific data, you could make the +problem go away. + + + +Cary Millsap +Hotsos Enterprises, Ltd. +http://www.hotsos.com + +Upcoming events: +- Hotsos Clinic , Oct 1-3 San +Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu +- 2003 Hotsos Symposium on +OracleR System Performance, Feb 9-12 Dallas +- Next event: Miracle Database Forum , Sep +20-22 Middlefart Denmark + +Listing [listing.sqltrace.pl]: a simple application that executes a +database query + +#!/usr/bin/perl + + + + + +# $Header: /home/cvs/cvm-book1/sqltrace/ex1.pl,v 1.2 2002/09/12 21:10:25 +cvm Exp $ + +# Cary Millsap (cary.millsap@hotsos.com) + + + + + +use strict; + +use warnings; + +use DBI; + +use DBD::Oracle; + +use Getopt::Long; + +use Term::ReadKey; + + + + + +my $sth; # Oracle statement handle + +my $hostname = ""; + +my $username = "/"; + +my $password = ""; + +my $logfile = "ex1.log"; + +my %attr = ( + + RaiseError => 1, + + AutoCommit => 0, + +); + +my %opt = ( + + pause => 0, + +); + + + + + +# Get command line options and arguments. + +GetOptions( + + "pause" => \$opt{pause}, + +); + +my $key = 37; # default query value + +$key = $ARGV[0] if $ARGV[0]; + + + + + +# Connect to Oracle. + +my $dbh = DBI->connect("dbi:Oracle:$hostname", $username, $password, +\%attr); + +$dbh->trace(9, $logfile); + + + + + +# Activate tracing. + +$sth = $dbh->prepare(q(alter session set events '10046 trace name +context forever, level 12')); + +$sth->execute; + + + + + +# Allow the user to find the Oracle session and activate OS diagnostic + +# tools like strace(1) or lsof(8). + +if ($opt{pause}) { + + print "Press any key to continue..."; + + 1 while not defined (my $k = ReadKey(-1)); + + print "\n"; + +} + + + + + +# Execute the query to trace. + +$sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); + +$sth->execute($key); + + + + + +# Print output header. + +my @cdefs = qw(%8d %8d %32s); # column definitions + +my @hdefs = qw(Key Fkey Value); # column headings + +my $bformat = join(" ", @cdefs) . "\n"; + +my $hformat; ($hformat = $bformat) =~ s/%(\d*)\S+/%$1s/g; + +printf $hformat, @hdefs; + +printf $hformat, do { my @h; push @h, "-" x (/(\d+)/?$1:10) for @cdefs; +@h }; + + + + + +# Print query results. + +for my $row (@{$sth->fetchall_arrayref}) { + + printf $bformat, @$row; + +} + + + + + +# Allow the user to do final OS diagnostic stuff. + +if ($opt{pause}) { + + print "Press any key to continue..."; + + 1 while not defined (my $k = ReadKey(-1)); + + print "\n"; + +} + + + + + +# Disconnect from Oracle. + +$dbh->disconnect; + + + + + +Listing [listing:sqltrace.trc]: raw SQL trace output for an execution of +our program + +/usr/local/oracle/admin/V816/udump/ora_17349.trc + +Oracle8i Enterprise Edition Release 8.1.6.1.0 - Production + +With the Partitioning option + +JServer Release 8.1.6.0.0 - Production + +ORACLE_HOME = /usr/local/oracle/product/8.1.6 + +System name: Linux + +Node name: www.hotsos.com + +Release: 2.2.16-22enterprise + +Version: #1 SMP Tue Aug 22 16:29:32 EDT 2000 + +Machine: i686 + +Instance name: V816 + +Redo thread mounted by this instance: 1 + +Oracle process number: 8 + +Unix process pid: 17349, image: oracle@www.hotsos.com (TNS V1-V3) + + + +*** SESSION ID:(7.9) 2002-09-12 16:14:01.582 + +===================== + +PARSING IN CURSOR #1 len=69 dep=0 uid=12 oct=42 lid=12 tim=107309054 +hv=1509700594 ad='54af5e14' + +alter session set events '10046 trace name context forever, level 12' + +END OF STMT + +EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107309054 + +WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1 p3=0 + +*** 2002-09-12 16:14:31.226 + +WAIT #1: nam='SQL*Net message from client' ela= 2964 p1=1650815232 p2=1 +p3=0 + +===================== + +PARSING IN CURSOR #2 len=44 dep=0 uid=12 oct=3 lid=12 tim=107312018 +hv=1997601641 ad='54af1384' + +select key, fkey, value from t where key=:p1 + +END OF STMT + +PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312018 + +WAIT #2: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1 p3=0 + +WAIT #2: nam='SQL*Net message from client' ela= 0 p1=1650815232 p2=1 +p3=0 + +===================== + +PARSING IN CURSOR #1 len=44 dep=0 uid=12 oct=3 lid=12 tim=107312019 +hv=1997601641 ad='54af1384' + +select key, fkey, value from t where key=:p1 + +END OF STMT + +PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312019 + +BINDS #1: + + bind 0: dty=1 mxl=32(04) mal=00 scl=00 pre=00 oacflg=25 oacfl2=10 +size=32 offset=0 + + bfp=0940e7f0 bln=32 avl=04 flg=05 + + value="8542" + +EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312019 + +WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1650815232 p2=1 p3=0 + +WAIT #1: nam='file open' ela= 0 p1=0 p2=0 p3=0 + +WAIT #1: nam='db file sequential read' ela= 0 p1=1 p2=6671 p3=1 + +WAIT #1: nam='db file sequential read' ela= 0 p1=1 p2=6678 p3=1 + +FETCH #1:c=0,e=0,p=2,cr=3,cu=0,mis=0,r=1,dep=0,og=3,tim=107312019 + +*** 2002-09-12 16:14:56.200 + +WAIT #1: nam='SQL*Net message from client' ela= 2496 p1=1650815232 p2=1 +p3=0 + +XCTEND rlbk=0, rd_only=1 + +STAT #1 id=1 cnt=1 pid=0 pos=0 obj=5156 op='TABLE ACCESS BY INDEX ROWID +T ' + +STAT #1 id=2 cnt=2 pid=1 pos=1 obj=5157 op='INDEX UNIQUE SCAN ' + + + + + +$ perl -V + +Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: + + Platform: + + osname=linux, osvers=2.2.5-22smp, archname=i386-linux + + uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 +09:11:51 edt 1999 i686 unknown ' + + config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc +-Dcccdlflags=-fPIC -Dinstallprefix=/usr -Dprefix=/usr +-Darchname=i386-linux -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm +-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Uuselargefiles' + + hint=recommended, useposix=true, d_sigaction=define + + usethreads=undef use5005threads=undef useithreads=undef +usemultiplicity=undef + + useperlio=undef d_sfio=undef uselargefiles=undef + + use64bitint=undef use64bitall=undef uselongdouble=undef +usesocks=undef + + Compiler: + + cc='gcc', optimize='-O2 -march=i386 -mcpu=i686', gccversion=2.96 +20000731 (experimental) + + cppflags='-fno-strict-aliasing' + + ccflags ='-fno-strict-aliasing' + + stdchar='char', d_stdstdio=define, usevfork=false + + intsize=4, longsize=4, ptrsize=4, doublesize=8 + + d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 + + ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', +lseeksize=4 + + alignbytes=4, usemymalloc=n, prototype=define + + Linker and Libraries: + + ld='gcc', ldflags =' -L/usr/local/lib' + + libpth=/usr/local/lib /lib /usr/lib + + libs=-lnsl -ldl -lm -lc -lcrypt + + libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a + + Dynamic Linking: + + dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' + + cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' + + + + + +Characteristics of this binary (from libperl): + + Compile-time options: + + Built under linux + + Compiled at Aug 7 2000 10:59:51 + + @INC: + + /usr/lib/perl5/5.6.0/i386-linux + + /usr/lib/perl5/5.6.0 + + /usr/lib/perl5/site_perl/5.6.0/i386-linux + + /usr/lib/perl5/site_perl/5.6.0 + + /usr/lib/perl5/site_perl + + . + + + + + +Other site information + +- Redhat Linux 7.0 + +- Oracle 8.1.6.1.0 + +- DBD-Oracle 1.12 + +- DBI 1.30 + + + + +------=_NextPart_001_016B_01C25A80.D1557E70 +Content-Type: text/html; + charset="us-ascii" +Content-Transfer-Encoding: quoted-printable + + + + + + + + + + + + + + + +
+ +

Tim,

+ +

 

+ +

How are you doing? I hope you’ve had a good two = +years +since I saw you on the Oracle Geek Cruise event.

+ +

 

+ +

I’ve been working on a project this year to = +construct +a book about optimizing Oracle response time. In my research, I’ve +discovered something about the DBI that I didn’t expect: it = +executes two +Oracle parse calls for every one that I would expect an efficient DBI = +layer to +make. I’ve included my Perl source (below), the Oracle level-12 = +trace +data that shows the sequence of calls it’s receiving from the Perl = +application +(below), a level-9 DBI trace from the application (attached), and our = +version information +(below).

+ +

 

+ +

The reason I’m bringing this to your attention = +in this +way is that I’m relying pretty heavily upon Perl for performance +measurement tools, examples, and simulators in the text. I love the = +language +and I want for the book to be an encouragement for more people to use = +Perl. +However, this extra-parse behavior is one of the things that the book = +highlights +as an important scalability barrier (some other tools do it too, = +unfortunately). +Of course, this is a speed bump on the road to my goal of helping to = +promote Perl.

+ +

 

+ +

I was hoping that by showing you this specific data, = +you +could make the problem go away.

+ +

 

+ +

Cary = +Millsap
+Hotsos Enterprises, Ltd.
+http://www.hotsos.com
+
+Upcoming events:
+- Hotsos Clinic, = +Oct +1–3 San Francisco, Oct 15–17 = +Dallas, Dec +9–11 Honolulu
+- 2003 Hotsos = +Symposium on +Oracle® System Performance, Feb 9–12 = +Dallas
+- Next event: Miracle Database = +Forum, Sep +20–22 Middlefart Denmark

+ +
+ +

Listing [listing.sqltrace.pl]: a simple = +application that +executes a database query

+ +
+ +
+ +

#!/usr/bin/perl

+ +

+ +

+ +

 

+ +

 

+ +

# = +$Header: +/home/cvs/cvm-book1/sqltrace/ex1.pl,v 1.2 2002/09/12 = +21:10:25 cvm Exp $

+ +

+ +

# = +Cary Millsap (cary.millsap@hotsos.com)

+ +

+ +

 

+ +

 

+ +

use = +strict;

+ +

+ +

use = +warnings;

+ +

+ +

use = +DBI;

+ +

+ +

use = +DBD::Oracle;

+ +

+ +

use = +Getopt::Long;

+ +

+ +

use = +Term::ReadKey;

+ +

+ +

 

+ +

 

+ +

my +$sth;           &n= +bsp;        +# Oracle statement handle

+ +

+ +

my = +$hostname =3D +"";

+ +

+ +

my = +$username =3D +"/";

+ +

+ +

my = +$password =3D +"";

+ +

+ +

my = +$logfile  +=3D "ex1.log";

+ +

+ +

my = +%attr =3D (

+ +

+ +

    +RaiseError =3D> 1,

+ +

+ +

    +AutoCommit =3D> 0,

+ +

+ +

);

+ +

+ +

my = +%opt =3D (

+ +

+ +

    +pause   =3D> 0,

+ +

+ +

);

+ +

+ +

 

+ +

 

+ +

# Get = +command line +options and arguments.

+ +

+ +

GetOptions(

+ +

+ +

    +"pause" =3D> \$opt{pause},

+ +

+ +

);

+ +

+ +

my = +$key =3D +37;           &nbs= +p;  + # default query value

+ +

+ +

$key = +=3D $ARGV[0] if +$ARGV[0];

+ +

+ +

 

+ +

 

+ +

# = +Connect to +Oracle.

+ +

+ +

my = +$dbh =3D +DBI->connect("dbi:Oracle:$hostname", $username, $password, +\%attr);

+ +

+ +

$dbh->trace(9, +$logfile);

+ +

+ +

 

+ +

 

+ +

# = +Activate +tracing.

+ +

+ +

$sth = +=3D +$dbh->prepare(q(alter session set events '10046 trace name context = +forever, +level 12'));

+ +

+ +

$sth->execute;

+ +

+ +

 

+ +

 

+ +

# = +Allow the user +to find the Oracle session and activate OS diagnostic

+ +

+ +

# = +tools like +strace(1) or lsof(8).

+ +

+ +

if = +($opt{pause}) {

+ +

+ +

    +print "Press any key to continue...";

+ +

+ +

    +1 while not defined (my $k =3D ReadKey(-1));

+ +

+ +

    +print "\n";

+ +

+ +

}

+ +

+ +

 

+ +

 

+ +

# = +Execute the +query to trace.

+ +

+ +

$sth = +=3D +$dbh->prepare(q(select key, fkey, value from t where = +key=3D?));

+ +

+ +

$sth->execute($key);

+ +

+ +

 

+ +

 

+ +

# = +Print output +header.

+ +

+ +

my = +@cdefs =3D qw(%8d +%8d %32s);   # column definitions

+ +

+ +

my = +@hdefs =3D qw(Key +Fkey Value); # column headings

+ +

+ +

my = +$bformat =3D +join("  ", @cdefs) . "\n";

+ +

+ +

my = +$hformat; +($hformat =3D $bformat) =3D~ s/%(\d*)\S+/%$1s/g;

+ +

+ +

printf $hformat, +@hdefs;

+ +

+ +

printf $hformat, +do { my @h; push @h, "-" x (/(\d+)/?$1:10) for = +@cdefs; @h };

+ +

+ +

 

+ +

 

+ +

# = +Print query +results.

+ +

+ +

for = +my $row +(@{$sth->fetchall_arrayref}) {

+ +

+ +

    +printf $bformat, @$row;

+ +

+ +

}

+ +

+ +

+ +

 

+ +

 

+ +

# = +Allow the user +to do final OS diagnostic stuff.

+ +

+ +

if = +($opt{pause}) {

+ +

+ +

    +print "Press any key to continue...";

+ +

+ +

    +1 while not defined (my $k =3D ReadKey(-1));

+ +

+ +

    +print "\n";

+ +

+ +

}

+ +

+ +

 

+ +

 

+ +

# = +Disconnect from +Oracle.

+ +

+ +

$dbh->disconnect;

+ +
+ +

 

+ +

 

+ +
+ +

Listing [listing:sqltrace.trc]: raw SQL trace = +output for +an execution of our program

+ +
+ +
+ +

/usr/local/oracle/admin/V816/udump/ora_17349.tr= +c

+ +

Oracle8i Enterprise +Edition Release 8.1.6.1.0 - Production

+ +

With = +the +Partitioning option

+ +

JServer Release +8.1.6.0.0 - Production

+ +

ORACLE_HOME =3D +/usr/local/oracle/product/8.1.6

+ +

System +name:        Linux

+ +

Node name:  = +www.hotsos.com

+ +

Release:    = +2.2.16-22enterprise

+ +

Version:    #1 +SMP Tue Aug 22 16:29:32 EDT 2000

+ +

Machine:    = +i686

+ +

Instance name: +V816

+ +

Redo = +thread +mounted by this instance: 1

+ +

Oracle process +number: 8

+ +

Unix = +process pid: +17349, image: oracle@www.hotsos.com (TNS V1-V3)

+ +

 

+ +

*** = +SESSION +ID:(7.9) 2002-09-12 16:14:01.582

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR +#1 len=3D69 dep=3D0 uid=3D12 oct=3D42 lid=3D12 = +tim=3D107309054 hv=3D1509700594 +ad=3D'54af5e14'

+ +

alter = +session set +events '10046 trace name context forever, level 12'

+ +

END = +OF STMT

+ +

EXEC +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +309054

+ +

WAIT = +#1: +nam=3D'SQL*Net message to client' ela=3D 0 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

*** = +2002-09-12 +16:14:31.226

+ +

WAIT = +#1: +nam=3D'SQL*Net message from client' ela=3D 2964 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR +#2 len=3D44 dep=3D0 uid=3D12 oct=3D3 lid=3D12 = +tim=3D107312018 hv=3D1997601641 +ad=3D'54af1384'

+ +

select key, fkey, +value from t where key=3D:p1

+ +

END = +OF STMT

+ +

PARSE +#2:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312018

+ +

WAIT = +#2: +nam=3D'SQL*Net message to client' ela=3D 0 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

WAIT = +#2: +nam=3D'SQL*Net message from client' ela=3D 0 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR +#1 len=3D44 dep=3D0 uid=3D12 oct=3D3 lid=3D12 = +tim=3D107312019 hv=3D1997601641 +ad=3D'54af1384'

+ +

select key, fkey, +value from t where key=3D:p1

+ +

END = +OF STMT

+ +

PARSE +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312019

+ +

BINDS = +#1:

+ +

 bind 0: +dty=3D1 mxl=3D32(04) mal=3D00 scl=3D00 pre=3D00 oacflg=3D25 oacfl2=3D10 = +size=3D32 offset=3D0

+ +

   bfp=3D0940e7f0 bln=3D32 avl=3D04 flg=3D05

+ +

   +value=3D"8542"

+ +

EXEC +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312019

+ +

WAIT = +#1: +nam=3D'SQL*Net message to client' ela=3D 0 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

WAIT = +#1: nam=3D'file +open' ela=3D 0 p1=3D0 p2=3D0 p3=3D0

+ +

WAIT = +#1: nam=3D'db +file sequential read' ela=3D 0 p1=3D1 p2=3D6671 p3=3D1

+ +

WAIT = +#1: nam=3D'db +file sequential read' ela=3D 0 p1=3D1 p2=3D6678 p3=3D1

+ +

FETCH +#1:c=3D0,e=3D0,p=3D2,cr=3D3,cu=3D0,mis=3D0,r=3D1,dep=3D0,og=3D3,tim=3D107= +312019

+ +

*** = +2002-09-12 +16:14:56.200

+ +

WAIT = +#1: +nam=3D'SQL*Net message from client' ela=3D 2496 p1=3D1650815232 p2=3D1 = +p3=3D0

+ +

XCTEND rlbk=3D0, +rd_only=3D1

+ +

STAT = +#1 id=3D1 cnt=3D1 +pid=3D0 pos=3D0 obj=3D5156 op=3D'TABLE ACCESS BY INDEX ROWID T = +'

+ +

STAT = +#1 id=3D2 cnt=3D2 +pid=3D1 pos=3D1 obj=3D5157 op=3D'INDEX UNIQUE SCAN '

+ +
+ +

 

+ +

 

+ +

$ perl -V

+ +

Summary of my perl5 (revision 5.0 version 6 subversion 0) = +configuration:

+ +

  Platform:

+ +

    osname=3Dlinux, osvers=3D2.2.5-22smp, = +archname=3Di386-linux

+ +

    uname=3D'linux porky.devel.redhat.com = +2.2.5-22smp #1 smp +wed jun 2 09:11:51 edt 1999 i686 unknown '

+ +

    config_args=3D'-des -Doptimize=3D-O2 = +-march=3Di386 -mcpu=3Di686 +-Dcc=3Dgcc -Dcccdlflags=3D-fPIC -Dinstallprefix=3D/usr -Dprefix=3D/usr = +-Darchname=3Di386-linux +-Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow = +-Di_syslog -Dman3ext=3D3pm -Uuselargefiles'

+ +

    hint=3Drecommended, useposix=3Dtrue, = +d_sigaction=3Ddefine

+ +

    usethreads=3Dundef use5005threads=3Dundef = +useithreads=3Dundef +usemultiplicity=3Dundef

+ +

    useperlio=3Dundef d_sfio=3Dundef = +uselargefiles=3Dundef

+ +

    use64bitint=3Dundef use64bitall=3Dundef = +uselongdouble=3Dundef +usesocks=3Dundef

+ +

  Compiler:

+ +

    cc=3D'gcc', optimize=3D'-O2 -march=3Di386 = +-mcpu=3Di686', gccversion=3D2.96 +20000731 (experimental)

+ +

    = +cppflags=3D'-fno-strict-aliasing'

+ +

    ccflags = +=3D'-fno-strict-aliasing'

+ +

    stdchar=3D'char', d_stdstdio=3Ddefine, = +usevfork=3Dfalse

+ +

    intsize=3D4, longsize=3D4, ptrsize=3D4, = +doublesize=3D8

+ +

    d_longlong=3Ddefine, longlongsize=3D8, = +d_longdbl=3Ddefine, +longdblsize=3D12

+ +

    ivtype=3D'long', ivsize=3D4, = +nvtype=3D'double', nvsize=3D8, Off_t=3D'off_t', +lseeksize=3D4

+ +

    alignbytes=3D4, usemymalloc=3Dn, = +prototype=3Ddefine

+ +

  Linker and Libraries:

+ +

    ld=3D'gcc', ldflags =3D' = +-L/usr/local/lib'

+ +

    libpth=3D/usr/local/lib /lib = +/usr/lib

+ +

    libs=3D-lnsl -ldl -lm -lc = +-lcrypt

+ +

    libc=3D/lib/libc-2.1.92.so, so=3Dso, = +useshrplib=3Dfalse, libperl=3Dlibperl.a

+ +

  Dynamic Linking:

+ +

    dlsrc=3Ddl_dlopen.xs, dlext=3Dso, = +d_dlsymun=3Dundef, ccdlflags=3D'-rdynamic'

+ +

    cccdlflags=3D'-fPIC', lddlflags=3D'-shared = +-L/usr/local/lib'

+ +

 

+ +

 

+ +

Characteristics of this binary (from libperl): = +

+ +

  Compile-time options:

+ +

  Built under linux

+ +

  Compiled at Aug  7 2000 10:59:51

+ +

  @INC:

+ +

    = +/usr/lib/perl5/5.6.0/i386-linux

+ +

    /usr/lib/perl5/5.6.0

+ +

    = +/usr/lib/perl5/site_perl/5.6.0/i386-linux

+ +

    = +/usr/lib/perl5/site_perl/5.6.0

+ +

    /usr/lib/perl5/site_perl

+ +

    .

+ +

 

+ +

 

+ +

Other site information

+ +

- Redhat Linux 7.0

+ +

- Oracle 8.1.6.1.0

+ +

- DBD-Oracle 1.12

+ +

- DBI 1.30

+ +

 

+ +
+ + + + + +------=_NextPart_001_016B_01C25A80.D1557E70-- + +------=_NextPart_000_016A_01C25A80.D1527130 +Content-Type: application/octet-stream; + name="ex1.log" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="ex1.log" + + DBI::db=3DHASH(0x8235a74) trace level set to 9 in DBI 1.30-nothread=0A= + -> prepare for DBD::Oracle::db (DBI::db=3DHASH(0x8235b34)~0x8235a74 = +'alter session set events '10046 trace name context forever, level 12'')=0A= + = +dbih_setup_handle(DBI::st=3DHASH(0x8240f68)=3D>DBI::st=3DHASH(0x8240f98),= + DBD::Oracle::st, 8240f74, Null!)=0A= + dbih_make_com(DBI::db=3DHASH(0x8235a74), DBD::Oracle::st, 208) = +thr#(nil)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), Err, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8162bb8) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), State, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8190e58) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), Errstr, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8162ba0) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), Debug, = +DBI::db=3DHASH(0x8235a74)) 9 (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), FetchHashKeyName, = +DBI::db=3DHASH(0x8235a74)) 'NAME' (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240f98), HandleError, = +DBI::db=3DHASH(0x8235a74)) undef (not defined)=0A= +OCIHandleAlloc(0x82465d8,0x826c948,OCI_HTYPE_STMT,0,(nil))=3DSUCCESS=0A= +OCIStmtPrepare(0x826bf48,0x82559ec,'alter session set events '10046 = +trace name context forever, level 12'',69,1,0)=3DSUCCESS=0A= +OCIAttrGet(0x826bf48,OCI_HTYPE_STMT,0x826c94c,(nil),24,0x82559ec)=3DSUCCE= +SS=0A= + dbd_st_prepare'd sql ALTER=0A= + dbd_describe skipped for ALTER=0A= + <- prepare=3D DBI::st=3DHASH(0x8240f68) at ex1.pl line 38=0A= + -> execute for DBD::Oracle::st (DBI::st=3DHASH(0x8240f68)~0x8240f98)=0A= + dbd_st_execute ALTER (out0, lob0)...=0A= +OCIStmtExecute(0x82557c4,0x826bf48,0x82559ec,1,0,(nil),(nil),0)=3DSUCCESS=0A= +OCIAttrGet(0x826bf48,OCI_HTYPE_STMT,0xbffff654,(nil),9,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826bf48,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=3DSUCC= +ESS=0A= + dbd_st_execute ALTER returned (SUCCESS, rpc0, fn52, out0)=0A= + <- execute=3D '0E0' at ex1.pl line 39=0A= + -> prepare for DBD::Oracle::db (DBI::db=3DHASH(0x8235b34)~0x8235a74 = +'select key, fkey, value from t where key=3D?')=0A= + = +dbih_setup_handle(DBI::st=3DHASH(0x8240fe0)=3D>DBI::st=3DHASH(0x8240fb0),= + DBD::Oracle::st, 8240fec, Null!)=0A= + dbih_make_com(DBI::db=3DHASH(0x8235a74), DBD::Oracle::st, 208) = +thr#(nil)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), Err, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8162bb8) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), State, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8190e58) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), Errstr, = +DBI::db=3DHASH(0x8235a74)) SCALAR(0x8162ba0) (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), Debug, = +DBI::db=3DHASH(0x8235a74)) 9 (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), FetchHashKeyName, = +DBI::db=3DHASH(0x8235a74)) 'NAME' (already defined)=0A= + dbih_setup_attrib(DBI::st=3DHASH(0x8240fb0), HandleError, = +DBI::db=3DHASH(0x8235a74)) undef (not defined)=0A= + dbd_preparse scanned 1 distinct placeholders=0A= +OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=3DSUCCESS=0A= +OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t where = +key=3D:p1',44,1,0)=3DSUCCESS=0A= +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=3DSUCCE= +SS=0A= + dbd_st_prepare'd sql SELECT=0A= + dbd_describe SELECT (EXPLICIT, lb 80)...=0A= +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=3DSUCCES= +S=0A= +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff3dc,(nil),18,0x82559ec)=3DSUCC= +ESS=0A= +OCIParamGet(0x826e4a0,4,0x82559ec,0x826d1c0,1)=3DSUCCESS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1d6,(nil),2,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1d4,(nil),1,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1d8,(nil),5,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1da,(nil),6,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1db,(nil),7,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e228,OCI_DTYPE_PARAM,0x826d1e8,0xbffff3d8,4,0x82559ec)=3D= +SUCCESS=0A= + fbh 1: 'KEY' NO null , otype 2-> 5, dbsize 22/134, p0.s0=0A= +OCIParamGet(0x826e4a0,4,0x82559ec,0x826d200,2)=3DSUCCESS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d216,(nil),2,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d214,(nil),1,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d218,(nil),5,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d21a,(nil),6,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d21b,(nil),7,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e208,OCI_DTYPE_PARAM,0x826d228,0xbffff3d8,4,0x82559ec)=3D= +SUCCESS=0A= + fbh 2: 'FKEY' NULLable, otype 2-> 5, dbsize 22/134, p0.s0=0A= +OCIParamGet(0x826e4a0,4,0x82559ec,0x826d240,3)=3DSUCCESS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d256,(nil),2,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d254,(nil),1,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d258,(nil),5,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d25a,(nil),6,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d25b,(nil),7,0x82559ec)=3DSUCCE= +SS=0A= +OCIAttrGet(0x826e1e8,OCI_DTYPE_PARAM,0x826d268,0xbffff3d8,4,0x82559ec)=3D= +SUCCESS=0A= + fbh 3: 'VALUE' NULLable, otype 1-> 5, dbsize 32/33, p32.s0=0A= +OCIAttrSet(0x826e4a0,OCI_HTYPE_STMT,0xbffff3d4,4,11,0x82559ec)=3DSUCCESS=0A= +OCIDefineByPos(0x826e4a0,0x826d1c4,0x82559ec,1,0x826e8d0,134,5,0x826d438,= +0x826d448,0x826d458,0)=3DSUCCESS=0A= +OCIDefineByPos(0x826e4a0,0x826d204,0x82559ec,2,0x826eaf8,134,5,0x826ca28,= +0x826ca38,0x826ca48,0)=3DSUCCESS=0A= +OCIDefineByPos(0x826e4a0,0x826d244,0x82559ec,3,0x826cbb8,33,5,0x826ca58,0= +x826cbe0,0x826cbf0,0)=3DSUCCESS=0A= + dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: 231)=0A= + <- prepare=3D DBI::st=3DHASH(0x8240fe0) at ex1.pl line 50=0A= + -> DESTROY for DBD::Oracle::st (DBI::st=3DHASH(0x8240f98)~INNER)=0A= +OCIHandleFree(0x826bf48,OCI_HTYPE_STMT)=3DSUCCESS=0A= + <- DESTROY=3D undef at ex1.pl line 51=0A= + -> execute for DBD::Oracle::st (DBI::st=3DHASH(0x8240fe0)~0x8240fb0 = +'8542')=0A= + bind :p1 <=3D=3D '8542' (type 0)=0A= + bind :p1 <=3D=3D '8542' (size 4/5/0, ptype 7, otype 1)=0A= + bind :p1 <=3D=3D '8542' (size 4/4, otype 1, indp 0, at_exec 1)=0A= +OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826cb= +6e,(nil),0x826cb6c,0,(nil),2)=3DSUCCESS=0A= +OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401da= +090)=3DSUCCESS=0A= + bind :p1 done with ftype 1=0A= + dbd_st_execute SELECT (out0, lob0)...=0A= + in ':p1' [0,0]: len 4, ind 0=0A= +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=3DSUCCESS=0A= +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=3DSUCC= +ESS=0A= + dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)=0A= + <- execute=3D '0E0' at ex1.pl line 51=0A= + -> fetchall_arrayref for DBD::Oracle::st = +(DBI::st=3DHASH(0x8240fe0)~0x8240fb0)=0A= + dbd_st_fetch 3 fields...=0A= +OCIStmtFetch(0x826e4a0,0x82559ec,1,2,0)=3DSUCCESS=0A= + dbih_setup_fbav for 3 fields =3D> 0x8240fbc=0A= + dbd_st_fetch 3 fields SUCCESS=0A= + 0 (rc=3D0): '8542'=0A= + 1 (rc=3D0): '8542'=0A= + 2 (rc=3D0): 'value'=0A= + dbd_st_fetch 3 fields...=0A= +OCIStmtFetch(0x826e4a0,0x82559ec,1,2,0)=3DNO_DATA=0A= + dbd_st_fetch no-more-data=0A= + <- fetchall_arrayref=3D [ ARRAY(0x82411f0) ] row1 at ex1.pl line 62=0A= + -> disconnect for DBD::Oracle::db = +(DBI::db=3DHASH(0x8235b34)~0x8235a74)=0A= +OCISessionEnd(0x82557c4,0x82559ec,0x826c384,0)=3DSUCCESS=0A= +OCIServerDetach(0x8255834,0x82559ec,0)=3DSUCCESS=0A= + <- disconnect=3D 1 at ex1.pl line 74=0A= + -> DESTROY for DBD::Oracle::st (DBI::st=3DHASH(0x8240fb0)~INNER)=0A= +OCIHandleFree(0x826e4a0,OCI_HTYPE_STMT)=3DSUCCESS=0A= + <- DESTROY=3D undef=0A= + -> DESTROY for DBD::Oracle::db (DBI::db=3DHASH(0x8235a74)~INNER)=0A= +OCIHandleFree(0x826c384,OCI_HTYPE_SESSION)=3DSUCCESS=0A= +OCIHandleFree(0x8255834,OCI_HTYPE_SERVER)=3DSUCCESS=0A= +OCIHandleFree(0x82557c4,OCI_HTYPE_SVCCTX)=3DSUCCESS=0A= +OCIHandleFree(0x82559ec,OCI_HTYPE_ERROR)=3DSUCCESS=0A= + <- DESTROY=3D undef=0A= + +------=_NextPart_000_016A_01C25A80.D1527130-- + + +From timbo@dansat.data-plan.com Fri Sep 13 07:30:31 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8D6UUC04053 + for ; Fri, 13 Sep 2002 07:30:30 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.21] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 07:30:30 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031871608:20:03733:55; Thu, 12 Sep 2002 23:00:08 GMT +Received: from cali-3.pobox.com ([64.71.166.116]) by punt-2.mail.demon.net + id ab2122693; 12 Sep 2002 23:00 GMT +Received: from cali-3.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-3.pobox.com (Postfix) with ESMTP id AE0642F0B8A + for ; Thu, 12 Sep 2002 18:58:25 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) + by cali-3.pobox.com (Postfix) with SMTP id 931D42F0D0A + for ; Thu, 12 Sep 2002 18:58:19 -0400 (EDT) +Received: (qmail 57270 messnum 519666 invoked from network[159.134.164.69/p69.as1.limerick1.eircom.net]); 12 Sep 2002 22:58:17 -0000 +Received: from p69.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.164.69) + by mail03.svc.cra.dublin.eircom.net (qp 57270) with SMTP; 12 Sep 2002 22:58:17 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g8CMwEQ02798; + Thu, 12 Sep 2002 23:58:14 +0100 (BST) + (envelope-from timbo) +Date: Thu, 12 Sep 2002 23:58:14 +0100 +From: Tim Bunce +To: Cary Millsap +Cc: tim.bunce@pobox.com +Subject: two Oracle parse calls +Message-ID: <20020912225814.GG539@dansat.data-plan.com> +References: <016901c25aaa$ba287930$6501a8c0@CVMLAP01> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <016901c25aaa$ba287930$6501a8c0@CVMLAP01> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 3530 +Lines: 77 + +On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap wrote: +> Tim, +> +> How are you doing? I hope you've had a good two years since I saw you on +> the Oracle Geek Cruise event. + +Yes thanks. And you? + +> I've been working on a project this year to construct a book about +> optimizing Oracle response time. In my research, I've discovered +> something about the DBI that I didn't expect: it executes two Oracle +> parse calls for every one that I would expect an efficient DBI layer to +> make. I've included my Perl source (below), the Oracle level-12 trace +> data that shows the sequence of calls it's receiving from the Perl +> application (below), a level-9 DBI trace from the application +> (attached), and our version information (below). +> +> I was hoping that by showing you this specific data, you could make the +> problem go away. + +I can only do what OCI lets me do... but within that I'll do what I can... + +I'm not familar with Oracle trace logs so I can't readily intrepret them +and I'll take what you say at face value. + +But I am familar with DBD::Oracle :) and the logs it writes :) + +> $sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); +> $sth->execute($key); + + + -> prepare for DBD::Oracle::db (DBI::db=HASH(0x8235b34)~0x8235a74 'select key, fkey, value from t where key=?') + dbd_preparse scanned 1 distinct placeholders +OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=SUCCESS +OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t where key=:p1',44,1,0)=SUCCESS +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=SUCCESS + dbd_st_prepare'd sql SELECT + dbd_describe SELECT (EXPLICIT, lb 80)... +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=SUCCESS + dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: 231) + <- prepare= DBI::st=HASH(0x8240fe0) at ex1.pl line 50 + -> execute for DBD::Oracle::st (DBI::st=HASH(0x8240fe0)~0x8240fb0 '8542') +OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826cb6e,(nil),0x826cb6c,0,(nil),2)=SUCCESS +OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401da090)=SUCCESS + bind :p1 done with ftype 1 + dbd_st_execute SELECT (out0, lob0)... + in ':p1' [0,0]: len 4, ind 0 +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=SUCCESS +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=SUCCESS + dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) + <- execute= '0E0' at ex1.pl line 51 + +Given those OCI calls, what is DBD::Oracle doing that it shouldn't? + +I'd guess that it's something to do with the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) +call that prepare() does. + +It doesn't do that for non-select statements so you could check if +non-selects also have two parse calls. + +Also try doing + $sth = $dbh->prepare(q(select key, fkey, value from t where key=?), { ora_check_sql=> 0 }); + +which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till after the +main OCIStmtExecute(). In that case the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) +is possibly redundant and could be removed (but Oracle ought to detect that +anyway and not make a round-trip for it, and certainly not call parse). + +If non-selects only have one parse call but ora_check_sql=>0 doesn't +fix selects, then I might be able to do a simple patch to avoid the +OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if ora_check_sql=>0. + +Then the issue will be: should ora_check_sql=>0 be the default... + +Tim. + +p.s. I'd love a copy of your book when it's ready! + +From cary.millsap@hotsos.com Fri Sep 13 07:31:55 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8D6VsC04590 + for ; Fri, 13 Sep 2002 07:31:54 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.21] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 07:31:54 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031889643:20:09494:0; Fri, 13 Sep 2002 04:00:43 GMT +Received: from wormwood.pobox.com ([208.210.125.20]) by punt-2.mail.demon.net + id aa2008866; 13 Sep 2002 4:00 GMT +Received: from wormwood.pobox.com (localhost.pobox.com [127.0.0.1]) + by wormwood.pobox.com (Postfix) with ESMTP id C94C67264F + for ; Fri, 13 Sep 2002 00:00:07 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by wormwood.pobox.com (Postfix) with ESMTP id A821072676 + for ; Fri, 13 Sep 2002 00:00:06 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8D405n19404 + for ; Thu, 12 Sep 2002 23:00:05 -0500 +From: "Cary Millsap" +To: "'Tim Bunce'" +Subject: RE: two Oracle parse calls +Date: Thu, 12 Sep 2002 22:59:56 -0500 +Message-ID: <019201c25ada$093c6ac0$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +In-Reply-To: <20020912225814.GG539@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 4825 +Lines: 129 + +Tim, + +Thanks so very much. The attribute ora_check_sql=>0 is new knowledge to +me; this is a nice reward for having written to you. I will test it +either tonight or the first thing tomorrow and then inform you of the +results immediately after that. If it solves the problem, then I will +lobby you to make 0 the default value and probably consider the issue +"problem solved." + +Things are very well, thank you. I've been at home with my family now +for over three straight weeks, and we're having a nice time of our lives +these days with the business settling into stride a bit. Tonight is a +big night for me. I've just crossed the line of accepting a preliminary +offer from O'Reilly. This book project has actually been underway for +quite some time now, but as of tonight it's quite a bit more "official." + + +Cary Millsap +Hotsos Enterprises, Ltd. +http://www.hotsos.com + +Upcoming events: +- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +Honolulu +- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +- Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark + + + +-----Original Message----- +From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +Sent: Thursday, September 12, 2002 5:58 PM +To: Cary Millsap +Cc: tim.bunce@pobox.com +Subject: two Oracle parse calls + +On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap wrote: +> Tim, +> +> How are you doing? I hope you've had a good two years since I saw you +on +> the Oracle Geek Cruise event. + +Yes thanks. And you? + +> I've been working on a project this year to construct a book about +> optimizing Oracle response time. In my research, I've discovered +> something about the DBI that I didn't expect: it executes two Oracle +> parse calls for every one that I would expect an efficient DBI layer +to +> make. I've included my Perl source (below), the Oracle level-12 trace +> data that shows the sequence of calls it's receiving from the Perl +> application (below), a level-9 DBI trace from the application +> (attached), and our version information (below). +> +> I was hoping that by showing you this specific data, you could make +the +> problem go away. + +I can only do what OCI lets me do... but within that I'll do what I +can... + +I'm not familar with Oracle trace logs so I can't readily intrepret them +and I'll take what you say at face value. + +But I am familar with DBD::Oracle :) and the logs it writes :) + +> $sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); +> $sth->execute($key); + + + -> prepare for DBD::Oracle::db (DBI::db=HASH(0x8235b34)~0x8235a74 +'select key, fkey, value from t where key=?') + dbd_preparse scanned 1 distinct placeholders +OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=SUCCESS +OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t where +key=:p1',44,1,0)=SUCCESS +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=SUCCES +S + dbd_st_prepare'd sql SELECT + dbd_describe SELECT (EXPLICIT, lb 80)... +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=SUCCESS + dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: 231) + <- prepare= DBI::st=HASH(0x8240fe0) at ex1.pl line 50 + -> execute for DBD::Oracle::st (DBI::st=HASH(0x8240fe0)~0x8240fb0 +'8542') +OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826c +b6e,(nil),0x826cb6c,0,(nil),2)=SUCCESS +OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401d +a090)=SUCCESS + bind :p1 done with ftype 1 + dbd_st_execute SELECT (out0, lob0)... + in ':p1' [0,0]: len 4, ind 0 +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=SUCCESS +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=SUCCE +SS + dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) + <- execute= '0E0' at ex1.pl line 51 + +Given those OCI calls, what is DBD::Oracle doing that it shouldn't? + +I'd guess that it's something to do with the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY) +call that prepare() does. + +It doesn't do that for non-select statements so you could check if +non-selects also have two parse calls. + +Also try doing + $sth = $dbh->prepare(q(select key, fkey, value from t where key=?), { +ora_check_sql=> 0 }); + +which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till after the +main OCIStmtExecute(). In that case the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY) +is possibly redundant and could be removed (but Oracle ought to detect +that +anyway and not make a round-trip for it, and certainly not call parse). + +If non-selects only have one parse call but ora_check_sql=>0 doesn't +fix selects, then I might be able to do a simple patch to avoid the +OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if ora_check_sql=>0. + +Then the issue will be: should ora_check_sql=>0 be the default... + +Tim. + +p.s. I'd love a copy of your book when it's ready! + + +From timbo@dansat.data-plan.com Fri Sep 13 10:48:59 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8D9mwC06022 + for ; Fri, 13 Sep 2002 10:48:58 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.22] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 10:48:58 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031907122:20:19599:21; Fri, 13 Sep 2002 08:52:02 GMT +Received: from cali-2.pobox.com ([64.71.166.115]) by punt-2.mail.demon.net + id aa2129553; 13 Sep 2002 8:52 GMT +Received: from cali-2.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-2.pobox.com (Postfix) with ESMTP id 99E263E660 + for ; Fri, 13 Sep 2002 04:51:54 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) + by cali-2.pobox.com (Postfix) with SMTP id 721613E637 + for ; Fri, 13 Sep 2002 04:51:53 -0400 (EDT) +Received: (qmail 29161 messnum 524631 invoked from network[159.134.167.5/p773.as1.limerick1.eircom.net]); 13 Sep 2002 08:51:51 -0000 +Received: from p773.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.167.5) + by mail03.svc.cra.dublin.eircom.net (qp 29161) with SMTP; 13 Sep 2002 08:51:51 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g8D8prO05752; + Fri, 13 Sep 2002 09:51:53 +0100 (BST) + (envelope-from timbo) +Date: Fri, 13 Sep 2002 09:51:53 +0100 +From: Tim Bunce +To: Cary Millsap +Cc: "'Tim Bunce'" +Subject: Re: two Oracle parse calls +Message-ID: <20020913085153.GJ539@dansat.data-plan.com> +References: <20020912225814.GG539@dansat.data-plan.com> <019201c25ada$093c6ac0$6501a8c0@CVMLAP01> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <019201c25ada$093c6ac0$6501a8c0@CVMLAP01> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 6172 +Lines: 154 + +On Thu, Sep 12, 2002 at 10:59:56PM -0500, Cary Millsap wrote: +> Tim, +> +> Thanks so very much. The attribute ora_check_sql=>0 is new knowledge to +> me; this is a nice reward for having written to you. I will test it +> either tonight or the first thing tomorrow and then inform you of the +> results immediately after that. If it solves the problem, then I will +> lobby you to make 0 the default value and probably consider the issue +> "problem solved." + +Ah, but there are down-sides to ora_check_sql=0 - it was the default +for a little while. Here's an old message that, although being out of +date in various ways, describes some of the issues: + +http://www.bitmechanic.com/mail-archives/dbi-users/Apr1999/0538.html + +In principle I don't have a fundamental objection to defering the +'describe' until execute and thus defering detection of syntax +errors until the execute. I'd probably add a new $dbh attribute to +set the desired default behaviour so you don't have to add it to +each prepare() call. + +> Things are very well, thank you. I've been at home with my family now +> for over three straight weeks, and we're having a nice time of our lives +> these days with the business settling into stride a bit. Tonight is a +> big night for me. I've just crossed the line of accepting a preliminary +> offer from O'Reilly. This book project has actually been underway for +> quite some time now, but as of tonight it's quite a bit more "official." + +Congratulations. I'm sure it'll be a success. + +BTW, if you happen to come across any work opportunities that might +fit my skills I'd be interested in hearing about them (would have to +be teleworking as I've no plans to move under any circumstances). +I'd especially love to find some company that uses DBI & DBD::Oracle +heavily and would basically pay me to develop them - there's *lots* +more valuable functionality that could be added to DBD::Oracle (and +my Oracle::OCI module). + +Tim. + +> +> Cary Millsap +> Hotsos Enterprises, Ltd. +> http://www.hotsos.com +> +> Upcoming events: +> - Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +> Honolulu +> - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +> - Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark +> +> +> +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Thursday, September 12, 2002 5:58 PM +> To: Cary Millsap +> Cc: tim.bunce@pobox.com +> Subject: two Oracle parse calls +> +> On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap wrote: +> > Tim, +> > +> > How are you doing? I hope you've had a good two years since I saw you +> on +> > the Oracle Geek Cruise event. +> +> Yes thanks. And you? +> +> > I've been working on a project this year to construct a book about +> > optimizing Oracle response time. In my research, I've discovered +> > something about the DBI that I didn't expect: it executes two Oracle +> > parse calls for every one that I would expect an efficient DBI layer +> to +> > make. I've included my Perl source (below), the Oracle level-12 trace +> > data that shows the sequence of calls it's receiving from the Perl +> > application (below), a level-9 DBI trace from the application +> > (attached), and our version information (below). +> > +> > I was hoping that by showing you this specific data, you could make +> the +> > problem go away. +> +> I can only do what OCI lets me do... but within that I'll do what I +> can... +> +> I'm not familar with Oracle trace logs so I can't readily intrepret them +> and I'll take what you say at face value. +> +> But I am familar with DBD::Oracle :) and the logs it writes :) +> +> > $sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); +> > $sth->execute($key); +> +> +> -> prepare for DBD::Oracle::db (DBI::db=HASH(0x8235b34)~0x8235a74 +> 'select key, fkey, value from t where key=?') +> dbd_preparse scanned 1 distinct placeholders +> OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=SUCCESS +> OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t where +> key=:p1',44,1,0)=SUCCESS +> OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=SUCCES +> S +> dbd_st_prepare'd sql SELECT +> dbd_describe SELECT (EXPLICIT, lb 80)... +> OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=SUCCESS +> dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: 231) +> <- prepare= DBI::st=HASH(0x8240fe0) at ex1.pl line 50 +> -> execute for DBD::Oracle::st (DBI::st=HASH(0x8240fe0)~0x8240fb0 +> '8542') +> OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826c +> b6e,(nil),0x826cb6c,0,(nil),2)=SUCCESS +> OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401d +> a090)=SUCCESS +> bind :p1 done with ftype 1 +> dbd_st_execute SELECT (out0, lob0)... +> in ':p1' [0,0]: len 4, ind 0 +> OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=SUCCESS +> OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=SUCCE +> SS +> dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) +> <- execute= '0E0' at ex1.pl line 51 +> +> Given those OCI calls, what is DBD::Oracle doing that it shouldn't? +> +> I'd guess that it's something to do with the OCIStmtExecute(..., +> OCI_DESCRIBE_ONLY) +> call that prepare() does. +> +> It doesn't do that for non-select statements so you could check if +> non-selects also have two parse calls. +> +> Also try doing +> $sth = $dbh->prepare(q(select key, fkey, value from t where key=?), { +> ora_check_sql=> 0 }); +> +> which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till after the +> main OCIStmtExecute(). In that case the OCIStmtExecute(..., +> OCI_DESCRIBE_ONLY) +> is possibly redundant and could be removed (but Oracle ought to detect +> that +> anyway and not make a round-trip for it, and certainly not call parse). +> +> If non-selects only have one parse call but ora_check_sql=>0 doesn't +> fix selects, then I might be able to do a simple patch to avoid the +> OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if ora_check_sql=>0. +> +> Then the issue will be: should ora_check_sql=>0 be the default... +> +> Tim. +> +> p.s. I'd love a copy of your book when it's ready! +> + +From cary.millsap@hotsos.com Fri Sep 13 17:52:40 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DGqdC10778 + for ; Fri, 13 Sep 2002 17:52:39 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.59] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 17:52:39 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031932999:10:25604:102; Fri, 13 Sep 2002 16:03:19 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1101673; 13 Sep 2002 16:03 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id E4A692C078 + for ; Fri, 13 Sep 2002 12:02:43 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by dolly1.pobox.com (Postfix) with ESMTP id 1609E2C03F + for ; Fri, 13 Sep 2002 12:02:29 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8DG2Sn24856 + for ; Fri, 13 Sep 2002 11:02:28 -0500 +From: "Cary Millsap" +To: "'Tim Bunce'" +Subject: RE: two Oracle parse calls +Date: Fri, 13 Sep 2002 11:02:20 -0500 +Message-ID: <01c501c25b3e$f3e7f440$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +In-Reply-To: <20020913085153.GJ539@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 9234 +Lines: 248 + +Tim, + +I think it's important for a developer to have the ability to turn this +on and off. But I would argue that 0 is the correct default. I think of +it as a probability times cost function. The cost of leaving the setting +at 1 accidentally in a production application is pretty high: if the app +doesn't scale (because it's parsing too much), then it jeopardizes the +business' ability to succeed with it. + +The probability of leaving the option set to 1 accidentally during +production is very high. A point in evidence is that I didn't find the +parameter until I corresponded personally with you. I in fact *still* +don't know where to find it. I've checked Descartes & Bunce, perldoc +DBI, and perldoc DBD::Oracle without finding it yet... + +If the default were 0, the probability of leaving the option set to 0 +accidentally during development would be much lower. A developer faced +with a SQL syntax problem he doesn't understand will do the research +necessary to fix that problem. He can't release his code until he does. + +The problem with the default of 1 is, in my opinion, that most +developers will never learn of the feature, and they'll accidentally +leave it turned on in production. The proportion of developers who +competently performance-test their code is, unfortunately, +microscopically small. But they all do some level of functional testing. + +I would recommend making the ora_check_sql feature a more prominently +documented feature, presumably in "perldoc DBD::Oracle". + +I did learn in a test that specifying the option in the DBI->connect() +call doesn't do anything. Is it possible that you could allow us to +specify it at the connection level? The workaround is to do something +like this: + + use Getopt::Long; + my %prepare_attr = (ora_check_sql=>0); + GetOptions("dev"=>\$dev); + $prepare_attr{ora_check_sql} = 1 if $dev; + # developer must specify the command-line flag to get the +unscalable + # behavior that's necessary for functional testing + ... + $sth = $dbh->prepare($sql, %prepare_attr); # MUST specify +%p..attr + +...But I doubt that most Oracle application developers would come up +with this without some coaching. + +I'll definitely keep an eye open for projects you might like. It would +be a hell of an opportunity for someone to have you, I think. It seems +that if you could make a list like Oracle-L (1,900 people) aware that +there's an opportunity, it would improve your chances of finding +something quickly. It's of course bad taste to advertise oneself overtly +on those lists, but there is almost always a clever way to do it anyway +without offending anyone. + + +Cary Millsap +Hotsos Enterprises, Ltd. +http://www.hotsos.com + +Upcoming events: +- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +Honolulu +- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +- Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark + + + +-----Original Message----- +From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +Sent: Friday, September 13, 2002 3:52 AM +To: Cary Millsap +Cc: 'Tim Bunce' +Subject: Re: two Oracle parse calls + +On Thu, Sep 12, 2002 at 10:59:56PM -0500, Cary Millsap wrote: +> Tim, +> +> Thanks so very much. The attribute ora_check_sql=>0 is new knowledge +to +> me; this is a nice reward for having written to you. I will test it +> either tonight or the first thing tomorrow and then inform you of the +> results immediately after that. If it solves the problem, then I will +> lobby you to make 0 the default value and probably consider the issue +> "problem solved." + +Ah, but there are down-sides to ora_check_sql=0 - it was the default +for a little while. Here's an old message that, although being out of +date in various ways, describes some of the issues: + +http://www.bitmechanic.com/mail-archives/dbi-users/Apr1999/0538.html + +In principle I don't have a fundamental objection to defering the +'describe' until execute and thus defering detection of syntax +errors until the execute. I'd probably add a new $dbh attribute to +set the desired default behaviour so you don't have to add it to +each prepare() call. + +> Things are very well, thank you. I've been at home with my family now +> for over three straight weeks, and we're having a nice time of our +lives +> these days with the business settling into stride a bit. Tonight is a +> big night for me. I've just crossed the line of accepting a +preliminary +> offer from O'Reilly. This book project has actually been underway for +> quite some time now, but as of tonight it's quite a bit more +"official." + +Congratulations. I'm sure it'll be a success. + +BTW, if you happen to come across any work opportunities that might +fit my skills I'd be interested in hearing about them (would have to +be teleworking as I've no plans to move under any circumstances). +I'd especially love to find some company that uses DBI & DBD::Oracle +heavily and would basically pay me to develop them - there's *lots* +more valuable functionality that could be added to DBD::Oracle (and +my Oracle::OCI module). + +Tim. + +> +> Cary Millsap +> Hotsos Enterprises, Ltd. +> http://www.hotsos.com +> +> Upcoming events: +> - Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +> Honolulu +> - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +> - Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark +> +> +> +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Thursday, September 12, 2002 5:58 PM +> To: Cary Millsap +> Cc: tim.bunce@pobox.com +> Subject: two Oracle parse calls +> +> On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap wrote: +> > Tim, +> > +> > How are you doing? I hope you've had a good two years since I saw +you +> on +> > the Oracle Geek Cruise event. +> +> Yes thanks. And you? +> +> > I've been working on a project this year to construct a book about +> > optimizing Oracle response time. In my research, I've discovered +> > something about the DBI that I didn't expect: it executes two Oracle +> > parse calls for every one that I would expect an efficient DBI layer +> to +> > make. I've included my Perl source (below), the Oracle level-12 +trace +> > data that shows the sequence of calls it's receiving from the Perl +> > application (below), a level-9 DBI trace from the application +> > (attached), and our version information (below). +> > +> > I was hoping that by showing you this specific data, you could make +> the +> > problem go away. +> +> I can only do what OCI lets me do... but within that I'll do what I +> can... +> +> I'm not familar with Oracle trace logs so I can't readily intrepret +them +> and I'll take what you say at face value. +> +> But I am familar with DBD::Oracle :) and the logs it writes :) +> +> > $sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); +> > $sth->execute($key); +> +> +> -> prepare for DBD::Oracle::db (DBI::db=HASH(0x8235b34)~0x8235a74 +> 'select key, fkey, value from t where key=?') +> dbd_preparse scanned 1 distinct placeholders +> OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=SUCCESS +> OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t +where +> key=:p1',44,1,0)=SUCCESS +> +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=SUCCES +> S +> dbd_st_prepare'd sql SELECT +> dbd_describe SELECT (EXPLICIT, lb 80)... +> +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=SUCCESS +> dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: +231) +> <- prepare= DBI::st=HASH(0x8240fe0) at ex1.pl line 50 +> -> execute for DBD::Oracle::st (DBI::st=HASH(0x8240fe0)~0x8240fb0 +> '8542') +> +OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826c +> b6e,(nil),0x826cb6c,0,(nil),2)=SUCCESS +> +OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401d +> a090)=SUCCESS +> bind :p1 done with ftype 1 +> dbd_st_execute SELECT (out0, lob0)... +> in ':p1' [0,0]: len 4, ind 0 +> +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=SUCCESS +> +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=SUCCE +> SS +> dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) +> <- execute= '0E0' at ex1.pl line 51 +> +> Given those OCI calls, what is DBD::Oracle doing that it shouldn't? +> +> I'd guess that it's something to do with the OCIStmtExecute(..., +> OCI_DESCRIBE_ONLY) +> call that prepare() does. +> +> It doesn't do that for non-select statements so you could check if +> non-selects also have two parse calls. +> +> Also try doing +> $sth = $dbh->prepare(q(select key, fkey, value from t where key=?), +{ +> ora_check_sql=> 0 }); +> +> which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till after the +> main OCIStmtExecute(). In that case the OCIStmtExecute(..., +> OCI_DESCRIBE_ONLY) +> is possibly redundant and could be removed (but Oracle ought to detect +> that +> anyway and not make a round-trip for it, and certainly not call +parse). +> +> If non-selects only have one parse call but ora_check_sql=>0 doesn't +> fix selects, then I might be able to do a simple patch to avoid the +> OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if ora_check_sql=>0. +> +> Then the issue will be: should ora_check_sql=>0 be the default... +> +> Tim. +> +> p.s. I'd love a copy of your book when it's ready! +> + + +From timbo@dansat.data-plan.com Fri Sep 13 23:21:37 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DMLbC13725 + for ; Fri, 13 Sep 2002 23:21:37 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 23:21:37 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031951069:20:15816:152; Fri, 13 Sep 2002 21:04:29 GMT +Received: from cali-2.pobox.com ([64.71.166.115]) by punt-2.mail.demon.net + id aa2120669; 13 Sep 2002 21:04 GMT +Received: from cali-2.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-2.pobox.com (Postfix) with ESMTP id 544863E642 + for ; Fri, 13 Sep 2002 17:04:17 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) + by cali-2.pobox.com (Postfix) with SMTP id 0AE7C3E667 + for ; Fri, 13 Sep 2002 17:04:16 -0400 (EDT) +Received: (qmail 16221 messnum 355694 invoked from network[159.134.166.226/p738.as1.limerick1.eircom.net]); 13 Sep 2002 21:04:14 -0000 +Received: from p738.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.166.226) + by mail05.svc.cra.dublin.eircom.net (qp 16221) with SMTP; 13 Sep 2002 21:04:14 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g8DL4Lx12642; + Fri, 13 Sep 2002 22:04:21 +0100 (BST) + (envelope-from timbo) +Date: Fri, 13 Sep 2002 22:04:21 +0100 +From: Tim Bunce +To: Cary Millsap +Cc: "'Tim Bunce'" +Subject: Re: two Oracle parse calls +Message-ID: <20020913210421.GR539@dansat.data-plan.com> +References: <20020913085153.GJ539@dansat.data-plan.com> <01c501c25b3e$f3e7f440$6501a8c0@CVMLAP01> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <01c501c25b3e$f3e7f440$6501a8c0@CVMLAP01> +User-Agent: Mutt/1.4i +Status: O +Content-Length: 3078 +Lines: 70 + +On Fri, Sep 13, 2002 at 11:02:20AM -0500, Cary Millsap wrote: +> Tim, +> +> I think it's important for a developer to have the ability to turn this +> on and off. But I would argue that 0 is the correct default. I think of +> it as a probability times cost function. The cost of leaving the setting +> at 1 accidentally in a production application is pretty high: if the app +> doesn't scale (because it's parsing too much), then it jeopardizes the +> business' ability to succeed with it. +> +> The probability of leaving the option set to 1 accidentally during +> production is very high. A point in evidence is that I didn't find the +> parameter until I corresponded personally with you. I in fact *still* +> don't know where to find it. I've checked Descartes & Bunce, perldoc +> DBI, and perldoc DBD::Oracle without finding it yet... + +It's not documented. + +As I recall it... originally DBD::Oracle defered the describe as +long as possible. But people reported very slow select performance: + + http://www.faqchest.com/prgm/dbi-l/dbi-99/dbi-9910/dbi-991005/dbi99101218_28018.html + +Turned out that the row cache logic needed the describe to try to +work out an optimal row cache size. Without the describe the row +cache wasn't getting set up. + +At some point I added code that would just set OCI_ATTR_PREFETCH_MEMORY +to a set size if ora_check_sql was 0. But I can't remember now why +I left ora_check_sql=1. + +It was possibly in relation to wanting to be able to use the +OCI_ATTR_PARSE_ERROR_OFFSET attribute to be able to highlight the +point in a query where the error was detected. But I think execute() +needs to be able to do that anyway (to catch syntax errors in +non-select statements). + +There is another problem. If the describe has been defered and the +application uses $sth->{NAME} or other similar attribute then the +describe has to be done at that point. The code is thee to do that +but the problem is how should the DBI behave if there's an error +in the SQL? It currently always croaks (rather than return undef, +in order to give a useful error message), but that's rather surprising +behaviour to many people and very unhelpful to some. + +There may well be other subtle issues that I can't recall right now. + +> I would recommend making the ora_check_sql feature a more prominently +> documented feature, presumably in "perldoc DBD::Oracle". +> +> I did learn in a test that specifying the option in the DBI->connect() +> call doesn't do anything. Is it possible that you could allow us to +> specify it at the connection level? + +By making it a database handle attribute, yes, that would be my plan. + +> I'll definitely keep an eye open for projects you might like. It would +> be a hell of an opportunity for someone to have you, I think. + +Thanks. + +> It seems that if you could make a list like Oracle-L (1,900 people) aware +> that there's an opportunity, it would improve your chances of finding +> something quickly. It's of course bad taste to advertise oneself overtly +> on those lists, but there is almost always a clever way to do it anyway +> without offending anyone. + +:-) + +Tim. + +From cary.millsap@hotsos.com Fri Sep 13 07:32:06 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8D6W1C04656 + for ; Fri, 13 Sep 2002 07:32:01 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.21] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 07:32:01 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031891038:20:04710:44; Fri, 13 Sep 2002 04:23:58 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-2.mail.demon.net + id ab2004623; 13 Sep 2002 4:23 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 942A82BF2C + for ; Fri, 13 Sep 2002 00:23:44 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by dolly1.pobox.com (Postfix) with ESMTP id 73C982BF33 + for ; Fri, 13 Sep 2002 00:23:42 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8D4Ndn19584 + for ; Thu, 12 Sep 2002 23:23:39 -0500 +From: "Cary Millsap" +To: "'Tim Bunce'" +Subject: RE: two Oracle parse calls +Date: Thu, 12 Sep 2002 23:23:30 -0500 +Message-ID: <019301c25add$53f5dfd0$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----=_NextPart_000_0194_01C25AB3.6B1FD7D0" +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +In-Reply-To: +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +Content-Length: 36859 +Lines: 1209 + +This is a multi-part message in MIME format. + +------=_NextPart_000_0194_01C25AB3.6B1FD7D0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit + +Well, that was easy. Setting ora_check_sql=>0 does solve the problem. + + + +I now shift into "Please make 0 the default" mode. + + + +Here are the Oracle trace files, by the way, with a splash of color to +illustrate how the Oracle kernel sees what's going on (I hope you have +an HTML mail reader)... + + + +With {ora_check_sql=>1} (or no setting at all), here's what Oracle does +for the application: + + + +===================== + +PARSING IN CURSOR #2 len=44 dep=0 uid=12 oct=3 lid=12 tim=107312018 +hv=1997601641 ad='54af1384' + +select key, fkey, value from t where key=:p1 + +END OF STMT + +PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312018 + +===================== + +PARSING IN CURSOR #1 len=44 dep=0 uid=12 oct=3 lid=12 tim=107312019 +hv=1997601641 ad='54af1384' + +select key, fkey, value from t where key=:p1 + +END OF STMT + +PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312019 + +EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=107312019 + +FETCH #1:c=0,e=0,p=2,cr=3,cu=0,mis=0,r=1,dep=0,og=3,tim=107312019 + + + +The PARSING IN CURSOR section tells us what SQL it is that we're +executing. Each line beginning with "PARSE" is emitted only when Oracle +executes a parse call. There are two. The first is wasted. + + + +Here's the same application with {ora_check_sql=>1} (the official new +default value, I am sure :-)): + + + +===================== + +PARSING IN CURSOR #1 len=44 dep=0 uid=12 oct=3 lid=12 tim=109776065 +hv=1997601641 ad='54af1384' + +select key, fkey, value from t where key=:p1 + +END OF STMT + +PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=109776065 + +EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=109776065 + +FETCH #1:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=3,tim=109776065 + + + +One parse call; problem solved. + + + +Thank you sincerely for your help. + + + + + +Cary Millsap + +Hotsos Enterprises, Ltd. + +http://www.hotsos.com + + + +Upcoming events: + +- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +Honolulu + +- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas + +- Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark + + + + + + + +-----Original Message----- +From: Cary Millsap [mailto:cary.millsap@hotsos.com] +Sent: Thursday, September 12, 2002 11:00 PM +To: 'Tim Bunce' +Subject: RE: two Oracle parse calls + + + +Tim, + + + +Thanks so very much. The attribute ora_check_sql=>0 is new knowledge to +me; this is a nice reward for having written to you. I will test it +either tonight or the first thing tomorrow and then inform you of the +results immediately after that. If it solves the problem, then I will +lobby you to make 0 the default value and probably consider the issue +"problem solved." + + + +Things are very well, thank you. I've been at home with my family now +for over three straight weeks, and we're having a nice time of our lives +these days with the business settling into stride a bit. Tonight is a +big night for me. I've just crossed the line of accepting a preliminary +offer from O'Reilly. This book project has actually been underway for +quite some time now, but as of tonight it's quite a bit more "official." + + + + + +Cary Millsap + +Hotsos Enterprises, Ltd. + +http://www.hotsos.com + + + +Upcoming events: + +- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +Honolulu + +- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas + +- Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark + + + + + + + +-----Original Message----- + +From: Tim Bunce [mailto:Tim.Bunce@pobox.com] + +Sent: Thursday, September 12, 2002 5:58 PM + +To: Cary Millsap + +Cc: tim.bunce@pobox.com + +Subject: two Oracle parse calls + + + +On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap wrote: + +> Tim, + +> + +> How are you doing? I hope you've had a good two years since I saw you +on + +> the Oracle Geek Cruise event. + + + +Yes thanks. And you? + + + +> I've been working on a project this year to construct a book about + +> optimizing Oracle response time. In my research, I've discovered + +> something about the DBI that I didn't expect: it executes two Oracle + +> parse calls for every one that I would expect an efficient DBI layer +to + +> make. I've included my Perl source (below), the Oracle level-12 trace + +> data that shows the sequence of calls it's receiving from the Perl + +> application (below), a level-9 DBI trace from the application + +> (attached), and our version information (below). + +> + +> I was hoping that by showing you this specific data, you could make +the + +> problem go away. + + + +I can only do what OCI lets me do... but within that I'll do what I +can... + + + +I'm not familar with Oracle trace logs so I can't readily intrepret them + +and I'll take what you say at face value. + + + +But I am familar with DBD::Oracle :) and the logs it writes :) + + + +> $sth = $dbh->prepare(q(select key, fkey, value from t where key=?)); + +> $sth->execute($key); + + + + + + -> prepare for DBD::Oracle::db (DBI::db=HASH(0x8235b34)~0x8235a74 +'select key, fkey, value from t where key=?') + + dbd_preparse scanned 1 distinct placeholders + +OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=SUCCESS + +OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from t where +key=:p1',44,1,0)=SUCCESS + +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)=SUCCES +S + + dbd_st_prepare'd sql SELECT + + dbd_describe SELECT (EXPLICIT, lb 80)... + +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=SUCCESS + + dbd_describe'd 3 columns (row bytes: 76 max, 40 est avg, cache: 231) + + <- prepare= DBI::st=HASH(0x8240fe0) at ex1.pl line 50 + + -> execute for DBD::Oracle::st (DBI::st=HASH(0x8240fe0)~0x8240fb0 +'8542') + +OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x826cd78,4,1,0x826c +b6e,(nil),0x826cb6c,0,(nil),2)=SUCCESS + +OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40,0x401d +a090)=SUCCESS + + bind :p1 done with ftype 1 + + dbd_st_execute SELECT (out0, lob0)... + + in ':p1' [0,0]: len 4, ind 0 + +OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=SUCCESS + +OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec)=SUCCE +SS + + dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0) + + <- execute= '0E0' at ex1.pl line 51 + + + +Given those OCI calls, what is DBD::Oracle doing that it shouldn't? + + + +I'd guess that it's something to do with the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY) + +call that prepare() does. + + + +It doesn't do that for non-select statements so you could check if + +non-selects also have two parse calls. + + + +Also try doing + + $sth = $dbh->prepare(q(select key, fkey, value from t where key=?), { +ora_check_sql=> 0 }); + + + +which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till after the + +main OCIStmtExecute(). In that case the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY) + +is possibly redundant and could be removed (but Oracle ought to detect +that + +anyway and not make a round-trip for it, and certainly not call parse). + + + +If non-selects only have one parse call but ora_check_sql=>0 doesn't + +fix selects, then I might be able to do a simple patch to avoid the + +OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if ora_check_sql=>0. + + + +Then the issue will be: should ora_check_sql=>0 be the default... + + + +Tim. + + + +p.s. I'd love a copy of your book when it's ready! + + +------=_NextPart_000_0194_01C25AB3.6B1FD7D0 +Content-Type: text/html; + charset="us-ascii" +Content-Transfer-Encoding: quoted-printable + + + + + + + + + + + + + + + +
+ +

Well, that was easy. Setting ora_check_sql=3D>0 = +does solve the +problem.

+ +

 

+ +

I now shift into "Please make 0 the = +default" mode.

+ +

 

+ +

Here are the Oracle trace files, by the way, with a = +splash +of color to illustrate how the Oracle kernel sees what’s going on = +(I hope +you have an HTML mail reader)...

+ +

 

+ +

With {ora_check_sql=3D>1} (or no setting at all), = +here’s +what Oracle does for the application:

+ +

 

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR #2 len=3D44 dep=3D0 uid=3D12 = +oct=3D3 lid=3D12 tim=3D107312018 = +hv=3D1997601641 ad=3D'54af1384'

+ +

select key, fkey, value from t where = +key=3D:p1

+ +

END OF STMT

+ +

PARSE = +#2:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312018

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR #1 len=3D44 dep=3D0 uid=3D12 = +oct=3D3 lid=3D12 tim=3D107312019 = +hv=3D1997601641 +ad=3D'54af1384'

+ +

select key, fkey, value from t where = +key=3D:p1

+ +

END OF = +STMT

+ +

PARSE = +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312019

+ +

EXEC = +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D107= +312019

+ +

FETCH = +#1:c=3D0,e=3D0,p=3D2,cr=3D3,cu=3D0,mis=3D0,r=3D1,dep=3D0,og=3D3,tim=3D107= +312019

+ +

 

+ +

The PARSING IN CURSOR section tells us what SQL it is = +that +we’re executing. Each line beginning with “PARSE” is = +emitted +only when Oracle executes a parse call. There are two. The first is = +wasted.

+ +

 

+ +

Here’s the same application with = +{ora_check_sql=3D>1} (the official new = +default value, I +am sure J):

+ +

 

+ +

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

+ +

PARSING IN CURSOR #1 len=3D44 = +dep=3D0 uid=3D12 +oct=3D3 lid=3D12 tim=3D109776065 hv=3D1997601641 = +ad=3D'54af1384'

+ +

select key, fkey, value from = +t where +key=3D:p1

+ +

END OF STMT

+ +

PARSE = +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D109= +776065

+ +

EXEC = +#1:c=3D0,e=3D0,p=3D0,cr=3D0,cu=3D0,mis=3D0,r=3D0,dep=3D0,og=3D3,tim=3D109= +776065

+ +

FETCH = +#1:c=3D0,e=3D0,p=3D0,cr=3D3,cu=3D0,mis=3D0,r=3D1,dep=3D0,og=3D3,tim=3D109= +776065

+ +

 

+ +

One parse call; problem solved.

+ +

 

+ +

Thank you sincerely for your help.

+ +

 

+ +

 

+ +

Cary = +Millsap

+ +

Hotsos Enterprises, Ltd.

+ +

http://www.hotsos.com

+ +

 

+ +

Upcoming events:

+ +

- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu

+ +

- 2003 Hotsos Symposium on Oracle® System = +Performance, +Feb 9-12 Dallas

+ +

- Next event: Miracle Database Forum, Sep 20-22 = +Middelfart Denmark

+ +

 

+ +

 

+ +

 

+ +

-----Original Message-----
+From: Cary Millsap [mailto:cary.millsap@hotsos.com]
+Sent: Thursday, September 12, 2002 11:00 PM
+To: 'Tim Bunce'
+Subject: RE: two Oracle parse calls

+ +

 

+ +

Tim,

+ +

 

+ +

Thanks so very much. The attribute ora_check_sql=3D>0 is new = +knowledge +to me; this is a nice reward for having written to you. I will test it = +either +tonight or the first thing tomorrow and then inform you of the results +immediately after that. If it solves the problem, then I will lobby you = +to make +0 the default value and probably consider the issue "problem = +solved."

+ +

 

+ +

Things are very well, thank you. I've been at home with my = +family now +for over three straight weeks, and we're having a nice time of our lives = +these +days with the business settling into stride a bit. Tonight is a big = +night for +me. I've just crossed the line of accepting a preliminary offer from = +O'Reilly. +This book project has actually been underway for quite some time now, = +but as of +tonight it's quite a bit more "official."

+ +

 

+ +

 

+ +

Cary Millsap

+ +

Hotsos Enterprises, Ltd.

+ +

http://www.hotsos.com

+ +

 

+ +

Upcoming events:

+ +

- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec = +9-11 +Honolulu

+ +

- 2003 Hotsos Symposium on Oracle® System Performance, Feb = +9-12 +Dallas

+ +

- Next event: Miracle Database Forum, Sep 20-22 Middelfart = +Denmark

+ +

 

+ +

 

+ +

 

+ +

-----Original Message-----

+ +

From: Tim Bunce [mailto:Tim.Bunce@pobox.com]

+ +

Sent: Thursday, September 12, 2002 5:58 PM

+ +

To: Cary Millsap

+ +

Cc: tim.bunce@pobox.com

+ +

Subject: two Oracle parse calls

+ +

 

+ +

On Thu, Sep 12, 2002 at 05:21:17PM -0500, Cary Millsap = +wrote:

+ +

> Tim,

+ +

>

+ +

> How are you doing? I hope you've had a good two years since = +I saw +you on

+ +

> the Oracle Geek Cruise event.

+ +

 

+ +

Yes thanks. And you?

+ +

 

+ +

> I've been working on a project this year to construct a = +book about

+ +

> optimizing Oracle response time. In my research, I've = +discovered

+ +

> something about the DBI that I didn't expect: it executes = +two +Oracle

+ +

> parse calls for every one that I would expect an efficient = +DBI +layer to

+ +

> make. I've included my Perl source (below), the Oracle = +level-12 +trace

+ +

> data that shows the sequence of calls it's receiving from = +the Perl

+ +

> application (below), a level-9 DBI trace from the = +application

+ +

> (attached), and our version information = +(below).

+ +

>

+ +

> I was hoping that by showing you this specific data, you = +could +make the

+ +

> problem go away.

+ +

 

+ +

I can only do what OCI lets me do... but within that I'll do = +what I +can...

+ +

 

+ +

I'm not familar with Oracle trace logs so I can't readily = +intrepret +them

+ +

and I'll take what you say at face value.

+ +

 

+ +

But I am familar with DBD::Oracle :) and the logs it writes = +:)

+ +

 

+ +

> $sth =3D $dbh->prepare(q(select key, fkey, value from t = +where +key=3D?));

+ +

> $sth->execute($key);

+ +

 

+ +

 

+ +

    -> prepare for DBD::Oracle::db +(DBI::db=3DHASH(0x8235b34)~0x8235a74 'select key, fkey, value from t = +where +key=3D?')

+ +

    dbd_preparse scanned 1 distinct = +placeholders

+ +

OCIHandleAlloc(0x82465d8,0x826cae8,OCI_HTYPE_STMT,0,(nil))=3DSUCC= +ESS

+ +

OCIStmtPrepare(0x826e4a0,0x82559ec,'select key, fkey, value from = +t +where key=3D:p1',44,1,0)=3DSUCCESS

+ +

OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0x826caec,(nil),24,0x82559ec)= +=3DSUCCESS

+ +

    dbd_st_prepare'd sql SELECT

+ +

    dbd_describe SELECT (EXPLICIT, lb = +80)...

+ +

OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),16)=3D= +SUCCESS

+ +

    dbd_describe'd 3 columns (row bytes: 76 max, = +40 est +avg, cache: 231)

+ +

    <- prepare=3D DBI::st=3DHASH(0x8240fe0) at = +ex1.pl +line 50

+ +

    -> execute for DBD::Oracle::st +(DBI::st=3DHASH(0x8240fe0)~0x8240fb0 '8542')

+ +

OCIBindByName(0x826e4a0,0x826cb5c,0x82559ec,":p1",3,0x8= +26cd78,4,1,0x826cb6e,(nil),0x826cb6c,0,(nil),2)=3DSUCCESS + +

OCIBindDynamic(0x826dc40,0x82559ec,0x826cb40,0x401d9f60,0x826cb40= +,0x401da090)=3DSUCCESS

+ +

       bind :p1 done with ftype = +1

+ +

    dbd_st_execute SELECT (out0, = +lob0)...

+ +

       in  ':p1' [0,0]: = +len  4, +ind 0

+ +

OCIStmtExecute(0x82557c4,0x826e4a0,0x82559ec,0,0,(nil),(nil),0)=3D= +SUCCESS

+ +

OCIAttrGet(0x826e4a0,OCI_HTYPE_STMT,0xbffff65a,(nil),10,0x82559ec= +)=3DSUCCESS

+ +

    dbd_st_execute SELECT returned (SUCCESS, = +rpc0, fn4, +out0)

+ +

    <- execute=3D '0E0' at ex1.pl line = +51

+ +

 

+ +

Given those OCI calls, what is DBD::Oracle doing that it = +shouldn't?

+ +

 

+ +

I'd guess that it's something to do with the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY)

+ +

call that prepare() does.

+ +

 

+ +

It doesn't do that for non-select statements so you could check = +if

+ +

non-selects also have two parse calls.

+ +

 

+ +

Also try doing

+ +

  $sth =3D $dbh->prepare(q(select key, fkey, value from = +t where +key=3D?), { ora_check_sql=3D> 0 });

+ +

 

+ +

which refers the OCIStmtExecute(..., OCI_DESCRIBE_ONLY) till = +after the

+ +

main OCIStmtExecute(). In that case the OCIStmtExecute(..., +OCI_DESCRIBE_ONLY)

+ +

is possibly redundant and could be removed (but Oracle ought to = +detect +that

+ +

anyway and not make a round-trip for it, and certainly not call = +parse).

+ +

 

+ +

If non-selects only have one parse call but = +ora_check_sql=3D>0 doesn't

+ +

fix selects, then I might be able to do a simple patch to avoid = +the

+ +

OCIStmtExecute(..., OCI_DESCRIBE_ONLY) if = +ora_check_sql=3D>0.

+ +

 

+ +

Then the issue will be: should ora_check_sql=3D>0 be the = +default...

+ +

 

+ +

Tim.

+ +

 

+ +

p.s. I'd love a copy of your book when it's = +ready!

+ +
+ + + + + +------=_NextPart_000_0194_01C25AB3.6B1FD7D0-- + + +From cary.millsap@hotsos.com Fri Sep 13 21:17:44 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DKHhC12417 + for ; Fri, 13 Sep 2002 21:17:43 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.59] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 21:17:43 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031946929:20:18513:70; Fri, 13 Sep 2002 19:55:29 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-2.mail.demon.net + id aa2018248; 13 Sep 2002 19:55 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 7FC402C01F + for ; Fri, 13 Sep 2002 15:55:06 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by dolly1.pobox.com (Postfix) with ESMTP id 76A5E2BFE1 + for ; Fri, 13 Sep 2002 15:55:05 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8DJt4n26736 + for ; Fri, 13 Sep 2002 14:55:04 -0500 +From: "Cary Millsap" +To: "Tim Bunce" +Subject: A little more data +Date: Fri, 13 Sep 2002 14:54:56 -0500 +Message-ID: <020201c25b5f$7248a760$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----=_NextPart_000_0203_01C25B35.89729F60" +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 4948 +Lines: 166 + +This is a multi-part message in MIME format. + +------=_NextPart_000_0203_01C25B35.89729F60 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit + +Tim, + + + +I hope this is helpful. I have noticed that I cannot produce the +extra-parse problem on my 8.1.7 laptop database, no matter what the +setting of ora_check_sql. All of the data I've sent you is from our +8.1.6 Linux database. If you really needed it, I could produce level-9 +DBI trace data from identical tests on both platforms, but I won't spend +the time doing that unless you say it will help... + + + +Cary Millsap +Hotsos Enterprises, Ltd. +http://www.hotsos.com + +Upcoming events: +- Hotsos Clinic , Oct 1-3 San +Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu +- 2003 Hotsos Symposium on +OracleR System Performance, Feb 9-12 Dallas +- Next event: Miracle Database Forum , Sep +20-22 Middlefart Denmark + + + + +------=_NextPart_000_0203_01C25B35.89729F60 +Content-Type: text/html; + charset="us-ascii" +Content-Transfer-Encoding: quoted-printable + + + + + + + + + + + + + + + +
+ +

Tim,

+ +

 

+ +

I hope this is helpful… I have noticed that I = +cannot +produce the extra-parse problem on my 8.1.7 laptop database, no matter = +what the +setting of ora_check_sql. All of the data I’ve sent you is from = +our 8.1.6 +Linux database. If you really needed it, I could produce level-9 DBI = +trace data +from identical tests on both platforms, but I won’t spend the time = +doing +that unless you say it will help...

+ +

 

+ +

Cary = +Millsap
+Hotsos Enterprises, Ltd.
+http://www.hotsos.com
+
+Upcoming events:
+- Hotsos Clinic, = +Oct +1–3 San Francisco, Oct 15–17 = +Dallas, Dec +9–11 Honolulu
+- 2003 Hotsos = +Symposium on +Oracle® System Performance, Feb 9–12 = +Dallas
+- Next event: Miracle Database = +Forum, Sep +20–22 Middlefart Denmark

+ +

 

+ +
+ + + + + +------=_NextPart_000_0203_01C25B35.89729F60-- + + +From timbo@dansat.data-plan.com Fri Sep 13 22:05:30 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DL5UC12942 + for ; Fri, 13 Sep 2002 22:05:30 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 22:05:30 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031948458:10:20432:5; Fri, 13 Sep 2002 20:20:58 GMT +Received: from cali-2.pobox.com ([64.71.166.115]) by punt-1.mail.demon.net + id aa1020174; 13 Sep 2002 20:20 GMT +Received: from cali-2.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-2.pobox.com (Postfix) with ESMTP id 8A60E3E659 + for ; Fri, 13 Sep 2002 16:20:41 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) + by cali-2.pobox.com (Postfix) with SMTP id CAC663E685 + for ; Fri, 13 Sep 2002 16:20:36 -0400 (EDT) +Received: (qmail 37861 messnum 258096 invoked from network[159.134.164.124/p124.as1.limerick1.eircom.net]); 13 Sep 2002 20:20:35 -0000 +Received: from p124.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.164.124) + by mail05.svc.cra.dublin.eircom.net (qp 37861) with SMTP; 13 Sep 2002 20:20:35 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g8DKKhu12535; + Fri, 13 Sep 2002 21:20:43 +0100 (BST) + (envelope-from timbo) +Date: Fri, 13 Sep 2002 21:20:43 +0100 +From: Tim Bunce +To: Cary Millsap +Cc: Tim Bunce +Subject: Re: A little more data +Message-ID: <20020913202043.GO539@dansat.data-plan.com> +References: <020201c25b5f$7248a760$6501a8c0@CVMLAP01> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <020201c25b5f$7248a760$6501a8c0@CVMLAP01> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 1098 +Lines: 34 + +If they're using the same version of DBD::Oracle then +the change must me on the sever side. Maybe Oracle's +woken up to the fact they don't need a second parse! + +Tim. + +On Fri, Sep 13, 2002 at 02:54:56PM -0500, Cary Millsap wrote: +> Tim, +> +> +> +> I hope this is helpful. I have noticed that I cannot produce the +> extra-parse problem on my 8.1.7 laptop database, no matter what the +> setting of ora_check_sql. All of the data I've sent you is from our +> 8.1.6 Linux database. If you really needed it, I could produce level-9 +> DBI trace data from identical tests on both platforms, but I won't spend +> the time doing that unless you say it will help... +> +> +> +> Cary Millsap +> Hotsos Enterprises, Ltd. +> http://www.hotsos.com +> +> Upcoming events: +> - Hotsos Clinic , Oct 1-3 San +> Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu +> - 2003 Hotsos Symposium on +> OracleR System Performance, Feb 9-12 Dallas +> - Next event: Miracle Database Forum , Sep +> 20-22 Middlefart Denmark +> +> +> + +From cary.millsap@hotsos.com Fri Sep 13 22:04:47 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DL4kC12684 + for ; Fri, 13 Sep 2002 22:04:46 +0100 (BST) + (envelope-from cary.millsap@hotsos.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 22:04:46 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031949629:20:13745:23; Fri, 13 Sep 2002 20:40:29 GMT +Received: from cali-1.pobox.com ([64.71.166.114]) by punt-2.mail.demon.net + id aa2013849; 13 Sep 2002 20:40 GMT +Received: from cali-1.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-1.pobox.com (Postfix) with ESMTP id 7D90A3E650 + for ; Fri, 13 Sep 2002 16:40:20 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from www.hotsos.com (unknown [63.145.61.17]) + by cali-1.pobox.com (Postfix) with ESMTP id 785AB3E642 + for ; Fri, 13 Sep 2002 16:40:19 -0400 (EDT) +Received: from CVMLAP01 (66-169-133-3.ftwrth.tx.charter.com [66.169.133.3]) + (authenticated (0 bits)) + by www.hotsos.com (8.11.3/8.11.0) with ESMTP id g8DKeIn27106 + for ; Fri, 13 Sep 2002 15:40:18 -0500 +From: "Cary Millsap" +To: "'Tim Bunce'" +Subject: RE: A little more data +Date: Fri, 13 Sep 2002 15:40:10 -0500 +Message-ID: <020d01c25b65$c4056e70$6501a8c0@CVMLAP01> +MIME-Version: 1.0 +Content-Type: text/plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook, Build 10.0.3416 +Importance: Normal +In-Reply-To: <20020913202043.GO539@dansat.data-plan.com> +X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 +Status: RO +X-Status: A +Content-Length: 1999 +Lines: 63 + +Well, it's 1.06 on my Windows machine (the most up-to-date version +available from ActiveState), and 1.12 on Linux. Not exactly a fair test, +but interesting that (admitting now that there's a new degree of freedom +running loose amid the test) "the older version performs better than the +newer one." :) That's certainly not a fair statement if the diff between +8.1.6 and 8.1.7 OCI is the root cause of the behavior difference. + + +Cary Millsap +Hotsos Enterprises, Ltd. +http://www.hotsos.com + +Upcoming events: +- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +Honolulu +- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +- Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark + + + +-----Original Message----- +From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +Sent: Friday, September 13, 2002 3:21 PM +To: Cary Millsap +Cc: Tim Bunce +Subject: Re: A little more data + +If they're using the same version of DBD::Oracle then +the change must me on the sever side. Maybe Oracle's +woken up to the fact they don't need a second parse! + +Tim. + +On Fri, Sep 13, 2002 at 02:54:56PM -0500, Cary Millsap wrote: +> Tim, +> +> +> +> I hope this is helpful. I have noticed that I cannot produce the +> extra-parse problem on my 8.1.7 laptop database, no matter what the +> setting of ora_check_sql. All of the data I've sent you is from our +> 8.1.6 Linux database. If you really needed it, I could produce level-9 +> DBI trace data from identical tests on both platforms, but I won't +spend +> the time doing that unless you say it will help... +> +> +> +> Cary Millsap +> Hotsos Enterprises, Ltd. +> http://www.hotsos.com +> +> Upcoming events: +> - Hotsos Clinic , Oct 1-3 San +> Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu +> - 2003 Hotsos Symposium on +> OracleR System Performance, Feb 9-12 Dallas +> - Next event: Miracle Database Forum , Sep +> 20-22 Middlefart Denmark +> +> +> + + +From timbo@dansat.data-plan.com Fri Sep 13 23:21:32 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g8DMLWC13692 + for ; Fri, 13 Sep 2002 23:21:32 +0100 (BST) + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.58] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 13 Sep 2002 23:21:32 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1031952887:10:13297:20; Fri, 13 Sep 2002 21:34:47 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1118141; 13 Sep 2002 21:34 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id C7D482BF23 + for ; Fri, 13 Sep 2002 17:34:38 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) + by dolly1.pobox.com (Postfix) with SMTP id 8352A2BF6C + for ; Fri, 13 Sep 2002 17:34:36 -0400 (EDT) +Received: (qmail 5093 messnum 521124 invoked from network[159.134.164.134/p134.as1.limerick1.eircom.net]); 13 Sep 2002 21:34:34 -0000 +Received: from p134.as1.limerick1.eircom.net (HELO dansat.data-plan.com) (159.134.164.134) + by mail00.svc.cra.dublin.eircom.net (qp 5093) with SMTP; 13 Sep 2002 21:34:34 -0000 +Received: (from timbo@localhost) + by dansat.data-plan.com (8.11.6/8.11.6) id g8DLYeI13070; + Fri, 13 Sep 2002 22:34:40 +0100 (BST) + (envelope-from timbo) +Date: Fri, 13 Sep 2002 22:34:40 +0100 +From: Tim Bunce +To: Cary Millsap +Cc: "'Tim Bunce'" +Subject: Re: A little more data +Message-ID: <20020913213440.GS539@dansat.data-plan.com> +References: <20020913202043.GO539@dansat.data-plan.com> <020d01c25b65$c4056e70$6501a8c0@CVMLAP01> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <020d01c25b65$c4056e70$6501a8c0@CVMLAP01> +User-Agent: Mutt/1.4i +Status: O +Content-Length: 2282 +Lines: 69 + +According my RCS the default for ora_check_sql changed from 0 to 1 +around version 1.03. + +Tim. + +On Fri, Sep 13, 2002 at 03:40:10PM -0500, Cary Millsap wrote: +> Well, it's 1.06 on my Windows machine (the most up-to-date version +> available from ActiveState), and 1.12 on Linux. Not exactly a fair test, +> but interesting that (admitting now that there's a new degree of freedom +> running loose amid the test) "the older version performs better than the +> newer one." :) That's certainly not a fair statement if the diff between +> 8.1.6 and 8.1.7 OCI is the root cause of the behavior difference. +> +> +> Cary Millsap +> Hotsos Enterprises, Ltd. +> http://www.hotsos.com +> +> Upcoming events: +> - Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 +> Honolulu +> - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas +> - Next event: Miracle Database Forum, Sep 20-22 Middelfart Denmark +> +> +> +> -----Original Message----- +> From: Tim Bunce [mailto:Tim.Bunce@pobox.com] +> Sent: Friday, September 13, 2002 3:21 PM +> To: Cary Millsap +> Cc: Tim Bunce +> Subject: Re: A little more data +> +> If they're using the same version of DBD::Oracle then +> the change must me on the sever side. Maybe Oracle's +> woken up to the fact they don't need a second parse! +> +> Tim. +> +> On Fri, Sep 13, 2002 at 02:54:56PM -0500, Cary Millsap wrote: +> > Tim, +> > +> > +> > +> > I hope this is helpful. I have noticed that I cannot produce the +> > extra-parse problem on my 8.1.7 laptop database, no matter what the +> > setting of ora_check_sql. All of the data I've sent you is from our +> > 8.1.6 Linux database. If you really needed it, I could produce level-9 +> > DBI trace data from identical tests on both platforms, but I won't +> spend +> > the time doing that unless you say it will help... +> > +> > +> > +> > Cary Millsap +> > Hotsos Enterprises, Ltd. +> > http://www.hotsos.com +> > +> > Upcoming events: +> > - Hotsos Clinic , Oct 1-3 San +> > Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu +> > - 2003 Hotsos Symposium on +> > OracleR System Performance, Feb 9-12 Dallas +> > - Next event: Miracle Database Forum , Sep +> > 20-22 Middlefart Denmark +> > +> > +> > +> + diff --git a/err_unsorted/err_xml.msg b/err_unsorted/err_xml.msg new file mode 100644 index 00000000..7a60a0cb --- /dev/null +++ b/err_unsorted/err_xml.msg @@ -0,0 +1,118 @@ +From dbi-users-return-19852-Tim.Bunce=pobox.com@perl.org Fri Aug 15 14:41:14 2003 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id h7FDe3MA043557 + for ; Fri, 15 Aug 2003 14:41:13 +0100 (BST) + (envelope-from dbi-users-return-19852-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 15 Aug 2003 14:41:13 +0100 (BST) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 19nc4X-0006LQ-BC; + Fri, 15 Aug 2003 10:44:41 +0000 +Received: from [207.106.49.22] (helo=dolly1.pobox.com) + by punt-3.mail.demon.net with esmtp id 19nc4X-0006LQ-BC + for pobox@dbi.demon.co.uk; Fri, 15 Aug 2003 10:44:41 +0000 +Received: from dolly1.pobox.com (localhost[127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 16F6B21C13B + for ; Fri, 15 Aug 2003 06:44:41 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.develooper.com[63.251.223.166]) + by dolly1.pobox.com (Postfix) with SMTP id 021F121C36F + for ; Fri, 15 Aug 2003 06:44:40 -0400 (EDT) +Received: (qmail 78180 invoked by uid 1005); 15 Aug 2003 10:44:34 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 71287 invoked by uid 76); 15 Aug 2003 10:32:13 -0000 +Delivered-To: dbi-users@perl.org +Received-SPF: unknown (domain of sender andyhassall@yahoo.com does not designate mailers: NXDOMAIN) +Message-ID: <20030815103200.24313.qmail@web9605.mail.yahoo.com> +Date: Fri, 15 Aug 2003 11:32:00 +0100 (BST) +From: =?iso-8859-1?q?Andy=20Hassall?= +Reply-To: andy@andyh.co.uk +Subject: Re: ERROR OCIDefineObject call needed but not implemented yet using XMLElement function +To: Susan Cassidy , dbi-users@perl.org +In-Reply-To: +MIME-Version: 1.0 +Content-Type: text/plain; charset=iso-8859-1 +X-SMTPD: qpsmtpd/0.27-dev, http://develooper.com/code/qpsmtpd/ +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=-0.8 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Content-Transfer-Encoding: 8bit +X-MIME-Autoconverted: from quoted-printable to 8bit by dansat.data-plan.com id h7FDe3MA043557 +Status: RO +Content-Length: 2299 +Lines: 65 + + --- Susan Cassidy wrote: > I am using DBD::Oracle. +I was on version 1.12, then I installed version +> 1.14, with the same result. +> +> This is Oracle 9.2.0. +> +> I have this select statement that works fine from SQL*Plus: +> +> select XMLElement("Sequences", +> XMLElement("Sequence", +> XMLATTRIBUTES ( b.local_name AS "ic-acckey", +> b.mol_type AS "molecule", +> n.seq_name AS "title"))) +> from gcg_bioseq b, gcg_annot_seq_name a, gcg_seq_name n +> where +> b.local_name = 'K00306' and +> b.seq_status = 'D' and +> b.seq_oid = a.seq_oid and +> a.seq_name_oid = n.seq_name_oid and +> n.name_type = 'LOCUS' +> +> +> When I run it via DBI/DBD I get this (trace level 2): +> +> DBI 1.32-nothread dispatch trace level set to 2 +> Note: perl is running without the recommended perl -w option +> -> prepare for DBD::Oracle::db (DBI::db=HASH(0x1b2314)~0x122bec ' +[snip +> Field 1 has an Oracle type (108) which is not explicitly supported +> fbh 1: +> +'XMLELEMENT("SEQUENCES",XMLELEMENT("SEQUENCE",XMLATTRIBUTES(B.LOCAL_NAMEAS"IC-ACCKEY",B.MOL_TYPEAS"MOLECULE",N.SEQ_NAMEAS"TITLE")))' +[snip] +> Error: prepare failed +> at line 56, error: ERROR OCIDefineObject call needed but not +> implemented yet +> +> Is there any other workaround for this than wrapping this up in a PL/SQL +> function? + + Don't rely on the implicit conversion to a string type that is done when +SQL*Plus displays an XMLElement; add .getClobVal() to the end of the +statement to retrieve it as a CLOB rather than the XMLElement object type +(which DBD::Oracle doesn't accept). + + i.e. + +select XMLElement("Sequences", + XMLElement("Sequence", + XMLATTRIBUTES ( b.local_name AS "ic-acckey", + b.mol_type AS "molecule", + n.seq_name AS "title"))).getClobVal() + from ... + + (or getStringVal() for a VARCHAR2) + +===== +-- +Andy Hassall (andy@andyh.org) icq(5747695) http://www.andyh.co.uk +http://www.andyhsoftware.co.uk/space | disk usage analysis tool + +________________________________________________________________________ +Want to chat instantly with your online friends? Get the FREE Yahoo! +Messenger http://uk.messenger.yahoo.com/ + + diff --git a/err_unsorted/err_xml2.msg b/err_unsorted/err_xml2.msg new file mode 100644 index 00000000..3bb291c5 --- /dev/null +++ b/err_unsorted/err_xml2.msg @@ -0,0 +1,700 @@ +From dbi-dev-return-2935-Tim.Bunce=pobox.com@perl.org Fri Jan 30 12:50:15 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i0UClt3q069307 + for ; Fri, 30 Jan 2004 12:50:14 GMT + (envelope-from dbi-dev-return-2935-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 30 Jan 2004 12:50:14 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AmWGJ-00057X-AG; + Fri, 30 Jan 2004 10:52:35 +0000 +Received: from [194.217.242.210] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1AmWGJ-00057X-AG + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 10:52:35 +0000 +Received: from [207.8.214.3] (helo=puzzle.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1AmWGI-0007XK-P3 + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 10:52:34 +0000 +Received: from puzzle.pobox.com (localhost [127.0.0.1]) + by puzzle.pobox.com (Postfix) with ESMTP id 029E8701C6 + for ; Fri, 30 Jan 2004 05:52:34 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by puzzle.pobox.com (Postfix) with ESMTP id 12ABF701C1 + for ; Fri, 30 Jan 2004 05:52:30 -0500 (EST) +Received: from onion.perl.org (onion.develooper.com [63.251.223.166]) + by puzzle.pobox.com (Postfix) with SMTP + for ; Fri, 30 Jan 2004 05:51:10 -0500 (EST) +Received: (qmail 33345 invoked by uid 1005); 30 Jan 2004 10:50:36 -0000 +Mailing-List: contact dbi-dev-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-dev@perl.org +Received: (qmail 33175 invoked by uid 76); 30 Jan 2004 10:50:26 -0000 +Received: from qmailr@one.develooper.com (HELO ran-out.mx.develooper.com) (64.81.84.115) by onion.perl.org (qpsmtpd/0.26) with SMTP; Fri, 30 Jan 2004 02:50:25 -0800 +Received: (qmail 21117 invoked by uid 225); 30 Jan 2004 10:48:52 -0000 +Delivered-To: dbi-dev@perl.org +Received: (qmail 21080 invoked by uid 507); 30 Jan 2004 10:48:49 -0000 +Received: from [212.89.121.1] (HELO babel.morphochem.de) (212.89.121.1) by one.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Fri, 30 Jan 2004 02:48:46 -0800 +Received: (qmail 31958 invoked from network); 30 Jan 2004 11:50:38 -0000 +Received: from unknown (HELO mail.morphochem.de) (10.1.15.5) by 212.89.121.1 with SMTP; 30 Jan 2004 11:50:38 -0000 +Received: (qmail 6921 invoked from network); 30 Jan 2004 10:49:58 -0000 +Received: from localhost.morphochem.de (HELO mail) ([127.0.0.1]) (envelope-sender ) by localhost.morphochem.de (qmail-ldap-1.03) with SMTP for ; 30 Jan 2004 10:49:58 -0000 +Received: from mars.MORPHOCHEM.de ([10.1.8.130]) by mail.morphochem.de (MailMonitor for SMTP v1.2.1 ) ; Fri, 30 Jan 2004 11:49:58 +0100 (CET) +Subject: DBD-Oracle and XMLType +From: Hendrik Fuss +To: "dbi-dev@perl.org" +Content-Type: multipart/mixed; boundary="=-fkyM33WAvQ5xV0uCPeSD" +X-Mailer: Ximian Evolution 1.0.8 +Date: 30 Jan 2004 11:41:31 +0100 +Message-Id: <1075459292.7305.46.camel@mars> +Mime-Version: 1.0 +X-Spam-Check-By: one.develooper.com +X-Spam-Status: No, hits=0.5 required=7.0 tests=MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,TO_ADDRESS_EQ_REAL version=2.44 +X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ +Status: RO +X-Status: A +Content-Length: 8148 +Lines: 302 + +--=-fkyM33WAvQ5xV0uCPeSD +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +Hi everyone, + +It's been a while since I last posted here. In September 2003 I was +trying to add support for binding XMLType objects to DBD-Oracle, so that +you could easily insert large (ie >4k) XML data into an XMLType table. + +Unfortunately my employer fired me in October 2003 and in the remaining +time I had to work on other projects, so I wasn't able to complete the +DBD project. Since I won't have access to an oracle database from now +on, I thought the least I can do is to provide my code as it is to the +list. Blame German economy. :-( + +The attached patch (based on DBD-Oracle 1.15) enables you to upload +XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.c +I added a function dbd_rebind_ph_nty for that purpose. You need to +create that XMLType object first using the C function +createxmlfromstring in xml.c. + +The XMLType object is either created from an OCIString or from a +temporary CLOB depending on the length of the source string. Have a look +at the bottom of ociap.h, all the (undocumented) XMLType functions are +there, and there are also some constants in oci.h. + +I'm not sure if the CLOB code currently works. + +Here is another code fragment: + + my $xml =3D createxml($dbh, 'Test document'); + my $sth =3D $dbh->prepare('INSERT INTO xml_type VALUES (?)'); + $sth->bind_param(1, $xml, { ora_type =3D> 108 }); # SQLT_NTY + $sth->execute(); + +Please note that this code is really just early development, which I +wouldn't publish under normal circumstances. :) I just hope it might me +useful to someone. + +Well then, time to say goodbye +thanks to Tim and everyone who contributed to dbi for a great piece of +software + +Cheers, +Hendrik + +--=20 +hendrik fu=DF + +morphochem AG +gmunder str. 37-37a +81379 muenchen + +tel. ++49-89-78005-0 +fax ++49-89-78005-555 + +hendrik.fuss@morphochem.de +http://www.morphochem.de + +--=-fkyM33WAvQ5xV0uCPeSD +Content-Description: +Content-Disposition: attachment; filename=dbdimp.c.diff +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; charset=ISO-8859-1 + +151a152 +> case 108: /* SQLT_NTY */ +992a994,996 +> case SQL_UDT: +> return 108; /* Oracle NTY */ +>=20 +1004a1009,1072 +> static int +> dbd_rebind_ph_nty(sth, imp_sth, phs) +> SV* sth; +> imp_sth_t *imp_sth; +> phs_t *phs; +> { +> OCIType *tdo =3D NULL; +> sword status; +> SV* ptr; +>=20 +> if (phs->is_inout) +> croak("OUT binding for NTY is currently unsupported"); +>=20 +> /* ensure that the value is a support named object type */ +> /* (currently only OCIXMLType*) */ +> if ( sv_isa(phs->sv, "OCIXMLTypePtr") ) { +> OCITypeByName(imp_sth->envhp, imp_sth->errhp, imp_sth->svchp, +> (CONST text*)"SYS", 3, +> (CONST text*)"XMLTYPE", 7, +> (CONST text*)0, 0, +> OCI_DURATION_CALLOUT, OCI_TYPEGET_HEADER, +> &tdo); +>=20 +> ptr =3D SvRV(phs->sv); +> phs->progv =3D (void*) SvIV(ptr); +> phs->maxlen =3D sizeof(OCIXMLType*); +> } +> else +> croak("Unsupported named object type for bind parameter"); +>=20 +>=20 +> /* bind by name */ +>=20 +> OCIBindByName_log_stat(imp_sth->stmhp, &phs->bndhp, imp_sth->errhp, +> (text*)phs->name, (sb4)strlen(phs->name), +> (dvoid *) NULL, /* value supplied in BindObject later */ +> 0, +> (ub2)phs->ftype, 0, +> NULL, +> 0, 0, +> NULL, +> (ub4)OCI_DEFAULT, +> status +> ); +>=20 +> if (status !=3D OCI_SUCCESS) { +> oci_error(sth, imp_sth->errhp, status, "OCIBindByName SQLT_NTY"); +> return 0; +> } +> if (DBIS->debug >=3D 3) +> PerlIO_printf(DBILOGFP, " pp_rebind_ph_nty: END\n"); +>=20 +>=20 +> /* bind the object */ +>=20 +> OCIBindObject(phs->bndhp, imp_sth->errhp, +> (CONST OCIType*)tdo, +> (dvoid **)&phs->progv, +> (ub4*)NULL, +> (dvoid **)NULL, +> (ub4*)NULL); +>=20 +> return 2; +> } +1309a1378,1380 +> case 108: +> done =3D dbd_rebind_ph_nty(sth, imp_sth, phs); +> break; +1331c1403 +< int at_exec =3D (phs->desc_h =3D=3D NULL); +--- +> int at_exec =3D (phs->desc_h =3D=3D NULL) && (phs->ftype !=3D 108); +1419c1491 +< if (SvROK(newvalue) && !IS_DBI_HANDLE(newvalue)) +--- +> if (SvROK(newvalue) && (!IS_DBI_HANDLE(newvalue)) && (sql_type!=3DSQL= +T_NTY)) +1420a1493 +> /* ref allowed for OCIXMLType* */ +2219a2293 +> case SQLT_NTY: sql_fbh.dbtype =3D SQL_UDT; break; + +--=-fkyM33WAvQ5xV0uCPeSD +Content-Disposition: attachment; filename=xml.c +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; name=xml.c; charset=ISO-8859-1 + +#include "oci.h" +#include + +/* This helper function creates an XMLType object from a string source. + * + * The resulting object can be bound to a placeholder, if ora_type =3D> + * SQLT_NTY is specified. + */ + +static void checkerr(errhp, status) +OCIError *errhp; +sword status; +{ + text errbuf[512]; + ub4 buflen; + sb4 errcode; + + switch (status) + { + case OCI_SUCCESS: + break; + case OCI_SUCCESS_WITH_INFO: + printf("Error - OCI_SUCCESS_WITH_INFO\n"); + break; + case OCI_NEED_DATA: + printf("Error - OCI_NEED_DATA\n"); + break; + case OCI_NO_DATA: + printf("Error - OCI_NO_DATA\n"); + break; + case OCI_ERROR: + OCIErrorGet ((dvoid *) errhp, (ub4) 1, (text *) NULL, &errcode, + errbuf, (ub4) sizeof(errbuf), (ub4) OCI_HTYPE_ERROR); + printf("Error - %s\n", errbuf); + exit(1); + break; + case OCI_INVALID_HANDLE: + printf("Error - OCI_INVALID_HANDLE\n"); + break; + case OCI_STILL_EXECUTING: + printf("Error - OCI_STILL_EXECUTE\n"); + break; + case OCI_CONTINUE: + printf("Error - OCI_CONTINUE\n"); + break; + default: + break; + } +} + + +#define MAX_OCISTRING_LEN 32766 + +SV* createxmlfromstring(SV* dbh, char* source) { + OCIXMLType *xml =3D NULL; + ub4 len; + ub1 src_type; + dvoid* src_ptr =3D NULL; + D_imp_dbh(dbh); + SV* sv_dest; + + len =3D strlen(source); + if(len > MAX_OCISTRING_LEN) { + src_type =3D OCI_XMLTYPE_CREATE_CLOB; + + printf("OCIDescriptorAlloc\n"); + checkerr( imp_dbh->errhp, + OCIDescriptorAlloc((dvoid*)imp_dbh->envhp, + (dvoid **)&src_ptr, + (ub4)OCI_DTYPE_LOB, + (size_t)0, + (dvoid**)0) ); + + printf("OCILobCreateTemporary\n"); + checkerr( imp_dbh->errhp, + OCILobCreateTemporary(imp_dbh->svchp, + imp_dbh->errhp,=20 + (OCILobLocator*) src_ptr, + (ub2)0,=20 + SQLCS_IMPLICIT,=20 + OCI_TEMP_CLOB,=20 + OCI_ATTR_NOCACHE,=20 + OCI_DURATION_SESSION) ); + + printf("OCILobWrite\n"); + checkerr (imp_dbh->errhp, + OCILobWriteAppend(imp_dbh->svchp, + imp_dbh->errhp, + (OCILobLocator*) src_ptr, + &len,=20 + (ub1*)source, + len, + OCI_ONE_PIECE, + (dvoid *)0,=20 + (sb4 (*)(dvoid*,dvoid*,ub4*,ub1 *))0, + 0, + SQLCS_IMPLICIT)); + + } else { + src_type =3D OCI_XMLTYPE_CREATE_OCISTRING; + + printf("OCIStringAssignText\n"); + checkerr( imp_dbh->errhp, + OCIStringAssignText(imp_dbh->envhp, + imp_dbh->errhp,=20 + (CONST text*) source,=20 + (ub2) strlen(source), + (OCIString **) &src_ptr) + ); + } + + printf("OCIXMLTypeCreateFromSrc\n"); + checkerr( imp_dbh->errhp, + OCIXMLTypeCreateFromSrc(imp_dbh->svchp, + imp_dbh->errhp, + (OCIDuration)OCI_DURATION_CALLOUT, + (ub1)src_type, + (dvoid *)src_ptr, + (sb4)OCI_IND_NOTNULL, + &xml) + ); + + + /* free temporary resources */ + if( src_type =3D=3D OCI_XMLTYPE_CREATE_CLOB ) { + checkerr( imp_dbh->errhp, + OCILobFreeTemporary(imp_dbh->svchp, imp_dbh->errhp, + (OCILobLocator*) src_ptr) ); + + checkerr( imp_dbh->errhp, + OCIDescriptorFree((dvoid *) src_ptr, (ub4) OCI_DTYPE_LOB) ); + } + + + sv_dest =3D newSViv(0); + sv_setref_pv(sv_dest, "OCIXMLTypePtr", xml); + return sv_dest; +} + +--=-fkyM33WAvQ5xV0uCPeSD-- + + + +From hendrik.fuss@morphochem.de Fri Jan 30 16:56:30 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i0UGsO3v071338 + for ; Fri, 30 Jan 2004 16:56:27 GMT + (envelope-from hendrik.fuss@morphochem.de) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 30 Jan 2004 16:56:27 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AmZJF-0001wN-DK; + Fri, 30 Jan 2004 14:07:49 +0000 +Received: from [194.217.242.211] (helo=lon1-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1AmZJF-0001wN-DK + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 14:07:49 +0000 +Received: from [208.58.1.193] (helo=boggle.pobox.com) + by lon1-hub.mail.demon.net with esmtp id 1AmZJE-0003GM-Bm + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 14:07:48 +0000 +Received: from boggle.pobox.com (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id 334DE30C57 + for ; Fri, 30 Jan 2004 09:07:47 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by boggle.pobox.com (Postfix) with ESMTP id E65B230C2C + for ; Fri, 30 Jan 2004 09:07:45 -0500 (EST) +Received: from babel.morphochem.de (unknown [212.89.121.1]) + by boggle.pobox.com (Postfix) with ESMTP + for ; Fri, 30 Jan 2004 09:07:04 -0500 (EST) +Received: (qmail 29768 invoked from network); 30 Jan 2004 15:10:09 -0000 +Received: from unknown (HELO mail.morphochem.de) (10.1.15.5) + by 212.89.121.1 with SMTP; 30 Jan 2004 15:10:09 -0000 +Received: (qmail 11736 invoked from network); 30 Jan 2004 14:09:30 -0000 +Received: from localhost.morphochem.de (HELO mail) ([127.0.0.1]) + (envelope-sender ) + by localhost.morphochem.de (qmail-ldap-1.03) with SMTP + for ; 30 Jan 2004 14:09:30 -0000 +Received: from mars.MORPHOCHEM.de ([10.1.8.130]) + by mail.morphochem.de (MailMonitor for SMTP v1.2.1 ) ; + Fri, 30 Jan 2004 15:09:30 +0100 (CET) +Subject: Re: DBD-Oracle and XMLType +From: Hendrik Fuss +To: Tim Bunce +Cc: "dbi-dev@perl.org" +In-Reply-To: <20040130133443.GC70215@dansat.data-plan.com> +References: <1075459292.7305.46.camel@mars> + <20040130133443.GC70215@dansat.data-plan.com> +Content-Type: multipart/mixed; boundary="=-Sq1IOPDEhKoqxUKefiS3" +X-Mailer: Ximian Evolution 1.0.8 +Date: 30 Jan 2004 15:01:03 +0100 +Message-Id: <1075471263.7305.73.camel@mars> +Mime-Version: 1.0 +Status: RO +X-Status: A +Content-Length: 5585 +Lines: 196 + + +--=-Sq1IOPDEhKoqxUKefiS3 +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +> > The attached patch (based on DBD-Oracle 1.15) enables you to upload +> > XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.= +c +> > I added a function dbd_rebind_ph_nty for that purpose. You need to +> > create that XMLType object first using the C function +> > createxmlfromstring in xml.c. +>=20 +> I there any chance you could post that as a context diff (diff -u ideally +> or else diff -c)? It's much safer and more useful. Thanks. + +Good idea. Here's a diff -u of dbdimp.c. + +By the way: I have thougt about general support of named types, not just +XMLType, but you need to get the type description (TDO) from somewhere. +My code just checks if the perl variable is a blessed reference of +"OCIXMLTypePtr". + +Also note that my code can't handle downloading of XMLType objects yet. + +best wishes, +Hendrik + +--=20 +hendrik fu=DF + +morphochem AG +gmunder str. 37-37a +81379 muenchen + +tel. ++49-89-78005-0 +fax ++49-89-78005-555 + +hendrik.fuss@morphochem.de +http://www.morphochem.de + +--=-Sq1IOPDEhKoqxUKefiS3 +Content-Description: Context diff for dbdimp.c +Content-Disposition: attachment; filename=dbdimp.c.diff +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; charset=ISO-8859-1 + +--- dbdimp.c.orig 2004-01-30 14:48:55.000000000 +0100 ++++ dbdimp.c 2003-10-07 12:17:17.000000000 +0200 +@@ -1,5 +1,5 @@ + /* +- $Id: dbdimp.c,v 1.1.1.1 2003/10/02 10:45:20 hfuss Exp $ ++ $Id: dbdimp.c,v 1.3 2003/10/07 10:17:17 hfuss Exp $ +=20 + Copyright (c) 1994,1995,1996,1997,1998 Tim Bunce +=20 +@@ -149,6 +149,7 @@ + case 97: /* CHARZ */ + case 106: /* MLSLABEL */ + case 102: /* SQLT_CUR OCI 7 cursor variable */ ++ case 108: /* SQLT_NTY */ + case 112: /* SQLT_CLOB / long */ + case 113: /* SQLT_BLOB / long */ + case 116: /* SQLT_RSET OCI 8 cursor variable */ +@@ -990,6 +991,9 @@ + case SQL_LONGVARCHAR: + return 8; /* Oracle LONG */ +=20 ++ case SQL_UDT: ++ return 108; /* Oracle NTY */ ++ + case SQL_DATE: + case SQL_TIME: + case SQL_TIMESTAMP: +@@ -1002,6 +1006,70 @@ + } +=20 +=20 ++static int ++dbd_rebind_ph_nty(sth, imp_sth, phs) ++ SV* sth; ++ imp_sth_t *imp_sth; ++ phs_t *phs; ++{ ++ OCIType *tdo =3D NULL; ++ sword status; ++ SV* ptr; ++ ++ if (phs->is_inout) ++ croak("OUT binding for NTY is currently unsupported"); ++ ++ /* ensure that the value is a support named object type */ ++ /* (currently only OCIXMLType*) */ ++ if ( sv_isa(phs->sv, "OCIXMLTypePtr") ) { ++ OCITypeByName(imp_sth->envhp, imp_sth->errhp, imp_sth->svchp, ++ (CONST text*)"SYS", 3, ++ (CONST text*)"XMLTYPE", 7, ++ (CONST text*)0, 0, ++ OCI_DURATION_CALLOUT, OCI_TYPEGET_HEADER, ++ &tdo); ++ ++ ptr =3D SvRV(phs->sv); ++ phs->progv =3D (void*) SvIV(ptr); ++ phs->maxlen =3D sizeof(OCIXMLType*); ++ } ++ else ++ croak("Unsupported named object type for bind parameter"); ++ ++ ++ /* bind by name */ ++ ++ OCIBindByName_log_stat(imp_sth->stmhp, &phs->bndhp, imp_sth->errhp, ++ (text*)phs->name, (sb4)strlen(phs->name), ++ (dvoid *) NULL, /* value supplied in BindObject later */ ++ 0, ++ (ub2)phs->ftype, 0, ++ NULL, ++ 0, 0, ++ NULL, ++ (ub4)OCI_DEFAULT, ++ status ++ ); ++ ++ if (status !=3D OCI_SUCCESS) { ++ oci_error(sth, imp_sth->errhp, status, "OCIBindByName SQLT_NTY"); ++ return 0; ++ } ++ if (DBIS->debug >=3D 3) ++ PerlIO_printf(DBILOGFP, " pp_rebind_ph_nty: END\n"); ++ ++ ++ /* bind the object */ ++ ++ OCIBindObject(phs->bndhp, imp_sth->errhp, ++ (CONST OCIType*)tdo, ++ (dvoid **)&phs->progv, ++ (ub4*)NULL, ++ (dvoid **)NULL, ++ (ub4*)NULL); ++ ++ return 2; ++} +=20 + static int=20 + dbd_rebind_ph_char(sth, imp_sth, phs, alen_ptr_ptr)=20 +@@ -1307,6 +1375,9 @@ + case SQLT_RSET: + done =3D dbd_rebind_ph_rset(sth, imp_sth, phs); + break; ++ case 108: ++ done =3D dbd_rebind_ph_nty(sth, imp_sth, phs); ++ break; + #else + case 102: /* SQLT_CUR */ + done =3D dbd_rebind_ph_cursor(sth, imp_sth, phs); +@@ -1315,6 +1386,7 @@ + default: + done =3D dbd_rebind_ph_char(sth, imp_sth, phs, &alen_ptr); + } ++ + if (done !=3D 1) { + if (done =3D=3D 2) { /* the rebind did the OCI bind call itself successfu= +lly */ + if (DBIS->debug >=3D 3) +@@ -1328,7 +1400,7 @@ + #ifdef OCI_V8_SYNTAX + if (phs->maxlen > phs->maxlen_bound) { + sword status; +- int at_exec =3D (phs->desc_h =3D=3D NULL); ++ int at_exec =3D (phs->desc_h =3D=3D NULL) && (phs->ftype !=3D 108); + OCIBindByName_log_stat(imp_sth->stmhp, &phs->bndhp, imp_sth->errhp, + (text*)phs->name, (sb4)strlen(phs->name), + phs->progv, +@@ -1416,8 +1488,9 @@ + } + assert(name !=3D Nullch); +=20 +- if (SvROK(newvalue) && !IS_DBI_HANDLE(newvalue)) ++ if (SvROK(newvalue) && (!IS_DBI_HANDLE(newvalue)) && (sql_type!=3DSQLT= +_NTY)) + /* dbi handle allowed for cursor variables */ ++ /* ref allowed for OCIXMLType* */ + croak("Can't bind a reference (%s)", neatsvpv(newvalue,0)); + if (SvTYPE(newvalue) > SVt_PVLV) /* hook for later array logic? */ + croak("Can't bind a non-scalar value (%s)", neatsvpv(newvalue,0)); +@@ -2217,6 +2290,7 @@ + #ifdef OCI_V8_SYNTAX + case SQLT_CLOB: sql_fbh.dbtype =3D SQL_CLOB; break; + case SQLT_BLOB: sql_fbh.dbtype =3D SQL_BLOB; break; ++ case SQLT_NTY: sql_fbh.dbtype =3D SQL_UDT; break; + #endif + #ifdef SQLT_TIMESTAMP_TZ + case SQLT_TIMESTAMP_TZ: sql_fbh.dbtype =3D SQL_TIMESTAMP; break; + +--=-Sq1IOPDEhKoqxUKefiS3-- + + + +From timbo@dansat.data-plan.com Fri Jan 30 18:32:30 2004 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i0UIVK3f073353 + for ; Fri, 30 Jan 2004 18:32:30 GMT + (envelope-from timbo@dansat.data-plan.com) +Received: from pop3.mail.demon.net [194.217.242.253] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Fri, 30 Jan 2004 18:32:30 +0000 (GMT) +Received: from punt-3.mail.demon.net by mailstore + for pobox@dbi.demon.co.uk id 1AmceP-000603-GP; + Fri, 30 Jan 2004 17:41:53 +0000 +Received: from [194.217.242.71] (helo=anchor-hub.mail.demon.net) + by punt-3.mail.demon.net with esmtp id 1AmceP-000603-GP + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 17:41:53 +0000 +Received: from [208.210.124.73] (helo=icicle.pobox.com) + by anchor-hub.mail.demon.net with esmtp id 1AmceO-0006dQ-DB + for pobox@dbi.demon.co.uk; Fri, 30 Jan 2004 17:41:52 +0000 +Received: from icicle.pobox.com (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 25AEA3F13D + for ; Fri, 30 Jan 2004 12:41:51 -0500 (EST) +Delivered-To: tim.bunce@pobox.com +Received: from colander (localhost [127.0.0.1]) + by icicle.pobox.com (Postfix) with ESMTP id 9FB863F16E + for ; Fri, 30 Jan 2004 12:41:49 -0500 (EST) +Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) + by icicle.pobox.com (Postfix) with SMTP + for ; Fri, 30 Jan 2004 12:41:11 -0500 (EST) +Received: (qmail 9504 messnum 226571 invoked from network[213.94.228.233/unknown]); 30 Jan 2004 17:40:43 -0000 +Received: from unknown (HELO dansat.data-plan.com) (213.94.228.233) + by mail09.svc.cra.dublin.eircom.net (qp 9504) with SMTP; 30 Jan 2004 17:40:43 -0000 +Received: from dansat.data-plan.com (localhost [127.0.0.1]) + by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i0UHf33A072739; + Fri, 30 Jan 2004 17:41:03 GMT + (envelope-from timbo@dansat.data-plan.com) +Received: (from timbo@localhost) + by dansat.data-plan.com (8.12.9/8.12.9/Submit) id i0UHf2Wr072738; + Fri, 30 Jan 2004 17:41:02 GMT +Date: Fri, 30 Jan 2004 17:41:02 +0000 +From: Tim Bunce +To: Hendrik Fuss +Cc: Tim Bunce , "dbi-dev@perl.org" +Subject: Re: DBD-Oracle and XMLType +Message-ID: <20040130174102.GB72657@dansat.data-plan.com> +References: <1075459292.7305.46.camel@mars> <20040130133443.GC70215@dansat.data-plan.com> <1075471263.7305.73.camel@mars> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <1075471263.7305.73.camel@mars> +User-Agent: Mutt/1.4i +Status: RO +Content-Length: 1129 +Lines: 29 + +On Fri, Jan 30, 2004 at 03:01:03PM +0100, Hendrik Fuss wrote: +> > > The attached patch (based on DBD-Oracle 1.15) enables you to upload +> > > XMLType objects (OCIXMLTypePtr) by binding them as SQLT_NTY. In dbdimp.c +> > > I added a function dbd_rebind_ph_nty for that purpose. You need to +> > > create that XMLType object first using the C function +> > > createxmlfromstring in xml.c. +> > +> > I there any chance you could post that as a context diff (diff -u ideally +> > or else diff -c)? It's much safer and more useful. Thanks. +> +> Good idea. Here's a diff -u of dbdimp.c. + +Thanks. + +> By the way: I have thougt about general support of named types, not just +> XMLType, but you need to get the type description (TDO) from somewhere. +> My code just checks if the perl variable is a blessed reference of +> "OCIXMLTypePtr". + +Doing the equivalent of m/^OCI(\w+)Ptr$/ and then calling OCITypeByName +with $1 uppercased might take us (or someone) a step further. + +> Also note that my code can't handle downloading of XMLType objects yet. + +I'll trust that some kind soul with an itch will send a patch :-) + +Thanks again Hendrik. + +Tim. + diff --git a/err_unsorted/err_xmltypebindplsql.msg b/err_unsorted/err_xmltypebindplsql.msg new file mode 100644 index 00000000..08faa725 --- /dev/null +++ b/err_unsorted/err_xmltypebindplsql.msg @@ -0,0 +1,174 @@ +From dbi-users-return-11068-Tim.Bunce=pobox.com@perl.org Thu Apr 25 11:02:42 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g3PA2gK34525 + for ; Thu, 25 Apr 2002 11:02:42 +0100 (BST) + (envelope-from dbi-users-return-11068-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.21] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Thu, 25 Apr 2002 11:02:42 +0100 (BST) +Received: from punt-1.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1019721492:10:18778:60; Thu, 25 Apr 2002 07:58:12 GMT +Received: from dolly1.pobox.com ([207.106.49.22]) by punt-1.mail.demon.net + id aa1109782; 25 Apr 2002 7:58 GMT +Received: from dolly1.pobox.com (localhost.localdomain [127.0.0.1]) + by dolly1.pobox.com (Postfix) with ESMTP id 791692BF11 + for ; Thu, 25 Apr 2002 03:58:08 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [209.85.157.220]) + by dolly1.pobox.com (Postfix) with SMTP id 976FB2BEE4 + for ; Thu, 25 Apr 2002 03:58:07 -0400 (EDT) +Received: (qmail 84467 invoked by uid 1005); 25 Apr 2002 07:58:05 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 77923 invoked by uid 76); 24 Apr 2002 23:08:56 -0000 +Date: Wed, 24 Apr 2002 19:08:54 -0400 +From: Mark Stillwell +To: dbi-users-help@perl.org, dbi-users@perl.org +Subject: Oracle 9 XMLTYPE insert +Message-ID: <20020424190852.C22854@byrd.biostat.ufl.edu> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5.1i +Status: RO +Content-Length: 1469 +Lines: 43 + +I'm using DBI 1.21 and DBD 1.12 with an oracle9i database backend. + +Here is my problem, I have a table named 'test' with three fields: eid +(integer), x (SYS.XMLTYPE) and formname (text) + +I create a database handler and connect to the database just fine. + +I create a new statement handler with the following command: + +$sth = $dbh->prepare("INSERT INTO test (eid, x, formname) VALUES (?, +SYS.XMLTYPE.CREATEXML(?), ?"); + +I loop over some data, $eid gets and integer, $xmlvalue gets a string, +and $formname gets a string. So long as $xmlvalue is relatively short +$sth->execute($eid, $xmlvalue, $formname); works great, but as soon as +it becomes long enough to force the use of clob's I have a problem. + +So I tried the following: + +$sth->bind_param(1, $i); +$sth->bind_param(2, $xmlvalue, { ora_type => ORA_CLOB }); +$sth->bind_param(3, $intable); +$sth->execute; + +This works great if column 'x' is a normal CLOB and I omit the +sys.xmltype.createxml statement above, but when 'x' is of type +sys.xmltype I get the following error: + +nvalid LOB locator specified +ORA-06512: at "SYS.XMLTYPE", line 0 + +Right now I've hacked the setup so there is a supplemental table called +'y' of type CLOB that I submit to, then I do $dbh->do("UPDATE test SET x += SYS.XMLTYPE.CREATEXML(y)");, which works but doesn't seem like the +right way to do this. + +Is there any way to do what I want in the current version of +DBI/OracleDBD? + +-- +Mark Stillwell +marklee@ufl.edu +http://plaza.ufl.edu/marklee/ + +From dbi-users-return-11340-Tim.Bunce=pobox.com@perl.org Wed May 8 16:11:46 2002 +Received: from localhost (localhost [127.0.0.1]) + by dansat.data-plan.com (8.11.6/8.11.6) with ESMTP id g48FBjo24814 + for ; Wed, 8 May 2002 16:11:45 +0100 (BST) + (envelope-from dbi-users-return-11340-Tim.Bunce=pobox.com@perl.org) +Received: from pop3.mail.demon.net [194.217.242.59] + by localhost with POP3 (fetchmail-5.8.5) + for timbo@localhost (single-drop); Wed, 08 May 2002 16:11:45 +0100 (BST) +Received: from punt-2.mail.demon.net by mailstore for Tim.Bunce@data-plan.com + id 1020870336:20:08175:2; Wed, 08 May 2002 15:05:36 GMT +Received: from cali-3.pobox.com ([64.71.166.116]) by punt-2.mail.demon.net + id aa2109147; 8 May 2002 15:05 GMT +Received: from cali-3.pobox.com (localhost.localdomain [127.0.0.1]) + by cali-3.pobox.com (Postfix) with ESMTP id 68FE23E6D4 + for ; Wed, 8 May 2002 11:01:49 -0400 (EDT) +Delivered-To: tim.bunce@pobox.com +Received: from onion.perl.org (onion.valueclick.com [209.85.157.220]) + by cali-3.pobox.com (Postfix) with SMTP id 33A783E64D + for ; Wed, 8 May 2002 11:01:49 -0400 (EDT) +Received: (qmail 65232 invoked by uid 1005); 8 May 2002 15:01:47 -0000 +Mailing-List: contact dbi-users-help@perl.org; run by ezmlm +Precedence: bulk +List-Post: +List-Help: +List-Unsubscribe: +List-Subscribe: +Delivered-To: mailing list dbi-users@perl.org +Delivered-To: moderator for dbi-users@perl.org +Received: (qmail 60079 invoked by uid 76); 8 May 2002 14:50:53 -0000 +From: "Ben Middleton" +To: +Cc: +Subject: Re: Oracle 9 XMLTYPE insert +Date: Wed, 8 May 2002 15:50:47 +0100 +Message-ID: +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 (Normal) +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) +Importance: Normal +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 +Status: RO +Content-Length: 1311 +Lines: 39 + +Hi. + +Not sure if you ever resolved this: + +> I'm using DBI 1.21 and DBD 1.12 with an oracle9i database backend. + +> Here is my problem, I have a table named 'test' with three fields: +> eid (integer), x (SYS.XMLTYPE) and formname (text) + +> I create a new statement handler with the following command: + +> $sth = $dbh->prepare("INSERT INTO test (eid, x, formname) VALUES (?, +> SYS.XMLTYPE.CREATEXML(?), ?"); + +.... + +> Invalid LOB locator specified +> ORA-06512: at "SYS.XMLTYPE", line 0 + +> Right now I've hacked the setup so there is a supplemental table +> called 'y' of type CLOB that I submit to, then I do $dbh->do("UPDATE +> test SET x= SYS.XMLTYPE.CREATEXML(y)");, which works but doesn't seem +> like the right way to do this. + +> Is there any way to do what I want in the current version of +> DBI/OracleDBD? + +I don't think that the current DBI/DBD can bind a CLOB to a PL/SQL function +(which is all the CREATEXML function is) - hence you will have to go with +the intermediate CLOB table solution. + +Incidentally, if you are using Oracle9i - have you tried using a TEMPORARY +TABLE with a CLOB column (see SQL Reference Guide)? If setup correctly, this +is automatically truncated at the end of a transaction, is managed by the +Server, and provides some efficiency benefits. We use this here quite +effectively. + +Ben. + +