Diff in explain plan of 9i and 10g

I am beginner and just started my dba career. Please can you help me by giving me the differences between a explain plan executed in oracle 9i and 10g. Why is there variations in the cost,cardinality and bytes. Is it that 9is explain plan is executed in a different way when compared to 10g's. Please help me out regarding the same.

Are your generating it against same sets of rows or using different tables ? we would love to see more information and could you please your explain plan on the board ?
hare krishna
Alok

Similar Messages

Explain plan for timesten and Oracle

we have a base table in our Oracle 10g database. We created a DSN for this in timesten 7.0 database and are able to connect. Now we have created 3 materialized views in timesten on top of the Oracle Base Table. How can we get the explain plan in timesten to find out when the table is being called by a custom java application, the materialized views are being used or not ? Please advice

Hi Can you help me in this regards,
i am getting the following error. Can you tell me how can i get rid of them?
Command> call ttcachestart();
15001: User lacks privilege ADMIN

Is there any tool to analyze explain plan and gives the report

Hi All,
Is there any tool/scripts to analyze explain plan from plan_table and gives the output report
Thanks,
Sankar

Hi Jaffar,
Thank you!!!
The below query will generate the execution tree:
SELECT OPERATION,
     OPTIONS OPTIONS,
DECODE(TO_CHAR(ID),'0','---',OBJECT_NAME) OBJECT_NAME,
     (ID ||'-'|| NVL(PARENT_ID,0) ||'-'|| NVL(POSITION,0) ) "ID**PARENT_ID**EXECUTION_STEP",
     SUBSTR(OPTIMIZER,1,8) OPT
FROM PLAN_TABLE
START WITH ID = 0
AND STATEMENT_ID = 'Q1'
CONNECT BY PRIOR ID = PARENT_ID
AND STATEMENT_ID = 'Q1'
Thanks,
Sankar

Explain plan changing between 9i and 11g

Hi
Recently we migrated the database from 9i to 11g.In 11g environment one query was running for long time and when we comapre the explain plan between 9i and 11g, we found one of the table is going through "INDEX RANGE SCAN NON UNIQUE" in 9i but in 11g it is accessing through "INDEX RANGE SCAN INDEX".
Is there any hint to add so that it will access table through "INDEX RANGE SCAN NON UNIQUE" in 11g?
Please Help.

I agree with Paul.
Why are you assuming that the optimizer in 11g, which has had bug fixes and vast improvements since 9i, is optimizing the query badly just because you think the query is running slowly.
Before making assumptions, you need to find the cause of the issue, not just look for differences in two non-comparible explain plans and assume that's the cause. Adding hints to force indexes and suchlike is not the answer (even though some idiots may suggest it is).
As it says in the documentation in relation to hints:
Comments
Hints were introduced in Oracle7, when users had little recourse if the optimizer generated suboptimal plans. Now Oracle provides a number of tools, including the SQL Tuning Advisor, SQL plan management, and SQL Performance Analyzer, to help you address performance problems that are not solved by the optimizer. Oracle strongly recommends that you use those tools rather than hints. The tools are far superior to hints, because when used on an ongoing basis, they provide fresh solutions as your data and database environment change.

Explain Plan

Just Question about Explain Plan.
Q- 1. Is it Possible to trace a current session query from other session without altering that session. If How can i do it. I can not do it with v$session becuase it will be different sessionid. Also i ndon't want to alter session.
Q-2 I have SQl statement gives different EXECUTION PLAN on 9R2 and 10g. Is it possible.
Can any one explain this please

