Similar Questions

• 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

• 12 c parallel execution Plans

  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:

  1. 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
  2. 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
  3. 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

• Execution Plan change

  Hello world

  I have this recommendation in Enterprise Manager, I would like to implement the first recommendation where there is a best execution plan that comes with the benefit of 99.7%. Its easy to implement using Enterprise manager by clicking just. But I would like to know how I can change execution plan using sqlplus. And if I want to return to the original plan, how can I do? Thank you in advance for your precious time really appreciate it.

  

  Yes, you can restore it-here, you will...

  http://docs.Oracle.com/CD/B28359_01/server.111/b28274/sql_tune.htm#CHDIDBBG

• 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

• "Execution plan is not available" in OEM.

  Greetings. Try to watch my first Exec Plan here and make the message displayed above in OEM 11 g even executing simple statements like below. I googled this and see only one question without an answer identical to this.

  Thank you!

  explain plan for

  Select * from SCOTT. DEPT;

  Don't know why you're looking for a plan in OEM.

  * Connect to the base of data with the help of sqlplus and wwho and extract the map below;

  SQL > explain plan for select * from SCOTT. DEPT;

  SQL > SELECT * FROM TABLE (dbms_xplan.display);

  * Very easy, set autotrace on and run the query, you will get the plan and statistics;

  SQL > set autotrace

  Syntax: SET AUTOT [RACE] {OFF |} WE | TRACE [ONLY]} [EXP [LAIN]] [[C] STAT]

  SQL > set autotrace on

  SQL > select * from double;

  D

  -

  X

  Execution plan

  ----------------------------------------------------------

  Hash value of plan: 272002086

  --------------------------------------------------------------------------

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

  --------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |      |     1.     2.     2 (0) | 00:00:01 |

  |   1.  TABLE ACCESS FULL | DOUBLE |     1.     2.     2 (0) | 00:00:01 |

  --------------------------------------------------------------------------

  Statistics

  ----------------------------------------------------------

  1 recursive calls

  0 db block Gets

  Gets 2 compatible

  0 physical reads

  0 redo size

  522 bytes sent via SQL * Net to client

  523 bytes received via SQL * Net from client

  2 SQL * Net back and forth to and from the client

  0 sorts (memory)

  0 sorts (disk)

  1 rows processed

  HTH,

  Pradeep

• Why 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.

• Trace SQL execution plan

  Hello

  I need to get the execution plan for a particular SQL, but I don't have it. Application it issues for a second or two and then his party so I think that the definition of a trace on specific user. Is it possible to get the execution plan of the query like this? Thank you!

  Find the sql code, you are interested in v$ sql using the sql_text column and get the SQL_ID and CHILD_NUMBER. Entry of these two values for the query to get the execution below plan.

  Select * from table

  (dbms_xplan.display_cursor ('> ',>, 'ALLSTATS'));

• Version 12: Same SQL, another scheme == &gt; 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.

• 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

• 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

  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

  http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

  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.

• 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

• Why I have an execution plan

  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

• What is the correct procedure of DMBS_XPLAN for the query execution plan

  Hello.

  We are on Oracle 11.2.0.3 on Linux. I am dev. DBA and we have about 80 developers Java development team. They want to question the execution plan of queries to resolve the sqls. Generally, they use the GUI tools like the toad to see execution plan. I always use the procedure for the following query execution plan:

  Select * from
  Table (dbms_xplan.display_cursor (null, null, 'allstats + cost'));

  I should suggest that they use this too rather than rely on tools like the toad - because they can show estimated plan and not the actual plan. And to provide a sql, it is best to use the real plan to work with. Do not take account of 'allstats + cost' part in the command above, but my point is: should I ask them of still rely on sqlplus and not the GUI tools and use the command display_cursor package DBMS_XPLAN?

  I will be grateful for suggestions.

  OrauserN

  You must use the DBMS_XPLAN package and functionality.

  The tool used to run the package doesn't matter. A raw request to DISPLAY_CURSOR will run the same server code in any tool including Toad.

  If you rely on other GUI features (for example a "explain plan" button or similar) then you know what this feature of actuall application running under-the-covers.

  My suggestion would be to assess and consider using Oracle free sql developer version 4 because it is not only FREE but also uses the DBMS_XPLAN correctly.

  http://www.Oracle.com/technetwork/developer-tools/SQL-Developer/downloads/index.html?ssSourceSiteId=ocomen

