Re: CBO irregularity

  • From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 9 Jun 2004 17:07:10 +0100

With a 'library_cache_recycle' like the recycle buffer cache.

Going back to the OP - I had understood your complaint
about waiting on a collision whilst searching for a match,
but I had assumed it was an old problem.

It seems unlikely that in an environment where you expect
most of your SQL to be sharable that it would be better
to give up the search for something that should be shared
in order to re-optimize it.  After all, you are giving up on
just one latch acquisition - but a recompile could easily
require you to queue for dozens of latch acquisitions -
including the latch you have just given up on.


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


----- Original Message ----- 
From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Tuesday, June 08, 2004 5:51 PM
Subject: RE: CBO irregularity


I still think that a "don't share me" algorithm/directive for a SQL
statement would be a good idea. I hadn't thought of this before, but perhaps
/*+NOSHARE*/ would be a clever implementation of what I'm talking about.


Cary Millsap


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: