[Bjørn Engsig]
>Admittedly, I am no JDCB expert, but I wouldn't expect to see the
>behaviour you see, in particular that each insert seems to produce a
>soft parse. Do you have a non-cached sequence? If you do, that's
>your reason - recursive SYS SQL is (almost) n
James,
Admittedly, I am no JDCB expert, but I wouldn't expect to see the behaviour
you see, in particular that each insert seems to produce a soft parse. Do
you have a non-cached sequence? If you do, that's your reason - recursive
SYS SQL is (almost) never cached, so your update to seq$ will
[Bjørn Engsig]
>There are two things worth mentioning: cursor_sharing does NOT remove
>soft parses (see my white paper for details) and PL/SQL does not
>generate unnecessary soft parses except when using native dynamic SQL.
I'm using the implicit statement caching in oracle's c
Jared Still wrote:
>Re the soft parse: this is essentially hashing the SQL
>and getting a hit in the lib cache. These can't be
>avoided.
>
Well, properly coded applications, that execute the same SQL statement
over and over again are code, such that there are no - hard or soft -
parses. A
[Connor McDonald]
> v$sesstat splits this down into hard and soft parses.
Ah - thanks Connor!
select name, sum(value) total
from v$sesstat,v$statname
where v$sesstat.statistic#=v$statname.statistic#
and name like '%parse%'
group by name
parse count (hard) 2169
parse co
[Daniþment Gazi Ünal]
> it looks like not normal. can you run your trace file by
> http://www.unal-bilisim.com/products/itrprof/itrprof.html . if results same, can you
> email me your raw file ?
When I ran it through that, it claimed only 18 hard parses which makes
me feel a *lot* better. But th
Re the soft parse: this is essentially hashing the SQL
and getting a hit in the lib cache. These can't be
avoided.
There may be more going on than that, but it's much
less work than a hard parse.
Jared
On Friday 08 February 2002 00:58, you wrote:
> v$sesstat splits this down into hard and s
v$sesstat splits this down into hard and soft parses.
sys@cust> col name format a30
sys@cust> select * from v$statname
2 where name like '%parse%'
3 /
STATISTIC# NAMECLASS
-- -- --
177 parse time cpu
I've seen what looks to be conflicting evidence, so I'm trying
to get a handle on whether the tkprof output I'm seeing with the
parse counts == execution counts is "real" or not:
What gets me is that it even happens for "static" statements that
are happening in triggers - like this statement that
