I do not observe this behaviour with Oracle version 10.2. In fact with the test scenario described above I get the following output in the observing session:

K.AF090D.AVALOQ> select name.name, stat.value
  2   from v$sesstat    stat
  3       ,v$statname   name
  4  where  stat.statistic# = name.statistic#
  5    and  stat.sid = 266
  6    and  name.name in ('parse count (hard)'
  7                      ,'parse count (total)'
  8                      ,'session cursor cache hits'
  9                      ,'session cursor cache count'
 10                      ,'opened cursors cumulative'
 11                      ,'opened cursors current'
 12                      );

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative                                               138
opened cursors current                                                   44
session cursor cache hits                                                28
session cursor cache count                                               39
parse count (total)                                                     137
parse count (hard)                                                        5

6 rows selected.

K.AF090D.AVALOQ>
K.AF090D.AVALOQ> -- AFTER THE LOOP HAS BEEN EXECUTED IN SESSION 266
K.AF090D.AVALOQ> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative                                               145
opened cursors current                                                   45
session cursor cache hits                                                29
session cursor cache count                                               41
parse count (total)                                                     142
parse count (hard)                                                        7

6 rows selected.

K.AF090D.AVALOQ> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

5 rows selected.

K.AF090D.AVALOQ>

Thanks for the post.

The first thing to do, of course, is to run your test against 10g and see if similar results appear. I did a quick check with some similar code against a 10.2.0.3 instance and didn’t see the session cursor cache hits that you report.

It’s possible, therefore, that the 11g code has done something to re-route the hits on the pl/sql cursor cache (which is what your code is using) through the code that handles the session cursor cache, or it may simply be counting pl/sql cursor cache hits as session cursor cache hits.

It’s possible that the cause of the anomaly reported in comments 22 and 23 is now universal, it’s possible that there are two different factors at play. It’s something that will need further investigation.

I just noticed that entry 22./23. address a similar topic (for Oracle 10.2). However, I am still not sure about which actions are accounted for in the statistics “session cursor cache hits” and “parse count (total)” and if there is an overlap (i.e. actions that increase both counters) or if the counters (for Oracle 10.2, 11g) refer to completely distinct actions.

kind regards
Martin

Motivated by this article, I did some experiments. On Oracle 11g I noticed, that the “session cursor cache hits” value can be larger than the “parse count (total)” value (see the test case below). From what you write in the above summary (“if the statement has been seen and authenticated before and has a reference in the session cursor cache then the ‘parse call’ may do virtually nothing “) I understood, that “session cursor cache hits” should also be accounted for in “parse count (total)”. Also with respect to the “session cursor cache hits”, the Oracle Reference says “…Subtract this statistic from “parse count (total)” to determine the real number of parses that occurred”, from which I conclude that the “parse count (total)” value should be >= the “session cursor cache hits” value. Did I maybe misunderstand something concerning these statistics or do you have an explanation for my observation?

thanks a lot for your help
kind regards
Martin

Test scenario
=============

Preparation
-----------

create table mma_test(id number(9));



Perform parses / session cursor cache lookups in Session 1
-----------------------------------------------------------

K.AF080C.AVALOQ> select distinct sid from v$mystat;

       SID
----------
       317

1 row selected.

K.AF080C.AVALOQ> begin
  2    for i in 1..4000 loop
  3      insert /*+ test_ins2 Schleife */ into mma_test values (33);
  4    end loop;
  5  end;
  6  /

PL/SQL procedure successfully completed.


Monitor statistics in Session 2
-------------------------------
K.AF080C.AVALOQ>
K.AF080C.AVALOQ>
K.AF080C.AVALOQ>
K.AF080C.AVALOQ> select name.name, stat.value
  2    from v$sesstat    stat
  3        ,v$statname   name
  4   where  stat.statistic# = name.statistic#
  5     and  stat.sid = 317
  6     and  name.name in ('parse count (hard)'
  7                       ,'parse count (total)'
  8                       ,'session cursor cache hits'
  9                       ,'session cursor cache count'
 10                       ,'opened cursors cumulative'
 11                       ,'opened cursors current'
 12                       );

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative                                               191
opened cursors current                                                    3
session cursor cache hits                                                80
session cursor cache count                                              108
parse count (total)                                                     135
parse count (hard)                                                        0

6 rows selected.

K.AF080C.AVALOQ> -- AFTER THE LOOP HAS BEEN EXECUTED IN SESSION 317
K.AF080C.AVALOQ> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative                                              4199
opened cursors current                                                    3
session cursor cache hits                                              4083
session cursor cache count                                              109
parse count (total)                                                     142
parse count (hard)                                                        1

6 rows selected.

K.AF080C.AVALOQ>

Oracle中SQL解析的主要流程: 我们说的游标概念比较复杂，它可以是客户端程序中的游标，服务进程中的私有游标，以及服务器端共享池里的共享游标。假设一个游标被打开了，一般来说它的共享游标信息(包括执行计划，优化树等)总是会在SQL AREA里，无需再次软/硬解析。 SESSION_CACHED_CURSORS是Oracle中的一个初始化参数(修改必须重启实例)，指定了每个会话缓存的游标上限(保留在PGA中)；客户端程序中open cursor的要求仍会被传递给服务进程，服务进程首先扫描自身缓存的游…