On Sun, Dec 01, 2002 at 05:41:42PM -0800, Jared Still wrote:
>
> It can be. Even a soft parse requires a latch in the database SGA,
> and since all latches are serialized, it could be a problem in a busy
> system.
>
> I am far from the expert in parsing and latching, but i do plan to run
> some
> tests comparing standard (easy) and DBMS_SQL (somewhat hard) cursors
> in PL/SQL with cursors in Perl/DBI.
>
> Given some interesting things I learned recently about using cursors in
> PL/Sql,
> I think Perl will lose agains DBMS_SQL. If so, it can be rectified.
>
> Should be trying this in the next couple of weeks.
>
> I'll let you know how it turns out.
Please do!
I expect to be working on DBD::Oracle again very soon, after what
has become an extended period of, er, stability.
:)
Tim.
> Jared
>
>
>
> On Sunday 01 December 2002 13:06, Tim Bunce wrote:
> > Thanks.
> >
> > So the next question... Is an extra soft parse a significant overhead?
> > (For some value of 'significant' :)
> >
> > Tim.
> >
> > On Thu, Nov 28, 2002 at 06:23:11PM -0800, Jared Still wrote:
> > > The first parse is a 'hard' parse. This is the parse that
> > > checks for existance of tables, privileges, and a bunch of
> > > other stuff I probably don't know about.
> > >
> > > The second parse is a 'soft' parse. It checks for existence
> > > of the SQL in the Oracle library cache.
> > >
> > > Oracle-Tools may not differentiate, or you may be on an
> > > older version of Oracle that reported them as equivalent.
> > >
> > > Jared
> > >
> > > On Thursday 28 November 2002 04:13, Tim Bunce wrote:
> > > > Try $dbh->prepare($call, { ora_check_sql => 0 });
> > > >
> > > > (The underlying issue is either an Oracle bug or that one of the
> > > > two parse steps counted isn't a real parse. DBD::Oracle does a
> > > > 'describe only' execute at prepare() time and then a normal execute
> > > > when execute() is called. The execute() should not count as a parse
> > > > as it has already been parsed, but oracle seems to do, or at least
> > > > count, another parse.)
> > > >
> > > > Tim.
> > > >
> > > > p.s. This is not about the development of drivers so belongs on
> > > > dbi-users and not on dbi-dev.
> > > >
> > > > On Thu, Nov 28, 2002 at 11:37:59AM +0100, Henning Meyer wrote:
> > > > > Hello,
> > > > >
> > > > > I use Perl 5.6.0, DBI 1.30 and DBD-Oracle 1.12.
> > > > > While checking the performance, my Oracle-Tools discovered, that the
> > > > > Database does two prepares for every
> > > > > execute.
> > > > >
> > > > > My Perl-Code looks like this:
> > > > >
> > > > > my $cur=$dbh->prepare($call);
> > > > > die "Prepare-Error: $DBI::err\n$call\n$DBI::errstr\n" if
> > > > > ($DBI::err);
> > > > > $cur->execute(@$vars);
> > > > > die "Execute-Error:
> > > > > $DBI::err\n$call\n$DBI::errstr\n" if
> > > > > ($DBI::err);
> > > > > my @res=();
> > > > > while (my $href=$cur->fetchrow_hashref) {
> > > > > die "Fetch-Error: $DBI::err\n$call\n$DBI::errstr\n" if
> > > > > ($DBI::err);
> > > > > for(keys %$href) {
> > > > > $href->{$_}=~s/[\s]*$//;
> > > > > $href->{$_}=~s/^[\s]//;
> > > > > }
> > > > > push(@res,$href);
> > > > > }
> > > > > $cur->finish;
> > > > > return(\@res);
> > > > >
> > > > > How could it be, that there is an prepare/execute ratio of 2? I have
> > > > > execute much equal +statements with bind-Values, and its very
> > > > > annoying that there are 400 prepares for 200 +executes instead of one
> > > > > prepare.
> > > > >
> > > > > Any hints?
> > > > >
> > > > > Henning
> > > > >
> > > > > --
> > > > > '''
> > > > > (0 0)
> > > > > +-------oOO----(_)-------------+
> > > > >
> > > > > |Henning Meyer |
> > > > > |SIEMENS AG ICM N PG ES PD D 2|
> > > > >
> > > > > +--------------------oOO-------+
> > > > >
> > > > > |__|__|
> > > > >
> > > > > ooO Ooo
