By: Jonathan Lewis

Jonathan Lewis — Mon, 08 Nov 2010 18:26:53 +0000

Abhinav,

Consider this analogy:

It takes 67 minutes to drive from Heathrow to Gatwick when travelling at the legal limit during off-peak hours. During peak periods in bad weather it can take more than two hours; at 3 a.m. on a clear night and driving dangerously all the way it takes 42 minutes.

How long does it take to drive from Heathrow to Gatwick – you are only allowed to give me one answer in minutes ?

Oracle has a model – it is rarely a perfect match for the real world.

By: abhinav

abhinav — Thu, 04 Nov 2010 21:16:23 +0000

the below query took 34 min, but why the execution plan is showing different timings, stats are upto date on the tables:::: [sourcecode] PLAN_TABLE_OUTPUT Plan hash value: 1046889487 ---------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ---------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2758K| 607K (1)| 02:01:30 | | | | | 1 | PX COORDINATOR | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10002 | 2758K| 607K (1)| 02:01:30 | Q1,02 | P->S | QC (RAND) | |* 3 | HASH JOIN | | 2758K| 607K (1)| 02:01:30 | Q1,02 | PCWP | | | 4 | PX RECEIVE | | 2758K| 44053 (2)| 00:08:49 | Q1,02 | PCWP | | | 5 | PX SEND HASH | :TQ10001 | 2758K| 44053 (2)| 00:08:49 | Q1,01 | P->P | HASH | | 6 | PX BLOCK ITERATOR | | 2758K| 44053 (2)| 00:08:49 | Q1,01 | PCWC | | |* 7 | TABLE ACCESS FULL | OI_PAYMENT | 2758K| 44053 (2)| 00:08:49 | Q1,01 | PCWP | | | 8 | BUFFER SORT | | | | | Q1,02 | PCWC | | | 9 | PX RECEIVE | | 31M| 563K (1)| 01:52:41 | Q1,02 | PCWP | | | 10 | PX SEND HASH | :TQ10000 | 31M| 563K (1)| 01:52:41 | | S->P | HASH | |* 11 | VIEW | index$_join$_003 | 31M| 563K (1)| 01:52:41 | | | | |* 12 | HASH JOIN | | | | | | | | | 13 | INLIST ITERATOR | | | | | | | | |* 14 | INDEX RANGE SCAN | TC_OICASE1 | 31M| 505M (87)|999:59:59 | | | | | 15 | INDEX FAST FULL SCAN| PK_OI_CASE | 31M| 369K (1)| 01:13:59 | | | | ---------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - access("OI_PAYMENT"."ACCOUNTNUMBER"="OI_CASE"."ACCOUNTNUMBER") 7 - filter("OI_PAYMENT"."DATEOFRECORD">=TO_DATE(' 2010-10-26 05:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "OI_PAYMENT"."DATEOFRECORD"

By: Kyle Hailey

Kyle Hailey — Sun, 30 May 2010 12:42:03 +0000

For a minute or two this confused me >>The estimated values are estimates for each execution of a rowsource, the actual values are the cumulative counts. Then I realized you meant "cumulative" across the loops of that line. When I think cumulative, I think the columns cr_buffer_gets cu_buffer_gets disk_reads disk_writes elapsed_time which are cumulative across the children, ie the parent rows include the sum of the children, which makes it hard to scan for say which line we spent the most time on. Ex: [sourcecode] ----------------------------------------------------------- |Operation |Starts|E-Rows|A-Rows| A-Time | ----------------------------------------------------------- |HASH GROUP BY | 1 | 1 | 1 |0:04.13 | | FILTER | 1 | | 1909 |0:04.12 | | HASH JOIN | 1 | 406 | 3413 |0:03.95 | | TABLE ACCESS FULL | 1 | 15 | 15 |0:00.01 | | HASH JOIN | 1 | 812 | 3413 |0:03.90 | | TABLE ACCESS BY INDEX R| 1 | 5 | 1 |0:00.01 | | INDEX RANGE SCAN | 1 | 5 | 1 |0:00.01 | | HASH JOIN | 1 |28213 | 111K|0:03.12 | | HASH JOIN | 1 |27456 | 115K|0:01.58 | | TABLE ACCESS FULL | 1 |13679 |13679 |0:00.03 | | TABLE ACCESS FULL | 1 |27456 | 122K|0:00.37 | | TABLE ACCESS FULL | 1 |40000 |40000 |0:00.12 | | SORT AGGREGATE | 1831 | 1 | 1831 |0:00.07 | | FIRST ROW | 1831 | 1 | 1617 |0:00.04 | | INDEX RANGE SCAN (MIN/M| 1831 | 1 | 1617 |0:00.02 | | SORT AGGREGATE | 1593 | 1 | 1593 |0:00.06 | | FIRST ROW | 1593 | 1 | 1593 |0:00.04 | | INDEX RANGE SCAN (MI| 1593 | 1 | 1593 |0:00.02 | [/sourcecode] Which it makes it easy to see that the "A-time" includes the sum of the time for the children, ie the cumulative time of the children. Put a script up to show Wolfgang's TCF ratios and Christian Antognini's LIO per row as well as the per row elapsed time: http://sites.google.com/site/embtdbo/tuner/oracle-tcf-query-and-lios-per-row

By: Jonathan Lewis

Jonathan Lewis — Fri, 26 Mar 2010 21:50:04 +0000

Starts * E-rows can only match A-rows where the optimizer has predicted the cardinality correctly.

The first place (in order of execution) where the values are significantly different from each other is the first place where something is likely to be going wrong.

In your case the first execution step is the index skip scan of S_ORG_EXT_M61 at line 27 where Oracle predicts one row and find 509,000.

Notice that the 509,000 rows drops to 120 thanks to the access into S_ORG_BU at line 34. This suggests that it may be possible to find a different join order that avoids collecting 509,000 rows.

Note, as a general rule, OUTER JOINs will never eliminate data from the accumulated data set, so it’s nice to postpone the nested loop outer joins until AFTER the “inner” joins that have managed to eliminate lots of data.

By: Frank

Frank — Thu, 25 Mar 2010 22:29:54 +0000

Continuation from previous post …

From line #4 to #39, could you shed some light why Starts * E-Rows is not equal to A-Rows? Is it a potential stats related issue?

Appreciate it!

By: Frank

Frank — Thu, 25 Mar 2010 22:19:50 +0000

Jonathan, your blog is so vital to help me get the insight of Oracle. Sorry for the long output. Did you anything wrong this explain plan? and why? [sourcecode] ---------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | ---------------------------------------------------------------------------------------------------------------------------------------------- | 1 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:48.23 | 3122K| 128K| | 2 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:48.23 | 3121K| 128K| | 3 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:48.23 | 3121K| 128K| | 4 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:48.23 | 3121K| 128K| | 5 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:48.22 | 3121K| 128K| | 6 | NESTED LOOPS | | 1 | 1 | 65 |00:02:47.80 | 3121K| 128K| | 7 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:47.80 | 3120K| 128K| | 8 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:47.80 | 3120K| 128K| | 9 | NESTED LOOPS | | 1 | 1 | 65 |00:02:47.80 | 3120K| 128K| | 10 | NESTED LOOPS | | 1 | 1 | 65 |00:02:47.13 | 3120K| 128K| | 11 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:47.13 | 3120K| 128K| | 12 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:47.12 | 3120K| 128K| | 13 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:47.12 | 3120K| 128K| | 14 | NESTED LOOPS | | 1 | 1 | 65 |00:02:47.12 | 3120K| 128K| | 15 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:46.67 | 3119K| 128K| | 16 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:46.67 | 3119K| 128K| | 17 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:46.67 | 3119K| 128K| | 18 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:46.66 | 3119K| 128K| | 19 | NESTED LOOPS OUTER | | 1 | 1 | 65 |00:02:46.09 | 3119K| 128K| | 20 | NESTED LOOPS | | 1 | 1 | 65 |00:02:46.08 | 3118K| 128K| | 21 | NESTED LOOPS | | 1 | 1 | 65 |00:02:45.90 | 3118K| 127K| | 22 | NESTED LOOPS | | 1 | 1 | 120 |00:02:45.89 | 3118K| 127K| | 23 | NESTED LOOPS OUTER | | 1 | 1 | 509K|00:02:07.89 | 1439K| 105K| | 24 | NESTED LOOPS OUTER | | 1 | 1 | 509K|00:02:05.85 | 1439K| 105K| | 25 | NESTED LOOPS OUTER | | 1 | 1 | 509K|00:02:04.32 | 1439K| 105K| | 26 | TABLE ACCESS BY INDEX ROWID| S_ORG_EXT | 1 | 1 | 509K|00:02:02.29 | 1439K| 105K| |* 27 | INDEX SKIP SCAN | S_ORG_EXT_M61 | 1 | 1 | 509K|00:00:03.74 | 229K| 5040 | | 28 | TABLE ACCESS BY INDEX ROWID| S_PRI_LST | 509K| 1 | 0 |00:00:01.13 | 0 | 0 | |* 29 | INDEX UNIQUE SCAN | S_PRI_LST_P1 | 509K| 1 | 0 |00:00:00.48 | 0 | 0 | | 30 | TABLE ACCESS BY INDEX ROWID | S_PRI_LST | 509K| 1 | 0 |00:00:00.94 | 0 | 0 | |* 31 | INDEX UNIQUE SCAN | S_PRI_LST_P1 | 509K| 1 | 0 |00:00:00.39 | 0 | 0 | | 32 | TABLE ACCESS BY INDEX ROWID | S_INDUST | 509K| 1 | 0 |00:00:01.60 | 7 | 1 | |* 33 | INDEX UNIQUE SCAN | S_INDUST_P1 | 509K| 1 | 0 |00:00:01.06 | 7 | 1 | |* 34 | TABLE ACCESS BY INDEX ROWID | S_ORG_BU | 509K| 1 | 120 |00:00:37.45 | 1678K| 22662 | |* 35 | INDEX RANGE SCAN | S_ORG_BU_U1 | 509K| 1 | 508K|00:00:09.04 | 1170K| 2392 | |* 36 | INDEX RANGE SCAN | S_PARTY_RPT_REL_U1 | 120 | 1 | 65 |00:00:00.01 | 134 | 4 | | 37 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 65 | 1 | 65 |00:00:00.18 | 202 | 55 | |* 38 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 65 | 1 | 65 |00:00:00.18 | 137 | 55 | | 39 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 65 | 1 | 65 |00:00:00.01 | 202 | 0 | |* 40 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 65 | 1 | 65 |00:00:00.01 | 137 | 0 | | 41 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 65 | 1 | 65 |00:00:00.58 | 208 | 111 | |* 42 | INDEX RANGE SCAN | S_CON_ADDR_M1 | 65 | 1 | 65 |00:00:00.25 | 143 | 53 | | 43 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 65 | 1 | 65 |00:00:00.01 | 208 | 0 | |* 44 | INDEX RANGE SCAN | S_CON_ADDR_M1 | 65 | 1 | 65 |00:00:00.01 | 143 | 0 | | 45 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 65 | 1 | 65 |00:00:00.01 | 208 | 0 | |* 46 | INDEX RANGE SCAN | S_CON_ADDR_M1 | 65 | 1 | 65 |00:00:00.01 | 143 | 0 | | 47 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 65 | 1 | 65 |00:00:00.01 | 208 | 0 | |* 48 | INDEX RANGE SCAN | S_CON_ADDR_M1 | 65 | 1 | 65 |00:00:00.01 | 143 | 0 | | 49 | TABLE ACCESS BY INDEX ROWID | S_PARTY | 65 | 1 | 65 |00:00:00.45 | 202 | 101 | |* 50 | INDEX UNIQUE SCAN | S_PARTY_P1 | 65 | 1 | 65 |00:00:00.12 | 137 | 45 | | 51 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 65 | 1 | 0 |00:00:00.01 | 6 | 0 | |* 52 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 65 | 1 | 0 |00:00:00.01 | 6 | 0 | | 53 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_SS | 65 | 1 | 0 |00:00:00.01 | 6 | 0 | |* 54 | INDEX RANGE SCAN | S_ORG_EXT_SS_U1 | 65 | 1 | 0 |00:00:00.01 | 6 | 0 | | 55 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_LSX | 65 | 1 | 0 |00:00:00.01 | 71 | 0 | |* 56 | INDEX RANGE SCAN | S_ORG_EXT_LSX_U1 | 65 | 1 | 0 |00:00:00.01 | 71 | 0 | | 57 | TABLE ACCESS BY INDEX ROWID | S_PARTY | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 58 | INDEX UNIQUE SCAN | S_PARTY_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | | 59 | TABLE ACCESS BY INDEX ROWID | S_ACCNT_POSTN | 65 | 9 | 65 |00:00:00.67 | 207 | 133 | |* 60 | INDEX RANGE SCAN | S_ACCNT_POSTN_U1 | 65 | 1 | 65 |00:00:00.35 | 142 | 74 | | 61 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | |* 62 | INDEX UNIQUE SCAN | S_POSTN_U2 | 65 | 1 | 65 |00:00:00.01 | 71 | 0 | | 63 | TABLE ACCESS BY INDEX ROWID | S_USER | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 64 | INDEX UNIQUE SCAN | S_USER_U2 | 65 | 1 | 65 |00:00:00.01 | 71 | 0 | |* 65 | INDEX UNIQUE SCAN | S_PARTY_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | | 66 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 65 | 1 | 65 |00:00:00.42 | 201 | 105 | |* 67 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 65 | 1 | 65 |00:00:00.13 | 136 | 46 | | 68 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 69 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | | 70 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 71 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | | 72 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 73 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | | 74 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 65 | 1 | 65 |00:00:00.01 | 201 | 0 | |* 75 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 65 | 1 | 65 |00:00:00.01 | 136 | 0 | ---------------------------------------------------------------------------------------------------------------------------------------------- [/sourcecode]

By: Jonathan Lewis

Jonathan Lewis — Wed, 16 Dec 2009 13:52:19 +0000

Orlando, If you want to see where the work is done you have to run the query, "explain plan" won't give you execution statistics. 11g has a new "Real-time SQL monitoring" feature that accumulates execution statistics every few seconds so that you don't necessarily have to run the query to completion to get a good idea of where the work is going - unfortunately that doesn't help you.

By: Orlando Reyes

Orlando Reyes — Tue, 15 Dec 2009 21:59:07 +0000

Jonathan, this is very handy, but it looks like we do need to totally execute the query to get the stats we need, so, what about using the “explain plan for select ….” method and generate the same info for those queries that would take too long to wait for execution ? I have a query that would take over 5 hours to run, so I don’t want to run it, I just want to see the explain plan and try to tune it form there, is there any way to use the “dbms_xplan.display_cursor(null, null, ‘ALLSTATS LAST’)” in this case? When I tried I get an error saying “cannot fetch plan for SQL_ID: 9b0mhpss56xhw, CHILD_NUMBER: 3
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_plan)”

By: Dependent Plans « Oracle Scratchpad

Dependent Plans « Oracle Scratchpad — Tue, 05 May 2009 18:11:18 +0000

[...] Lewis @ 6:09 pm UTC May 5,2009 I’ve written several posts about dbms_xplan, and the display_cursor function in 10g. One of the nice feature of this function is that it is a “pipelined” [...]

By: Histogram change « Oracle Scratchpad

Histogram change « Oracle Scratchpad — Thu, 23 Apr 2009 21:25:11 +0000

[...] then the optimizer would calcualte a cardinality of one for this predicate (having recorded a density of 1/(2 * num_rows) in the data dictionary (see comments 21 and 22 of this note on dbms_xplan). [...]

Comments on: dbms_xplan in 10g

By: Jonathan Lewis

By: abhinav

By: Kyle Hailey

By: Jonathan Lewis

By: Frank

By: Frank

By: Jonathan Lewis

By: Orlando Reyes

By: Dependent Plans « Oracle Scratchpad

By: Histogram change « Oracle Scratchpad