thank you smoradi and william for your response.
Sorry for Long Post
I tried to post it before also. i did not get the conculsion. This are the final results i got. So can any one Help me.
Following are the information
I have TKPROF result. can any one expalin me this what it means. Where are wait time.
I got the explain plan as unnder can any one explain me please i am still having problem solving this
can any one explain me how to improve the perfomance.
1.SS_SKU_STORE_WEEk is the biggest table around 12 million rows.
2. SS_SKU_STORE 50 thosand rows
3. ITEM 44 thousand
4.Rest all tables are small.
SQL> SELECT   /*+ index( ss_sku_store SS_SKU_ST_PK ) */
2              TO_NUMBER( ss_sku_store.sku || ss_sku_store.store_num) rowkey,
3              ss_sku_store.sku psku,
4              ' ' || INITCAP( item.descrip ) description,
5              dept_id,
6              TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) subdepartment,
7              TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) ||'.'|| TO_CHAR( class_id ) class,
8              NVL( vendor_id, -1 ),
9              NVL( buyer_num, -1),
10              NVL( TRIM(pattern_cd), -1),
11              DECODE(Color_Cd, 0, -1, NVL( Color_Cd, -1)) Color_Cd,
12              NVL( size_cd, -1),
13              -1 list_id,
14              ss_sku.sku skuattribute,
15              ss_sku_store.store_num pstore,
16              INITCAP( store.name ) location,
17              store.state,
18              NVL( INITCAP( regional_vp), :cUNASSIGNED) regional_vp,
19              NVL( INITCAP( regional_merch_mgr), :cUNASSIGNED) regional_merch_mgr,
20              NVL( INITCAP( district_mgr), :cUNASSIGNED) district_mgr,
21              NVL( INITCAP( area_mgr), :cUNASSIGNED) area_mgr,
22              NVL( sq_footage, -1),
23              SUBSTR( '000' || fashion_attribute.seq, -3, 3 ) || NVL( store.fashion_att_cd, '' ) fashion_att_cd,
24              SUBSTR( '000' || cust_profile.seq, -3, 3 ) || NVL( store.cust_type_cd, '' ) cust_type_cd,
25              NVL( section_count, -1) section_count,
26              '000' corp_vol_grp_cd,
27              0 storegroup,
28              store.store_num storeattribute,
29              0 storesort,
30              submit_status,
31              DECODE( current_user, :pUserID, shipment_schedules.check_staged_sku(ss_sku_store.sku,-1), 1) lockedflag,
32              '' aggregatedrowkey,
33              '' AttributeDescription,
34              starting_on_hand     onhand
35     FROM     cust_profile,
36              fashion_attribute,
37              ( SELECT   vendor_id,
38                         sku
39                FROM     item_vendor
40                WHERE    sku IN ( SELECT sku
41                                  FROM    ss_session_sku
42                                  WHERE   user_key = :pUserKey)
43                AND      primary_flag = :cTRUE ) primaryvendor,
44              ( SELECT   SKU,
45                         DECODE( status, 0, 0, DECODE( status, 1 ,0 ,1) ) AS submit_status
46                FROM     ( SELECT   /*+ full(ss_session_sku) use_nl(ss_session_sku,ss_sku_store_week) index(ss_sku_store_week SS_SKU_STR_WK_SKU )*/
47                                    SS_SKU_Store_Week.SKU,
48                                    MAX( NVL( ssk_week_status, 0 ) ) AS status
49                           FROM     ss_session_sku,
50                                    ss_sku_store_week
51                           WHERE    user_key              = :pUserKey
52                           AND      ss_sku_store_week.sku = ss_session_sku.sku
53                           GROUP BY ss_sku_store_week.sku )
54               ) sku_status,
55              ss_sku,
56              store,
57              ss_sku_store,
58              item
59     WHERE    sku_status.sku           = item.sku
60     AND      sku_status.sku           = ss_sku.sku
61     AND      sku_status.sku           = ss_sku_store.sku
62     AND      sku_status.sku           = primaryvendor.sku
63     AND      sku_status.sku           = sku_status.sku
64     AND      ss_sku_store.store_num   = store.store_num
65     AND      store.cust_type_cd       = cust_profile.cust_type_cd(+)
66     AND      store.fashion_att_cd     = fashion_attribute.fashion_att_cd(+)
67     ORDER BY ss_sku_store.sku,
68              ss_sku_store.store_num;
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=531 Card=3203 Bytes=948088)
   1    0 SORT (GROUP BY) (Cost=531 Card=3203 Bytes=948088)
   2    1    HASH JOIN (RIGHT OUTER) (Cost=323 Card=3203 Bytes=948088)
   3    2      TABLE ACCESS (FULL) OF 'CUST_PROFILE' (TABLE) (Cost=2 Card=16 Bytes=304)
   4    2      HASH JOIN (RIGHT OUTER) (Cost=321 Card=3203 Bytes=887231)
   5    4        TABLE ACCESS (FULL) OF 'FASHION_ATTRIBUTE' (TABLE) (Cost=2 Card=9 Bytes=162)
   6    4        HASH JOIN (Cost=318 Card=3203 Bytes=829577)
   7    6          TABLE ACCESS (FULL) OF 'STORE' (TABLE) (Cost=15 Card=1289 Bytes=105698)
   8    6          TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'SS_SKU_STORE' (TABLE) (Cost=3 Card=707 Bytes=17675)
   9    8           NESTED LOOPS (Cost=302 Card=3203 Bytes=566931)
