You should set OPTIMIZER_INDEX_COST_ADJ and OPTIMIZER_INDEX_CACHING. Explanation:
It is realistic to expect a part of an index to be cached and it is also realistic to expect the index access to be somewhat cheaper then the table
access. These two parameters give the same slant toward the index access path and nested loops path as RBO. For the rest, buy Jonathan's book.
On 2003.06.16 02:54, Hussain Ahmed Qadri wrote:
Hi, We have two DBs, a production and a development, identical query was running very quickly on the Development and very slowly on the Production. Both have the similar structures, same number of indexes and everything. When I checked the explain plan, I found out that on the Production DB, it was doing a FTS on a couple of tables and was doing an Index scan on the Development server. The only difference was that the tables on the Production were ANALYZED. To confirm my theory, I analyzed the tables on Development and it started doing a FTS there as well hence slowing the query down. I know the optimizer, after analyzing, would have chosen the better path in its own sense but its not producing the desired result and it is taking ages now. is there any way to undo that?
Regards,
Hussain Ahmed Qadri DBA SKMCH&RC
-- Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala 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).
