Re: SESSION_CACHED_CURSORS -- RE: Parse Vs Execute

Jonathan,

I've understood that when cursor_space_for_time is true, then unpin is only done when cursor is closed, thus there's no need for pinning/unpinning for every execution of a cursor. This should reduce hits on library cache latches since pinning is not done so often?

Hermant,

I've sometimes seen this parameter recommended when having library cache latching issues in large Apps installations, I have not used it myself in Apps though.

Also note, that cursor_space_for_time requires 50-100% larger shared_pool (and some more private SQL area in PGA, shared_pool or large_pool, depending on configuration), since shared cursor's frames can't be aged out from library cache until all corresponding cursors are closed (normally if there's not enough free memory in shared pool when parsing a new statement, some unpinned, but open cursors can be thrown out, but with cursor_space_for_time they can't be).

So, if you don't find any better cure and decide to use this parameter, you should first increase your shared pool quite much to avoid ORA-4031 errors and then start reducing in small amounts, based on v$librarycache, v$rowcache, x$kghlu and shared pool/library cache latch wait statistics. It's not good idea to leave shared pool too large, otherwise your memory allocations from there (hard parses for example) will get slow (shared pool latch (or latches in 9i) are kept too long when searching for free/recreatable chunks).

Tanel.

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Sunday, November 30, 2003 9:34 PM

>
> You still have to hit the library cache to execute
> a statement as it needs to be pinned in share mode,
> and unpinned when you finish with it. Library cache
> latch waits can be a symptom of excessive executions.
>
> Have you checked the library cache latch children
> to see if the load is evenly balanced, or whether there
> is a single library cache latch that is suffering most of
> the sleeps.
>
> Good news for 9.2 - v$sql, and a couple of others
> include the library cache child latch number, so you
> can see which objects are protected by the hot latch
> without having to use Steve's algorithm.
>
>
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> The educated person is not the person
> who can answer the questions, but the
> person who can question the answers -- T. Schick Jr
>
>
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
>
>
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> ____UK___November
>
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Sunday, November 30, 2003 1:29 PM
>
>
> What's the value for your cursor_space_for_time parameter?
>
> Tanel.
>
> ----- Original Message -----
> From: Hemant K Chitale
> To: Multiple recipients of list ORACLE-L
> Sent: Sunday, November 30, 2003 8:54 AM
> Subject: SESSION_CACHED_CURSORS -- RE: Parse Vs Execute
>
>
>
> I have taken SESSION_CACHED_CURSORS from 0 to 100 to 400. On occassion
I
> still see
> very high LIBRARY CACHE LATCH contention and am considering upping the
> value again.
> Currently, I set it at the Instance level. Since I am running Oracle
> Apps, I have suggested
> to the application team to put a custom ALTER SESSION trigger into the
> specific first
> responsibility form for users who do navigate between forms a lot and
> where we see
> high contention.
> Running Steve Adams's query, I get
> SQL> @Session_Cursor_Cache.sql
>
> PARAMETER VALUE USAGE
> ----------------------------- ----- -----
> session_cached_cursors 400 50%
> open_cursors 1024 36%
>
>
> CURSOR_CACHE_HITS SOFT_PARSES HARD_PARSES
> ----------------- ----------- -----------
> 35.10% 63.09% 1.81%
>
>
> MAX_CACHEABLE_CURSORS
> ---------------------
> 5227
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Jonathan Lewis
> INET: jonathan_at_jlcomp.demon.co.uk
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).