10    9             HASH JOIN (Cost=287 Card=5 Bytes=760)
11   10               NESTED LOOPS (Cost=284 Card=5 Bytes=655)
12   11                 NESTED LOOPS (Cost=273 Card=5 Bytes=270)
13   12                   NESTED LOOPS (Cost=252 Card=86 Bytes=3784)
14   13                     NESTED LOOPS (Cost=17 Card=13 Bytes=468)
15   14                       SORT (UNIQUE) (Cost=1 Card=13 Bytes=130)
16   15                         INDEX (RANGE SCAN) OF 'SS_SESS_SKU_PK' (INDEX (UNIQUE)) (Cost=1 Card=13 Bytes=130)
17   14                       TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_VENDOR' (TABLE) (Cost=3 Card=1 Bytes=26)
18   17                         INDEX (RANGE SCAN) OF 'ITEM_VENDOR_ITEM_FK_IDX' (INDEX) (Cost=2 Card=1)
19   13                     PARTITION HASH (ITERATOR) (Cost=65 Card=7 Bytes=56)
20   19                       TABLE ACCESS (BY LOCAL INDEX ROWID)OF 'SS_SKU_STORE_WEEK' (TABLE) (Cost=65 Card=7 Bytes=56)
21   20                         INDEX (RANGE SCAN) OF 'SS_SKU_STR_WK_SKU' (INDEX) (Cost=14 Card=6427)
22   12                   TABLE ACCESS (FULL) OF 'SS_SESSION_SKU'(TABLE) (Cost=0 Card=1 Bytes=10)
23   11                 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (TABLE) (Cost=2 Card=1 Bytes=77)
24   23                   INDEX (UNIQUE SCAN) OF 'ITEM_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
25   10               TABLE ACCESS (FULL) OF 'SS_SKU' (TABLE) (Cost=3 Card=343 Bytes=7203)
26    9             PARTITION HASH (ITERATOR) (Cost=1 Card=211)
27   26               INDEX (RANGE SCAN) OF 'SS_SKU_ST_PK' (INDEX(UNIQUE)) (Cost=1 Card=211)
EXPLIAN PLAN AND DATA FROM TKPROF
all     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.01          0          0          0           0
Execute      2      1.35       1.30          0          0          0           0
Fetch        5      0.14       0.16          5       2497          0         111
total        9      1.49       1.49          5       2497          0         111
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 30 (MDSEADMIN)
Rows     Row Source Operation
      0 PX COORDINATOR FORCED SERIAL (cr=797 pr=2 pw=0 time=42745 us)
      0   PX SEND QC (ORDER) :TQ10005 (cr=797 pr=2 pw=0 time=42711 us)
      0    SORT ORDER BY (cr=797 pr=2 pw=0 time=42701 us)
      0     PX RECEIVE (cr=797 pr=2 pw=0 time=42627 us)
      0      PX SEND RANGE :TQ10004 (cr=797 pr=2 pw=0 time=42617 us)
      0       BUFFER SORT (cr=797 pr=2 pw=0 time=42609 us)
      0        NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42532 us)
      0         NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42520 us)
      0          NESTED LOOPS (cr=797 pr=2 pw=0 time=42510 us)
      0           NESTED LOOPS (cr=797 pr=2 pw=0 time=42502 us)
      0            NESTED LOOPS (cr=797 pr=2 pw=0 time=42495 us)
      0             NESTED LOOPS (cr=797 pr=2 pw=0 time=42488 us)
      0              HASH JOIN (cr=797 pr=2 pw=0 time=42480 us)
      1               BUFFER SORT (cr=5 pr=1 pw=0 time=13357 us)
      1                PX RECEIVE (cr=5 pr=1 pw=0 time=13300 us)
      1                 PX SEND HASH :TQ10001 (cr=5 pr=1 pw=0 time=13291 us)
      1                  TABLE ACCESS BY INDEX ROWID ITEM_VENDOR (cr=5 pr=1 pw=0 time=13280 us)
      3                   NESTED LOOPS (cr=4 pr=0 pw=0 time=423 us)
      1                    SORT UNIQUE (cr=1 pr=0 pw=0 time=189 us)
      1                     INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=86 us)(object id 25279)
      1                    INDEX RANGE SCAN ITEM_VENDOR_ITEM_FK_IDX (cr=3 pr=0 pw=0 time=53 us)(object id 24079)
      0               PX RECEIVE (cr=792 pr=1 pw=0 time=28530 us)
      0                PX SEND HASH :TQ10003 (cr=792 pr=1 pw=0 time=28524 us)
      0                 VIEW (cr=792 pr=1 pw=0 time=28517 us)
      0                  HASH GROUP BY (cr=792 pr=1 pw=0 time=28509 us)
      0                   PX RECEIVE (cr=792 pr=1 pw=0 time=28295 us)
      0                    PX SEND HASH :TQ10002 (cr=792 pr=1 pw=0 time=28290 us)
      0                     NESTED LOOPS (cr=792 pr=1 pw=0 time=28284 us)
      1                      BUFFER SORT (cr=1 pr=0 pw=0 time=139 us)
      1                       PX RECEIVE (cr=1 pr=0 pw=0 time=45 us)
      1                        PX SEND BROADCAST :TQ10000 (cr=1 pr=0 pw=0 time=40 us)
      1                         INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=34 us)(object id 25279)
      0                      PX BLOCK ITERATOR PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28136 us)
      0                       TABLE ACCESS FULL SS_SKU_STORE_WEEK PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28084 us)
      0              TABLE ACCESS BY INDEX ROWID ITEM (cr=0 pr=0 pw=0 time=0 us)
      0               INDEX UNIQUE SCAN ITEM_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24055)
      0             TABLE ACCESS BY INDEX ROWID SS_SKU (cr=0 pr=0 pw=0 time=0 us)
      0              INDEX UNIQUE SCAN SS_SKU_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25300)
      0            PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
      0             TABLE ACCESS BY LOCAL INDEX ROWID SS_SKU_STORE PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
      0              INDEX RANGE SCAN SS_SKU_ST_PK PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)(object id 25547)
      0           TABLE ACCESS BY INDEX ROWID STORE (cr=0 pr=0 pw=0 time=0 us)
      0            INDEX UNIQUE SCAN STORE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25586)
      0          TABLE ACCESS BY INDEX ROWID FASHION_ATTRIBUTE (cr=0 pr=0 pw=0 time=0 us)
      0           INDEX UNIQUE SCAN FASHION_ATTRIBUTE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24035)
      0         TABLE ACCESS BY INDEX ROWID CUST_PROFILE (cr=0 pr=0 pw=0 time=0 us)
      0          INDEX UNIQUE SCAN CUST_PROFILE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24036)
ALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       43      0.10       0.11          0          1          0           0
Execute    861      0.38       0.45        357        622         46         621
Fetch      845      0.21       0.21        128       2626          2         892
total     1749      0.69       0.78        485       3249         48        1513
Misses in library cache during parse: 21
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                      60        0.00          0.00
SQL*Net message from client                    39        0.00          0.16
db file scattered read                         82        0.01          0.05
db file sequential read                       185        0.01          0.05
log file sync                                   1        0.00          0.00
191 user SQL statements in session.
   23 internal SQL statements in session.
214 SQL statements in session.
   37 statements EXPLAINed in this session.Thank you for your help in advance
Message was edited by:
devmiral

Performance problem: Query explain plan changes in pl/sql vs. literal args

I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.

AmandaSoosai wrote:
I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
A basic illustration of my guess
http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus

Explain plan for same query in three databases

Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clin

user627471 wrote:
Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clinpost both EXPLAIN PLAN here

Explain Plan useability

I like the explain plan functionality - it is good for doing spot checks on execution plans. Unfortunately, I cannot copy the plan once it is produced, so if I need to send someone a copy of the plan, I revert to producing the execution plan in TOAD.

Yes ..
I too feel same.
I right-click explain plan in TOAD and then paste it in excel.
It goes there row by row...Useful Feature.
--Sanjeev

Explain plan not displayed in sql trace file

Hello,
I don't understand why in sql trace file, after tkprof transformation, for several queries the explain plan is displayed and for several queries, no explain plan is displayed.
How can I have the explain plan for all queries?
Thanks for your help.

Was this a trace started on an already running task? Was the trace stopped before the task completed? Did the trace file reach its set size limit before the task compled?
In all three cases above you would have cursors that were not closed and stats information not written to the trace file resulting in incomplete data for some SQL.
HTH -- Mark D Powell --

SQL Tuning - Explain plan analysis

Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..
UNIT ENVT
==========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation                         | Name                     | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT                  |                          | 4739K|   646M|       | 85917   (1)| 00:19:12 |
|   1 | LOAD TABLE CONVENTIONAL          | F_DRV_FUEL_W             |       |       |       |            |          |
|   2 |   HASH UNIQUE                     |                          | 4739K|   646M|   726M| 85917   (1)| 00:19:12 |
|* 3 |    HASH JOIN RIGHT OUTER          |                          | 4739K|   646M|       | 7881   (3)| 00:01:46 |
|   4 |     VIEW                          |                          | 20936 |   756K|       | 1456   (1)| 00:00:20 |
|* 5 |      HASH JOIN RIGHT OUTER        |                          | 10468 |   572K|       |   594K (5)| 02:12:51 |
|   6 |       TABLE ACCESS FULL           | X_SNI_TRK_STP_P          | 2754 | 33048 |       |     5   (0)| 00:00:01 |
|   7 |       NESTED LOOPS OUTER          |                          | 10468 |   449K|       |   594K (5)| 02:12:51 |
|   8 |        TABLE ACCESS FULL          | X_SNI_FUEL_CMPLY_DTL_P   | 10468 |   184K|       |    14   (0)| 00:00:01 |
|   9 |        VIEW                       |                          |     1 |    26 |       |    57   (6)| 00:00:01 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    59 |       |    57   (6)| 00:00:01 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    28 |       |    27   (0)| 00:00:01 |
|* 13 |           VIEW                    |                          | 17659 |   534K|       |    29   (7)| 00:00:01 |
|* 14 |            WINDOW SORT PUSHED RANK|                          | 17659 |   448K|       |    29   (7)| 00:00:01 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P | 17659 |   448K|       |    27   (0)| 00:00:01 |
|* 16 |     HASH JOIN RIGHT OUTER         |                          | 4739K|   479M|    14M| 6404   (3)| 00:01:26 |
|* 17 |      TABLE ACCESS FULL            | XO_E_PER_ASSIGNMENT_P    |   276K|    11M|       | 2616   (2)| 00:00:36 |
|* 18 |      HASH JOIN                    |                          |   699K|    42M|    20M| 2704   (3)| 00:00:37 |
|* 19 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_PRD_P |   702K|    12M|       |   536   (3)| 00:00:08 |
|* 20 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_P     |   695K|    30M|       | 1202   (3)| 00:00:17 |
Predicate Information (identified by operation id):
   3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
   5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
              INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
       filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
              "X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1
              AND "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
