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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
