How to force the optimaizer to stop using an index ?

Question

Hello,
I have an index on a very large table and I want to see how the applications running on this DB handles a situation in which this index does not exists.
Therfore I have 2 options:
1. drop the index - but this is too risky as if i will need to recreate it , it will last forever and will result in long application downtime which I can not afford.
The test and Dev environments does not contain ammounts of data like the prodicution so its hard to predict from these environments.
2. the second option is Modify the index columns statistics (which I have done) giving it low NDV (number of diftinct values) -- but sadly this did not work.
when cheking event 10053 I see a the line "Using prorated density: [ 1/(2*num_rows) ] of col #n as selectivity of out-of-range value pred" which I guess meens the High value of the column is lower then the value given it the query ( I do not run statistics every day , the current statistics for all columns (execpt this one ) suits best and I do not want to handle plan changes . also it will take a lot of time to gather table stats on daily basis.
So - to make a long story short - how do I force Oracle to avoid using an index but continue builing it and without dropping it?
I can not use the 'NO_INDEX' hint as it will requre change in many Applications.
I don need something like NO_INDEX hint on system level.
I am using Oracle 10g Enterprise edition.
the optimaized_mode is set to COST BASED.
Thanks in advance for any help resolving this complicated issue.
Regards,
Amit Zor.
ADBA.

Answer 1

user3698066 wrote:
Hello,
I have an index on a very large table and I want to see how the applications running on this DB handles a situation in which this index does not exists.
2. the second option is Modify the index columns statistics (which I have done)
I'm still wondering if there is a way of modifying the statistics of the index in such a way so that it is not used by the optimizer.
Since the main contributors of the formula for an simple b-tree index access path are the height of index, the number of leaf blocks and for the table access the clustering factor, may be you could come up with all those values bumped up to very large values for that particular index.
Unfortunately the only component of the formula that is not multiplied by a factor is the height of the index, which is sanity checked (at least in 10.2) when set manually and is limited to a (already quite unreasonable) 255, so you can't set it greater than 255, but the remaining attributes can be set more or less to whatever you want.
So you could come up with an manual modification of the index statistics like this. Note that I don't modify the NUM_ROWS and DISTINCT_KEYS values in an attempt to limit the risk of unwanted side effects of this modification.
begin dbms_stats.set_index_stats(
ownname=>'<index_owner>,
indname=>'<index_name>',
indlevel=>255,
numlblks=>1000000000,
clstfct=>1000000000,
avglblk=>1000000000/<num_distinct>,
avgdblk=>1000000000);
end;
/In a quick test I was successfully able to prevent a very selective index access path using these settings, but depending on your remaining statistics and the access paths chosen by the optimizer this might not work for you, at least not in all possible cases, e.g. an index unique scan won't cost more than 256 even using these settings because only a single leaf block by definition has to be visited in this case.
Of course I haven't checked thoroughly what other side effects this statistics fudging does have, so use at your own risk resp. test it in your non-production environment before even thinking about applying it to an production system.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/