49 rows selected.
UAT ENVT
=========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation                         | Name                     | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT                  |                          |   998K|   139M|       | 34826   (1)| 00:07:47 |
|   1 | LOAD TABLE CONVENTIONAL          | F_DRV_FUEL_W             |       |       |       |            |          |
|   2 |   HASH UNIQUE                     |                          |   998K|   139M|   157M| 34826   (1)| 00:07:47 |
|* 3 |    HASH JOIN RIGHT OUTER          |                          |   998K|   139M|    44M| 18001   (2)| 00:04:02 |
|   4 |     VIEW                          |                          |   931K|    33M|       | 4250   (1)| 00:00:57 |
|* 5 |      HASH JOIN RIGHT OUTER        |                          | 62082 | 3576K|       |    25M (2)| 96:08:31 |
|   6 |       TABLE ACCESS FULL           | X_SNI_TRK_STP_P          | 5603 | 61633 |       |    10   (0)| 00:00:01 |
|   7 |       NESTED LOOPS OUTER          |                          | 30548 | 1431K|       |    25M (2)| 96:08:31 |
|   8 |        TABLE ACCESS FULL          | X_SNI_FUEL_CMPLY_DTL_P   | 30548 |   715K|       |    46   (3)| 00:00:01 |
|   9 |        VIEW                       |                          |     1 |    24 |       |   845   (2)| 00:00:12 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    57 |       |   845   (2)| 00:00:12 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    29 |       |   150   (2)| 00:00:03 |
|* 13 |           VIEW                    |                          |   151K| 4155K|       |   694   (2)| 00:00:10 |
|* 14 |            WINDOW SORT PUSHED RANK|                          |   151K| 3413K| 5376K|   694   (2)| 00:00:10 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P |   151K| 3413K|       |   150   (2)| 00:00:03 |
|* 16 |     HASH JOIN RIGHT OUTER         |                          |   998K|   103M|    15M| 11138   (2)| 00:02:30 |
|* 17 |      TABLE ACCESS FULL            | XO_E_PER_ASSIGNMENT_P    |   296K|    11M|       | 5060   (2)| 00:01:08 |
|* 18 |      HASH JOIN                    |                          | 1028K|    65M|    31M| 4555   (3)| 00:01:02 |
|* 19 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_PRD_P | 1037K|    19M|       | 1000   (2)| 00:00:14 |
|* 20 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_P     | 1020K|    45M|       | 2088   (3)| 00:00:28 |
Predicate Information (identified by operation id):
   3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
   5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
              INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
       filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
              "X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND
              "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1 AND
              "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
Note
   - SQL profile "SYS_SQLPROF_0139a0175fb30006" used for this statement

Ora DBA wrote:
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..As a first step towards diagnosis, I would check following:
1) First step would be to isolate the problem. So you may want to verify if the SELECT part or the INSERT part is contributing more to run-time (It looks like the SELECT part but always good to confirm). That way, you can concentrate on, for e.g., tuning only SELECT part.
2) When trying to compare the runtime from 2 environments, ensure that you are using almost similar (if not same) data volumes and same tables/index structures
3) As both environments produce same plan, presumably the tables involved have similar pattern of statistics. But the actual data volume may be quite different. So check whether statistics are representative of actual data
4) Fortunately, your plan uses all FULL TABLE ACCESS and HASH JOIN (except one NESTED LOOP). So for a query that runs for more than 5 hours, you should be able to monitor individual steps using v$session_longops. As you are on 11G, you may also make use of Real-time SQL monitoring.
5) While it is not possible to decisively conclude anything based on EXPLAIN PLAN output, you may want to compare the PGA settings and TEMP file disk I/O capabilities of both environments. For e.g. in UNIT env, all the HASH JOINS that spill to disk are expected to be completed quicker than the corresponding HASH JOINS on UAT env. (Again, same volume of data would benefit the comparison here).
6) You may want to get rid of any HINTs used to check how CBO decides to process the query when left on its own.
7) Last but not the least, you may want to check the table design, especially as this query appears to involve lots of outer joins and analytical functions. Difficult to say anything conclusive without knowing the query but the following part of the plan suggests that there might be an opportunity to validate the logic used.
|   9 |        VIEW                       |                          |     1 |    26 |       |    57   (6)| 00:00:01 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    59 |       |    57   (6)| 00:00:01 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    28 |       |    27   (0)| 00:00:01 |
|* 13 |           VIEW                    |                          | 17659 |   534K|       |    29   (7)| 00:00:01 |
|* 14 |            WINDOW SORT PUSHED RANK|                          | 17659 |   448K|       |    29   (7)| 00:00:01 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P | 17659 |   448K|       |    27   (0)| 00:00:01 |This looks like a self-join of a table with itself, combined with usage of analytic function. Both might not be necessary and may be re-written to either avoid self-join or the analytic function part or replace them with a simpler query, which, in turn may impact the CBO's choice of subsequent NESTED LOOP join.
Hope this helps.

What is difference between oracle 8i ,9i and 10g

i want to know what is difference between oracle 8i ,9i and 10g with explain.

Differences between 9i and 10g
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10750/toc.htm
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14214/toc.htm
... between 8i and 9i
http://download-west.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/toc.htm
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96531/toc.htm

Explain Plan Cache?

How do you flush the Explain Plan Cache on Oracle 10g?

Do you refer to the contents of these views?
V$SQLAREA_PLAN_HASH
V$SQL_PLAN
V$SQL_PLAN_STATISTICS
V$SQL_PLAN_STATISTICS_ALL
If this is the case, those cannot be flushed but by an instance restart.
If you mean flushing the library cache, then this can be achieved by means of the command:
ALTER SYSTEM FLUSH SHARED POOL;
~ Madrid
http://hrivera99.blogspot.com/

