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.
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 -
OBIEE logical column has same SQL but returns different results
I have a SQL query with a case statement that returns the correct results by operating in Oracle SQL Developer. I've created several logical columns in OBIEE, one for each case in the original query. However, the results returned by each logical column OBIEE are radically different from the original SQL query results, even if the SQL code is virtually identical.
For example, a column logical OBIEE that returns incorrect results contains the following SQL code:
SUM (CASE when
("Registration - College". "" Effective colleges F. ("" Postal code "like '% a %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%B %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%c %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like"% %") or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%G %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like"hour %") or
("Registration - College". "" Effective colleges F. ("" Postal code "like"%%J") or
("Registration - College". "" Effective colleges F. ("' Postal code ' like '%R %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%s %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%T %') or
("Registration - College". "" Effective colleges F. ("" Postal code "like"% %") or
("Registration - College". "" Effective colleges F. ("" Postal code "like '%x %') or
("Registration - College". "" Effective colleges F. ("' Postal code ' like '%Y %')
THEN 0 OTHERWISE 1 END)
The case statement in the original SQL query, which returns the correct results, is as follows:
CASE
WHEN (postal_zip_code_permanent like "%%K") or (postal_zip_code_permanent like '% %') or (postal_zip_code_permanent like '%m %') or (postal_zip_code_permanent like '%n %') or (postal_zip_code_permanent like "%p %") THEN "Ontario".
WHEN (postal_zip_code_permanent like '% a %') or (postal_zip_code_permanent like '%B %') or (postal_zip_code_permanent like '%c %') or (postal_zip_code_permanent like '% %') or (postal_zip_code_permanent like '%G %') or (postal_zip_code_permanent like "%hour") or (postal_zip_code_permanent like "%%J") or (postal_zip_code_permanent like "%%R") or (postal_zip_code_permanent like '%s %') or (postal_zip_code_permanent like '%t %') or (postal_zip_code_permanent like '% %') or (postal_zip_ code_permanent like '%x %') or (postal_zip_code_permanent like "%%Y") THEN "Canada, other than Ontario.
WHEN (substr(postal_zip_code_permanent,1,1) IN ('1 ', '2', '3', '4', '5', '6' ', 7',' 8 ', ' 9',' 0') or (postal_zip_code_permanent like '%d %') or (postal_zip_code_permanent like '%f %') or (postal_zip_code_permanent like ' % I %') or (postal_zip_code_permanent like "% O") or (postal_zip_code_permanent like "%%Q") or (postal_zip_code_permanent like "%%U") or (postal_zip_code_permanent like ' % W ') or (postal_zip_code_permanent like "%%Z")) THEN 'other')
WHEN (postal_zip_code_permanent like '% + %') or (postal_zip_code_permanent like '%. %') or (postal_zip_code_permanent like ' %? %') or (postal_zip_code_permanent like '% %') or postal_zip_code_permanent IN ('+ ','.', '?)) (',',') And THEN "Invalid."
WHEN postal_zip_code_permanent is null THEN 'Blank '.
Of OTHER postal_zip_code_permanent
END
Now I see what the problem was. In the original SQL query, each condition is exclusive, for each record will only be categorized in one of the scenarios WHEN. But in OBIEE, each logical column is autonomous, so some records were classified into more than logical column, even if each logical column was supposed to be exclusive.
-
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?
-
Multiple execution plan.
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/ -
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
-
Import a table from a fullexport to an another schema with a different name
Hello
I habe a full export created with expdp. I want to import a table (tkz.verlauf) of this fullexport to another schema (Tom) with another (zzz) name of this table.
I tried this:
content = all
Full = N
Directory = ORADUMP
dumpfile = fullexp.dmp
sqlFile = IMP. SQL
logfile = IMP.log
schemas = tkz
tables = verlauf
remap_schema = tkz:blubb
REMAP_TABLESPACE = verlauf:zzz
But it does not work:
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle 12 c database Release 12.1.0.1.0 - 64 bit Production
UDI-00010: several work modes, patterns and paintings.
When I use it without the 'paintings' all tables will be imported.
Can someone help me?
Best wishes Jessica
Hi Jessica,.
You must just have something like this
Directory = ORADUMP
dumpfile = fullexp.dmp
logfile = IMP.log
tables is TKZ. Verlauf
remap_schema = tkz:blubb
remap_table = verlauf:zzz
Not sure if you want to rename the table or put a different tablespace (I did rename the table) - replace the last line with rather than table tablespace if you just want it in a different tablespace.
See you soon,.
Rich
-
Different plan for the same sql id
Hello
Our team of application reported recently that a query ran longer than usual.
Search in tables AWR (dba_hist_active_sess_history & dba_hist_sqlstat), it was a change of plan_hash_value. The next day, without intervention from anyone (collect statistics did not run, no change in the tables involved) the sql used the former plan and completed quickly.
The differences in the plan was the index that was used to access the table.
What could be the reason for the optimizer to choose a bad plan and return once more the good thing. ?
The code sql that has been run twice & three in one day and then it years off cursor cache.
Regime shifts are normal.
Flipfloppping plans are quite normal.
I'd be willing to bet that a large percentage of your SQL shows variations in implementation plans and you never notice.
And there are several reasons why you might get a different plan.
1 bind variable peeking - it is normal SQL for the age from the cache and then get analyzed once again with different bind variable leading to different cardinality estimates and plans
2. the statistics change - it is normal that the statistics of change over time causing different cardinality estimates and the various plans, especially if the histograms are involved and changing buckets
3. data change - especially if you use dynamic sampling it is normal to get a different sample of data leading to different cardinality estimates and plans
4 SYSDATE - it's normal for queries with SYSDATE in them to recognize that time is never on leave and which, in conjunction with statistics or data, can lead to different cardinality estimates and plans
5. integrated optimization features - it's normal for features like ACS to kick in and notice that they got forecasts wrong in an execution plan and force the recalculation to a different plan with an adjusted cardinality.
Using DBMS_XPLAN. DISPLAY_CURSOR or DISPLAY_AWR you can get different plans (provided that they are in memory or AWR). The notes section should indicate cardinality comments have been a factor. You can also get links peeked with format mask of "+ PEEKED_BINDS".
-
Performance problem, same range scan different execution time
Oracle 11 GR 1 material, execute queries within seconds of each other.
I have 2 questions that are logically the same. Even the explain command plans are very similar, except the other indicates a range index scan doing much more work than the first. The table is an IOT with deal_bucket_id and datetime as PK (in that order).
TKPROF output below:
select count(*) from deal_bucket_detail where deal_bucket_id
How can I work on why the second query is much more work than the first?
in
(815
, 816
, 817
, 818
...
, 997)
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
-----------------------------------------------------------------------------------------------------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.79 2.24 2936 3551 0 1
-----------------------------------------------------------------------------------------------------
total 4 0.79 2.24 2936 3551 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=3551 pr=2936 pw=2936 time=0 us)
1430928 FILTER (cr=3551 pr=2936 pw=2936 time=380920 us)
1430928 INLIST ITERATOR (cr=3551 pr=2936 pw=2936 time=372057 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=3551 pr=2936 pw=2936 time=8782 us cost=1203 size=4069596 card=339133)(object id 14199)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 2936 0.02 1.49
SQL*Net message from client 2 0.00 0.00
********************************************************************************
select count(*) from deal_bucket_detail where deal_bucket_id
between 815 and 997
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
-----------------------------------------------------------------------------------------------------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 3.70 8.86 29199 26986 0 1
-----------------------------------------------------------------------------------------------------
total 4 3.70 8.86 29199 26986 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=26986 pr=29199 pw=29199 time=0 us)
1430928 FILTER (cr=26986 pr=29199 pw=29199 time=6986078 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=26986 pr=29199 pw=29199 time=6977063 us cost=45208 size=5195748 card=432979)(object id 14199)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 219 0.04 0.08
db file parallel read 35 0.04 0.32
db file scattered read 211 0.10 5.02
SQL*Net message from client 2 0.00 0.00
********************************************************************************
Published by: SamB on August 5, 2009 18:09The two make an index range scan, but another index range scan.
Query 1: inlist iterator withrange of index analysis for 1 value, because of the hard-coded values.
Query 2: analysis of range of index for all values, starting at the bottom, thanks to between.-------------
Sybrand Bakker
Senior Oracle DBA -
Plans of multiple executions for the same SQL statement
Dear experts,
awrsqrpt. SQL shows several plans for a single SQL statement executions. How is it possible that a single SQL statement will be several Plans of executions within the AWR report.
Here is the output of the awrsqrpt for your reference.
Your contribution is very much appreciated.WORKLOAD REPOSITORY SQL Report Snapshot Period Summary DB Name DB Id Instance Inst Num Release RAC Host ------------ ----------- ------------ -------- ----------- --- ------------ TESTDB 2157605839 TESTDB1 1 10.2.0.3.0 YES testhost1 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 32541 11-Oct-08 21:00:13 248 141.1 End Snap: 32542 11-Oct-08 21:15:06 245 143.4 Elapsed: 14.88 (mins) DB Time: 12.18 (mins) SQL Summary DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542 Elapsed SQL Id Time (ms) ------------- ---------- 51szt7b736bmg 25,131 Module: SQL*Plus UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 ) ------------------------------------------------------------- SQL ID: 51szt7b736bmg DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542 -> 1st Capture and Last Capture Snap IDs refer to Snapshot IDs witin the snapshot range -> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC... Plan Hash Total Elapsed 1st Capture Last Capture # Value Time(ms) Executions Snap ID Snap ID --- ---------------- ---------------- ------------- ------------- -------------- 1 2960830398 25,131 1 32542 32542 2 3834848140 0 0 32542 32542 ------------------------------------------------------------- Plan 1(PHV: 2960830398) ----------------------- Plan Statistics DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542 -> % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100 Stat Name Statement Per Execution % Snap ---------------------------------------- ---------- -------------- ------- Elapsed Time (ms) 25,131 25,130.7 3.4 CPU Time (ms) 23,270 23,270.2 3.9 Executions 1 N/A N/A Buffer Gets 2,626,166 2,626,166.0 14.6 Disk Reads 305 305.0 0.3 Parse Calls 1 1.0 0.0 Rows 371,735 371,735.0 N/A User I/O Wait Time (ms) 564 N/A N/A Cluster Wait Time (ms) 0 N/A N/A Application Wait Time (ms) 0 N/A N/A Concurrency Wait Time (ms) 0 N/A N/A Invalidations 0 N/A N/A Version Count 2 N/A N/A Sharable Mem(KB) 26 N/A N/A ------------------------------------------------------------- Execution Plan ------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------ | 0 | UPDATE STATEMENT | | | | 1110 (100)| | | 1 | UPDATE | TEST | | | | | | 2 | TABLE ACCESS FULL | TEST | 116K| 2740K| 1110 (2)| 00:00:14 | | 3 | TABLE ACCESS BY INDEX ROWID| ACCT | 1 | 26 | 5 (0)| 00:00:01 | | 4 | INDEX RANGE SCAN | ACCT_DT_ACC_IDX | 1 | | 4 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------ Plan 2(PHV: 3834848140) ----------------------- Plan Statistics DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542 -> % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100 Stat Name Statement Per Execution % Snap ---------------------------------------- ---------- -------------- ------- Elapsed Time (ms) 0 N/A 0.0 CPU Time (ms) 0 N/A 0.0 Executions 0 N/A N/A Buffer Gets 0 N/A 0.0 Disk Reads 0 N/A 0.0 Parse Calls 0 N/A 0.0 Rows 0 N/A N/A User I/O Wait Time (ms) 0 N/A N/A Cluster Wait Time (ms) 0 N/A N/A Application Wait Time (ms) 0 N/A N/A Concurrency Wait Time (ms) 0 N/A N/A Invalidations 0 N/A N/A Version Count 2 N/A N/A Sharable Mem(KB) 26 N/A N/A ------------------------------------------------------------- Execution Plan --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | UPDATE STATEMENT | | | | 2 (100)| | | 1 | UPDATE | TEST | | | | | | 2 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 28 | 2 (0)| 00:00:01 | | 3 | INDEX RANGE SCAN | TEST_DT_IND | 1 | | 1 (0)| 00:00:01 | | 4 | TABLE ACCESS BY INDEX ROWID| ACCT | 1 | 26 | 4 (0)| 00:00:01 | | 5 | INDEX RANGE SCAN | INDX_ACCT_DT | 1 | | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------------------- Full SQL Text SQL ID SQL Text ------------ ----------------------------------------------------------------- 51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) + NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )
Thank you for taking your time to answer my question.
ConcerningOracle Lover3 wrote:
How will I know (from Plan 1 and Plan 2) whose execution plan chose for the current run?Since you're already on 10.2, you can identify the actual execution plan by checking in V$ SESSION SQL_ID and SQL_CHILD_NUMBER column. This can be used to identify the plan in V$ SQL_PLAN (columns SQL_ID and CHILD_NUMBER) and in 10g, you can use the convenient DBMS_XPLAN. Function DISPLAY_CURSOR for the information of the real plan using these two parameters.
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/ -
Re: "insufficient privileges" error when you run the Java stored procedure in another schema
I get an "insufficient privileges" error when you run the Java stored procedure in another schema, see details below. I don't know what are missing privileges (I already granted the EXECUTE privilege), suggestions? -Thank you.
Define a simple java class and deploy it as a Java stored procedure to test:
Schema: User1
test of the package;
public class HelloWorld {}
public HelloWorld() {
Super();
}
public static String Hello () {}
Return "HELLO";
}
}
CREATE or REPLACE FUNCTION HELLO RETURN VARCHAR2 AUTHID CURRENT_USER AS LANGUAGE JAVA NAME ' test. HelloWorld.hello () return java.lang.String';
Grant execute on USER2 HELLO
Test the Java stored procedure through the PL/SQL function call (in the same schema):
Schema: User1
SET SERVEROUTPUT ON
DECLARE
v_Return VARCHAR2 (200);
BEGIN
v_Return: = User1. HELLO;
DBMS_OUTPUT. Put_line ('v_Return =' | v_Return);
END;
anonymous block filled
v_Return = HELLO
Test the Java stored procedure through the PL/SQL function call in a different pattern:
Schema: USER2
SET SERVEROUTPUT ON
DECLARE
v_Return VARCHAR2 (200);
BEGIN
v_Return: = User1. HELLO;
DBMS_OUTPUT. Put_line ('v_Return =' | v_Return);
END;
Error report-
ORA-01031: insufficient privileges
ORA-06512: at "User1." HELLO', line 1
ORA-06512: at line 4 level
01031 00000 - "insufficient privileges".
* Cause: An attempt was made to change the user name or password
without the privilege appropriate. This error also occurs if
trying to install a database without the need for employment
access privileges.
When Trusted Oracle is configure in DBMS MAC, this error may occur
If the user has been granted the privilege necessary for a higher label
that the connection is active.
* Action: Ask the database to perform the operation or grant administrator
the required privileges.
For users Trusted Oracle get this error, well that granted the
the privilege that is suitable for the top label, ask the database
administrator to grant the privilege to the appropriate label.
You have created the function with AUTHID CURRENT_USER, which means that the function is executed with the rights of the applicant (but not with the rights of the author). This means that the applicant must have grants (directly or through roles) on all used/accessible objects in the service. In your case the user USER2 has not granted with EXECUTE on the class/source Java test. Class HelloWorld, causing the ORA-01031 exception. You create service without AUTHID CURRENT_USER (i.e. with AUTHID DEFINE, which is by default, if you do not have a specific reason to use AUTHID CURRENT_USER) or grant EXECUTE on JAVA test SOURCE. Class HelloWorld to User2.
Dimitar
-
Cost of the execution plan is different in the two databases
Hi gurus,
I have two databases, which are 12 C.
The execution plan cost is different in the two databases for the same query.
is it possible to copy the execution to another plan.
Thank you in advance
Kind regards
REDA
Jr.Raj wrote:
There are a few differences.
The machine that has a high cost, has setup up, linux, 2-node RAC, more CPU.
and
other machine windows server less Setup and less cpus.
Please explain, cost really makes a difference.
Thank you & best regards
REDA
You simply can't compare costs like that. It does not work like that. Especially through two different systems. Here is a very good read: column the COST of the PLAN to EXPLAIN. Oracle FAQ
-
Call another schema in a cursor
Hello world
I am trying to export data using UTL_FILE and using a function that receives the SQL as a parameter. Thus, the opening of the cursor within the function like this:
P_Query contains SQL code, and it works with tables on the same schemaOPEN C_Cursor FOR P_Query;
for example.
But when I set P_Query to select another schema, it fails.P_Query = ‘select col1, col2 from table1’)
for example
I know that if I try this, will work:P_Query = ‘select col1 from schema2.table1’;
But I need to set the schema of the function parameters.OPEN C_Cursor FOR 'SELECT col1 FROM '||schema2||'.table1';
My question: is there a way to select another schema with a slider, just change the sql script?Rafhael Dantas says:
But when I set P_Query to select another schema, it fails.
Well, when I open my wallet, I can see what is inside, but when I try to open the wallets of my colleague... :). In order to select from one table to the other schema, you must have the appropriate privileges. In addition, if the option is within the rights define object stored, privilege must be granted directly, without going through the role.
SY.
-
create existing table in another schema
Hi master,
We are using oracle 10g R2 on linux.
I have a scheme say user1 with many tables, starting with
BC_ (50 PICTURES)
PC_ (20 TABLES)
LC_ (30 TABLES) etc.,.
now, I want to create these tables in another schema with their constraints and their privileges in another schema.
as I want to generate a create table script, which will create a table that begins with "BC_" only. another script will create table starting with "PC_" only. and like that.
is it possible with the command
create the table AS
Select * from (old scheme). (table_name);
can we use query sub in it to be more precise?
and it will transfer all its privileges and grants the new schema?
Thanks and greetings
VDIt is possible to CREATE TABLE as SELECT from a different scheme but CREATE TABLE as SELECT will transfer only the data and the structure of the base (column names and data types) table, no constraints.
I think, you have two options to do this easily:
(1) use SQLDeveloper (GUI) or a procedure from PL/SQL DBMS_METADATA. GET_DDL to generate the SQL script to create table with constraints, you can use INSERT INTO new table (columns) column SELECT FROM oldschema.oldtable
DBMS_METADATA Description: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_metada.htm#i1019414(2) export a schema data, import it into the other using Data Pump or exp/IMP.
http://download.Oracle.com/docs/CD/B19306_01/server.102/b14215/dp_export.htm#i1007466
Maybe you are looking for
-
PORECTOL in MS Dynamics GP 2010 - accounting units returned and replaced?
In GP, if we order 10 units on a purchase order, we receive 10 units (or 12 if we have a tolerance of 20%). If we go back 5 and select 'replace returned products' option, then GP represents the units 'replaced' defaults to '5' on the next shipment tr
-
Microsoft updates installation gives me an error 800706BE
I had just reinstalled Windows 7 Enterprise 64-bit on a reformatted hard drive. The first thing I did once inside, ran Windows Update and start installation updates one by one (with a system reboot between each of them, even if it was not necessary).
-
I'm unable to receive emails.
I cannot receive emails - I get an email saying exceeded reviewed e-mail message mailbox. Please try again later. Help! I've tried everything.
-
Vista Premium home help and support missing by mistake reviews. How can I get that back
Vista Premium home help and support missing by mistake reviews. How can I get that back. This happens when I try to access it using the start menu of the menu of boot-may have been inadvertantly deleted.
-
Photosmart C4780 on Windows 7 family
Had installed HP need to Center and the printer on the laptop and work very well until problems with the format of scanning and printing started occurring. They advised me to reinstall the printer from scratch. remove the printer and the software via