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
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/
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
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,
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 c
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::e