Strange explain plan

I wrote a SQL in Oracle EBS, please see the following:
SELECT msi.segment1 item_num, mmt.revision revision,
msi.description description_en,
msi_tl.long_description description_cn,
mmt.transfer_organization_id mfg_org_id,
xxuts_inv_trh_pkg.get_organization_name(mmt.transfer_organization_id),
mmt.subinventory_code subinv, mmt.locator_id,
mtln.lot_number lot_num, mmt.transaction_id txn_id,
mmt.transfer_subinventory co_subinv, mmt.transfer_locator_id,
mmt.transaction_date txn_date, fn.user_name user_name,
mts.transaction_source_type_name txn_source_type,
wie.wip_entity_name order_num,
xxuts_inv_trh_pkg.get_qty_before (mmt.organization_id,
mmt.inventory_item_id,
mmt.revision,
mmt.subinventory_code,
mmt.transaction_id,
mmt.transaction_date
DECODE (msi.lot_control_code,
2, mtln.transaction_quantity,
mmt.transaction_quantity
) txn_qty,
mtt.transaction_type_name txn_type, mmt.actual_cost item_cost,
DECODE (msi.lot_control_code,
2, mtln.transaction_quantity,
mmt.transaction_quantity
* mmt.actual_cost amount,
mtln.primary_quantity primary_qty,
NVL
(mtr.reason_name,
(SELECT mtrh.attribute1 || mtrh.attribute2 || mtrh.attribute3
FROM mtl_txn_request_headers mtrh
WHERE EXISTS (
SELECT 'X'
FROM mtl_txn_request_lines mtrl
WHERE mtrh.header_id = mtrl.header_id
AND mtrl.transaction_header_id =
mmt.transaction_set_id
AND mtrl.txn_source_id = mmt.transaction_source_id
AND mtrl.line_id = mmt.source_line_id))
) reason,
mmt.transaction_reference REFERENCE
FROM mtl_system_items_b msi --250,
mtl_system_items_tl msi_tl --500,
mtl_transaction_lot_numbers mtln -210,
mtl_material_transactions mmt -333,
mtl_transaction_types mtt,
mtl_txn_source_types mts,
mtl_item_categories mic -800,
mtl_transaction_reasons mtr,
fnd_user fn,
wip_entities wie --5
WHERE msi.inventory_item_id = mmt.inventory_item_id
AND msi.inventory_item_id = msi_tl.inventory_item_id
AND msi.organization_id = msi_tl.organization_id
AND mtr.reason_id(+) = mmt.reason_id
AND msi_tl.LANGUAGE = USERENV ('LANG')
AND mmt.transaction_id = mtln.transaction_id(+)
AND mic.inventory_item_id = mmt.inventory_item_id
AND mic.organization_id = mmt.organization_id
AND mic.category_set_id = :b15
AND mmt.transaction_type_id = mtt.transaction_type_id
AND mmt.transaction_source_type_id = mts.transaction_source_type_id
AND msi.organization_id = mmt.organization_id
AND mmt.transaction_source_id = wie.wip_entity_id
AND mmt.transaction_source_type_id IN (5)
AND fn.user_id = mmt.created_by
AND mmt.organization_id = :b14
AND msi.segment1 >= NVL (:b13, msi.segment1)
AND msi.segment1 <= NVL (:b12, msi.segment1)
AND NVL (mmt.revision, '-99') = NVL (NVL (:b11, mmt.revision), '-99')
AND mmt.subinventory_code >= NVL (:b10, mmt.subinventory_code)
AND mmt.subinventory_code <= NVL (:b9, mmt.subinventory_code)
AND mmt.transaction_date BETWEEN :b8 AND :b7
AND mmt.creation_date BETWEEN :b6 AND :b5
AND mmt.transaction_type_id = NVL (:b4, mmt.transaction_type_id)
AND mmt.transaction_source_type_id = NVL (:b3, mmt.transaction_source_type_id)
AND mmt.transaction_id = NVL (:b2, mmt.transaction_id)
AND fn.user_id = NVL (:b1, fn.user_id)
It's explain plan is:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | INSERT STATEMENT | | | | 33 (100)| |
| 1 | CONCATENATION | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | 1 | 312 | 17 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 297 | 15 (0)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 1 | 282 | 13 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 257 | 10 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 188 | 8 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 174 | 7 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 148 | 6 (0)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 1 | 128 | 5 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 108 | 4 (0)| 00:00:01 |
| 12 | TABLE ACCESS BY INDEX ROWID| MTL_TXN_SOURCE_TYPES | 1 | 18 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | MTL_TXN_SOURCE_TYPES_U1 | 1 | | 0 (0)| |
|* 14 | TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS | 1 | 90 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | MTL_MATERIAL_TRANSACTIONS_N8 | 1 | | 2 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_REASONS | 1 | 20 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | MTL_TRANSACTION_REASONS_U1 | 1 | | 0 (0)| |
| 18 | TABLE ACCESS BY INDEX ROWID | WIP_ENTITIES | 1 | 20 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | WIP_ENTITIES_U1 | 1 | | 0 (0)| |
| 20 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_TYPES | 1 | 26 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | MTL_TRANSACTION_TYPES_U1 | 1 | | 0 (0)| |
| 22 | TABLE ACCESS BY INDEX ROWID | FND_USER | 1 | 14 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | FND_USER_U1 | 1 | | 0 (0)| |
|* 24 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 1 | 69 | 2 (0)| 00:00:01 |
|* 25 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_LOT_NUMBERS | 1 | 25 | 3 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | MTL_TRANSACTION_LOT_NUMBERS_N1 | 1 | | 2 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | MTL_ITEM_CATEGORIES_U1 | 1 | 15 | 2 (0)| 00:00:01 |
| 29 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_TL | 1 | 15 | 2 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_TL_U1 | 1 | | 1 (0)| 00:00:01 |
|* 31 | FILTER | | | | | |
| 32 | NESTED LOOPS OUTER | | 1 | 312 | 16 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 287 | 13 (0)| 00:00:01 |
| 34 | NESTED LOOPS | | 1 | 272 | 11 (0)| 00:00:01 |
| 35 | NESTED LOOPS | | 1 | 257 | 9 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | 1 | 188 | 7 (0)| 00:00:01 |
| 37 | NESTED LOOPS OUTER | | 1 | 162 | 6 (0)| 00:00:01 |
| 38 | NESTED LOOPS | | 1 | 142 | 5 (0)| 00:00:01 |
| 39 | NESTED LOOPS | | 1 | 128 | 4 (0)| 00:00:01 |
| 40 | NESTED LOOPS | | 1 | 108 | 3 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID| MTL_TXN_SOURCE_TYPES | 1 | 18 | 1 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | MTL_TXN_SOURCE_TYPES_U1 | 1 | | 0 (0)| |
|* 43 | TABLE ACCESS BY INDEX ROWID| MTL_MATERIAL_TRANSACTIONS | 1 | 90 | 2 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | MTL_MATERIAL_TRANSACTIONS_U1 | 1 | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | WIP_ENTITIES | 48143 | 940K| 1 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | WIP_ENTITIES_U1 | 1 | | 0 (0)| |
| 47 | TABLE ACCESS BY INDEX ROWID | FND_USER | 1 | 14 | 1 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | FND_USER_U1 | 1 | | 0 (0)| |
| 49 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_REASONS | 36 | 720 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | MTL_TRANSACTION_REASONS_U1 | 1 | | 0 (0)| |
| 51 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_TYPES | 98 | 2548 | 1 (0)| 00:00:01 |
|* 52 | INDEX UNIQUE SCAN | MTL_TRANSACTION_TYPES_U1 | 1 | | 0 (0)| |
|* 53 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 297 | 20493 | 2 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_B_U1 | 1 | | 1 (0)| 00:00:01 |
| 55 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_TL | 96026 | 1406K| 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | MTL_SYSTEM_ITEMS_TL_U1 | 1 | | 1 (0)| 00:00:01 |
|* 57 | INDEX RANGE SCAN | MTL_ITEM_CATEGORIES_U1 | 1 | 15 | 2 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | MTL_TRANSACTION_LOT_NUMBERS | 1 | 25 | 3 (0)| 00:00:01 |
|* 59 | INDEX RANGE SCAN | MTL_TRANSACTION_LOT_NUMBERS_N1 | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter((:B6<=:B5 AND :B8<=:B7 AND :B2 IS NULL))
13 - access("MTS"."TRANSACTION_SOURCE_TYPE_ID"=5)
14 - filter(("MMT"."TRANSACTION_SOURCE_ID" IS NOT NULL AND
"MMT"."TRANSACTION_TYPE_ID"=NVL(:B4,"MMT"."TRANSACTION_TYPE_ID") AND
"MMT"."SUBINVENTORY_CODE">=NVL(:B10,"MMT"."SUBINVENTORY_CODE") AND
"MMT"."SUBINVENTORY_CODE"<=NVL(:B9,"MMT"."SUBINVENTORY_CODE") AND
NVL("MMT"."REVISION",'-99')=NVL(NVL(:B11,"MMT"."REVISION"),'-99') AND "MMT"."TRANSACTION_ID" IS NOT NULL AND
"MMT"."CREATION_DATE">=:B6 AND "MMT"."CREATION_DATE"<=:B5))
15 - access("MMT"."TRANSACTION_SOURCE_TYPE_ID"=5 AND "MMT"."ORGANIZATION_ID"=:B14 AND
"MMT"."TRANSACTION_DATE">=:B8 AND "MMT"."TRANSACTION_DATE"<=:B7)
filter(NVL(:B3,"MMT"."TRANSACTION_SOURCE_TYPE_ID")=5)
17 - access("MTR"."REASON_ID"="MMT"."REASON_ID")
19 - access("MMT"."TRANSACTION_SOURCE_ID"="WIE"."WIP_ENTITY_ID")
21 - access("MMT"."TRANSACTION_TYPE_ID"="MTT"."TRANSACTION_TYPE_ID")
23 - access("FN"."USER_ID"="MMT"."CREATED_BY")
filter("FN"."USER_ID"=NVL(:B1,"FN"."USER_ID"))
24 - filter(("MSI"."SEGMENT1">=NVL(:B13,"MSI"."SEGMENT1") AND "MSI"."SEGMENT1"<=NVL(:B12,"MSI"."SEGMENT1")))
25 - access("MSI"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND "MSI"."ORGANIZATION_ID"=:B14)
27 - access("MMT"."TRANSACTION_ID"="MTLN"."TRANSACTION_ID")
28 - access("MIC"."ORGANIZATION_ID"=:B14 AND "MIC"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND
"MIC"."CATEGORY_SET_ID"=:B15)
30 - access("MSI"."INVENTORY_ITEM_ID"="MSI_TL"."INVENTORY_ITEM_ID" AND "MSI_TL"."ORGANIZATION_ID"=:B14 AND
"MSI_TL"."LANGUAGE"=USERENV('LANG'))
31 - filter((:B6<=:B5 AND :B8<=:B7 AND :B2 IS NOT NULL))
42 - access("MTS"."TRANSACTION_SOURCE_TYPE_ID"=5)
43 - filter(("MMT"."TRANSACTION_SOURCE_ID" IS NOT NULL AND "MMT"."TRANSACTION_DATE">=:B8 AND
"MMT"."ORGANIZATION_ID"=:B14 AND "MMT"."TRANSACTION_SOURCE_TYPE_ID"=5 AND
NVL(:B3,"MMT"."TRANSACTION_SOURCE_TYPE_ID")=5 AND "MMT"."TRANSACTION_TYPE_ID"=NVL(:B4,"MMT"."TRANSACTION_TYPE_ID"
) AND "MMT"."SUBINVENTORY_CODE">=NVL(:B10,"MMT"."SUBINVENTORY_CODE") AND
"MMT"."SUBINVENTORY_CODE"<=NVL(:B9,"MMT"."SUBINVENTORY_CODE") AND
NVL("MMT"."REVISION",'-99')=NVL(NVL(:B11,"MMT"."REVISION"),'-99') AND "MMT"."TRANSACTION_DATE"<=:B7 AND
"MMT"."CREATION_DATE">=:B6 AND "MMT"."CREATION_DATE"<=:B5))
44 - access("MMT"."TRANSACTION_ID"=:B2)
46 - access("MMT"."TRANSACTION_SOURCE_ID"="WIE"."WIP_ENTITY_ID")
48 - access("FN"."USER_ID"="MMT"."CREATED_BY")
filter("FN"."USER_ID"=NVL(:B1,"FN"."USER_ID"))
50 - access("MTR"."REASON_ID"="MMT"."REASON_ID")
52 - access("MMT"."TRANSACTION_TYPE_ID"="MTT"."TRANSACTION_TYPE_ID")
53 - filter(("MSI"."SEGMENT1">=NVL(:B13,"MSI"."SEGMENT1") AND "MSI"."SEGMENT1"<=NVL(:B12,"MSI"."SEGMENT1")))
54 - access("MSI"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND "MSI"."ORGANIZATION_ID"=:B14)
56 - access("MSI"."INVENTORY_ITEM_ID"="MSI_TL"."INVENTORY_ITEM_ID" AND "MSI_TL"."ORGANIZATION_ID"=:B14 AND
"MSI_TL"."LANGUAGE"=USERENV('LANG'))
57 - access("MIC"."ORGANIZATION_ID"=:B14 AND "MIC"."INVENTORY_ITEM_ID"="MMT"."INVENTORY_ITEM_ID" AND
"MIC"."CATEGORY_SET_ID"=:B15)
59 - access("MMT"."TRANSACTION_ID"="MTLN"."TRANSACTION_ID")
I am doubt why to perform two times explain plan(Predicate -2 and 31).
Thanks

Tom.lai wrote:
I wrote a SQL in Oracle EBS, please see the following:
AND msi.segment1 >= NVL (:b13, msi.segment1)
AND msi.segment1 <= NVL (:b12, msi.segment1)
AND NVL (mmt.revision, '-99') = NVL (NVL (:b11, mmt.revision), '-99')
AND mmt.subinventory_code >= NVL (:b10, mmt.subinventory_code)
AND mmt.subinventory_code <= NVL (:b9, mmt.subinventory_code)
AND mmt.transaction_date BETWEEN :b8 AND :b7
AND mmt.creation_date BETWEEN :b6 AND :b5
AND mmt.transaction_type_id = NVL (:b4, mmt.transaction_type_id)
AND mmt.transaction_source_type_id = NVL (:b3, mmt.transaction_source_type_id)
AND mmt.transaction_id = NVL (:b2, mmt.transaction_id)
AND fn.user_id = NVL (:b1, fn.user_id)I am doubt why to perform two times explain plan(Predicate -2 and 31).Using your NVL expressions above you've hit a special implementation for this particular construct in the Oracle optimizer, for more information, see here:
http://jonathanlewis.wordpress.com/2007/01/09/conditional-sql/
http://jonathanlewis.wordpress.com/2007/02/14/conditional-sql-2/
This splits your plan into two plans for the two cases possible, and depending on if the value passed is NULL or not only one of the branches will actually get executed.
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/

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
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/

Oracle 10g Diff in execution plan query with binding var Vs without

We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'

I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM

Diff in explain plan of 9i and 10g

Similar Messages

Maybe you are looking for