Different explain plan between 10.2.0.3 and 10.2.0.4

Question

Had a problem with an explain plan changing after upgrade from 10.2.0.3 to 10.2.0.4. Managed to simplify as much as possible for now:
Query is :
SELECT * FROM m_promo_chk_str
WHERE (m_promo_chk_str.cust_cd) IN (
SELECT cust_cd
FROM s_usergrp_pda
GROUP BY cust_cd)
On 10.2.0.3 explain plan is:
| 0 | SELECT STATEMENT | | 1 | 1227 | 26 (16)| 00:00:01 |
|* 1 | HASH JOIN SEMI | | 1 | 1227 | 26 (16)| 00:00:01 |
| 2 | TABLE ACCESS FULL | M_PROMO_CHK_STR | 1 | 1185 | 14 (0)| 00:00:01 |
| 3 | VIEW | VW_NSO_1 | 137 | 5754 | 11 (28)| 00:00:01 |
| 4 | HASH GROUP BY | | 137 | 548 | 11 (28)| 00:00:01 |
| 5 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 9 (12)| 00:00:01 |
On 10.2.0.4 with same data is:
| 0 | SELECT STATEMENT | | 1 | 1201 | 46 (5)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 1201 | 46 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 1 | 1201 | 45 (3)| 00:00:01 |
| 3 | TABLE ACCESS FULL| M_PROMO_CHK_STR | 1 | 1197 | 29 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 15 (0)| 00:00:01 |
Explain plan is reasonable for when M_PROMO_CHK_STR is empty, however we have the case where stats are gathered when table is empty, but table is then populated and the query runs slowly. I understand that this is not a problem with the database exactly, but want to try to understand why the different behaviour.
Will look into CBO trace tommorrow, but for now anyone want to share any thoughts?

Answer 1

PatHK wrote:
Here is further simplification to reproduce the different behaviour - I think about as simple as I can get it!
SELECT * FROM dual WHERE (dummy) IN (SELECT dummy FROM dual GROUP BY dummy);
On 10.2.0.3
|   0 | SELECT STATEMENT     |          |     1 |     4 |     5  (20)| 00:00:01 |
|   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     5  (20)| 00:00:01 |
|   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     2   (0)| 00:00:01 |
|*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     3  (34)| 00:00:01 |
|   4 |    SORT GROUP BY     |          |     1 |     2 |     3  (34)| 00:00:01 |
|   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     2   (0)| 00:00:01 |On 10.2.0.4
|   0 | SELECT STATEMENT     |      |     1 |     4 |     4   (0)| 00:00:01 |
|   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     4   (0)| 00:00:01 |
|   2 |   NESTED LOOPS       |      |     1 |     4 |     4   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
Timur's suggestion to look at a 10053 trace file is a good idea. It might be the case that someone disabled complex view merging in the 10.2.0.3 database instance. See the following:
_complex_view_merging
http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/
Here is a test you might try on both database versions:
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=TRUE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST1';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=FALSE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST2';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';The first plan output:
| Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |      |       |       |     8 (100)|          |
|   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     8   (0)| 00:00:01 |
|   2 |   NESTED LOOPS       |      |     1 |     4 |     8   (0)| 00:00:01 |
|   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("DUMMY"="DUMMY")The second plan output:
| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |          |       |       |     9 (100)|          |
|   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     9  (12)| 00:00:01 |
|   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
|*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     5  (20)| 00:00:01 |
|   4 |    SORT GROUP BY     |          |     1 |     2 |     5  (20)| 00:00:01 |
|   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("DUMMY"="$nso_col_1")From the first 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
  PARAMETERS WITH ALTERED VALUES
  _pga_max_size                       = 368640 KB
pgamax_size is the only parameter non-default value which could affect the optimizer.
From the second 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
  PARAMETERS WITH ALTERED VALUES
  _pga_max_size                       = 368640 KB
  _complex_view_merging               = false
  *********************************This section in the first 10053 trace seems to show the complex view merging:
SU: Considering interleaved complex view merging
SU:   Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
CVM: CBQT Marking query block SEL$683B0107 (#2)as valid for CVM.
CVM:   Merging complex view SEL$683B0107 (#2) into SEL$5DA710D3 (#1).
qbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM  (SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY") "VW_NSO_2","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
vqbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY"
CVM: result SEL$5DA710D3 (#1).
******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM "SYS"."DUAL" "DUAL","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="DUAL"."DUMMY" GROUP BY "DUAL"."DUMMY","DUAL".ROWID,"DUAL"."DUMMY"
Registered qb: SEL$C9C6826C 0x155e2020 (VIEW MERGE SEL$5DA710D3; SEL$683B0107)
  signature (): qb_name=SEL$C9C6826C nbfros=2 flg=0
    fro(0): flg=0 objn=258 hint_alias="DUAL"@"SEL$1"
    fro(1): flg=0 objn=258 hint_alias="DUAL"@"SEL$2"
FPD: Considering simple filter push in SEL$C9C6826C (#1)
FPD:   Current where clause predicates in SEL$C9C6826C (#1) :
         "DUAL"."DUMMY"="DUAL"."DUMMY"
kkogcp: try to generate transitive predicate from check constraints for SEL$C9C6826C (#1)
predicates with check contraints: "DUAL"."DUMMY"="DUAL"."DUMMY"
after transitive predicate generation: "DUAL"."DUMMY"="DUAL"."DUMMY"
finally: "DUAL"."DUMMY"="DUAL"."DUMMY"
CVM: Costing transformed query.
kkoqbc-start
            : call(in-use=25864, alloc=65448), compile(in-use=115280, alloc=118736)
kkoqbc-subheap (create addr=000000001556CD70)This is the same section from the second 10053 trace:
SU: Considering interleaved complex view merging
SU:   Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
FPD: Considering simple filter push in SEL$5DA710D3 (#1)
FPD:   Current where clause predicates in SEL$5DA710D3 (#1) :
         "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
predicates with check contraints: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
after transitive predicate generation: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
finally: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
FPD: Considering simple filter push in SEL$683B0107 (#2)
FPD:   Current where clause predicates in SEL$683B0107 (#2) :
         CVM: Costing transformed query.
kkoqbc-start
            : call(in-use=25656, alloc=65448), compile(in-use=113992, alloc=114592)
kkoqbc-subheap (create addr=00000000157E9078)Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.