• order of operations in the execution plan

  Hello

  I'm not sure if my order of the following execution plan is correct.

  So hopefully someone can confirm or refute my order of the plan.

  
  

  This is the query:

  SELECT DISTINCT 'A3. ' "' ISIN '.

  Of

  "WERTPAPIERE" "A3."

  "LOGTABLE" "A2."

  "WP_STATUS" "A1".

  WHERE

  "A2". "PK_ID"= "A3". "" IDENTITY CARD "AND

  "A2". "" REFERENCE "> TIMESTAMP' 2014-01-06 18:30 ' AND

  "A2". "" REFERENCE "< = TIMESTAMP' 2014-01-08 07:00 ' AND

  "A2". "" LOG_DATUM "> TIMESTAMP' 2014-01-07 18:30 ' AND

  "A2". "" LOG_DATUM "< = TIMESTAMP' 2014-01-08 07:00 ' AND

  "A2". "TABLE" = "WERTPAPIERE" AND "

  "A3". ' BATCH '= 'A1'. "" IDENTITY CARD "AND

  "A1". "" CODE "<>" * 33' AND "

  (THERE ARE

  (SELECT "BESTANDS_MERKM" 0 "A7"

  WHERE 'A7 '. "ID"= "A3". "' BESTANDS_MERKMAL_ID ' AND ('A7'. "CODE"= "1" OR "A7". "CODE"(= '2')) AND ("A3" ".") " USER name "= 'Ect' OR 'A3'." USER name "= 'pro' OR 'A3'". "" Username "(= 'prom') or does NOT EXIST"

  (SELECT 0

  OF 'BESTANDS_MERKM' "A6".

  WHERE "A6". «ID «= NVL ("A3".» ("' BESTANDS_MERKMAL_ID ', 0) AND ("A6". "CODE"= "1" OR "A6". "CODE"(= '2')) AND ("A3" ".") " Username "="Res"OR"A3"." Username "(= 'prom') AND ("A3"". ")" LOESCH_KZ_ID' IS NULL OR EXISTS

  (SELECT 0

  OF 'WERTPAPIER_LOESCH_KZ' "A5".

  WHERE "A5". "ID"= "A3". "' LOESCH_KZ_ID ' AND 'A5 '. (("CODE"="1")) AND THERE ARE

  (SELECT 'PRODUKTGRUPPE_SEGMENT' 0 'A4'

  WHERE "A4". "ID"= "A3". "' PRODUKTGRUPPE_SEGMENTIERUNG_ID ' AND ('A4'. "CODE"= "USE" OR "A4". "CODE"= "ZUUZ" OR "A4". "CODE"= "4000" OR "A4". "CODE"= "5000" OR "A4". "CODE"= "3000" OR "A4". "CODE"= "4444" OR "A4". "CODE"= "4445" OR "A4". "CODE"= "5544" OR "A4". "CODE"= "6544" OR "A4". «CODE ' = ' 6543 "OR"A4".» ((("CODE"="8765')))

  The plan has been acquired through dbms_xplan:

  Select * from table (dbms_xplan.display_cursor (format = > 'ALLSTATS LAST SCHEMA'));

  
  

  Here's the plan:

  
  

  -----------------------------------------------------------------------------------------------------------------------------------------------------------------

  | ID | Operation | Name                     | Begins | E - lines. A - lines.   A - time | Pads | Bed |  OMem |  1Mem | Used Mem.

  -----------------------------------------------------------------------------------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |                          |      1.        |   1252 | 00:05:55.03 |      11 M |    594K |       |       |          |

  |   1.  UNIQUE HASH |                          |      1.  28517 |   1252 | 00:05:55.03 |      11 M |    594K |  1135K |  1135K | 2976K (0) |

  |*  2 |   FILTER                               |                          |      1.        |   2579 | 00:05:55.02 |      11 M |    594K |       |       |          |

  |*  3 |    HASH JOIN |                          |      1.    571K |   2219K | 00:05:53.49 |      11 M |    594K |  1306K |  1306K | 1 272 K (0) |

  |*  4 |     INDEX SCAN FULL | WP_STAT_UPI |      1.     57.     57. 00:00:00.01 |       1.      0 |       |       |          |

  |   5.     NESTED LOOPS |                          |      1.        |   2219K | 00:05:52.17 |      11 M |    594K |       |       |          |

  |   6.      NESTED LOOPS |                          |      1.    583K |   2219K | 00:00:18.62 |     726K |    436K |       |       |          |

  |   7.       RANGE OF SINGLE PARTITION |                          |      1.    583K |   2219K | 00:00:12.29 |     436K |    436K |       |       |          |

  |   8.        PARTITION LIST ALL |                          |      1.    583K |   2219K | 00:00:11.96 |     436K |    436K |       |       |          |

  |*  9 |         TABLE ACCESS FULL | LOGTABLE |      4.    583K |   2219K | 00:00:11.61 |     436K |    436K |       |       |          |

  | * 10 |       INDEX UNIQUE SCAN | WP_PK_I                  |   2219K |      1.   2219K | 00:00:05.34 |     289K |    491.       |       |          |

  |  11.      TABLE ACCESS BY INDEX ROWID | WERTPAPIERE |   2219K |      1.   2219K | 00:05:32.59 |      10 M |    157K |       |       |          |

  | * 12 |    TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM |      5.      1.      2. 00:00:00.01 |       8.      0 |       |       |          |

  | * 13 |     INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I |      5.      1.      4. 00:00:00.01 |       4.      0 |       |       |          |

  | * 14 |    TABLE ACCESS BY INDEX ROWID | BESTANDS_MERKM |      3.      1.      0 | 00:00:00.01 |       5.      0 |       |       |          |

  | * 15 |     INDEX UNIQUE SCAN | BESTANDS_MERKM_PK_I |      3.      1.      2. 00:00:00.01 |       3.      0 |       |       |          |

  | * 16.    TABLE ACCESS BY INDEX ROWID | PRODUKTGRUPPE_SEGMENT |      3.      1.      2. 00:00:00.01 |       6.      0 |       |       |          |

  | * 17.     INDEX UNIQUE SCAN | PRG_SEG_PK_I |      3.      1.      3. 00:00:00.01 |       3.      0 |       |       |          |

  | * 18.    INDEX UNIQUE SCAN | WERTPAPIER_LOESCH_KZ_UPI |      2.      1.      1. 00:00:00.01 |       2.      0 |       |       |          |

  -----------------------------------------------------------------------------------------------------------------------------------------------------------------

  Vector data

  -------------

  /*+

  BEGIN_OUTLINE_DATA

  IGNORE_OPTIM_EMBEDDED_HINTS

  OPTIMIZER_FEATURES_ENABLE ('11.2.0.3')

  DB_VERSION ('11.2.0.3')

  ALL_ROWS

  OUTLINE_LEAF(@"SEL$2")

  OUTLINE_LEAF(@"SEL$3")

  OUTLINE_LEAF(@"SEL$4")

  OUTLINE_LEAF(@"BLOCK1")

  OUTLINE_LEAF(@"SEL$1")

  OUTLINE(@"BLOCK1")

  FULL (@"SALT$ 1" "A2"@"SEL$1")

  INDEX (@"SALT$ 1" "A3"@"SEL$1" ("WERTPAPIERE".) "ID")) "

  INDEX (@"SALT$ 1" "A1"@"SEL$1" ("WP_STATUS".) "CODE" "WP_STATUS" "." " ID'))

  LEADING (@"SALT$ 1" "A2"@"SEL$1" "A3"@"SEL$1" "A1"@"SEL$1")

  USE_NL (@"SALT$ 1" "A3"@"SEL$1")

  NLJ_BATCHING (@"SALT$ 1" "A3"@"SEL$1")

  USE_HASH (@"SALT$ 1" "A1"@"SEL$1")

  SWAP_JOIN_INPUTS (@"SALT$ 1" "A1"@"SEL$1")

  USE_HASH_AGGREGATION(@"SEL$1")

  INDEX_RS_ASC (@"BLOCK1" "A4"@"BLOCK1" ("PRODUKTGRUPPE_SEGMENT".) "ID")) "

  INDEX (@"SALT$ 4" "A5"@"SEL$4" ("WERTPAPIER_LOESCH_KZ".) "CODE" "WERTPAPIER_LOESCH_KZ" "." " ID'))

  INDEX_RS_ASC (@"SALT$ 3" "A6"@"SEL$3" ("BESTANDS_MERKM".) "ID")) "

  INDEX_RS_ASC (@"SALT$ 2" "A7"@"SEL$2" ("BESTANDS_MERKM".) "ID")) "

  END_OUTLINE_DATA

  */

  According to independent-combine- JOIN operation by HASH, I assumed the first operation's Id 4 because the "INDEX FULL SCAN' on 'WP_STAT_UPI' is the first child.

  So I guess the order of operations by Id is 4,9,10 and so on.

  I got my information from the official oracle documentation, the book of Troubleshooting Oracle Performance (APRESS) and some research on the internet.

  Unfortunately so far I have found a good documentation on the scheduling. Most of the tutorials and documentation talk a lot operations themselves, but very little about the opening sequence.

  According to the section ATTACK to State "LEADING(@"SEL$1""A2"@"SEL$1""A3"@"SEL$1""A1"@"SEL$1")", for the classification should be Id: 9,10 and so on.

  
  

  I also tried to find order information in the v$ sql_plan. The database version is 11.2.
  

  
  

  Any help welcome.

  
  

  Best regards
  

  Your interpretation is correct (even if you have obscured the lines 5-8, but they do not add significant value to what you're saying).

  The explanation of the difference between your interpretation and the indicator leading() is the indicator USE_HASH() is accompanied by a hint of swap_join_inputs(). Hash joins | Oracle scratchpad indicator tells you the order of join optimizer was examining, but the optimizer exchange the roles of man and hash tables when it comes to her 'now to join A1 (WP_STAT)' part of the analysis - and this is reflected in the implementation plan.

  Symbolically, the main indicator says

  You should join A2 and A3--> (A2, A3)

  Then you must join A1--> ((A2, A3), A1)

  But Exchange - join entries. (A1, (A2, A3))

  Concerning

  Jonathan Lewis