the two execution Plan
Hellocan you be kind to such me which is better and why (based on the columns of the execution Plan):
Execution Plan A
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17)
1 0 SORT (AGGREGATE)
2 1 INDEX (RANGE SCAN) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=1 Bytes=17)
3 2 SORT (AGGREGATE)
4 3 FIRST ROW (Cost=2 Card=6 Bytes=60)
5 4 INDEX (RANGE SCAN (MIN/MAX)) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=1060)
tkprof gek1_ora_16520.trc gek1_ora_16520.out explain=scott/tiger sort=exeela sys=no
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 2 0 0
Fetch 2 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.00 0.00 0 4 0 1 Execution Plan B
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=13)
1 0 COUNT (STOPKEY)
2 1 VIEW (Cost=2 Card=6 Bytes=78)
3 2 INDEX (RANGE SCAN DESCENDING) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=6 Bytes=102)
tkprof gek1_ora_16521.trc gek1_ora_16521.out explain=scott/tiger sort=exeela sys=no
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.03 0.06 2 41 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 2 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.03 0.06 2 43 0 1 What is the version of db? Why you have not posted the actual queries as well? In a very generic view, the first is more beautiful, but is purely based on the elapsed time. What you are actually looking for?
HTH
Aman...
Tags: Database
Similar Questions
-
How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you
How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you
After two execution plans that have the same sql_id, so we can see what you're talking about.
See "Oracle Explain Explain Plan optimizer" by Maria Colgan of the Oracle optimizer group
Examine the various aspects of a selectivity to parallel execution plan
performance and understand what information you should be brilliant
the plan can be overwhelming even for the most experienced DBA. This document
offers a detailed explanation on each of the aspects of the execution plan and a
Overview of what caused the CBO to make the decision, he did.
-
Need help to get the actual execution plan
I need to get the actual execution plan of a query and its actual cost.
If I understand correctly explaining the plan gives only the estimated according to my plan. Can someone help me please?I'm doing this:
SQL> select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where owner='SANTU'; OBJECT_NAME DATA_OBJECT_ID STATUS -------------------------------------------------------------------------------- ------------------------------------------------ -------------- ------- TST_REDEF 73444 VALID REDEF_PK 73447 VALID SQL> select sql_id,sql_text from v$sqlarea where sql_text like '%DATA_OBJECT_ID,STATUS from dba_objects%'; SQL_ID ------------- SQL_TEXT -------------------------------------------------------------------------------- gbvnfhs59t98f select sql_id,sql_text from v$sqlarea where sql_text like '%DATA_OBJECT_ID,STATUS from dba_objects%' bxdyf6ph2g3ay select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where owner='SANTU' SQL> select * from table(dbms_xplan.display_cursor('bxdyf6ph2g3ay')); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- SQL_ID bxdyf6ph2g3ay, child number 0 ------------------------------------- select OBJECT_NAME,DATA_OBJECT_ID,STATUS from dba_objects where owner='SANTU' Plan hash value: 2160718650 ------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 47 (100)| | | 1 | VIEW | DBA_OBJECTS | 1638 | 161K| 47 (3)| 00:00:01 | | 2 | UNION-ALL | | | | | | |* 3 | FILTER | | | | | | |* 4 | HASH JOIN | | 1830 | 209K| 46 (3)| 00:00:01 | | 5 | INDEX FULL SCAN | I_USER2 | 88 | 1936 | 1 (0)| 00:00:01 | | 6 | NESTED LOOPS | | 1830 | 169K| 45 (3)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID| USER$ | 1 | 18 | 1 (0)| 00:00:01 | |* 8 | INDEX UNIQUE SCAN | I_USER1 | 1 | | 0 (0)| | |* 9 | TABLE ACCESS FULL | OBJ$ | 1830 | 137K| 44 (3)| 00:00:01 | |* 10 | TABLE ACCESS BY INDEX ROWID | IND$ | 1 | 8 | 2 (0)| 00:00:01 | |* 11 | INDEX UNIQUE SCAN | I_IND1 | 1 | | 1 (0)| 00:00:01 | | 12 | NESTED LOOPS | | 1 | 29 | 2 (0)| 00:00:01 | |* 13 | INDEX FULL SCAN | I_USER2 | 1 | 20 | 1 (0)| 00:00:01 | |* 14 | INDEX RANGE SCAN | I_OBJ4 | 1 | 9 | 1 (0)| 00:00:01 | | 15 | NESTED LOOPS | | 1 | 97 | 1 (0)| 00:00:01 | | 16 | TABLE ACCESS BY INDEX ROWID | USER$ | 1 | 18 | 1 (0)| 00:00:01 | |* 17 | INDEX UNIQUE SCAN | I_USER1 | 1 | | 0 (0)| | |* 18 | INDEX RANGE SCAN | I_LINK1 | 1 | 79 | 0 (0)| | ------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter(((("O"."TYPE#"<>1 AND "O"."TYPE#"<>10) OR ("O"."TYPE#"=1 AND =1)) AND (("O"."TYPE#"<>4 AND "O"."TYPE#"<>5 AND "O"."TYPE#"<>7 AND "O"."TYPE#"<>8 AND "O"."TYPE#"<>9 AND "O"."TYPE#"<>10 AND "O"."TYPE#"<>11 AND "O"."TYPE#"<>12 AND "O"."TYPE#"<>13 AND "O"."TYPE#"<>14 AND "O"."TYPE#"<>22 AND "O"."TYPE#"<>87 AND "O"."TYPE#"<>88) OR BITAND("U"."SPARE1",16)=0 OR (INTERNAL_FUNCTION("O"."TYPE#") AND ((SYS_CONTEXT('userenv','current_edition_name')='ORA$BASE' AND "U"."TYPE#"<>2) OR ("U"."TYPE#"=2 AND "U"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv','current_edition_id'))) OR IS NOT NULL))))) 4 - access("O"."OWNER#"="U"."USER#") 8 - access("U"."NAME"='SANTU') 9 - filter(("O"."NAME"<>'_NEXT_OBJECT' AND "O"."NAME"<>'_default_auditing_opt ions_' AND "O"."LINKNAME" IS NULL AND BITAND("O"."FLAGS",128)=0 AND "O"." SPARE3"="U"."USER#")) 10 - filter(("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4 OR "I"."TYPE#"=6 OR "I"."TYPE#"=7 OR "I"."TYPE#"=9)) 11 - access("I"."OBJ#"=:B1) 13 - access("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv',' current_ edition_id'))) filter(("U2"."TYPE#"=2 AND "U2"."SPARE2"=TO_NUMBER(SYS_CONTEXT('userenv', 'current _edition_id')))) 14 - access("O2"."DATAOBJ#"=:B1 AND "O2"."TYPE#"=88 AND "O2"."OWNER#"="U2"."US ER#") 17 - access("U"."NAME"='SANTU') 18 - access("L"."OWNER#"="U"."USER#") 57 rows selected. SQL>Kind regards
S.K. -
What is the correct procedure of DMBS_XPLAN for the query execution plan
Hello.
We are on Oracle 11.2.0.3 on Linux. I am dev. DBA and we have about 80 developers Java development team. They want to question the execution plan of queries to resolve the sqls. Generally, they use the GUI tools like the toad to see execution plan. I always use the procedure for the following query execution plan:
Select * from
Table (dbms_xplan.display_cursor (null, null, 'allstats + cost'));I should suggest that they use this too rather than rely on tools like the toad - because they can show estimated plan and not the actual plan. And to provide a sql, it is best to use the real plan to work with. Do not take account of 'allstats + cost' part in the command above, but my point is: should I ask them of still rely on sqlplus and not the GUI tools and use the command display_cursor package DBMS_XPLAN?
I will be grateful for suggestions.
OrauserN
You must use the DBMS_XPLAN package and functionality.
The tool used to run the package doesn't matter. A raw request to DISPLAY_CURSOR will run the same server code in any tool including Toad.
If you rely on other GUI features (for example a "explain plan" button or similar) then you know what this feature of actuall application running under-the-covers.
My suggestion would be to assess and consider using Oracle free sql developer version 4 because it is not only FREE but also uses the DBMS_XPLAN correctly.
-
Get the SQL execution plan that is currently running in 9i
Hello
Apologies for the magnitude of this issue, but I was wondering if someone could help me to the more accurate/efficient way to get a piece of running Oracle 9i SQL execution plan.
in 10g and 11g of course dbms_xplan.display_cursor (sql_id) can be used.
How can this be achieved in 9i, currently I am just get the SQL_TEXT and then executing a plan to explain ("EXPLAIN PLAN for.") - I think that this is not neccesserally the same plan to explain that will be used for the sql code that runs if
Any help would be appreciated.
Thank youThe plan exists after analysis difficult.
Statistics of actual execution will require a completed.
That is why sql followed in real time is so great in 11g.
In 9i, difficult. -
CBO does not choose the right execution plan
Database: Oracle 9.2.0.6 EA
OS: Solaris 9
I'm trying to settle a query that is generated through Siebel Analytics. I see a behavior which is confusing to me but I hope, would be 'basic' for someone like JPL.
The query is based on a total of 7 tables. If I comment on the 2 dimension tables, the query takes the right index finger on the fact table. However, at the point where I have to add another table to the query, the plan goes awry.
The query with 5 tables is as below:
And the implementation plan is as below:select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1, T352305.DAY_DT as c2, case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end as c3, T352305.ROW_WID as c5 from W_PRODUCT_D T30955, W_PRDATTRNM_D T44643, W_DAY_D T352305, W_ORDERITEM_F T30256, W_PRDATTR_D T40081 where ( T30955.ROW_WID = T44643.ROW_WID and T30256.LAST_UPD_DT_WID = T352305.ROW_WID and T30256.PROD_ATTRIB_WID = T40081.ROW_WID and T30256.PROD_WID = T30955.ROW_WID and T30955.PROD_NAME = 'Mobile Subscription' and (case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M')) and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1 ) group by T352305.ROW_WID, T352305.DAY_DT, case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end ;
Note how the dimension tables W_PRODUCT_D & W_DAY_D are connected by a Cartesian join before joining the fact W_ORDERITEM_F table using the composite index 'W_ORDERITEM_F_INDX9 '. This index is composed of LAST_UPD_DT_WID, PROD_WID and ACTION_TYPE_WID, which are foreign keys to the dimension tables.---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 269 | 25824 | 18660 (3)| | 1 | SORT GROUP BY | | 269 | 25824 | 18660 (3)| | 2 | NESTED LOOPS | | 269 | 25824 | 18658 (3)| | 3 | NESTED LOOPS | | 6826 | 579K| 4734 (3)| | 4 | MERGE JOIN CARTESIAN | | 8 | 544 | 6 (17)| | 5 | NESTED LOOPS | | 1 | 54 | 4 (25)| | 6 | TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D | 1 | 37 | 3 (34)| |* 7 | INDEX RANGE SCAN | W_PRODUCT_D_M2 | 1 | | 2 (50)| | 8 | TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D | 1 | 17 | 2 (50)| |* 9 | INDEX UNIQUE SCAN | W_PRDATTRNM_D_P1 | 1 | | | | 10 | BUFFER SORT | | 8 | 112 | 4 (0)| | 11 | TABLE ACCESS BY INDEX ROWID| W_DAY_D | 8 | 112 | 3 (34)| |* 12 | INDEX RANGE SCAN | W_DAY_D_M39 | 8 | | 2 (50)| | 13 | TABLE ACCESS BY INDEX ROWID | W_ORDERITEM_F | 849 | 16131 | 592 (3)| |* 14 | INDEX RANGE SCAN | W_ORDERITEM_F_INDX9 | 852 | | 4 (25)| |* 15 | INDEX RANGE SCAN | W_PRDATTR_D_M29_T1 | 1 | 9 | 3 (34)| ----------------------------------------------------------------------------------------------
Now, if I add several tables to the query:
I added a single table W_ORDER_D to the query and execution plan is:select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1, T352305.DAY_DT as c2, case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end as c3, T30371.X_BT_DLR_GROUP as c4, T352305.ROW_WID as c5 from W_PRODUCT_D T30955, W_PRDATTRNM_D T44643, W_DAY_D T352305, W_ORDERITEM_F T30256, W_ORDER_D T30371, W_PRDATTR_D T40081 where ( T30955.ROW_WID = T44643.ROW_WID and T30256.LAST_UPD_DT_WID = T352305.ROW_WID and T30256.PROD_ATTRIB_WID = T40081.ROW_WID and T30256.PROD_WID = T30955.ROW_WID and T30256.ORDER_WID = T30371.ROW_WID and T30955.PROD_NAME = 'Mobile Subscription' and T30371.STATUS_CD = 'Complete' and T30371.ORDER_TYPE = 'Sales Order' and (case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M')) and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1 ) group by T30371.X_BT_DLR_GROUP, T352305.ROW_WID, T352305.DAY_DT, case when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end;
Now, CBO choose the composite index and the cost has also increased to 78695. But if I just add a / * + SORTED * / referring to the above query, whereas it should join the dimension tables prior to joining the fact table, then the cost falls to 20913. This means that CBO is not choose the plan with the lowest cost. I tried increasing the optimizer_max_permutations 80000, setting session optimizer_dynamic_sampling level 8 (just to see if it works), but without success.----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 44 | 6336 | 78695 (3)| | 1 | SORT GROUP BY | | 44 | 6336 | 78695 (3)| | 2 | NESTED LOOPS | | 44 | 6336 | 78694 (3)| | 3 | NESTED LOOPS | | 269 | 27707 | 78145 (3)| |* 4 | HASH JOIN | | 6826 | 626K| 64221 (3)| | 5 | TABLE ACCESS BY INDEX ROWID | W_DAY_D | 8 | 112 | 4 (25)| |* 6 | INDEX RANGE SCAN | W_DAY_D_M39 | 1 | | 3 (34)| | 7 | TABLE ACCESS BY INDEX ROWID | W_ORDERITEM_F | 86886 | 2206K| 64197 (3)| | 8 | NESTED LOOPS | | 87004 | 6797K| 64200 (3)| | 9 | NESTED LOOPS | | 1 | 54 | 4 (25)| | 10 | TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D | 1 | 37 | 3 (34)| |* 11 | INDEX RANGE SCAN | W_PRODUCT_D_M2 | 1 | | 2 (50)| | 12 | TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D | 1 | 17 | 2 (50)| |* 13 | INDEX UNIQUE SCAN | W_PRDATTRNM_D_P1 | 1 | | | |* 14 | INDEX RANGE SCAN | W_ORDERITEM_F_N6 | 86886 | | 212 (18)| |* 15 | INDEX RANGE SCAN | W_PRDATTR_D_M29_T1 | 1 | 9 | 3 (34)| |* 16 | INDEX RANGE SCAN | W_ORDER_D_N6 | 1 | 41 | 3 (34)| -----------------------------------------------------------------------------------------------
Could you please tell how to overcome this problem?
Thank you very much.joshic wrote:
Hi Randolph,The optimizer is set to 'choose', which is the default in 9i. So I guess that CBO uses the "all_rows" mode, because his stats are present.
According to your advice, I tried to adjust optimizer_mode, first_rows_1, first_rows_10, first_rows_100 and all_rows at the session level, but nothing helped.
Another question: since you are obviously having a schema star why don't you use not three separate bitmap indexes on the foreign key columns in the fact table? In this way, you can use a transformation star rather than using a composite index.
You use many OLTP, small, such as transactions that modify your fact table, or is it only loaded by loading in bulk? If you use only loads in bulk index bitmap should be fine.
Kind regards
RandolfOracle related blog stuff:
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/ -
Same SQL different execution Plans in two different database instances.
Hi all
I run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.
OS: Redhat Linux 5
Database version: 11.2.02 (on two instances)
Plan on 1 Instance that takes 30 minutes.
On the Instance 2SELECT X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, X_REPLEN_RQST_INV_STG.INV_ITEM_ID, X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, X_REPLEN_RQST_INV_STG.REPLEN_STATUS, X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, X_REPLEN_RQST_INV_STG.REQ_ID, X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, P.FIRST_PO_DISP_DT, W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID FROM X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_PURCH_COST_F ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID INNER join W_PURCH_SCHEDULE_LINE_F ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_STATUS_D S1 ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS LEFT OUTER JOIN W_STATUS_D S2 ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT FROM X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = P.PO_ID LEFT OUTER JOIN W_PRODUCT_D ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID LEFT OUTER JOIN X_ITEM_ATTRIB_D ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID WHERE TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL AND X_REPLEN_RQST_INV_STG.replenish_type = '1' AND X_REPLEN_RQST_INV_STG.replen_status = '4' AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' AND S1.STATUS_CODE != 'X' AND S2.STATUS_CODE != 'X' AND P.FIRST_PO_DISP_DT IS NOT NULL Execution Plan ---------------------------------------------------------- Plan hash value: 1674299164 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 461 | 13942 (1)| 00:04:11 | |* 1 | HASH JOIN | | 1 | 461 | 13942 (1)| 00:04:11 | | 2 | NESTED LOOPS | | | | | | | 3 | NESTED LOOPS | | 1 | 441 | 10409 (1)| 00:03:08 | | 4 | NESTED LOOPS | | 1 | 421 | 10407 (1)| 00:03:08 | | 5 | NESTED LOOPS | | 1 | 388 | 10406 (1)| 00:03:08 | | 6 | NESTED LOOPS | | 1 | 319 | 10405 (1)| 00:03:08 | | 7 | NESTED LOOPS | | 1 | 280 | 10404 (1)| 00:03:08 | |* 8 | HASH JOIN | | 1 | 220 | 10401 (1)| 00:03:08 | | 9 | NESTED LOOPS | | | | | | | 10 | NESTED LOOPS | | 16 | 2896 | 10392 (1)| 00:03:08 | |* 11 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 16 | 2432 | 10375 (1)| 00:03:07 | |* 12 | INDEX UNIQUE SCAN | W_RQST_LN_CS_F_U1 | 1 | | 1 (0)| 00:00:01 | | 13 | TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F | 1 | 29 | 2 (0)| 00:00:01 | |* 14 | TABLE ACCESS FULL | W_STATUS_D | 1 | 39 | 8 (0)| 00:00:01 | | 15 | TABLE ACCESS BY INDEX ROWID | W_PURCH_COST_F | 1 | 60 | 3 (0)| 00:00:01 | |* 16 | INDEX RANGE SCAN | W_PURCH_COST_F_M1 | 1 | | 2 (0)| 00:00:01 | |* 17 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 39 | 1 (0)| 00:00:01 | |* 18 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | | 19 | TABLE ACCESS BY INDEX ROWID | W_PURCH_SCHEDULE_LINE_F | 1 | 69 | 1 (0)| 00:00:01 | |* 20 | INDEX UNIQUE SCAN | W_PRCH_SC_LN_F_U1 | 1 | | 1 (0)| 00:00:01 | | 21 | TABLE ACCESS BY INDEX ROWID | W_PRODUCT_D | 1 | 33 | 1 (0)| 00:00:01 | |* 22 | INDEX UNIQUE SCAN | W_PRODUCT_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 23 | INDEX RANGE SCAN | X_ITEM_ATTRIB_U01 | 1 | | 1 (0)| 00:00:01 | |* 24 | TABLE ACCESS BY INDEX ROWID | X_ITEM_ATTRIB_D | 1 | 20 | 2 (0)| 00:00:01 | | 25 | VIEW | | 1428K| 27M| 3529 (2)| 00:01:04 | |* 26 | FILTER | | | | | | | 27 | HASH GROUP BY | | 1428K| 27M| 3529 (2)| 00:01:04 | | 28 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 3493 (1)| 00:01:03 | ----------------------------------------------------------------------------------------------------------------
In the second execution plan, we can see that it uses a Cartesian product.SELECT X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, X_REPLEN_RQST_INV_STG.INV_ITEM_ID, X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, X_REPLEN_RQST_INV_STG.REPLEN_STATUS, X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, X_REPLEN_RQST_INV_STG.REQ_ID, X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, P.FIRST_PO_DISP_DT, W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID FROM X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_PURCH_COST_F ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID INNER join W_PURCH_SCHEDULE_LINE_F ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_STATUS_D S1 ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS LEFT OUTER JOIN W_STATUS_D S2 ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT FROM X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = P.PO_ID LEFT OUTER JOIN W_PRODUCT_D ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID LEFT OUTER JOIN X_ITEM_ATTRIB_D ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID WHERE TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL AND X_REPLEN_RQST_INV_STG.replenish_type = '1' AND X_REPLEN_RQST_INV_STG.replen_status = '4' AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' AND S1.STATUS_CODE != 'X' AND S2.STATUS_CODE != 'X' AND P.FIRST_PO_DISP_DT IS NOT NULL --------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 420 | 19630 (1)| 00:04:35 | | 1 | NESTED LOOPS | | | | | | | 2 | NESTED LOOPS | | 1 | 420 | 19630 (1)| 00:04:35 | | 3 | NESTED LOOPS | | 1 | 400 | 19627 (1)| 00:04:35 | | 4 | NESTED LOOPS | | 1 | 386 | 19626 (1)| 00:04:35 | | 5 | NESTED LOOPS | | 1 | 317 | 19625 (1)| 00:04:35 | | 6 | NESTED LOOPS | | 1 | 289 | 19624 (1)| 00:04:35 | | 7 | NESTED LOOPS | | 1 | 229 | 19621 (1)| 00:04:35 | | 8 | NESTED LOOPS | | 1 | 201 | 19620 (1)| 00:04:35 | | 9 | MERGE JOIN CARTESIAN | | 1 | 172 | 19619 (1)| 00:04:35 | | 10 | VIEW | | 1 | 20 | 4942 (2)| 00:01:10 | |* 11 | FILTER | | | | | | | 12 | HASH GROUP BY | | 1 | 20 | 4942 (2)| 00:01:10 | | 13 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 4902 (1)| 00:01:09 | | 14 | BUFFER SORT | | 1 | 152 | 19619 (1)| 00:04:35 | |* 15 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 1 | 152 | 14676 (1)| 00:03:26 | | 16 | TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F | 1 | 29 | 1 (0)| 00:00:01 | |* 17 | INDEX UNIQUE SCAN | W_RQST_LN_CS_F_U1 | 1 | | 1 (0)| 00:00:01 | |* 18 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 28 | 1 (0)| 00:00:01 | |* 19 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | | 20 | TABLE ACCESS BY INDEX ROWID | W_PURCH_COST_F | 3 | 180 | 3 (0)| 00:00:01 | |* 21 | INDEX RANGE SCAN | W_PURCH_COST_F_M1 | 1 | | 2 (0)| 00:00:01 | |* 22 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 28 | 1 (0)| 00:00:01 | |* 23 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 24 | TABLE ACCESS BY INDEX ROWID | W_PURCH_SCHEDULE_LINE_F | 1 | 69 | 1 (0)| 00:00:01 | |* 25 | INDEX UNIQUE SCAN | W_PRCH_SC_LN_F_U1 | 1 | | 1 (0)| 00:00:01 | |* 26 | TABLE ACCESS BY INDEX ROWID | W_PRODUCT_D | 1 | 14 | 1 (0)| 00:00:01 | |* 27 | INDEX UNIQUE SCAN | W_PRODUCT_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 28 | INDEX RANGE SCAN | X_ITEM_ATTRIB_U01 | 1 | | 2 (0)| 00:00:01 | |* 29 | TABLE ACCESS BY INDEX ROWID | X_ITEM_ATTRIB_D | 1 | 20 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------------
Thank you.Oceaner wrote:
Hi allI run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.
The most obvious difference is the subquery total inline:
Quick plan:
---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------- |* 1 | HASH JOIN | | 1 | 461 | 13942 (1)| 00:04:11 | | 2 | NESTED LOOPS | | | | | | ... | 25 | VIEW | | 1428K| 27M| 3529 (2)| 00:01:04 | |* 26 | FILTER | | | | | | | 27 | HASH GROUP BY | | 1428K| 27M| 3529 (2)| 00:01:04 | | 28 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 3493 (1)| 00:01:03 | ----------------------------------------------------------------------------------------------------------------Plan of slow
--------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------------- ... | 9 | MERGE JOIN CARTESIAN | | 1 | 172 | 19619 (1)| 00:04:35 | | 10 | VIEW | | 1 | 20 | 4942 (2)| 00:01:10 | |* 11 | FILTER | | | | | | | 12 | HASH GROUP BY | | 1 | 20 | 4942 (2)| 00:01:10 | | 13 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 4902 (1)| 00:01:09 | | 14 | BUFFER SORT | | 1 | 152 | 19619 (1)| 00:04:35 | |* 15 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 1 | 152 | 14676 (1)| 00:03:26 | ... ---------------------------------------------------------------------------------------------------------------Note the value of lines given to the operation - VIEW
One for the slow plan - that of why Oracle chose display online as a starting point for the query and used a Cartesian merge join to join to the table nearby.1.4Million for the fast plan - this is why Oracle has decided to visit the table set and use it as the table of the probe in a hash join.
I think we can assume that the estimation of the single line is a big mistake. We can also assume that the two series of statistics (or possibly index definitions) on the tables two versions do not match.
It would be useful, of course, see the comprehensive implementation plan, and preferably one from memory: (http://jonathanlewis.wordpress.com/2006/12/22/dbms_xplan-again/).
You might notice that you outer joins are not relevant - maybe this SQL is a framework for a more general query - given that the plan shows that they have all been turned away.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle -
Should I wait until the end of the execution time of the query for the execution plan?
Hello Experts,
I want to see the execution plan of the query below. However, it takes more than 3 hours. Should I wait all the time to see the execution plan?
Note: EXPLAIN PLAN for does not work. (I mean that I do not see the actual line number, etc. with EXPLAIN the PLAN of market)
You can see the output of the execution plan when I canceled the execution after 1 minute.
My first question is: what should I do to see the execution plan for queries running out of time time?
2nd question: when I cancel the query during execution in order to see the execution plan, will I see the specific plan of execution or erroneous values? Because the first execution plan seems inaccurate, what do you think?
question 3: why EXPLAIN the PLAN for the clause does not work? Also, should I use EXPLAIN the PLAN of the clause to this scenerio? Can I see the result of running for long time without her queries?
Thnaks for your help.
Oracle Database 11 g Enterprise Edition Release 11.2.0.2.0 - 64 bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE Production 11.2.0.2.0
AMT for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SQL_ID, dznya6x7st0t8, number of children 0
-------------------------------------
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT,.
J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price of
CustInvoiceJour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
Hash value of plan: 2002317666
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Begins | E - lines. A - lines. A - time | Pads | Bed | OMem | 1Mem | Used Mem.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 1 | HASH JOIN | | 1. 3956. 0 | 00:00:00.01 | 0 | 0 | 2254K | 1061K | 2190K (0) |
|* 2 | HASH JOIN | | 1. 87. 16676. 00:00:01.64 | 227K | 3552. 3109K | 1106K | 4111K (0) |
|* 3 | TABLE ACCESS BY INDEX ROWID | CUSTINVOICEJOUR | 1. 1155 | 31889 | 00:00:01.16 | 223KO | 15. | | |
|* 4 | INDEX RANGE SCAN | I_062INVOICEDATEORDERTYPEIDX | 1. 4943 | 134K | 00:00:00.83 | 45440 | 0 | | | |
| 5. SIMPLE LIST OF PARTITION. | 1. 82360 | 173K | 00:00:00.08 | 3809 | 3537 | | | |
|* 6 | TABLE ACCESS FULL | AVTR_SEG_CUST_CAMPEND | 1. 82360 | 173K | 00:00:00.06 | 3809 | 3537 | | | |
| 7. TABLE ACCESS BY INDEX ROWID | CUSTINVOICETRANS | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 8 | INDEX RANGE SCAN | I_064INVLINENUMCAMPAIGNOFPRICE | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("J".") "SYS_NC00299$"="T". "' SYS_NC00165$ ' AND SUBSTR (NLS_LOWER ('J'. "" "" REFFACTURE")(, 1, 25) = SUBSTR (NLS_LOWER ("T"." "" "REFFACTURE")(, 1, 25)).
2 - access("J".") INVOICEACCOUNT '= SYS_OP_C2C ("EC". ". ACCOUNTNUM'))
3 - filter("J".") AVAWARDSALES"> 190)
4 - access("J".") SYS_NC00299$ "= U ' 201"AND "J". INVOICEDATE"> = TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"J"." SYS_NC00307$ "= U ' 201406"AND "J". INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss')))
filter ((' J'. "INVOICEDATE' > = 'J' AND TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') '." " SYS_NC00307$ "= U '201406' AND"
"J"." INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss'))))
6 filter (("CE". "SEGMENT_LEVEL" = A "OR"THIS"." SEGMENT_LEVEL "=" E"))
8 - access("T".") SYS_NC00165$ "= U ' 201"AND "T". AVBROCHURELINENUM "= 29457)
filter ("T". ("AVBROCHURELINENUM" = 29457)
EXPLAIN PLAN FOR
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR);
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR ('7h1nbzqjgwsp7', 2));
SQL_ID, 7h1nbzqjgwsp7, number of children 2
EXPLAIN PLAN for select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * /.
J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE,
(T.LINEAMOUNT + T.LINEAMOUNTTAX) join price j custinvoicejour
CustInvoiceTrans t on substr (nls_lower (j.dataareaid), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
NOTE: cannot fetch SQL_ID plan: 7h1nbzqjgwsp7, CHILD_NUMBER: 2
Check the value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in the cursor cache (check v$ sql_plan)
NightWing wrote:
Randolf,
I don't understand. What you hear from the above statement that you mean A-lines and E will be incorrect, but the ratio between them remain the same. Therefore, you can deduct the bad things by comparing the differences.
Thus, A-lines always give a wrong result for cancellation of queries, isn't it?
Charlie,
I think that Martin gave a good explanation. Here's another example that hopefully makes more obvious things:
17:56:55 SQL >-things go very wrong here with a small buffer cache
17:56:55 SQL >-T2 lines are badly scattered when you access through T1. FK
17:56:55 SQL >--
17:56:55 SQL >-"Small job" approach would have been a good idea
17:56:55 SQL >-if the estimate of 100 iterations of the loop was correct!
17:56:55 SQL > select
17:56:55 (t2.attr2) count 2
17:56:55 3 of
17:56:55 4 t1
17:56:55 5, t2
17:56:55 6 where
17:56:55 7 /*------------------*/
17:56:55 8 trunc (t1.attr1) = 1
17:56:55 9 and trunc (t1.attr2) = 1
17:56:55 10 / *-* /.
17:56:55 11 and t1.fk = t2.id
17:56:55 12.
T1
*
ERROR on line 4:
ORA-01013: user has requested the cancellation of the current operation
Elapsed time: 00:04:58.30
18:01:53 SQL >
18:01:53 SQL > @xplan_extended_display_cursor ' ' ' ' 'ALLSTATS LAST + COST.
18:01:53 SQL > set echo off verify off termout off
SQL_ID, 353msax56jvvp, number of children 0
-------------------------------------
SELECT count (t2.attr2) from t1, t2 where
/ / *-* trunc (t1.attr1) = 1 and
trunc (T1.attr2) = 1 / *-* / and t1.fk = t2.id
Hash value of plan: 2900488714
------------------------------------------------------------------------------------------------------------------------------------
| ID | The NEST | DSB | Operation | Name | Begins | E - lines. Cost (% CPU). A - lines. A - time | Pads | Bed |
------------------------------------------------------------------------------------------------------------------------------------
| 0 | | 7. SELECT STATEMENT | | 1. | 4999 (100) | 0 | 00:00:00.01 | 0 | 0 |
| 1. 0 | 8 2 GLOBAL TRI | | 1. 1. | 0 | 00:00:00.01 | 0 | 0 |
| 2. 1. 5. NESTED LOOPS | | 1. | | 57516 | 00:04:58.26 | 173K | 30770 |
| 3. 2. 3. NESTED LOOPS | | 1. 100. 4999 (1) | 57516 | 00:00:21.06 | 116K | 3632.
|* 4 | 3. 1. TABLE ACCESS FULL | T1 | 1. 100. 4799 (1) | 57516 | 00:00:00.19 | 1008 | 1087 |
|* 5 | 3. 2. INDEX UNIQUE SCAN | T2_IDX | 57516 | 1. 1 (0) | 57516 | 00:00:20.82 | 115K | 2545 |
| 8 2 2 | 4. TABLE ACCESS BY INDEX ROWID | T2 | 57516 | 1. 2 (0) | 57516 | 00:04:37.14 | 57516 | 27138 |
------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
4 filter ((TRUNC ('T1'. "ATTR1") = 1 AND TRUNC ('T1'. " ATTR2') = 1))
5 - access("T1".") FK '= 'T2'.' (ID')
You say here that I canceled a query after about 5 minutes, and looking at the statistics of content (RowSource) I can already say the following:
1. the estimation of cardinality of T1 is far - the optimizer estimated 100 lines, but it actually generated more than 57000 lines when the query was cancelled. If this definitely seems like a candidate at the origin of the problems
2. the query has spent most of the time in search of random table T2
So while it is true that I don't know final A-lines of this cancelled query information, I can still say a lot of this and begin to deal with the problems identified so far.
Randolf
-
order of operations in the execution plan
Hello
I'm not sure if my order of the following execution plan is correct.
So hopefully someone can confirm or refute my order of the plan.
This is the query:
SELECT DISTINCT 'A3. ' "' ISIN '.
Of
"WERTPAPIERE" "A3."
"LOGTABLE" "A2."
"WP_STATUS" "A1".
WHERE
"A2". "PK_ID"= "A3". "" IDENTITY CARD "AND
"A2". "" REFERENCE "> TIMESTAMP' 2014-01-06 18:30 ' AND
"A2". "" REFERENCE "< = TIMESTAMP' 2014-01-08 07:00 ' AND
"A2". "" LOG_DATUM "> TIMESTAMP' 2014-01-07 18:30 ' AND
"A2". "" LOG_DATUM "< = TIMESTAMP' 2014-01-08 07:00 ' AND
"A2". "TABLE" = "WERTPAPIERE" AND "
"A3". ' BATCH '= 'A1'. "" IDENTITY CARD "AND
"A1". "" CODE "<>" * 33' AND "
(THERE ARE
(SELECT "BESTANDS_MERKM" 0 "A7"
WHERE 'A7 '. "ID"= "A3". "' BESTANDS_MERKMAL_ID ' AND ('A7'. "CODE"= "1" OR "A7". "CODE"(= '2')) AND ("A3" ".") " USER name "= 'Ect' OR 'A3'." USER name "= 'pro' OR 'A3'". "" Username "(= 'prom') or does NOT EXIST"
(SELECT 0
OF 'BESTANDS_MERKM' "A6".
WHERE "A6". «ID «= NVL ("A3".» ("' BESTANDS_MERKMAL_ID ', 0) AND ("A6". "CODE"= "1" OR "A6". "CODE"(= '2')) AND ("A3" ".") " Username "="Res"OR"A3"." Username "(= 'prom') AND ("A3"". ")" LOESCH_KZ_ID' IS NULL OR EXISTS
(SELECT 0
OF 'WERTPAPIER_LOESCH_KZ' "A5".
WHERE "A5". "ID"= "A3". "' LOESCH_KZ_ID ' AND 'A5 '. (("CODE"="1")) AND THERE ARE
(SELECT 'PRODUKTGRUPPE_SEGMENT' 0 'A4'
WHERE "A4". "ID"= "A3". "' PRODUKTGRUPPE_SEGMENTIERUNG_ID ' AND ('A4'. "CODE"= "USE" OR "A4". "CODE"= "ZUUZ" OR "A4". "CODE"= "4000" OR "A4". "CODE"= "5000" OR "A4". "CODE"= "3000" OR "A4". "CODE"= "4444" OR "A4". "CODE"= "4445" OR "A4". "CODE"= "5544" OR "A4". "CODE"= "6544" OR "A4". «CODE ' = ' 6543 "OR"A4".» ((("CODE"="8765')))
The plan has been acquired through dbms_xplan:
Select * from table (dbms_xplan.display_cursor (format = > 'ALLSTATS LAST SCHEMA'));
Here's the plan:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Begins | E - lines. A - lines. A - time | Pads | Bed | OMem | 1Mem | Used Mem.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. | 1252 | 00:05:55.03 | 11 M | 594K | | | |
| 1. UNIQUE HASH | | 1. 28517 | 1252 | 00:05:55.03 | 11 M | 594K | 1135K | 1135K | 2976K (0) |
|* 2 | FILTER | | 1. | 2579 | 00:05:55.02 | 11 M | 594K | | | |
|* 3 | HASH JOIN | | 1. 571K | 2219K | 00:05:53.49 | 11 M | 594K | 1306K | 1306K | 1 272 K (0) |
|* 4 | INDEX SCAN FULL | WP_STAT_UPI | 1. 57. 57. 00:00:00.01 | 1. 0 | | | |
| 5. NESTED LOOPS | | 1. | 2219K | 00:05:52.17 | 11 M | 594K | | | |
| 6. NESTED LOOPS | | 1. 583K | 2219K | 00:00:18.62 | 726K | 436K | | | |
| 7. RANGE OF SINGLE PARTITION | | 1. 583K | 2219K | 00:00:12.29 | 436K | 436K | | | |
| 8. PARTITION LIST ALL | | 1. 583K | 2219K | 00:00:11.96 | 436K | 436K | | | |
|* 9 | TABLE ACCESS FULL | LOGTABLE | 4. 583K | 2219K | 00:00:11.61 | 436K | 436K | | | |
| * 10 | INDEX UNIQUE SCAN | WP_PK_I | 2219K | 1. 2219K | 00:00:05.34 | 289K | 491. | | |
| 11. TABLE ACCESS BY INDEX ROWID | WERTPAPIERE | 2219K | 1. 2219K | 00:05:32.59 | 10 M | 157K | | | |
| * 12 | TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM | 5. 1. 2. 00:00:00.01 | 8. 0 | | | |
| * 13 | INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I | 5. 1. 4. 00:00:00.01 | 4. 0 | | | |
| * 14 | TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM | 3. 1. 0 | 00:00:00.01 | 5. 0 | | | |
| * 15 | INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I | 3. 1. 2. 00:00:00.01 | 3. 0 | | | |
| * 16. TABLE ACCESS BY INDEX ROWID | PRODUKTGRUPPE_SEGMENT | 3. 1. 2. 00:00:00.01 | 6. 0 | | | |
| * 17. INDEX UNIQUE SCAN | PRG_SEG_PK_I | 3. 1. 3. 00:00:00.01 | 3. 0 | | | |
| * 18. INDEX UNIQUE SCAN | WERTPAPIER_LOESCH_KZ_UPI | 2. 1. 1. 00:00:00.01 | 2. 0 | | | |
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Vector data
-------------
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE ('11.2.0.3')
DB_VERSION ('11.2.0.3')
ALL_ROWS
OUTLINE_LEAF(@"SEL$2")
OUTLINE_LEAF(@"SEL$3")
OUTLINE_LEAF(@"SEL$4")
OUTLINE_LEAF(@"BLOCK1")
OUTLINE_LEAF(@"SEL$1")
OUTLINE(@"BLOCK1")
FULL (@"SALT$ 1" "A2"@"SEL$1")
INDEX (@"SALT$ 1" "A3"@"SEL$1" ("WERTPAPIERE".) "ID")) "
INDEX (@"SALT$ 1" "A1"@"SEL$1" ("WP_STATUS".) "CODE" "WP_STATUS" "." " ID'))
LEADING (@"SALT$ 1" "A2"@"SEL$1" "A3"@"SEL$1" "A1"@"SEL$1")
USE_NL (@"SALT$ 1" "A3"@"SEL$1")
NLJ_BATCHING (@"SALT$ 1" "A3"@"SEL$1")
USE_HASH (@"SALT$ 1" "A1"@"SEL$1")
SWAP_JOIN_INPUTS (@"SALT$ 1" "A1"@"SEL$1")
USE_HASH_AGGREGATION(@"SEL$1")
INDEX_RS_ASC (@"BLOCK1" "A4"@"BLOCK1" ("PRODUKTGRUPPE_SEGMENT".) "ID")) "
INDEX (@"SALT$ 4" "A5"@"SEL$4" ("WERTPAPIER_LOESCH_KZ".) "CODE" "WERTPAPIER_LOESCH_KZ" "." " ID'))
INDEX_RS_ASC (@"SALT$ 3" "A6"@"SEL$3" ("BESTANDS_MERKM".) "ID")) "
INDEX_RS_ASC (@"SALT$ 2" "A7"@"SEL$2" ("BESTANDS_MERKM".) "ID")) "
END_OUTLINE_DATA
*/
According to independent-combine- JOIN operation by HASH, I assumed the first operation's Id 4 because the "INDEX FULL SCAN' on 'WP_STAT_UPI' is the first child.
So I guess the order of operations by Id is 4,9,10 and so on.
I got my information from the official oracle documentation, the book of Troubleshooting Oracle Performance (APRESS) and some research on the internet.
Unfortunately so far I have found a good documentation on the scheduling. Most of the tutorials and documentation talk a lot operations themselves, but very little about the opening sequence.
According to the section ATTACK to State "LEADING(@"SEL$1""A2"@"SEL$1""A3"@"SEL$1""A1"@"SEL$1")", for the classification should be Id: 9,10 and so on.
I also tried to find order information in the v$ sql_plan. The database version is 11.2.
Any help welcome.
Best regards
Your interpretation is correct (even if you have obscured the lines 5-8, but they do not add significant value to what you're saying).
The explanation of the difference between your interpretation and the indicator leading() is the indicator USE_HASH() is accompanied by a hint of swap_join_inputs(). Hash joins | Oracle scratchpad indicator tells you the order of join optimizer was examining, but the optimizer exchange the roles of man and hash tables when it comes to her 'now to join A1 (WP_STAT)' part of the analysis - and this is reflected in the implementation plan.
Symbolically, the main indicator says
You should join A2 and A3--> (A2, A3)
Then you must join A1--> ((A2, A3), A1)
But Exchange - join entries. (A1, (A2, A3))
Concerning
Jonathan Lewis
-
How to capture the execution plan for a query
Hi all
Can someone help me please to find the command to capture the execution plan for a query.
Execution plan for select * from EMP where < condition >
Is getting executed successfully, but I need to get the appropriate for the same execution plan.
Thank youRead the Doc
-
Version 12: Same SQL, another scheme == > different execution plan?
I'm testing a huge application with a database middleware sophisticated against the Oracle 12 database. So far, it works well with Pervasive SQL, MSSQL and Oracle 8 database... 11.
There are many questions about execution plans changed from Version 11 to 12. Oracle will tell what all of the improvements are (or at least have to improvements), and I can't really denied him. It's not the subject.
But I met some SQLs with horrible execution time, especially connected to Crystal Reports. Whenever I tried to check them, the queries have been executed quickly. As far as I can see, this has to do with the schema/user who executes the SQL statement in a first time. Here are the details:
• = ADMIN, DML = GUI DDL: all data are stored in a scheme of the ADMIN. The ADMIN user creates the tables, views and so on. It grants access to and creates synonyms for users, but it cannot modify the data using DML, given that triggers prevent him. End users, named 'GUI' users, are allowed to use the DML, but they have no privileges DDL.
• Database of reports (on paper) are generally quite complex. They have only a limited data set (must fit on sheets of paper!), and the Oracle optimizer optimizes often against this goal. Because Crystal Reports generates no advice, most of the reports are based on a view ADMIN. < xyz > (with the necessary information) and are accessible via a GUI. < xyz > synonym of user GUI.
• Crystal Reports running slowly (~ 5 minutes) connected as a GUI. I export it, get the SQL export, log in as an ADMINISTRATORand run the query, it works quickly (~ 2 seconds). Well, I've probably changed some white space, the line endings and others then copy / paste, I don't?
• I tried many things, connecting both GUI and ADMIN, simplifying the application, execution and so on. Then I got confused version of who this query: when the ADMIN has added an additional space character it was fast, removed again and it was slow again. Whitespace have an influence on the execution plan? Probably not, and if yes, my vision of the world would collapse.
• Later, I found out: in Version 12, depends on the user executing this query. Nail down us the source of the query for the synonym GUI. < xyz >. Let us make a new version of it (coded by white space - smile), and if run you it like GUI first, it's slow. Even if you re - log on as ADMINISTRATOR, the same version of this query is still slow. (This is a bug!)
Question 1: When I prepend the SQL with 'EXPLAIN PLAN FOR', I seem to be changing. As GUI has no plan_table and no privilege to explain a plan, I can't spy on the implementation plan of 'bad '. I don't want to give too much GUI, and I fear it could alter the execution plan. Is there a trick to get the plan of execution of a SQL statement in v$ sql or v$ sqlarea? (Means: execute the query: GUI and explain it as an ADMINISTRATOR)
Question 2: Is this on the privileges of the GUI? What you think, what direction will further investigate?
Oracle database generates an execution plan based on SQL, the dictionary, the statistics, the privileges of the user of the analysis and database and session settings. One of the privileges is GRANT MERGE [ALL] DISPLAY, which was responsible for the difference in this particular example and in this particular version.
When you log on as another user and run the same code in SQL, Oracle database verifies all required components before she reuses the old execution plan. This is a minor bug, but it is.
In the example, the privilege GRANT MERGE ANY NOTICE was given implicitly by the DBA privilege. Because MERGE ANY VIEW disables security controls, the privilege of s/n, default, also disables security controls. This is not a desired behavior from the DBA privilege.
-
Why sql_trace sometimes generate an execution plan
I use "alter session set sql_trace = true;" to trace a package.
I use the tkprof to format the raw trace with no options.
But there's one thing confuses me.
In the trace of any statement have plans of execution as below.
SELECT BATCH_ID FROM OPS_DW_BUSINESS_DT WHERE CURRENT_I = 'Y' AND OPS_NAME = :B1 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 2 0.00 0.00 0 0 0 0 Fetch 2 0.00 0.00 1 2 0 2 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 5 0.00 0.00 1 2 0 2 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 61 (recursive depth: 1) Rows Row Source Operation ------- --------------------------------------------------- 2 INDEX RANGE SCAN OPS_DW_BUSINESS_DT_IDX1 (cr=2 pr=1 pw=0 time=350 us)(object id 135871)
Any statement have no implementation plan
******************************************************************************** SELECT ACTIVITY_CODE,TRIP,EQUIPMENT_N,LOCATION,DISC_VSL_NAME,DISC_VOY, LOAD_VSL_NAME,LOAD_VOY,MOVE_OPS, ACTIVITY_DT, ACT_SEQ, LAG(TRIP, 1) OVER(ORDER BY TRIP, ACTIVITY_DT, ACT_SEQ) AS PREV_TRIP, LEAD(TRIP, 1) OVER(ORDER BY TRIP, ACTIVITY_DT, ACT_SEQ) AS NEXT_TRIP FROM OIS_HRLY_PMOPS B WHERE ( BATCH_ID = :B3 AND (INSTR(:B2 , ACTIVITY_CODE) <> 0 OR INSTR(:B1 , ACTIVITY_CODE) <> 0) ) OR ( BATCH_ID < :B3 AND (INSTR(:B2 , ACTIVITY_CODE) <> 0 OR INSTR(:B1 , ACTIVITY_CODE) <> 0) AND EXISTS (SELECT 1 FROM OIS_HRLY_PMOPS C WHERE C.BATCH_ID = :B3 AND C.TRIP=B.TRIP) ) ORDER BY TRIP, ACTIVITY_DT, ACT_SEQ call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.02 0.01 0 0 0 0 Fetch 2246 25.77 24.87 0 46319 0 224517 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2248 25.79 24.88 0 46319 0 224517 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 61 (recursive depth: 1) ********************************************************************************
I know that I can use the tkprof explain = name of user and password to force generate a. But for the time being. Why some statement make execution plan while others have not?
Concerning
Monique
> Source line operation lines
What you have is Source line operations - the * real * execution plan.
The EXPLAIN command option gives you the estimated execution plan.
Why didn't you not operations Source online for all SQLs? Row Source operations are printed only if the cursor is closed. Usually in pure SQL sessions, SQL cursor is closed when the following SQL is running. However, with PLSQL and stored procedures, the procedure cannot close the cursor for the SQL statement, it calls (closing is made when the session is closed). In such a case, the operations line Source not to print.
Hemant K Collette
-
explain the analysis analyzed, plan implementation, the hash value code
whts the hash value, code analysis, plan to run?
can we see the hash value?The analysis is the first step in the treatment of any statement in an Oracle database. Statements are broken down into its components and so DML or DDL statement type is determined and different controls are carried out on this subject. A statement must be evaluated and validated before execution. Oracle evaluates statements for syntax, the validation of objects and the privileges assigned to the user.
Oracle hash value will check privileges for any SQL statement, and then assigns a number called the hash value SQL for the SQL statement to check whether or not this statement exists in memory
The statement execution plan, will select the best methods to access the SQL statement
http://www.articles.freemegazone.com/Oracle-parsing.php
-
Hello
Most of the time that I see the actual execution plan (run time) differs from the plan we get grace explains (plan estimated). or several times the execution plan obtained using "explain plan" differs from the plan we get from 'awrsqrpt.sql' or 'sprepsql.sql '.
Why does this happen?
Thank you and best regards.One more for the list:
http://hoopercharles.WordPress.com/2010/01/11/explain-plan-lies-AutoTrace-lies-TKPROF-lies-what-is-the-plan/The above shows a test case where same TKPROF displayed the level of poor execution, even when the EXPLAIN of TKPROF command option is not used.
The best option is to use DBMS_XPLAN. DISPLAY_CURSOR to pull the actual execution directly plan from the memory of the server (or use a 10046 trace to capture execution plans, as the SQL statements are executed). Note that there may be several cursors child in memory for a SQL statement only due to changes in the environment of optimization, permissions on the referenced objects bind peeking, collection of statistics, adaptive cursor sharing, and an improvement in Oracle Database 11.2.0.1 that re - optimizes some SQL statements after execution of a repetition that return numbers significantly different lines in the steps of the execution plan than what has been predicted by the optimizer - in this case even for the SQL statements that make does not bind variables (this feature is called feedback cardinality).
See this series into three parts in order to recover the actual execution plan:
http://hoopercharles.WordPress.com/2010/01/30/execution-plans-what-is-the-plan-and-where-do-i-find-it/Charles Hooper
Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
http://hoopercharles.WordPress.com/
IT Manager/Oracle DBA
K & M-making Machine, Inc. -
How to clear failed execution Plans?
Hello world
This should be an easy thing, but I can't seem to find a way to do it.
I created a custom implementation plan and added each financial area in the plan. Then I generated settings, you click on build and then he ran. Failed to run.
I noticed that there is a pre-configured with "R12 Financials_Oracle" execution plan and decided that I wanted to really run was Financials_Oracle R12 and not my personal plan. So I clicked on build for R12 Financials_Oracle plan of execution, and once it is finished, I clicked 'Run Now'. When you click Run now he told me that my custom implementation plan was completed with a failed State and until she is done correctly, no other plan could be run. I really don't want my custom plan completes successfully. I want to run the other plan instead.
How to remove/delete on my failure run data so I can start a new execution plan?
Thanks for the help!
-JoeIn DACS under the window RUN, do the following:
-Go to the tab "Run in progress".
-Highlight the execution plan has failed.
-Click right and selected 'Brand.' as completed
-Enter the number/text in the box.Then:
-In the toolbar at the top of the page, select--> management ETL tools--> reset Data Sources
-Enter the number/text in the boox.Now you are ready to start the new execution plan.
I hope this helps.
-Austin
Maybe you are looking for
-
Graphic problem on Satellite P200-13Z
Hello Satellite P200-13z running 32-bit vista - intel graphics software displays + does not work because of insufficient resources + other checks indicate that the chip has no allocated memory.Machine runs Ok'ish on the LCD screen in mode VGA base bu
-
F20-137: Bluetooth does not work if connect my mobile phone
I recently bought a F20-137 for my son and when I hack with her at Christmas bluetooth apeared in configfree, but today I decided to try and connect my mobile phone via bluetooth and there is no bluetooth option in configfree where it should be accor
-
Voicemail - automatic password entry
Someone knows how to make the automatic password entry in the box voice stock when you add commas, your password then the sign #? I can't understand how do in KitKat.
-
CHKDSK verifying indexes will not end
When I start my computer, it says it needs check the drive for consistency. If I let him continue to get through files that controlled very well, but when he goes to a check of the index, it is about 12-15% and restarts the computer. I have read and
-
REGEXP_LIKE starting by h7 or r7 and finishing is not with _rtrd
I'm using oracle 11.2.0.3. How can I write regexp_like who will give me names beginning with h7 or r7 and finishing is not with _rtrd?