Optimizer regression in 9.2

Question

Hi, we have serious performance degradation problems after migration from 8.0.6 to 9.2.0.4.0
The greatest problem is caused by the difference in the access plans
generated by the optimizer. Having the simple test table with 2 indexes:
CREATE TABLE PRUEBA
CAMPO1 VARCHAR2(10) NOT NULL,
CAMPO2 VARCHAR2(10) NOT NULL,
CAMPO3 VARCHAR2(10) NOT NULL,
CAMPO4 VARCHAR2(10) NOT NULL
NOPARALLEL;
CREATE UNIQUE INDEX I_2_3_4 ON PRUEBA
(CAMPO2, CAMPO3, CAMPO4)
ALTER TABLE PRUEBA ADD (
CONSTRAINT PK PRIMARY KEY (CAMPO1)
USING INDEX
After that insert 100000 rows, and issue the following query and have different execution plans in 8.x and 9.2:
select campo1,campo2
from prueba
where (campo1= :valor1 Or campo2= :valor2) and rownum <=2
Execution plan in 8.0.6:
SELECT STATEMENT Optimizer Mode=CHOOSE                                        
COUNT STOPKEY                                        
CONCATENATION                                        
FILTER                                        
TABLE ACCESS BY INDEX ROWID     PRUEBA                                   
INDEX RANGE SCAN     I_2_3_4                                   
FILTER                                        
TABLE ACCESS BY INDEX ROWID     PRUEBA                                   
INDEX UNIQUE SCAN     PK                              
Execution plan in 9.2.0.4.0:
SELECT STATEMENT Optimizer Mode=CHOOSE                                        
COUNT STOPKEY                                        
TABLE ACCESS FULL     PRUEBA          
WHY ??????? It has serious performance implicattions in our application when table prueba has 50 million rows!!!
Optimizer mode is choose, and tables are not analyzed because of man power implications in such change.

Answer 1

Some mor info:
Hi,
the parameter optimizer_mode is set to CHOOSE because our tables are not analyzed. The only tables analyzed are partitioned tables, and where the joins involving partitioned tables + not partitioned tables have the hints needed, but joins involving only NOT Patitioned tables, thus NOT analyzed tables, are using RBO.
I have tried the example query in the folowing scenarios/parameters:
1) 9.2.0.4.0 database server ->
SELECT STATEMENT Optimizer Mode=CHOOSE
COUNT STOPKEY
TABLE ACCESS FULL PRUEBA
2) 9.0.1.3.1 database server ->
SELECT STATEMENT Optimizer Mode=CHOOSE
COUNT STOPKEY
CONCATENATION
FILTER
TABLE ACCESS BY INDEX ROWID PRUEBA
INDEX RANGE SCAN I_2_3_4
FILTER
TABLE ACCESS BY INDEX ROWID PRUEBA
INDEX UNIQUE SCAN PK
3) Finally tried 9.2.0.4.0 database server setting parameter optimizer_features_enable=9.0.1 ->
SELECT STATEMENT Optimizer Mode=CHOOSE
COUNT STOPKEY
TABLE ACCESS FULL PRUEBA
WHY???? The execution plan shuold be the same as in 9.0.1 database version or not ?????
Table and indexes are not analyzed, thus the optimizer must be using RULE, but where is the difference???? It look like optimizer bug, not???