Trace SQL execution plan
Hello
I need to get the execution plan for a particular SQL, but I don't have it. Application it issues for a second or two and then his party so I think that the definition of a trace on specific user. Is it possible to get the execution plan of the query like this? Thank you!
Find the sql code, you are interested in v$ sql using the sql_text column and get the SQL_ID and CHILD_NUMBER. Entry of these two values for the query to get the execution below plan.
Select * from table
(dbms_xplan.display_cursor ('
Tags: Database
Similar Questions
-
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. -
Under SQL result in development in a few seconds, but in production continues to run. Explain plan is also less.
Oracle Database 11 g Enterprise Edition Release 11.2.0.4.0 - 64 bit Production
CURSOR_SHARING is set to EXACT (production) and FORCE (development) - is this the reason?
select wonum from workorder where worktype in ('EM','CM') and siteid = 'DWS_DSS' and historyflag = 0 and (exists (select null from dcw_ddotpermits b where workorder.wonum = b.wonum and workorder.siteid = b.siteid and b.permittype in ('Construction Permit', 'Occupancy Permit') and b.permitenddate > sysdate group by b.wonum, b.permittype having count(wonum) > 1));Explain the Plan of Production (which is slow)
------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 26 | 162K (17)| 00:32:30 | | | |* 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| WORKORDER | 1491 | 38766 | 4259 (1)| 00:00:52 | 1 | 1 | |* 2 | INDEX RANGE SCAN | WORKORDER_NDX20 | 2399 | | 988 (1)| 00:00:12 | | | |* 3 | FILTER | | | | | | | | | 4 | HASH GROUP BY | | 1 | 35 | 6 (17)| 00:00:01 | | | |* 5 | TABLE ACCESS BY INDEX ROWID | DCW_DDOTPERMITS | 1 | 35 | 5 (0)| 00:00:01 | | | |* 6 | INDEX RANGE SCAN | W_DDOTPERMITS_NDX2 | 3 | | 2 (0)| 00:00:01 | | | ------------------------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("WORKTYPE"='CM' OR "WORKTYPE"='EM') 2 - access("SITEID"='DWS_DSS' AND "HISTORYFLAG"=0) filter( EXISTS (SELECT 0 FROM "MAXIMO"."DCW_DDOTPERMITS" "B" WHERE "B"."WONUM"=:B1 AND ("B"."PERMITTYPE"='Construction Permit' OR "B"."PERMITTYPE"='Occupancy Permit') AND "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B2 GROUP BY "B"."WONUM","B"."PERMITTYPE" HAVING COUNT(*)>1)) 3 - filter(COUNT(*)>1) 5 - filter(("B"."PERMITTYPE"='Construction Permit' OR "B"."PERMITTYPE"='Occupancy Permit') AND "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B1) 6 - access("B"."WONUM"=:B1)Explain the Plan of development (which is fast)
----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 25 | 28247 (17)| 00:05:39 | |* 1 | FILTER | | | | | | |* 2 | VIEW | index$_join$_001 | 7991 | 195K| 985 (1)| 00:00:12 | |* 3 | HASH JOIN | | | | | | | 4 | INLIST ITERATOR | | | | | | |* 5 | INDEX RANGE SCAN | WWORKORDER_NDX32 | 7991 | 195K| 279 (2)| 00:00:04 | |* 6 | INDEX RANGE SCAN | WORKORDER_NDX20 | 7991 | 195K| 973 (1)| 00:00:12 | |* 7 | FILTER | | | | | | | 8 | HASH GROUP BY | | 1 | 39 | 6 (17)| 00:00:01 | |* 9 | TABLE ACCESS BY INDEX ROWID| DCW_DDOTPERMITS | 1 | 39 | 5 (0)| 00:00:01 | |* 10 | INDEX RANGE SCAN | W_DDOTPERMITS_NDX2 | 3 | | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter( EXISTS (SELECT 0 FROM "MAXIMO"."DCW_DDOTPERMITS" "B" WHERE "B"."WONUM"=:B1 AND ("B"."PERMITTYPE"=:SYS_B_4 OR "B"."PERMITTYPE"=:SYS_B_5) AND "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B2 GROUP BY "B"."WONUM","B"."PERMITTYPE" HAVING COUNT(*)>:SYS_B_6)) 2 - filter("HISTORYFLAG"=:SYS_B_3 AND "SITEID"=:SYS_B_2 AND ("WORKTYPE"=:SYS_B_0 OR "WORKTYPE"=:SYS_B_1)) 3 - access(ROWID=ROWID) 5 - access("WORKTYPE"=:SYS_B_0 OR "WORKTYPE"=:SYS_B_1) 6 - access("SITEID"=:SYS_B_2 AND "HISTORYFLAG"=:SYS_B_3) 7 - filter(COUNT(*)>:SYS_B_6) 9 - filter(("B"."PERMITTYPE"=:SYS_B_4 OR "B"."PERMITTYPE"=:SYS_B_5) AND "B"."PERMITENDDATE">SYSDATE@! AND "B"."SITEID"=:B1) 10 - access("B"."WONUM"=:B1)It looks more like a problem with the size of the data and related statistics. (It may be simply the outdated statistics on dev).
In the production of a larger data NDX20 index on its own looks too expensive to the optimizer so it combines this with the index of ndx32 to avoid visiting the table.
The first step to study the problem would be to check if the estimated row counts are realistic for individual systems, and then to determine if the data cluster for the production system is much better than Oracle think it is - if yes, then (for newer versions) affecting the preference of table 'table made of blocks cached' a realistic value can help ( https://jonathanlewis.wordpress.com/2015/11/02/clustering_factor-4/ ). If all else fails and the dev is good then allusion and capture of a Plan SQL database may be required.
Concerning
Jonathan Lewis
-
Hi all
How we can find the bottoleneks in the pl/sql package. I know we can use dbms_profiler. Gathersed data, but not having planned the details.
Here's the query I use
Select s.text,
p.total_occur,
p.TOTAL_TIME/1000000000 total_time,
p.min_time / 1000000000 min_time,.
p.max_time / 1000000000 max_time
of plsql_profiler_data p, user_source s, plsql_profiler_runs r
where p.line # = Check
and p.runid = r.runid
and r.run_comment = 'XXXX_YYY_INIT.XXX_TO_DDD(1,,360). '
and s.name LIKE 'XXX % ';
I see that dbms_profiler has gathered data. But it does give that which line is how long take.
Please guide findout that.
Thank you
Col owner format a10
Col name format a20
row col 9999 format
Col source format a40 word_wrap
occurrences of col 9999999 format
Col tot_time_s format 999,999,990.999
Col run_comment format a40
format of pct col 999
Select runid, run_date, plsql_profiler_runs run_comment;
Select OWNER u.unit_owner, u.unit_name NAME, d.line # LINE, (select the text from all_source where type in ('BODY of PACKAGE', 'FUNCTION', 'PROCEDURE', 'TRIGGER') and name = u.unit_name and = d.line line # and u.unit_owner and type = u.unit_type = owner) SOURCE, d.total_occur OCCURRENCES, (d.total_time/1000000000) TOT_TIME_S, d.total_time/r.run_total_time*100 "PCT".
of plsql_profiler_runs r, plsql_profiler_units u, plsql_profiler_data d
where are.runid = & runid
and r.runid = u.runid
and r.runid = d.runid
and d.unit_number = u.unit_number
and (d.total_time/1000000000) > 1 - more than 1 second
order of tot_time_s
/
Kind regards
Harman
-
Hi all
Can I get a query to see if there are several implementation plans for a query.
I tried with v$ sql where CHILD_NUMBER can be 0 or 1 at a time.
What interests me is any plans for a particular sql.
Also I can get good technical quality for outln paper / and the profile of sql. I have some links but do not have enough to her.
Thank you
Rana.user582224 wrote:
Can I get a query to see if there are several implementation plans for a query.
I tried with v$ sql where CHILD_NUMBER can be 0 or 1 at a time.What interests me is any plans for a particular sql.
Rana,
If you are interested in what you have now in the pool that is shared, you can start with V$ SQL, V$ SQLAREA, SQLSTATS $ V and V$ SQL_PLAN.
Note that different the same statement execution plans may already have aged out of the shared pool, that's why this information does not necessarily reflect the number of versions you may have had over time.
If you are already on 10g or later, you can use the DBMS_XPLAN. Function DISPLAY_CURSOR. If you specify "NULL" for the second parameter ("cursor_child_no"), it will show you all the sliders of the specified SQL_ID child execution plans.
If you have 10g or later and a CWA license, you can use DBA_HIST_SQL_PLAN and DBMS_XPLAN. DISPLAY_AWR to get stored for a particular SQL_ID. Note different execution plans that AWR cannot capture your particular statement, since it only samples consumers albums according to certain thresholds.
If you do not have a license of AWR you will always get a similar historical view of your plans with using STATSPACK snapshot level > = 6 that captures SQL execution plans. Once your statement again could not enjoy according to the load and thresholds (STATSPACK documentation: "to collect plans for all statements in the shared pool, you can temporarily specify the threshold of executions (i_executions_th) to be zero (0) for these snapshots").
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/ -
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.
-
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 -
Plan shows SQL execution Hrs 999:59:59 Sec.
Dear masters,
My development team announced today that the query below takes more time. When I check the plan for my shok show Hrs 999:59:59 Sec.
Kindly help me for this query setting.
I use the oracle 10.2.0.3 version.
Execution plan is: select * from table (dbms_xplan.display);SELECT S_INVLOC.NAME , S_ORDER.ACCNT_ID , S_ORDER.APPR_BY_EMP_ID , S_ORDER.BL_CON_ID , S_ORDER.BL_OU_ID , S_ORDER.CARRIER_CD , S_ORDER.CONTACT_ID , S_ORDER.CURCY_CD , S_ORDER.TAX_EXEMPT_FLG , S_ORDER.REQ_SHIP_DT , S_ORDER.SHIP_ADDR_ID , S_ORDER.SHIP_CON_ID , S_ORDER.SHIP_METH_CD , S_ORDER.SHIP_OU_ID , S_ORDER.STATUS_CD , S_ORDER.TAX_EXEMPT_NUM , S_ORDER.TAX_EXEMPT_REASON , S_ORDER.OPTY_ID , S_ORDER.BU_ID PR_VIS_ORG_ID , S_ORDER.PROMO_ID , S_ORDER.PRI_LST_ID , S_ORDER.AGREE_ID AGREEMENT_ID , S_ORDER.ENTLMNT_ID ENTITLEMENT_ID , S_ORDER.SR_ID , S_ORDER.BILLABLE_FLG , S_ORDER_ITEM.ROW_ID , S_ORDER_ITEM.ORDER_ID , S_ORDER_ITEM.LN_NUM , S_ORDER_ITEM.PROD_ID , S_ORDER_ITEM.ADJ_UNIT_PRI , S_ORDER_ITEM.BASE_UNIT_PRI , S_ORDER_ITEM.CARRIER_CD CARRIER_CD1 , S_ORDER_ITEM.EXTD_QTY , S_ORDER_ITEM.QTY_SHIPPED , S_ORDER_ITEM.REQ_SHIP_DT REQ_SHIP_DT1 , S_ORDER_ITEM.SHIP_ADDR_ID SHIP_ADDR_ID1 , S_ORDER_ITEM.SHIP_CON_ID SHIP_CON_ID1 , S_ORDER_ITEM.SHIP_METH_CD SHIP_METH_CD1 , S_ORDER_ITEM.STATUS_CD STATUS_CD1 , S_ORDER_ITEM.PROD_STATUS_CD , S_ORDER_ITEM.PROD_NAME , S_ORDER_ITEM.LOANER_FLG , S_ORDER_ITEM.DISCNT_METH_CD , S_ORDER_ITEM.SHIP_OU_ID SHIP_OU_ID1 , S_ORDER_ITEM.STATUS_DT , S_ORDER_ITEM.MUST_DLVR_BY_DT , S_ORDER_ITEM.ACTION_CD , S_ORDER_ITEM.ROLLUP_PRI , S_PROD_INT.NAME NAME1 , A.NAME NAME2 , B.NAME NAME3 , S_VOL_DISCNT.NAME NAME4 , ACCNT.PR_INDUST_ID , POSCRTDORG.OU_ID CREATED_BY_ORG_ID , POSOWNERORG.OU_ID PR_OWNER_ORG_ID , PAROITEM.LN_NUM , PAROITEM.PROD_ID , SHIPOITEM.CITY , SHIPOITEM.COUNTRY , SHIPOITEM.ZIPCODE , SHIPO.CITY , SHIPO.COUNTRY , SHIPO.ZIPCODE , BILL.CITY , BILL.COUNTRY , BILL.ZIPCODE , S_CAMP_CON.PR_CALL_LST_ID SEGMENT_ID , S_ORDER.DCP_ID OFFER_ID , APPRBYPOS.PR_HELD_POSTN_ID , POSOWNERORG.ROW_ID , POSOWNERORG.PR_EMP_ID , S_ENTLMNT.PAR_AGREE_ID , ROOTOITEM.PROD_ID ROOT_LN_PROD_ID , ROOTOITEM.LN_NUM ROOT_LN_NUM , S_ORDER.PR_POSTN_ID , S_CAMP_CON.CAMP_LD_WAVE_ID , S_SRC.REGION_ID , OPRI.COST_PRI , S_ORDER_ITEM.ORDER_ITM_CURCY_CD OITM_CURCY_CD , ROOTOITEM.ORDER_ITM_CURCY_CD ROOTOITM_CURCY_CD , S_ORDER_ITEM.ORDER_ITM_EXCH_DT OITM_AMT_DT , S_ORDER.ORDER_EXCH_DT , S_ORDER_ITEM.CREATED , S_ORDER_ITEM.NET_PRI , S_ORDER_ITEM.CRSE_OFFR_ID , S_ORDER_ITEM.PRI_LST_ID OITM_PRI_LST_ID , ROOTOITEM.PRI_LST_ID ROOTOITM_PRI_LST_ID , OWNORG.PRTNR_FLG , VISORG.PRTNR_FLG , S_CAMP_LD_WAVE.LAUNCHED_TS , QUOTE.CREATED , S_ORDER.ACTIVE_FLG , S_ORDER.APPROVED_FLG , PARPROD.PROD_TYPE_CD , ROOTPROD.PROD_TYPE_CD , S_PROD_INT.PRICE_TYPE_CD , S_SRC.PROG_END_DT , S_SRC.PROG_START_DT , S_SRC.ROW_ID , S_ORDER.CREATED , OWNORG.ROW_ID , 0 AS X_CUSTOM , S_ORDER_ITEM. X_PHONE_NUMBER , S_ORDER_ITEM.X_BACKEND_SERVICE_ID , S_ORDER_ITEM.SERVICE_NUM , S_ORDER_ITEM.BILL_ACCNT_ID , S_ORDER_X.ATTRIB_04 , S_ORDER_X.ATTRIB_30 , S_ORDER_X.ATTRIB_31 FROM SIEBEL.V_ORDER_ITEM S_ORDER_ITEM, SIEBEL.S_ORDER_ITEM PAROITEM, SIEBEL.S_ORDER_ITEM ROOTOITEM, SIEBEL.S_ORDER, SIEBEL.S_VDISCNT_ITEM A, SIEBEL.S_VOL_DISCNT, SIEBEL.S_PROD_INT, SIEBEL.S_VDISCNT_ITEM B, SIEBEL.S_INVLOC, SIEBEL.S_ORG_EXT ACCNT, SIEBEL.S_POSTN POSOWNERORG, SIEBEL.S_CONTACT CRTD, SIEBEL.S_CONTACT APPRBYPOS, SIEBEL.S_POSTN POSCRTDORG, SIEBEL.S_ADDR_ORG SHIPOITEM, SIEBEL.S_ADDR_ORG SHIPO, SIEBEL.S_ADDR_ORG BILL, SIEBEL.S_CAMP_CON, SIEBEL.S_ENTLMNT, SIEBEL.S_SRC, SIEBEL.S_ORDER_ITM_PRI OPRI, SIEBEL.S_CAMP_LD_WAVE, SIEBEL.S_DOC_QUOTE QUOTE, SIEBEL.S_ORG_EXT OWNORG, SIEBEL.S_ORG_EXT OWNORG1, SIEBEL.S_ORG_EXT VISORG1, SIEBEL.S_ORG_EXT VISORG, SIEBEL.S_PROD_INT PARPROD, SIEBEL.S_PROD_INT ROOTPROD, SIEBEL.S_ORDER_X WHERE S_ORDER_ITEM.ORDER_ID = S_ORDER.ROW_ID AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID = ROOTOITEM.ROW_ID AND S_ORDER_ITEM.PAR_ORDER_ITEM_ID = PAROITEM.ROW_ID(+) AND S_ORDER_ITEM.PROD_ID = S_PROD_INT.ROW_ID(+) AND S_ORDER_ITEM.SRC_INVLOC_ID = S_INVLOC.ROW_ID(+) AND S_ORDER_ITEM.VOL_DISCNT_ITEM_ID = A.ROW_ID(+) AND S_ORDER_ITEM.VOL_DISCNT_ID = S_VOL_DISCNT.ROW_ID(+) AND S_ORDER_ITEM.VOL_UPSELL_ITEM_ID = B.ROW_ID(+) AND S_ORDER_ITEM.SHIP_ADDR_ID = SHIPOITEM.ROW_ID(+) AND S_ORDER.PR_POSTN_ID = POSOWNERORG.ROW_ID(+) AND S_ORDER_ITEM.CREATED_BY = CRTD.ROW_ID(+) AND CRTD.PR_HELD_POSTN_ID = POSCRTDORG.ROW_ID(+) AND S_ORDER.ACCNT_ID = ACCNT.ROW_ID(+) AND S_ORDER.CAMP_CON_ID = S_CAMP_CON.ROW_ID(+) AND S_ORDER.SHIP_ADDR_ID = SHIPO.ROW_ID(+) AND S_ORDER.BL_ADDR_ID = BILL.ROW_ID(+) AND S_ORDER.APPR_BY_EMP_ID = APPRBYPOS.ROW_ID(+) AND S_ORDER.ENTLMNT_ID = S_ENTLMNT.ROW_ID(+) AND S_ORDER.PROMO_ID = S_SRC.ROW_ID(+) AND S_ORDER_ITEM.ROW_ID = OPRI.PAR_ROW_ID(+) AND S_CAMP_CON.CAMP_LD_WAVE_ID = S_CAMP_LD_WAVE.ROW_ID(+) AND S_ORDER.QUOTE_ID = QUOTE.ROW_ID(+) AND POSOWNERORG.OU_ID = OWNORG1.ROW_ID(+) AND OWNORG1.PAR_BU_ID = OWNORG.ROW_ID(+) AND S_ORDER.BU_ID = VISORG1.ROW_ID(+) AND VISORG1.PAR_BU_ID = VISORG.ROW_ID(+) AND PAROITEM.PROD_ID = PARPROD.ROW_ID(+) AND ROOTOITEM.PROD_ID = ROOTPROD.ROW_ID(+) AND S_ORDER_ITEM.ORDER_ID = S_ORDER_X.PAR_ROW_ID(+) AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID IS NOT NULL;
Published by: KODS on 13 December 2012 14:11PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 73463824 ------------------------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 3170K| 12G| 4100G (4)|999:59:59 | | 1 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 2 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 3 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 4 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 5 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 6 | NESTED LOOPS | | 3170K| 12G| 4100G (4)|999:59:59 | | 7 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 8 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 9 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 10 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 11 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 12 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 13 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 14 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 | | 15 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 | | 16 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 | | 17 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 | | 18 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 | | 19 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 | | 20 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 | | 21 | NESTED LOOPS | | 3170K| 9911M| 4100G (4)|999:59:59 | | 22 | NESTED LOOPS OUTER | | 3108K| 4927M| 2569K (2)| 01:08:47 | | 23 | NESTED LOOPS OUTER | | 3108K| 4835M| 115K (14)| 00:03:06 | | 24 | NESTED LOOPS OUTER | | 3108K| 4782M| 115K (14)| 00:03:06 | | 25 | NESTED LOOPS OUTER | | 3108K| 4660M| 112K (12)| 00:03:02 | | 26 | NESTED LOOPS OUTER | | 3108K| 4417M| 112K (12)| 00:03:02 | | 27 | NESTED LOOPS OUTER | | 3108K| 4227M| 112K (12)| 00:03:02 | | 28 | NESTED LOOPS OUTER | | 3108K| 3943M| 112K (12)| 00:03:02 | | 29 | NESTED LOOPS OUTER | | 3108K| 3178M| 111K (11)| 00:02:59 | | 30 | TABLE ACCESS FULL | S_ORDER | 3108K| 2413M| 109K (9)| 00:02:56 | | 31 | TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 | |* 32 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 | | 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 | |* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 | | 35 | TABLE ACCESS BY INDEX ROWID | S_CAMP_CON | 1 | 96 | 1 (0)| 00:00:01 | |* 36 | INDEX UNIQUE SCAN | S_CAMP_CON_P1 | 1 | | 1 (0)| 00:00:01 | | 37 | TABLE ACCESS BY INDEX ROWID | S_ENTLMNT | 1 | 64 | 1 (0)| 00:00:01 | |* 38 | INDEX UNIQUE SCAN | S_ENTLMNT_P1 | 1 | | 1 (0)| 00:00:01 | | 39 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 82 | 1 (0)| 00:00:01 | |* 40 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 | | 41 | TABLE ACCESS BY INDEX ROWID | S_CAMP_LD_WAVE | 1 | 41 | 1 (0)| 00:00:01 | |* 42 | INDEX UNIQUE SCAN | S_CAMP_LD_WAVE_P1 | 1 | | 1 (0)| 00:00:01 | | 43 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 18 | 1 (0)| 00:00:01 | |* 44 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | 1 (0)| 00:00:01 | | 45 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 31 | 1 (0)| 00:00:01 | |* 46 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 | |* 47 | VIEW | V_ORDER_ITEM | 1 | 1616 | 1318K (4)| 00:35:19 | | 48 | NESTED LOOPS | | 3128K| 1372M| 1318K (4)| 00:35:19 | | 49 | INDEX FAST FULL SCAN | S_ETL_I_IMG_25_M2 | 3128K| 32M| 2756 (11)| 00:00:05 | |* 50 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 449 | 2 (0)| 00:00:01 | |* 51 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 | | 52 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 | |* 53 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 | | 54 | TABLE ACCESS BY INDEX ROWID | S_VOL_DISCNT | 1 | 134 | 1 (0)| 00:00:01 | |* 55 | INDEX UNIQUE SCAN | S_VOL_DISCNT_P1 | 1 | | 1 (0)| 00:00:01 | | 56 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 | |* 57 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 | | 58 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 | |* 59 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 | |* 60 | TABLE ACCESS FULL | S_ORDER_ITM_PRI | 1 | 45 | 0 (0)| 00:00:01 | | 61 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 33 | 1 (0)| 00:00:01 | |* 62 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | 1 (0)| 00:00:01 | | 63 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 58 | 1 (0)| 00:00:01 | |* 64 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 | | 65 | TABLE ACCESS BY INDEX ROWID | S_ORDER_X | 1 | 36 | 2 (0)| 00:00:01 | |* 66 | INDEX RANGE SCAN | S_ORDER_X_U1 | 1 | | 2 (0)| 00:00:01 | | 67 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 2 (0)| 00:00:01 | |* 68 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 | | 69 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 20 | 1 (0)| 00:00:01 | |* 70 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 | | 71 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 1 (0)| 00:00:01 | |* 72 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 | | 73 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 | |* 74 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 | | 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 | |* 76 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 | | 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 | |* 78 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 | | 79 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 60 | 2 (0)| 00:00:01 | |* 80 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 | | 81 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 24 | 2 (0)| 00:00:01 | |* 82 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 | | 83 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 | |* 84 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 | | 85 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 | |* 86 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 | | 87 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 | |* 88 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 | | 89 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 | |* 90 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID"(+)) 34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID"(+)) 36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID"(+)) 38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID"(+)) 40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID"(+)) 42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID"(+)) 44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID"(+)) 46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID"(+)) 47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID") 50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL) 51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID") 53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID"(+)) 55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID"(+)) 57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID"(+)) 59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID"(+)) 60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID"(+)) PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ 62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID"(+)) 64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID"(+)) 66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID"(+)) 68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID"(+)) 70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID"(+)) 72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID"(+)) 74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID"(+)) 76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID"(+)) 78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID"(+)) 80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID") 82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID"(+)) 84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID"(+)) 86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID"(+)) 88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID"(+)) 90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID"(+)) 132 rows selected.Hello
what the plan for
SELECT * FROM V_ORDER_ITEM WHERE ROW_ID = :ROW_ID?
If it's the same thing, this means that the optimizer cannot merge the view (in fact, he can't even lower the predicate). Nothing in the view looks like he could have done fusion (such as the use of rownum etc.), so is lack of privilege VIEW MERGE or a bug in the optimizer.
GRANT MERGE VIEW ON V_ORDER_ITEM try
or run the query under the account of the owner of the view and see what happens. Best regards
Nikolai -
"Execution plan is not available" in OEM.
Greetings. Try to watch my first Exec Plan here and make the message displayed above in OEM 11 g even executing simple statements like below. I googled this and see only one question without an answer identical to this.
Thank you!
explain plan for
Select * from SCOTT. DEPT;
Don't know why you're looking for a plan in OEM.
* Connect to the base of data with the help of sqlplus and wwho and extract the map below;
SQL > explain plan for select * from SCOTT. DEPT;
SQL > SELECT * FROM TABLE (dbms_xplan.display);
* Very easy, set autotrace on and run the query, you will get the plan and statistics;
SQL > set autotrace
Syntax: SET AUTOT [RACE] {OFF |} WE | TRACE [ONLY]} [EXP [LAIN]] [[C] STAT]
SQL > set autotrace on
SQL > select * from double;
D
-
X
Execution plan
----------------------------------------------------------
Hash value of plan: 272002086
--------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 2. 2 (0) | 00:00:01 |
| 1. TABLE ACCESS FULL | DOUBLE | 1. 2. 2 (0) | 00:00:01 |
--------------------------------------------------------------------------
Statistics
----------------------------------------------------------
1 recursive calls
0 db block Gets
Gets 2 compatible
0 physical reads
0 redo size
522 bytes sent via SQL * Net to client
523 bytes received via SQL * Net from client
2 SQL * Net back and forth to and from the client
0 sorts (memory)
0 sorts (disk)
1 rows processed
HTH,
Pradeep
-
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
-
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. -
Ask the events of trace sql result 10046 level 8 and 12
Hi all, I read the result of events to trace sql 10046 level 8 on
http://www.Oracle-base.com/articles/10G/SQLTrace10046TrcsessAndTkprof10g.php#trace_example
and I do the level of Event 10046 SQL trace 8 or 12. But the results were not even, plan of execution does not appear
How to make the execution plan appears?How to make the execution plan appears?
TKProf
trace_results.txt .trc explain = name of user and password -
OEM12c: in execution plans, no more links to tables (OEM10g has them)
in the Plan for SQL, version details tab OEM 10g has hyperlinks to the objects mentioned in the implementation plan.
It seems not to be the case more in OEM12c:
Does anyone know how to activate the ability to directly open the details page of the objects listed in the execution plans?
Hello
This feature has been valuable, but unfortunately has not been set up at EM12c. If you want to access the Cloud control, once connected to the database, the best way is to click on the schema, database objects and then go to the correct data type to search for the object in question. If you are looking for information on the object in the execution plan, then the best way to see it is via SQL Monitor if the process has not aged. If it has, then use SQL statements search, (under the menu Performance/SQL for the database that you are connected) and then do a search for cache, CWA and other, you know you want to watch for the SQLID in question.
I hope this helps!
Kevin Pot' wine-Gorman
-
Hello world
I have a little a problem of performance on 12 c that gives me a little trouble at the head. I moved from 11 to 12 databases and no amendment of the application have been made. Our requests are generated somewhat dynamically, so that they are the same thing every time.
Let's start with the execution plan I get:
SQL > select * from table (dbms_xplan.display ());
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3567104424
-----------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | TQ | IN-OUT | PQ Distrib.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 55. 7095 | 3764 (1) | 00:00:01 | | | |
| 1. COORDINATOR OF PX | | | | | | | | |
| 2. PX SEND QC (ORDER). : TQ10006 | 55. 7095 | 3764 (1) | 00:00:01 | Q1, 06 | P > S | QC (ORDER).
| 3. SORT ORDER BY | | 55. 7095 | 3764 (1) | 00:00:01 | Q1, 06 | SVCP | |
| 4. PX RECEIVE | | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 06 | SVCP | |
| 5. RANGE OF SEND PX | : TQ10005 | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 05 | P > P | RANGE |
| 6. UNIQUE FATE | | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 05 | SVCP | |
|* 7 | HASH JOIN | | 55. 7095 | 3762 (1) | 00:00:01 | Q1, 05 | SVCP | |
| 8. PX RECEIVE | | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 05 | SVCP | |
| 9. PX SEND HASH | : TQ10003 | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 03 | P > P | HASH |
| * 10 | HASH JOIN | | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 03 | SVCP | |
| 11. RECEIVE PX | | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 03 | SVCP | |
| 12. PX SEND BROADCAST | : TQ10002 | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 02 | P > P | BROADCAST |
| 13. NESTED LOOPS | | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 02 | SVCP | |
| 14. KIND OF BUFFER. | | | | | Q1, 02 | ISSUE | |
| 15. RECEIVE PX | | | | | | Q1, 02 | SVCP | |
| 16. PX SEND HASH | : TQ10000 | | | | | | S > P | HASH |
| 17. NESTED LOOPS | | 823. 31274 | 1509 (1) | 00:00:01 | | | |
| * 18. TABLE ACCESS BY ROWID INDEX BATCH | PAGED_LOOKUP_PKS | 500 | 9500 | 3 (0) | 00:00:01 | | | |
| * 19. INDEX RANGE SCAN | PAGED_LOOKUP_PKS_IDX2 | 1. | 2 (0) | 00:00:01 | | | |
| 20. TABLE ACCESS BY ROWID INDEX BATCH | BILL_ITEM | 2. 38. 4 (0) | 00:00:01 | | | |
| * 21. INDEX RANGE SCAN | BILL_ITEM_FK2 | 4. | 2 (0) | 00:00:01 | | | |
| * 22. INDEX UNIQUE SCAN | PK_INSERTION | 1. 13. 1 (0) | 00:00:01 | Q1, 02 | SVCP | |
| 23. ITERATOR BLOCK PX | | 1548K | 17 M | 1353 (2) | 00:00:01 | Q1, 03 | ISSUE | |
| 24. FULL RESTRICTED INDEX SCAN FAST | BOOKING_ACCOUNT_1 | 1548K | 17 M | 1353 (2) | 00:00:01 | Q1, 03 | SVCP | |
| 25. PX RECEIVE | | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 05 | SVCP | |
| 26. PX SEND HASH | : TQ10004 | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 04 | S > P | HASH |
| 27. SELECTOR PX | | | | | | Q1, 04 | SCWC | |
| 28. TABLE ACCESS FULL | CONTACT | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 04 | SCWP | |
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
7 - access ("ACCOUNT_ID" ="ACCOUNT_ID")
10 - access ("BOOKING" ="BOOKING")
18 - filter("T1".") SEQUENCE_NO' < 501 AND "T1". ("' SEQUENCE_NO" > = 1).
19 - access("T1".") SESSION_ID '= 123456 AND 'T1'.' SEARCH_ID "= 25)
21 - access("T1".") N1 "=" BILL_ID")
22 - access ("BOOKING" = "BOOKING" AND "INSERTION_SET" = "INSERTION_SET" AND "INSERT"="INSERT")
Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)
-This is an adaptation plan
-2 directives Plan Sql used for this statement
51 selected lines.
Elapsed time: 00:00:00.15
SQL > spool off
OK, now let's go through the problem:
- It's a development running on a virtual server, and which hosts a few other databases, so the parallel execution is not a good thing. parallel_degree_policy is set to MANUAL, parallel_max_servers and all other parallel_ limits are set to 1 and tables have been changed with the settings of NOPARALLEL. So why is the execution plan always generated with all stages of parallel execution? I don't seem to get rid of in 12 c
- Next mystery is that the said plan of the explain command is an adaptation plan, and yet I put the true optimizer_adaptive_reproting_only
- Now to the problem of effective enforcement, so I'm playing around with all these settings. The query runs for 3-4 seconds, returning around about 500 cases. However, in some cases this same query with the same input variable races for hours and if I can believe the AWR and ASH reports, read a good 180 GB of data. The main wait event is direct path read temp temp and writing.
This is not isolated to that one query. I have a few queries now that all display the same behavior, one of them running overnight. I don't seem to get to a standard nested loop execution plans.
The entire base is a database plug-in and I don't know I just missed something in the new features Guide.
Would appreciate some ideas.
Thank you
If you want to disable parallel execution, you must set parallel_max_servers to zero. Maybe the optimizer thinks he can use a parallel plan because parallel_max_servers is non-zero (even though the number of slaves available means that it will be serialized to a parallel plan).
Note that you have a ticket saying dynamic stats have been used. Maybe you have a 11 for optimizer_dynamic_sampling setting, and allowing Oracle to be very inventive with collection of samples and parallelism.
You have also 2 SQL instructions in game. These are the things that get associated with objects rather than the instructions, then perhaps someone has been playing with parallelism and managed to associate the parallelism with one of the tables in your query (I am not sure 100% that it is possible, just throw a suggestion). Take a look at the SQL used for education guidelines.
To give us a little more information, you can:
Shoot memory execution plan dbms_xplan.display_cursor ({sql_id}, {number of children}, 'ALL'));
We show all the parallel settings (see setting the parallel)
Pull on the parameters of the optimizer for query memory (select name, value of V$ sql_optimizer_env where sql_id = {your sql identifier} and child_number = {your child number})
Concerning
Jonathan Lewis
-
SQL execution 11.2.0.1 to 11.2.0.4
Hi all
I have a problem of my version of the 11.2.0.1 to 11.2.0.4 database migration, save you resources are the same, but when to perform a select Oracle consumes 100% of CPU and not respond to the request.
Is there a function or something that could have an impact on?
Thank you very much.
Thank you to all the world and we have seen how you run THAT SQL is apparently the execution plan that is oracle doing was choose better execution plans, but this affects the performance of the database, try to modify the hidden parameter "_optimizer_use_feedback"a false and started to behave better basis. "
SQL > alter system set "_enable_shared_pool_durations" = false scope = spfile;
Thank you very much
Maybe you are looking for
-
Satellite C50-A-138 - all USB ports do not have
Hello I have a major problem with my Satellite C50-A-138.The card reader has never worked, and one by one the USB ports have stopped working.I can connect my phone to each of them, and he will. But I can not plug any device into the port and have the
-
How can I restore a folder of bookmarks in Safari, but keep all my other bookmark folders published?
Hi, I have a Macbook Pro with Yosemite and have a backup hard drive. I've been doing many changes/modifications to my bookmarks in Safari for weeks, but I notice that a folder of bookmarks that I moved is missing one more a week ago. How can I restor
-
Need a license key to reinstall Windows 7 Starter
I have a HP Mini 110-3135dx. The hard drive is dead and I don't have a recovery media. I can reinstall the OS, but I need a license key for it. What should I do? Is it possible to get this based on the serial number of the laptop?
-
Clean the underside of the glass. The user manual it says to go to 'hp.com/support' for instructions on cleaning the underside of the glass, but I couldn't find any information here. Any help? Dan
-
Laptop G62-a50EV: problem with GPU drivers! :/
Hey guys,. I currently installed windows 8.1 x 64 OS on a laptop OS from windows 7 to the previous address. Problem is that none of my cards (AMD/ATI Radeon HD5470 & Intel HD graphics card) are properly recognized by the system. Whenever I try to ins