Re: Suggestions Needed: Latch free - library cache

Note in-line

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

Next public appearance2:
 March 2004 Hotsos Symposium - Keynote
 March 2004 Charlotte NC - OUG Tutorial
 April 2004 Iceland

One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html

Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html ____UK___February

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: Friday, January 09, 2004 5:09 PM

> > I'm not sure that's right. If everyone uses a public synonym, then
> > you get one sql text, and one cursor. I think the contention appears
> > because everyone has to have a 'non-existent' reference in memory
> > to say that they don't own an object with the same name as the public
> > synonym - consequently if you have lots of users who have to check
> > long chains of 'non-existent' then the latches get held for longer
> > periods of time.
>
> Hi Jonathan,
>
> I don't see how your statement contradicts the claim that heavy use of
public
> synonyms causes contention for not only library cache latches but also row
> cache objects latches. What I had in mind is Steve Adams' test. Here's the
URL
> http://www.ixora.com.au/newsletter/2001_05.htm#synonyms. If I understand
right,
> the additional row cache objects latch gets are for synonym translations,
> particularly public synonym translations.
>

Given that Steve has replied, I don't suppose there is much need to say anything more. However, you will note that Steve's experiment covers the authentication call to an existing cursor. Subsequent uses result in no further access to the rowcache - hence my comment that it is not the rowcache, just the length of what Steve has pointed out is a 'segmented array' that lurks in the library cache that causes the problem by pushing up library cache latch hold times.

However, if parsing is so extreme that lots of statements never get beyond the slightly softer "authentication only" parse call, then the presence of public synonyms makes a bad problem worse, and a big chunk of the latch impact is in the rowcache objects latch.

(I haven't check v9 closely yet to see how much this has changed, but there are extra latches for the library cache the row cache which may mean a different strategy now exists).

> Yong Huang
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Yong Huang
> INET: yong321_at_yahoo.com
>
> 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: 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).