>From the O'Reilly "Oracle SQL Tuning Pocket Reference"

"There is one situation in which bind variables are not such a great choice.
If you have column data in a table having a disproportionate number of rows
with certain values, and a very small number of rows with other values, you
should be using histograms. Bind variables cannot use histogram
information."

"Using bind variables will prevent the optimizer from doing this, [using
histograms] because the optimizer is unaware of the value that will be in
the bind variable at the time it decides on the execution plan"

"Beginning with Oracle9i, the optimizer will consider bind variable values
when choosing execution plans."

HTH
Kev.

-----Original Message-----
Sent: 22 July 2002 17:29
To: Multiple recipients of list ORACLE-L


I thought it was simply that with values the optimizer could look at the
histograms to see if data was skewed, whereas it couldn't with bind
variables.  So the index may not have too many distinct values but the
values you were supplying had less than their fair share of records.  I'd
guess that someone at some point has done a analyze table for all indexes
(or something similar) on the particular table.  

I'd also tend to agree though that it's better to hint the index rather than
use values (if that is in your control)

-----Original Message-----
Sent: Monday, July 22, 2002 4:39 PM
To: Multiple recipients of list ORACLE-L


Barbara,

    The path that the optimizer chooses is based on what values are bound
into
the variables, but also on what information it has in the data dictionary.
If
those particular tables/indexes have not been analyzed recently then the
optimizer will make wrong decisions.  Also init parameters like
db_file_multiblock_read_count can prejudice the optimizer to a particular
path
over others.  I would not so much blame the use of bind variables before
looking
at the data dictionary entries for the table/indexes and the init.ora file.
And
yes, the optimizer in 7.x was flaky, at best.

Dick Goulet

____________________Reply Separator____________________
Author: "Baker; Barbara" <[EMAIL PROTECTED]>
Date:       7/22/2002 7:08 AM

prem.
Never did get an answer to this question.  I don't know why using bind
variables changed the execution path.  My best guess comes from the
developer.  She thinks that when we supplied the values, the optimizer knew
what the range of values would be, and could therefore determine to use the
index.  With the bind variable, the optimizer did not have a range of values
to work with and therefore did not choose the index in the execution path.

I have no knowledge that using bind variables will suppress indexes.  Just
happened that it did in this case.
Also keep in mind that this particular database is using an old version of
Oracle (7.3.4).  Optimizer got much better in version 8.

The list helped me out with a work-around, which was to index-hint the index
I wanted.

Bind variables are definitely "good guys".  I highly recommend you continue
with your code changes to include binds.

Good luck.
Barb


> ----------
> From:         oraora  oraora[SMTP:[EMAIL PROTECTED]]
> Reply To:     oraora  oraora
> Sent:         Sunday, July 21, 2002 8:24 PM
> To:   [EMAIL PROTECTED]
> Subject:      Re: bind vars change explain plan
> 
> Baker,
> 
> sorry i did not read the reply to ur query.
> what was the reply ?
> will using bind vars suppress index ?
> kindly let me know b'coz i have also changed my code to SQL with 
> bind vars just now.
> 
> Regards,
> prem.
> 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Baker, Barbara
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
-- 
Author: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
-- 
Author: Nicoll, Iain (Calanais)
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
-- 
Author: Thomas, Kevin
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).

Reply via email to