OEM12c: in execution plans, no more links to tables (OEM10g has them)
in the Plan for SQL, version details tab OEM 10g has hyperlinks to the objects mentioned in the implementation plan.
It seems not to be the case more in OEM12c:
Does anyone know how to activate the ability to directly open the details page of the objects listed in the execution plans?
Hello
This feature has been valuable, but unfortunately has not been set up at EM12c. If you want to access the Cloud control, once connected to the database, the best way is to click on the schema, database objects and then go to the correct data type to search for the object in question. If you are looking for information on the object in the execution plan, then the best way to see it is via SQL Monitor if the process has not aged. If it has, then use SQL statements search, (under the menu Performance/SQL for the database that you are connected) and then do a search for cache, CWA and other, you know you want to watch for the SQLID in question.
I hope this helps!
Kevin Pot' wine-Gorman
Tags: Enterprise Manager
Similar Questions
-
How can I create custom DAC execution plan
Hello
I need to create custom DAC execution plan to load data into tables. in fact schema we build with 2 custom tables Sun, 8 tables OOTB (fact and Sun). So I need to copy the OOTB existing execution plan, delete unwanted tables, stains ect and rebuild. But I do not know the exact process to do could you please provide step by step details?
We use 10.1.3.4.1 OBIEE, BI Apps 7.9.6.1 and customer DAC is on windows XP.
Grateful for your help!
Thank you
Jay.Visit this link...
DAC-> Execute-> implementation plans-> click New and add your domains, settings, etc. see this link which details
http://download.Oracle.com/docs/CD/E12104_01/books/DAC/DADesignETL16.html
-
How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you
How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you
After two execution plans that have the same sql_id, so we can see what you're talking about.
See "Oracle Explain Explain Plan optimizer" by Maria Colgan of the Oracle optimizer group
Examine the various aspects of a selectivity to parallel execution plan
performance and understand what information you should be brilliant
the plan can be overwhelming even for the most experienced DBA. This document
offers a detailed explanation on each of the aspects of the execution plan and a
Overview of what caused the CBO to make the decision, he did.
-
10.2.0.5 - execution plan has changed because of the link stealthily
Hi guys,.
Our DB server has very heavy use of the CPU on some days.
After investigation, it is due to a particular change in SQL in the execution plan.
For example, this SQL has SQL_ID: 123, with execution plan 2 (hash value).
PLAN 1 - ABC [GOOD] - scan of systematic index
PLAN 2 - DEF [BAD] - full analysis
Problem SQL < not really sql, for example simplify >
SELECT *.
XX
WHERE CRITERIA =: B1;
I would like to identify the value he threw a look that caused the change in plan 1 plan 2 plan.
In any case, I know?
I also have the SQLT report. But can't really understand the part of connection overview of the report.
Please advise.
Thank youUsing DBMS_XPLAN. DISPLAY_CURSOR, you can use the format mask of '+ PEEKED_BINDS', for example
select * from table(dbms_xplan.display_cursor('',' ','+PEEKED_BINDS')); Or you can watch V$ SQL. BIND_DATA or, possibly, V$ SQL_PLAN. OTHER_XML although I'm not sure which version the links peeked appear in the latter.
You can use DBMS_SQLTUNE. EXTRACT_BIND/S on the amount GROSS of V$ SQL. (BIND_DATA so) you a license for the tuning pack and b) there is in this version.Published by: Dom Brooks on November 23, 2012 09:54
-
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
-
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
-
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.
-
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
-
Space of bunch of java error when executing execution plan
I get this error at the start of the execution plan ETL, to the capture of change task.
I ve tried to change the startclient.bat and using a larger setting... -Xmx1612... I can not set more... (get a JVM error).
Pls. y at - it suggestions to work around this error? The race AND stop right there... and nothing is loaded.
TXS.
Antonio
Solved... the increase in the parameter - Xmx in startserver.sh did the trick.
TXS for all your comments.
Antonio
-
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
-
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. -
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 -
With concatenation execution plan
Hi all
Could someone help to find out why concatenation is used by the optimizer and how I avoid it.
Oracle Version: 10.2.0.4
table of IFE.entityids were brought - partitioned on the data_provider column.select * from ( select distinct EntityType, EntityID, DateModified, DateCreated, IsDeleted from ife.EntityIDs i join (select orgid from equifaxnormalize.org_relationships where orgid is not null and related_orgid is not null and ((Date_Modified >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and Date_Modified < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss')) OR (Date_Created >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and Date_Created < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss')) ) ) r on(r.orgid= i.entityid) where EntityType = 1 and ((DateModified >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and DateModified < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss')) OR (DateCreated >= to_date('2011-06-12 14:00:00','yyyy-mm-dd hh24:mi:ss') and DateCreated < to_date('2011-06-13 14:00:00','yyyy-mm-dd hh24:mi:ss')) ) and ( IsDeleted = 0) and IsDistributable = 1 and EntityID >= 0 order by EntityID --order by NLSSORT(EntityID,'NLS_SORT=BINARY') ) where rownum <= 10; Execution Plan ---------------------------------------------------------- Plan hash value: 227906424 ------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10 | 570 | 39 (6)| 00:00:01 | | | |* 1 | COUNT STOPKEY | | | | | | | | | 2 | VIEW | | 56 | 3192 | 39 (6)| 00:00:01 | | | |* 3 | SORT ORDER BY STOPKEY | | 56 | 3416 | 39 (6)| 00:00:01 | | | | 4 | HASH UNIQUE | | 56 | 3416 | 38 (3)| 00:00:01 | | | | 5 | CONCATENATION | | | | | | | | |* 6 | TABLE ACCESS BY INDEX ROWID | ORG_RELATIONSHIPS | 1 | 29 | 1 (0)| 00:00:01 | | | | 7 | NESTED LOOPS | | 27 | 1647 | 17 (0)| 00:00:01 | | | | 8 | TABLE ACCESS BY GLOBAL INDEX ROWID| ENTITYIDS | 27 | 864 | 4 (0)| 00:00:01 | ROWID | ROWID | |* 9 | INDEX RANGE SCAN | UX_TYPE_MOD_DIST_DEL_ENTITYID | 27 | | 2 (0)| 00:00:01 | | | |* 10 | INDEX RANGE SCAN | IX_EFX_ORGRELATION_ORGID | 1 | | 1 (0)| 00:00:01 | | | |* 11 | TABLE ACCESS BY INDEX ROWID | ORG_RELATIONSHIPS | 1 | 29 | 1 (0)| 00:00:01 | | | | 12 | NESTED LOOPS | | 29 | 1769 | 20 (0)| 00:00:01 | | | | 13 | PARTITION RANGE ALL | | 29 | 928 | 5 (0)| 00:00:01 | 1 | 3 | |* 14 | TABLE ACCESS BY LOCAL INDEX ROWID| ENTITYIDS | 29 | 928 | 5 (0)| 00:00:01 | 1 | 3 | |* 15 | INDEX RANGE SCAN | IDX_ENTITYIDS_ETYPE_DC | 29 | | 4 (0)| 00:00:01 | 1 | 3 | |* 16 | INDEX RANGE SCAN | IX_EFX_ORGRELATION_ORGID | 1 | | 1 (0)| 00:00:01 | | | ------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(ROWNUM<=10) 3 - filter(ROWNUM<=10) 6 - filter(("DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND "RELATED_ORGID" IS NOT NULL) 9 - access("I"."ENTITYTYPE"=1 AND "I"."DATEMODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0 AND "I"."DATEMODIFIED"<=TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND "I"."ENTITYID">=0) 10 - access("ORGID"="I"."ENTITYID") filter("ORGID" IS NOT NULL AND "ORGID">=0) 11 - filter(("DATE_MODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_MODIFIED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss') OR "DATE_CREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "DATE_CREATED"<TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND "RELATED_ORGID" IS NOT NULL) 14 - filter("I"."ISDISTRIBUTABLE"=1 AND "I"."ISDELETED"=0 AND (LNNVL("I"."DATEMODIFIED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("I"."DATEMODIFIED"<=TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND "I"."ENTITYID">=0) 15 - access("I"."ENTITYTYPE"=1 AND "I"."DATECREATED">=TO_DATE(' 2011-06-12 14:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "I"."DATECREATED"<=TO_DATE(' 2011-06-13 14:00:00', 'syyyy-mm-dd hh24:mi:ss')) 16 - access("ORGID"="I"."ENTITYID") filter("ORGID" IS NOT NULL AND "ORGID">=0)
Is there a better way to rewrite this sql OR is it possible to eliminate the concatenation?
Thank youAs general approach, see the tuning wires:
[url http://forums.oracle.com/forums/thread.jspa?threadID=863295] How to post a sql tuning request
[url http://forums.oracle.com/forums/thread.jspa?messageID=1812597] When your query takes too longThe approach is essentially, for where the estimates are more inaccurate compared to actual expenditures and can find the reasons why.
Most of the time, if the statistics are accurate and then the estimates are correct, you will have a good plan. -
Hello
can you be kind to such me which is better and why (based on the columns of the execution Plan):
AND:Execution Plan A ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=17) 1 0 SORT (AGGREGATE) 2 1 INDEX (RANGE SCAN) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=1 Bytes=17) 3 2 SORT (AGGREGATE) 4 3 FIRST ROW (Cost=2 Card=6 Bytes=60) 5 4 INDEX (RANGE SCAN (MIN/MAX)) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=1060) tkprof gek1_ora_16520.trc gek1_ora_16520.out explain=scott/tiger sort=exeela sys=no call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 2 0 0 Fetch 2 0.00 0.00 0 2 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.00 0.00 0 4 0 1
Thank you.Execution Plan B ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=13) 1 0 COUNT (STOPKEY) 2 1 VIEW (Cost=2 Card=6 Bytes=78) 3 2 INDEX (RANGE SCAN DESCENDING) OF 'TEST_IDX' (NON-UNIQUE) (Cost=2 Card=6 Bytes=102) tkprof gek1_ora_16521.trc gek1_ora_16521.out explain=scott/tiger sort=exeela sys=no call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.03 0.06 2 41 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.00 0.00 0 2 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.03 0.06 2 43 0 1What is the version of db? Why you have not posted the actual queries as well? In a very generic view, the first is more beautiful, but is purely based on the elapsed time. What you are actually looking for?
HTH
Aman...
Maybe you are looking for
-
Media stream issue, charging/sync from my PC, photos are not in any kind of folder structure, all the photos are uploaded to the album pictures in iCloud. I have a folder structure in my Uploads folder on my PC, I was expecting this folder structure
-
Hello world I have a satellite M30, and the 'PC Diagnostic tool' utility does not work (nothing happens when I click on the program). I have windows XP service pack 1. I uninstalled and downloaded a new site of toshiba, but it still does not work. No
-
Firefox 3. had a drop-down list box the "<-" go back a page / '-> 'go forward icons on a page that allowed to choose what page he wanted rather than go back or forward one page at a time. "" Firefox 4. does not have this feature. At least I didn't th
-
I have problems with the installation of a game. It keeps buzzing look at me; data error (cyclic redundancy check) how can I get this game to install or is it a failure?
-
External Flash for t4i options
I recently bought the Canon t4i and am more than a little impressed by the unit. Years, I bought an external flash Canon Speedlite 299 T to use with my camera Canon AE1 Program. Ask yourself whether or not this old work, but still, flash works with