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
Tags: Database
Similar Questions
-
Why I have two different execution plans for the same query on two different servers
Hello everyone.
I need your help to solve the problem quickly.
In a nutshell, we have two servers that have the same version of Oracle RDBMS (11.2.0.4 EE). One of them for purposes of development and another is a production one.
We have therefore two different execution plans for the same query executed on both servers. The only case of execution is OK and another is too slow.
So I have to slow down the work of query using the same scheme to explain that young.
Fence wire.
-
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 -
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.
-
An execution plan is produced for a user without subsidies?
Oracle generates an execution plan for syntactically correct PL/SQL submitted by a user has no authority to interpret a table or will 1st check syntax, then the dictionary, then the rights before generating the execution plan?I hope this helps to answer:
http://docs.Oracle.com/CD/E11882_01/server.112/e25789/sqllangu.htm#CNCPT216
-
Hello
I do not understand why this sql has a bad execution plan?
SELECT DISTINCT LETTER0_. LE_IDENT AS col_0_0_
THE LETTER LETTER0_
LEFT OUTER JOIN CONTEXT1_ CONTEXT
ON LETTER0_. LE_PTRCTXID = CONTEXT1_. CTX_IDENT
LEFT OUTER JOIN F_DOC f_doc2_
ON LETTER0_. LE_PTRDOCID = f_doc2_. DOC_IDENT
WHERE LETTER0_. LE_IDENT IN
(SELECT LETTER3_. LE_IDENT
THE LETTER LETTER3_, CONTEXT CONTEXT4_
WHERE LETTER3_. LE_PTRCTXID = CONTEXT4_. CTX_IDENT
AND CONTEXT4_. CTX_PTRPOLID = 400728434)
OR LETTER0_. LE_IDENT IN (2525432);
Execution plan
----------------------------------------------------------
0 SELECT optimizer Mode STATEMENT = ALL_ROWS (cost = card 175 = 14 K bytes = 83 K)
1 FILTER 0
2 1 INDEX FULL SCAN PROSHIVA1. PK_LE_CLE (cost = card 175 = 284 K bytes = 1 M)
3 1 LOOPS IMBRIQUEES (cost = 4 cards = 1 bytes = 22)
TABLE 3 ACCESS BY INDEX ROWID PROSHIVA1 4. F_LETTRES (cost = 2 card = 1 bytes = 13)
5 4 INDEX UNIQUE PROSHIVA1 SCAN. PK_LE_CLE (cost = 1 card = 1)
6 TABLE ACCESS BY INDEX ROWID PROSHIVA1 3. F_CONTEXT (cost = 2 card = 1 bytes = 9)
7 6 INDEX RANGE SCAN PROSHIVA1. IND_CTX_PTRPOLID (cost = 1 card = 1)
Statistics
----------------------------------------------------------
5 user calls
0 physical total bytes read
physical write 0 total bytes
0 3 spare statistics
0 commit failures of drain plug: can not pin
Extension of TBS 0: extended bytes
0 total number of times SMON post
SMON 0 posted for undo segment recovery
SMON 0 posted to drop the temp segment
prealloc segment 0 tasks
1 rows processed
9f9cf8b7-e5bc-4AAF-B369-b189dadb9d77 wrote:
Thanks for the reply
due to the second line of the execution plan. INDEX FULL SCAN PROSHIVA1. PK_LE_CLE (cost = card 175 = 284 K bytes = 1 M).
This sql takes 2 seconds. and if I remove any OF the sql condition. There are only 200 ms.
This is a typical problem optimizer - IN / associate EXISTS OR does work well in many cases. Most likely, if you simply specify the IN clause, the optimizer will unnest subquery, which could be much faster in this case.
Furthermore, the optimizer has already done a good job in eliminating unnecessary outer joins, there is no mention of CONTEXT or F_DOC in the source line of the FILTER operator. He even eliminated the SEPARATE, most likely because he knows that LETTER. LE_IDENT is unique.
Think of what the database has to do with your request - need to find matches which have the mentioned ID or who have a match in the specified list as subquery. So without more clever query processing, it must pass the primary key index set and check, for each line, if it is a match in the IN subquery - that's exactly what makes the FILTER operator, it executes the LOOP IMBRIQUEE join that represents the IN clause for each row returned by the full index scan.
Ideally, this should be transformed by using a transformation of CONCATENATION, where this query is actually split in two: part of the research for the mentioned ID and the other party responsible for looking for matches with subqueries and this making, ensuring that the two branches do not result in duplicate (since a line could satisfy both conditions).
You can try an explicit indication of USE_CONCAT for the query, but I doubt that the optimizer will do it automatically.
So if it does not, you could do the same thing as a manual rewrite:
SELECT LETTER0_. LE_IDENT AS col_0_0_
THE LETTER LETTER0_
WHERE LETTER0_. LE_IDENT = 2525432
UNION ALL
SELECT LETTER0_. LE_IDENT AS col_0_0_
THE LETTER LETTER0_
WHERE LETTER0_. LE_IDENT IN
(SELECT LETTER3_. LE_IDENT
THE LETTER LETTER3_, CONTEXT CONTEXT4_
WHERE LETTER3_. LE_PTRCTXID = CONTEXT4_. CTX_IDENT
AND CONTEXT4_. CTX_PTRPOLID = 400728434)
AND LNNVL (LETTER0_. LE_IDENT = 2525432);
The LNNVL is the bit that filter potential duplicates and which would be automatically generated by the transformation of the CONCATENATION.
Randolf
-
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
-
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
-
The execution plan changes for the same query.
Hi all
This issue was raised before also, but still not able to find the real cause of this.
Thread1:
Thread2:
It comes, sometimes hammers server 100% CPU utilization with free latch and buffer busy wait events.
We found a single query consumes high CPU usage that is run by different sessions.
This query have two types of execution plans, where one is accurate and is not (its primary key hit index index no appropriate means present on the table)
Because its primary key index hit repeatedly at various sessions, some sessions are powerful db file sequential read and a few sessions waiting buffer busy waits for event. Also during this time a few sessions waiting for latch free event.
My doubt is how to sql even with different literal values execution plan changes and causes a prob.
How to avoid this... why its different execution plan using (I mean bad index PK)select count(*),event from v$session_wait group by event; COUNT(*) EVENT ---------- ---------------------------------------------------------------- 165 SQL*Net message from client 1 SQL*Net message to client 3 buffer busy waits 2 db file parallel read 18 db file sequential read 10 latch free 5 log file sync 1 pmon timer 6 rdbms ipc message 1 smon timer SQL> select sid from v$session_wait where event='db file sequential read'; SID ---------- 26 58 82 107 116 223 212 203 192 173 161 157 150 147 254 238 229 112 101 81 68 SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID; Enter value for sid: 161 old 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID new 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=161 SPID SID SERIAL# PROGRAM --------- ---------- ---------- ------------------------------------------------ 4231 161 49569 oracle@tfrdb3 (TNS V1-V3) SQL> select sql_text from v$process a, v$session b, 2 3 v$sql c where a.addr = b.paddr and b.sql_hash_value = c.hash_value and a.spid = &PID; 4 5 6 7 Enter value for pid: 4231 old 7: a.spid = &PID new 7: a.spid = 4231 SQL_TEXT -------------------------------------------------------------------------------- SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM LOG WHERE ID = '09292AMR 10B41FE' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'234225222' OR TYPE = 18 AND LOG_SEQ='234225222') ORDER BY TIME_STAMP ASC SQL> set autotrace traceonly exp SQL> SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM amrwf1.LOG WHERE ID = '09292AMR10B41FE' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'234225222' OR TYPE =18 AND LOG_SEQ='234225222') ORDER BY TIME_STAMP ASC; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=2 Bytes=126) 1 0 SORT (ORDER BY) (Cost=11 Card=2 Bytes=126) 2 1 CONCATENATION 3 2 TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=4 Card=1 Bytes=63) 4 3 INDEX (UNIQUE SCAN) OF 'PK_LOG_LOG_SEQ' (UNIQUE) (Co st=3 Card=1) 5 2 TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=4 Card=1 Bytes=63) 6 5 INDEX (RANGE SCAN) OF 'PK_LOG_LOG_SEQ' (UNIQUE) (Cos t=3 Card=1) SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID; Enter value for sid: 147 old 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID new 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=147 SPID SID SERIAL# PROGRAM --------- ---------- ---------- ------------------------------------------------ 6255 147 38306 oracle@tfrdb3 (TNS V1-V3) SQL> select sql_text from v$process a, v$session b, v$sql c 2 3 where a.addr = b.paddr and b.sql_hash_value = c.hash_value and a.spid = &PID; 4 5 6 7 Enter value for pid: 6255 old 7: a.spid = &PID new 7: a.spid = 6255 SQL_TEXT -------------------------------------------------------------------------------- SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM LOG WHERE ID = '09273AMR 62B4894' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'223324996' OR TYPE = 18 AND LOG_SEQ='223324996') ORDER BY TIME_STAMP ASC SQL> set autotrace traceonly exp SQL> SELECT ERROR,TIME_STAMP,O_RESOURCE,QUEUE,NEW_QUEUE FROM amrwf1.LOG WHERE ID = '09273AMR62B4894' AND TYPE IN (11, 28, 25, 18, 60, 13) AND (LOG_SEQ>'223324996' OR TYPE =18 AND LOG_SEQ='223324996') ORDER BY TIME_STAMP ASC; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1538 Card=736 Bytes= 46368) 1 0 SORT (ORDER BY) (Cost=1538 Card=736 Bytes=46368) 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'LOG' (Cost=1527 Card=7 36 Bytes=46368) 3 2 INDEX (RANGE SCAN) OF 'LOG_ID' (NON-UNIQUE) (Cost=32 C ard=736) SQL> select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID; Enter value for sid: 82 old 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=&SID new 1: select spid, sid, s.serial#, p.program from v$session s, v$process p where paddr=addr and sid=82 SPID SID SERIAL# PROGRAM --------- ---------- ---------- ------------------------------------------------ 6172 82 45378 oracle@tfrdb3 (TNS V1-V3) SQL> select sql_text from v$process a, v$session b, v$sql c where a.addr = b.paddr and b.sql_hash_value = c.hash_value and 2 3 a.spid = &PID; 4 5 6 7 Enter value for pid: 6172 old 7: a.spid = &PID new 7: a.spid = 6172 SQL_TEXT -------------------------------------------------------------------------------- INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) SQL_TEXT -------------------------------------------------------------------------------- INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V SQL_TEXT -------------------------------------------------------------------------------- 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010) INSERT INTO LOG (ID,TIME_STAMP,TYPE,ERROR,INSTANCE,RULE_NUM,RULE_TYPE,PRIORITY,F LAGS,NAME,BATCH,O_RESOURCE,QUEUE,NEW_QUEUE,SERVER,FORM,WORKSET) VALUES (:V001,:V 002,11,0,0,3,1,0,1,:V003,:V004,:V005,:V006,:V007,:V008,:V009,:V010)
Is it possible to avoid this?
If any details please check out some of my previous post on this specific URL (above)
-YasserMy doubt is how to sql even with different literal values execution plan changes and causes a prob.
Different literal values cause analysis difficult.
Hard analysis includes the re-evaluation of the best path.
Literal value is included in the assessment of the selectivity for the scan interval (log_seq >...)See
http://www.centrexcc.com/A%20Look%20under%20The%20Hood%20Of%20CBO%20-%20The%2010053%20Event.ppt.PDF
http://www.centrexcc.com/fallacies%20Of%20The%20Cost%20Based%20Optimizer.PDF
more the book of Jonathan Lewis which other threads, I believe that you already have.You must lower your CPU.
Previous discussions, if the situation is still the same, it sounded like hard analysis particularly with this SELECTION against the NEWSPAPER plays an important role in that.How to avoid this... why its different execution plan using (I mean bad index PK)
The points raised in the previous discussion remain valid.
-Do you have access to this SQL to change?
for example using bind variable or trick it if necessary due to problems caused by data as discussed in the previous thread.
- Or you could it repoint the view to a view and a hint?
-If a particular user makes this sql, could affect you cursor_sharing just for this user. If not, you should consider implementing pan-Canadian database.Oracle 8.1.6 still?
-
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/ -
"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
-
Newbie. SELECT with Clause: bad execution plan.
Hello
1)
SQL> WITH CTATEL AS 2 (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO 3 FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C 4 WHERE B.CTA_FACTURAC=A.CTA_FACTURAC 5 AND C.NUM_TELEFONO=A.NUM_TELEFONO) 6 SELECT 71, A.CTA_FACTURAC, B.NUM_TELEFONO, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E' 7 FROM SOL_FICHERO a, CTATEL b 8 WHERE ID_SOLICITUD=71 9 AND A.CTA_FACTURAC=B.CTA_FACTURAC 10 AND (A.NUM_TELEFONO IS NULL OR (A.NUM_TELEFONO <> '0' AND B.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO=B.NUM_TELEFONO)) 11 AND A.COD_CONFACTU IS NOT NULL AND EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU); Execution Plan ---------------------------------------------------------- Plan hash value: 711563975 --------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 64 | 6 (0)| 00:00:01 | | 1 | NESTED LOOPS | | 1 | 64 | 6 (0)| 00:00:01 | | 2 | NESTED LOOPS | | 1 | 54 | 5 (0)| 00:00:01 | | 3 | NESTED LOOPS | | 1 | 45 | 4 (0)| 00:00:01 | | 4 | NESTED LOOPS SEMI | | 1 | 26 | 2 (0)| 00:00:01 | |* 5 | TABLE ACCESS BY INDEX ROWID| SOL_FICHERO | 2 | 44 | 2 (0)| 00:00:01 | |* 6 | INDEX RANGE SCAN | SOL_FICHERO_I01 | 6 | | 1 (0)| 00:00:01 | |* 7 | INDEX UNIQUE SCAN | PK_CONFACTU | 5820 | 23280 | 0 (0)| 00:00:01 | |* 8 | INDEX RANGE SCAN | PK_CONTABON | 1 | 19 | 2 (0)| 00:00:01 | |* 9 | INDEX UNIQUE SCAN | PK_CTAFACTU | 1 | 9 | 1 (0)| 00:00:01 | |* 10 | INDEX UNIQUE SCAN | PK_ABONOS | 1 | 10 | 1 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - filter("A"."COD_CONFACTU" IS NOT NULL) 6 - access("ID_SOLICITUD"=71) 7 - access("COD_CONFACTU"="A"."COD_CONFACTU") 8 - access("A"."CTA_FACTURAC"="A"."CTA_FACTURAC") filter("A"."NUM_TELEFONO" IS NULL OR "A"."NUM_TELEFONO"="A"."NUM_TELEFONO" AND "A"."NUM_TELEFONO"<>'0') 9 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC") 10 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO")2)
SQL> WITH CTATEL AS 2 (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO 3 FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C 4 WHERE B.CTA_FACTURAC=A.CTA_FACTURAC 5 AND C.NUM_TELEFONO=A.NUM_TELEFONO) 6 SELECT 71, A.CTA_FACTURAC, NULL, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E' 7 FROM SOL_FICHERO a 8 WHERE ID_SOLICITUD=71 9 AND A.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO='0' 10 AND EXISTS (SELECT 1 FROM CTATEL b WHERE A.CTA_FACTURAC=B.CTA_FACTURAC) 11 AND A.COD_CONFACTU IS NOT NULL AND EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU); Execution Plan ---------------------------------------------------------- Plan hash value: 3992598922 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 26 | 7 (0)| 00:00:01 | |* 1 | FILTER | | | | | | | 2 | NESTED LOOPS SEMI | | 1 | 26 | 2 (0)| 00:00:01 | |* 3 | TABLE ACCESS BY INDEX ROWID| SOL_FICHERO | 1 | 22 | 2 (0)| 00:00:01 | |* 4 | INDEX RANGE SCAN | SOL_FICHERO_I01 | 6 | | 1 (0)| 00:00:01 | |* 5 | INDEX UNIQUE SCAN | PK_CONFACTU | 5820 | 23280 | 0 (0)| 00:00:01 | | 6 | NESTED LOOPS | | 1 | 38 | 5 (0)| 00:00:01 | | 7 | NESTED LOOPS | | 1 | 28 | 4 (0)| 00:00:01 | |* 8 | INDEX UNIQUE SCAN | PK_CTAFACTU | 1 | 9 | 2 (0)| 00:00:01 | |* 9 | INDEX RANGE SCAN | PK_CONTABON | 1 | 19 | 2 (0)| 00:00:01 | |* 10 | INDEX UNIQUE SCAN | PK_ABONOS | 1 | 10 | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter( EXISTS (SELECT /*+ */ 0 FROM "FACTMS"."PGA_ABONOS_1" "C","FACTMS"."PGA_CTAFACTU" "B","FACTMS"."PFA_CONTABON_1" "A" WHERE "B"."CTA_FACTURAC"="A"."CTA_FACTURAC" AND "A"."CTA_FACTURAC"=:B1 AND "B"."CTA_FACTURAC"=:B2 AND "C"."NUM_TELEFONO"="A"."NUM_TELEFONO")) 3 - filter("A"."COD_CONFACTU" IS NOT NULL AND "A"."NUM_TELEFONO" IS NOT NULL AND "A"."NUM_TELEFONO"='0') 4 - access("ID_SOLICITUD"=71) 5 - access("COD_CONFACTU"="A"."COD_CONFACTU") 8 - access("B"."CTA_FACTURAC"=:B1) 9 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC") filter("A"."CTA_FACTURAC"=:B1) 10 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO")3)
1 WITH CTATEL AS 2 (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO 3 FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C 4 WHERE B.CTA_FACTURAC=A.CTA_FACTURAC 5 AND C.NUM_TELEFONO=A.NUM_TELEFONO) 6 SELECT 71, A.CTA_FACTURAC, B.NUM_TELEFONO, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E' 7 FROM SOL_FICHERO a, CTATEL b 8 WHERE ID_SOLICITUD=71 9 AND A.CTA_FACTURAC=B.CTA_FACTURAC 10 AND (A.NUM_TELEFONO IS NULL OR (A.NUM_TELEFONO <> '0' AND B.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO=B.NUM_TELEFONO)) 11 AND A.COD_CONFACTU IS NOT NULL AND EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU) 12 UNION ALL 13 SELECT 71, A.CTA_FACTURAC, NULL, A.COD_CONFACTU, SYSDATE, 0, A.TOT_IMPORTE*166.386, A.TOT_IMPORTE, 'E' 14 FROM SOL_FICHERO a 15 WHERE ID_SOLICITUD=71 16 AND A.NUM_TELEFONO IS NOT NULL AND A.NUM_TELEFONO='0' 17 AND EXISTS (SELECT 1 FROM CTATEL b WHERE A.CTA_FACTURAC=B.CTA_FACTURAC) 18* AND A.COD_CONFACTU IS NOT NULL AND EXISTS (SELECT 1 FROM PGSM_CONFACTU WHERE COD_CONFACTU=A.COD_CONFACTU) Execution Plan ---------------------------------------------------------- Plan hash value: 3945970136 ----------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 3351 | 127K| | 776 (53)| 00:00:10 | | 1 | TEMP TABLE TRANSFORMATION | | | | | | | | 2 | LOAD AS SELECT | | | | | | | |* 3 | HASH JOIN | | 323K| 11M| 12M| 66832 (4)| 00:13:22 | |* 4 | HASH JOIN | | 338K| 9254K| 4176K| 39353 (3)| 00:07:53 | | 5 | INDEX FAST FULL SCAN | PK_CTAFACTU | 203K| 1788K| | 190 (4)| 00:00:03 | | 6 | INDEX FAST FULL SCAN | PK_CONTABON | 16M| 300M| | 13975 (4)| 00:02:48 | | 7 | INDEX FAST FULL SCAN | PK_ABONOS | 15M| 150M| | 9766 (5)| 00:01:58 | | 8 | UNION-ALL | | | | | | | |* 9 | HASH JOIN | | 3350 | 127K| | 388 (5)| 00:00:05 | | 10 | NESTED LOOPS SEMI | | 1 | 26 | | 2 (0)| 00:00:01 | |* 11 | TABLE ACCESS BY INDEX ROWID| SOL_FICHERO | 2 | 44 | | 2 (0)| 00:00:01 | |* 12 | INDEX RANGE SCAN | SOL_FICHERO_I01 | 6 | | | 1 (0)| 00:00:01 | |* 13 | INDEX UNIQUE SCAN | PK_CONFACTU | 5820 | 23280 | | 0 (0)| 00:00:01 | | 14 | VIEW | | 323K| 4112K| | 379 (4)| 00:00:05 | | 15 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6621_1BE166BB | 323K| 6009K| | 379 (4)| 00:00:05 | |* 16 | HASH JOIN SEMI | | 1 | 33 | | 388 (5)| 00:00:05 | | 17 | NESTED LOOPS SEMI | | 1 | 26 | | 2 (0)| 00:00:01 | |* 18 | TABLE ACCESS BY INDEX ROWID| SOL_FICHERO | 1 | 22 | | 2 (0)| 00:00:01 | |* 19 | INDEX RANGE SCAN | SOL_FICHERO_I01 | 6 | | | 1 (0)| 00:00:01 | |* 20 | INDEX UNIQUE SCAN | PK_CONFACTU | 5820 | 23280 | | 0 (0)| 00:00:01 | | 21 | VIEW | | 323K| 2214K| | 379 (4)| 00:00:05 | | 22 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6621_1BE166BB | 323K| 6009K| | 379 (4)| 00:00:05 | ----------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("C"."NUM_TELEFONO"="A"."NUM_TELEFONO") 4 - access("B"."CTA_FACTURAC"="A"."CTA_FACTURAC") 9 - access("A"."CTA_FACTURAC"="B"."CTA_FACTURAC") filter("A"."NUM_TELEFONO" IS NULL OR "A"."NUM_TELEFONO"="B"."NUM_TELEFONO" AND "A"."NUM_TELEFONO"<>'0') 11 - filter("A"."COD_CONFACTU" IS NOT NULL) 12 - access("ID_SOLICITUD"=71) 13 - access("COD_CONFACTU"="A"."COD_CONFACTU") 16 - access("A"."CTA_FACTURAC"="B"."CTA_FACTURAC") 18 - filter("A"."COD_CONFACTU" IS NOT NULL AND "A"."NUM_TELEFONO" IS NOT NULL AND "A"."NUM_TELEFONO"='0') 19 - access("ID_SOLICITUD"=71) 20 - access("COD_CONFACTU"="A"."COD_CONFACTU")I use this WITH clausule in the query above:
operating system
WITH CTATEL AS (SELECT A.CTA_FACTURAC, A.NUM_TELEFONO FROM PFA_CONTABON A, PGA_CTAFACTU B, PGA_ABONOS C WHERE B.CTA_FACTURAC=A.CTA_FACTURAC AND C.NUM_TELEFONO=A.NUM_TELEFONO)
Why 3) plan is so bad? (In any case, it's like "UNION ALL" of 1) and 2).
Thanks in advance,
Jose Luis
We do not know if one of them is 'bad' plans.
In fact, there is no such thing as a bad plan, one or several inaccurate estimates.
To determine whether a plan is 'bad', you really see who believes are inaccurate - and which means the time of execution of the execution plans and runtime enforcement measures.
Please take a look at the notice in the following thread:
HOW to: Validate a query of SQL statement tuning - model showing
What happens in the third SQL, is that because you referenced the subquery WITH twice, Oracle decides to materialise it in a temporary table for the reason that it is cheaper that to do the same thing one subquery normally twice - a reasonable approach.
It is probably more likely that the third query estimates are more accurate than the other two.
-
Star_transformation not shoiwng in the execution plan
Hello
We have a data warehouse and processing star not no projection in the execution plan.
STAR_TRANSFORMATION_ENABLED at the database level.
With the help of 11.2.0.3 on AIX
The fact table has index bitmap and fks to keys on tables dimesnion dimesnion.
Example query
Anthing we are ' % s '?select * from media m, retailer_transaction rt , retailer r where m.dimension_key = rt.plant_issue_id and rt.outlet_id = r.dimension_key and prod_num = 600
Found how interrogate more selective cause said to use star_transformation
added and plis_handled_year = 2013
and out_num 123423
Why is this good?
Is there a rule such as only highly selective queries will use transformation star?
Thank you
Published by: user5716448 on February 15, 2013 04:10Transformation of Star I it'sactually one expensive thing to do. So, the optimizer plans an ABC on this subject. This quote comes from a piece on the blog of optimizer Oracle [url https://blogs.oracle.com/optimizer/entry/star_transformation]:
"The transformation is performed based on cost - when the cost of the transformed plan is lower than that of the unprocessed plan. If dimension filters do not significantly reduce the amount of data to be extracted from the fact table, and then a full table scan is more effective. »
Cheers, APC
-
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. -
difference between the execution plan and explain the plan?
What is the difference between the execution plan & explain the plan?an execution plan is the actual steps that oracle will pass by when it executes a query.
explain plan is a tool that is used to generate the steps of an execution plan for a query.
Maybe you are looking for
-
How can I make the screen easier to read?
I increased the font size, but the police is very pale and I want to make it more "BOLD".
-
I have an old Mac Mini running 10.7.5 server and I'll try to get everything set up correctly, so I can use L2TP VPN and I tried the rest of this guide (https://macminicolo.net/lionservervpn) and I can connect when I'm on my internal network, but not
-
Motorola Moto G 3rd Gen "Dual Sim" GREECE/EUROPE
Hi all I come and live Greece (EU) and have question the interest to buy a 'New' Motorola Moto G (3rd generation) Dual Sim, 2 GB Ram, 16 GB of storage Please tell me what is the model? to support Dual SIM (Sim Type) and networks? Please tell how to f
-
Iconia b1-720 keeps overheating
My tablet is only 7months old and he just repeats it is overheating and then stops. It doesn't feel particularly hot, and it's annoying because I can't do anything on this issue now before its judgment. If anyone has any ideas how I can overcome this
-
Windows 7 Ultimate Upgrade from Vista Ultimate stopped and said that that wouldn't work with Bus controllers series DS1M12. Is the HDX 9010nr supprted? It was only 18 months old. I'm stuck in the middle of the installation. Thank you