On Wed, October 16 11:51 +0100, Tim Bunce wrote:
> Try:
> my $sth = $dbh->prepare("SELECT 1 FROM dual", { ora_check_sql => 0 });
Thanks, that did the trick. Thanks also for the detailed explanation
and links.
> I believe the parse at execute time is fundamentally an Oracle bug
> (and/or isn't a "full" parse). I'd be grateful if someone could ask
> Oracle support about that.
>From querying
SQL> select name, value from v$sysstat;
I confirmed that these are not doing hard parses each time, just soft.
parse count (total) 8152668
parse count (hard) 2551
execute count 4928937
But soft parses still put additional load on the database, 12% in ours
according to statspack. This should drop that in about half, but it's
too bad about the oracle bug on parsing on execute. That seems to
reduce much of the value of prepare_cached. Does anyone know if that
is there in Oracle 9 as well?
> Meanwhile, ora_check_sql => 0 disables the parse-at-prepare.
>
> 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:
I would prefer the default be better performance, but as long as both
options are available I'm happy. It would be good if this were
documented in DBD::Oracle.
