Query taking time in Oracle 10g

Question

Hi,
Recently we had a database upgrade from 9.2.0.8 to 10.2.0.4. We use HP-UX B11.23 as OS.The problem is we have a query which used to take 3 mins in 9i database but it is not returning any output in 10g database after running for 8 hours after which we need to kill it . The query is ,
SELECT DPPB.CO_CD, DPPB.PRC_BOOK_CD,NVL(PB.CO_PRC_BOOK_CD,'NULL') ,
NVL(BP.BASE_PROD_CD,'NULL'),NVL(FG.FG_CD,'NULL'),DPPB.EFFTV_STRT_DT,
DPPB.EFFTV_END_DT,PRC_BOOK_AMT, PRC_LST_RPT_IND   ,
SYSDATE +  (RANK () OVER (PARTITION BY  PROD_PRC_BOOK_CD  ORDER BY DPPB.EFFTV_STRT_DT)/(24*60*60)) "RANK",
SYSDATE      FROM
DIM_PROD_PRC_BOOK DPPB,dim_prod  FG,dim_prod  BP,dim_prc_book  PB
WHERE
DPPB.BASE_PROD_OID =BP.BASE_PROD_OID and bp.end_date>sysdate and bp.be_id=bp.base_prod_oid AND
FG.FG_OID=DPPB.FG_OID and fg.end_date>sysdate and fg.be_id=fg.fg_oid
AND DPPB.PRC_BOOK_OID=PB.prc_book_oid and pb.end_date>sysdate and  pb.be_id=pb.PRC_BOOK_OID
AND DPPB.EFFTV_END_DT > ADD_MONTHS(TRUNC(SYSDATE), -15)
AND DPPB.CURR_IND='Y'
AND
PROD_PRC_BOOK_CD ||'-'||TO_CHAR(DPPB.END_DATE ,'DD-MM-YYYY hh24:mi:ss')
IN(
SELECT PROD_PRC_BOOK_CD ||'-'||TO_CHAR(MAX(DPPB.END_DATE ),'DD-MM-YYYY hh24:mi:ss')
FROM DIM_PROD_PRC_BOOK DPPB WHERE PROD_PRC_BOOK_CD IS NOT NULL GROUP BY PROD_PRC_BOOK_CD ,EFFTV_STRT_DT
)The explain plan of the query in 9i is,
            Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=CHOOSE          1             2964                                          
  WINDOW SORT          1       661       2964                                          
    HASH JOIN          1       661       2958                                          
      TABLE ACCESS BY INDEX ROWID     WHSUSR.DIM_PROD     1       73       1                                          
        NESTED LOOPS          1       355       290                                          
          NESTED LOOPS          1       282       289                                          
            HASH JOIN          164       32 K     284                                          
              TABLE ACCESS FULL     WHSUSR.DIM_PRC_BOOK     1       57       2                                          
              TABLE ACCESS FULL     WHSUSR.DIM_PROD_PRC_BOOK     6 K     957 K     281                                          
            TABLE ACCESS BY INDEX ROWID     WHSUSR.DIM_PROD     1       77       1                                          
              INDEX RANGE SCAN     WHSUSR.XN15_DIM_PROD     3             1                                          
          INDEX RANGE SCAN     WHSUSR.XN22_DIM_PROD     5             1                                          
      VIEW     SYS.VW_NSO_1     132 K     38 M     2665                                          
        SORT UNIQUE          132 K     6 M     2665                                          
          SORT GROUP BY          132 K     6 M     2665                                          
            TABLE ACCESS FULL     WHSUSR.DIM_PROD_PRC_BOOK     132 K     6 M     281                   And the explain plan of the query in 10g database is
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS          4             1702                                          
  WINDOW SORT          4       1 K     1702                                          
    FILTER                                                                
      TABLE ACCESS BY INDEX ROWID     WHSUSR.DIM_PROD     1       73       1                                          
        NESTED LOOPS          1       339       899                                          
          NESTED LOOPS          14       3 K     898                                          
            HASH JOIN          2 K     428 K     805                                          
              TABLE ACCESS FULL     WHSUSR.DIM_PRC_BOOK     1       53       3                                          
              TABLE ACCESS FULL     WHSUSR.DIM_PROD_PRC_BOOK     93 K     12 M     801                                          
            TABLE ACCESS BY INDEX ROWID     WHSUSR.DIM_PROD     1       77       1                                          
              INDEX RANGE SCAN     WHSUSR.XN15_DIM_PROD     2             1                                          
          INDEX RANGE SCAN     WHSUSR.XN22_DIM_PROD     5             1                                          
      FILTER                                                                
        HASH GROUP BY          1 K     59 K     802                                          
          TABLE ACCESS FULL     WHSUSR.DIM_PROD_PRC_BOOK     117 K     5 M     794        Please help in identifying the problem and how to tune it.

Answer 1

user605926 wrote:
Thanks Sir for your immense help. I used the hint /*+ optimizer_features_enable('9.2.0.8') */ and the query took only 2 seconds. I am really delighted.
Sorry for not clicking the 'helpful' button earlier since honestly I did not know about the rules. Going forward I will not forget to do that.Don't apologise, it wasn't intended as a personal criticism - it's just a footnote I tend to use at present as a general reminder to everyone that feedback is useful.
I have one question. Do i have to use this hint for each and every query that is becoming a headache or is their any permanent solution to fix all the queries that used to run good on 9.2.0.8 database ? Please suggest.When doing an upgrade it is always valid (in the short term) to set the optimizer_features_enable parameter to the value of the database your moving from so that you can get the code improvements (or bug fixes) of the newer software without risking execution plan changes.
After that the ideal is to test software and identify generic cases where a change like an index definition, or some statistical information needs to be corrected for a particular reason in classes of queries. Eventually you get down to the point where you have a few awkward queries which the optimizer can't handle where you need hints. The optimizer_features_enable is very convenient here. In 10g, however, you could then capture the older plan and record is as an SQL Baseline against the unhinted query rather than permanently including hints.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.