Re: session_cached_cursors

You've issues 2804 parse calls.
Of these, 51 have required a full optimize cycle. The rest have found pre-parsed images (sharable cursors).

If your setting of session_cached_cursors had been greater than 51, then the figures reported would not have been different. However, you could have found that the statistic "session cursor cache hits" was as high as 2702, and the statistic "session cursor cache count" as high as 51.

Although the parse count would have been the same, the cost of parse calls that use the session cursor cache is a little cheaper.

You can get a little extra information from "cursor authentications", (cursor authentications - hard parses) which would give you an idea how many times your parses were 'soft parses' that piggy-backed on cursors that had been parsed by other people.

-- 
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated May 1st


"utkanbir" <hopehope_123_at_yahoo.com> wrote in message
news:f6c90ebe.0406030436.bba073b_at_posting.google.com...


> Hi ,

>

> Do i need to increase the session_cached_cursors which is 0?

>

> I have checked parse count against 'session cursor cache hits' ,

> 'session cursor cache hits ' is always zero for all the sessions .

> Below is an output belonging to a session which has high parse count

> value. This is a  rac system and datawarehouse.

>

>

> INST_ID SID STATISTIC# VALUE INST_ID_1 STATISTIC#_1 NAME CLASS

> 1 207 232 2804 1 232 parse count (total) 64

> 1 207 233 51 1 233 parse count (hard) 64

> 1 207 205 0 1 205 session cursor cache hits 64

> 1 207 234 0 1 234 parse count (failures) 64

>

>

> Kind Regards,

> tolga