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