Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: autotrace issue

RE: autotrace issue

From: Yasin Baskan <yasbs_at_kocbank.com.tr>
Date: Fri, 14 Oct 2005 15:23:50 +0300
Message-ID: <083667B535F3464CA0DD0D1DAFA4E3760773331C@camexc1.kfs.local>

Sure it will reuse the same plan for a sql statement with bind variables. But it does not use the same plan for sqls with literals.

Select * from <table>
Where col1=1;

Select * from <table>
Where col1=2;

The optimizer can give 2 different plans for these sqls (according to the statistics of course). I was talking about sqls with literals as the sqls in the question.

-----Original Message-----
From: Mladen Gogala [mailto:gogala_at_sbcglobal.net] Sent: Friday, October 14, 2005 3:06 PM
To: Yasin Baskan
Cc: madan.sanjay_at_gmail.com; oracle-l_at_freelists.org Subject: Re: autotrace issue

Yassin, no, it isn't normal. Once you have parsed and optimized statement, Oracle
will resuse the same plan with utter disregard for the actual value of the bind
variables. There is, however, a thing known as "bind value peeking" or a "peeping Tom
optimizer" introduced in 9i, but without the lady godiva support. Optimizer looks into
the value of the bind variables and uses the values there to query the column histograms.
That causes an additional problem: if the first value is not representative for the majority
of cases and there is very little you can do about it, short of recalculating statistics
for one of the underlying tables, which is likely to influence all queries referencing
that table.

BTW, what makes hard parse such an expensive beast is exactly the enormous
complexity of CBO. It has to look into all those tables to gather information
like num_rows, leaf_blocks, clustering factor, value distribution for all
columns that are referenced in the "WHERE" clause and have histograms, to look
for the functional index and perform quite a complex task. You want to use bind
variables to avoid invoking the optimizer at any time but the time of the very
first execution.

On 10/14/2005 07:37:08 AM, Yasin Baskan wrote:
>
>
> Isn't it normal that the plan changes with the actual value in the
where
> clause. That is what the optimizer does. You can use a bind variable
> instead of that literal and see what the plan is.

--
Mladen Gogala
http://www.mgogala.com





Bu mesaj ve onunla iletilen tum ekler gonderildigi kisi ya da kuruma ozel ve Bankalar Kanunu geregince, gizlilik yukumlulugu tasiyor olabilir. Bu mesaj, hicbir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz; mesajin yetkili alicisi veya alicisina iletmekten sorumlu kisi degilseniz, mesaj icerigini ya da eklerini kopyalamayiniz, yayinlamayiniz, baska kisilere yonlendirmeyiniz ve mesaji gonderen kisiyi derhal uyararak bu mesaji siliniz. Bu mesajin iceriginde ya da eklerinde yer alan bilgilerin dogrulugu, butunlugu ve guncelligi Bankamiz tarafindan garanti edilmemektedir ve bilinen viruslere karsi kontrolleri yapilmis olarak yollanan mesajin sisteminizde yaratabilecegi zararlardan Bankamiz sorumlu tutulamaz.

This message and the files attached to it are under the privacy liability in accordance with the Banking Law and confidential to the use of the individual or entity to whom they are addressed. This message cannot be copied, disclosed or sold monetary consideration for any purpose. If you are not the intended recipient of this message, you should not copy, distribute, disclose or forward the information that exists in the content and in the attachments of this message; please notify the sender immediately and delete all copies of this message. Our Bank does not warrant the accuracy, integrity and currency of the information transmitted with this message. This message has been detected for all known computer viruses thence our Bank is not liable for the occurrence of any system corruption caused by this message
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Oct 14 2005 - 07:24:43 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US