Explain Plan shows Nested Loops, Is it good or bad?

Hi All,
I have a doubt in the explain plan, I would like to know if the Nested Loops , will it degrade the query performance?
Note: I have pasted only few output that I had taken from the expalin plan.
Do let me know if there is any article I could read to get clear understanding about the same.
17 NESTED LOOPS ANTI Cost: 125 Bytes: 186 Cardinality: 1
15 NESTED LOOPS ANTI Cost: 124 Bytes: 166 Cardinality: 1
12 NESTED LOOPS Cost: 122 Bytes: 140 Cardinality: 1
     9 NESTED LOOPS Cost: 121 Bytes: 117 Cardinality: 1
Thanks

Hi,
there is absolutely nothing wrong about nested loops (NL). It's a very efficient way of combining data from two rowsources. It works pretty much like a regular loop: it takes all rows from one rowsource (the "outer" one) and for each of them it looks up a row matching the join condition in the other rowsource (the "inner" one).
Note that there are not so many alternatives in Oracle: there are only 3 ways to join data in Oracle, and one of them is used in rather special circumstances (merge join). So normally the choice is between a NL and a hash join. Hash join (HJ) takes the smaller dataset and builds an in-memory lookup table using a hash function on join column(s). Then it goes through the other dataset and as it goes, it applies the hashing function to join column(s) and picks the matching rows from the smaller dataset.
Actually, hash joins and nested loops are not all that different. The basic mechanism is same: you go through one datasource and as you go, you pick matching rows from the other and do the join. The main difference is that a HJ requires some preparation work (it costs resources to build the in-memory table) and thus HJ are typically associated with less-selective queries and full table scans.
In your particular case it's nor possible to tell whether or not NL is in order based on just a few rows from the explain plan. We need to know the structure of your tables (the DDL), what kind of data they hold (optimizer stats) and what query you are running to be able to tell.
Best regards,
Nikolay

Similar Messages

Explain plan shows 300T of TempSpc and 999 hours - tuning request

Hi,
I have a query which obtains summary statistics. There is an items table which contains the dictionary of items which can be recorded. There is an events table which contains the item ID, timestamp and a value. The query summarizes the data for each item. e.g. Mean, stddev, sample values, length. I have trimmed the query down as simply as possible and am having a problem with large temp space and runtime estimates in the explain plan. Here is the query:
WITH ChartItems AS (
    SELECT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      COUNT(*),
      COUNT(distinct subject_id)
    FROM mimic2v26.d_chartitems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
    --WHERE ci.itemid = 51
    GROUP BY ci.itemid,
             ci.label,
             ci.category,
             ci.description
--select * from ChartItems;
, RawData AS (
    SELECT DISTINCT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
      ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
      value1_last
    FROM ChartItems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData;Which gives this explain plan:
Plan hash value: 642453121
| Id | Operation                    | Name           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                | 4811G| 1238T|       | 3686M (13)|999:59:59 |
|   1 | VIEW                        |                | 4811G| 1238T|       | 3686M (13)|999:59:59 |
|   2 |   HASH UNIQUE                |                | 4811G|   258T|       | 3686M (13)|999:59:59 |
|   3 |    WINDOW BUFFER             |                | 4811G|   258T|       | 3686M (13)|999:59:59 |
|   4 |     SORT GROUP BY            |                | 4811G|   258T|   317T| 3686M (13)|999:59:59 |
|* 5 |      HASH JOIN               |                | 4811G|   258T| 4943M|    25M (90)| 85:14:28 |
|   6 |       VIEW                   | VW_DAG_0       |   152M| 3199M|       | 1366K (1)| 04:33:18 |
|   7 |        HASH GROUP BY         |                |   152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 8 |         HASH JOIN            |                |   152M| 4216M|       |   147K (2)| 00:29:36 |
|   9 |          TABLE ACCESS FULL   | D_CHARTITEMS   | 4832 | 96640 |       |     7   (0)| 00:00:01 |
| 10 |          INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M| 1683M|       |   147K (1)| 00:29:25 |
| 11 |       TABLE ACCESS FULL      | CHARTEVENTS    |   196M| 6922M|       |   616K (1)| 02:03:19 |
Predicate Information (identified by operation id):
   5 - access("CE"."ITEMID"="ITEM_2")300T of temp space! Ouch.
TKPROF output (I let the query run for a short while. I let it run for ages earlier, but wasn't tracing the session. Should I let it run for longer?):
TKPROF: Release 11.2.0.3.0 - Development on Tue Jul 10 16:54:27 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
WITH ChartItems AS (
    SELECT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      COUNT(*),
      COUNT(distinct subject_id)
    FROM mimic2v26.d_chartitems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
    GROUP BY ci.itemid,
             ci.label,
             ci.category,
             ci.description
, RawData AS (
    SELECT DISTINCT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
      ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
      value1_last
    FROM ChartItems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.02       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1    582.40     712.23     705238     737351          0           0
total        3    582.43     712.25     705238     737351          0           0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         0          0          0 VIEW (cr=0 pr=0 pw=0 time=184 us cost=3686387254 size=1361581801333882 card=4811243114254)
         0          0          0   HASH UNIQUE (cr=0 pr=0 pw=0 time=180 us cost=3686387254 size=283863343740986 card=4811243114254)
         0          0          0    WINDOW BUFFER (cr=0 pr=0 pw=0 time=74 us cost=3686387254 size=283863343740986 card=4811243114254)
         0          0          0     SORT GROUP BY (cr=0 pr=0 pw=0 time=59 us cost=3686387254 size=283863343740986 card=4811243114254)
178073889 178073889 178073889      HASH JOIN (cr=737351 pr=705238 pw=124635 time=476372451 us cost=25572251 size=283863343740986 card=4811243114254)
   6211631    6211631    6211631       VIEW VW_DAG_0 (cr=613768 pr=581413 pw=35805 time=286546567 us cost=1366486 size=3354399576 card=152472708)
   6211631    6211631    6211631        HASH GROUP BY (cr=613768 pr=581413 pw=35805 time=281271878 us cost=1366486 size=4421708532 card=152472708)
196182740 196182740 196182740         HASH JOIN (cr=613768 pr=545608 pw=0 time=557485047 us cost=147987 size=4421708532 card=152472708)
      4832       4832       4832          TABLE ACCESS FULL D_CHARTITEMS (cr=18 pr=16 pw=0 time=13666 us cost=7 size=96640 card=4832)
196182740 196182740 196182740          INDEX FAST FULL SCAN CHARTEVENTS_O2 (cr=613750 pr=545592 pw=0 time=148428499 us cost=147046 size=1765644660 card=196182740)(object id 96501)
10683044   10683044   10683044       TABLE ACCESS FULL CHARTEVENTS (cr=123583 pr=123825 pw=0 time=25175510 us cost=616507 size=7258761380 card=196182740)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
db file sequential read                         2        0.01          0.01
db file scattered read                          3        0.02          0.03
direct path read                             5265        0.75         77.13
asynch descriptor resize                        1        0.00          0.00
direct path write temp                      15077        0.71         45.54
direct path read temp                        2387        0.29         13.54
SQL*Net break/reset to client                   1        0.66          0.66
SQL*Net message from client                     1        0.00          0.00
SQL ID: 7jby2dxrpkkm9 Plan Hash: 1388734953
select SYS_CONTEXT('USERENV','SESSIONID')
from
dual
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          0          0           1
total        3      0.00       0.01          0          0          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         1          1          1 FAST DUAL (cr=0 pr=0 pw=0 time=4 us cost=2 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.02       0.04          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        2    582.40     712.23     705238     737351          0           1
total        6    582.43     712.27     705238     737351          0           1
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       4        0.00          0.00
db file sequential read                         2        0.01          0.01
db file scattered read                          3        0.02          0.03
direct path read                             5265        0.75         77.13
asynch descriptor resize                        1        0.00          0.00
direct path write temp                      15077        0.71         45.54
direct path read temp                        2387        0.29         13.54
SQL*Net break/reset to client                   1        0.66          0.66
SQL*Net message from client                     3       14.99         15.01
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
    2 user SQL statements in session.
    0 internal SQL statements in session.
    2 SQL statements in session.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Trace file compatibility: 11.1.0.7
Sort options: default
       1 session in tracefile.
       2 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       2 SQL statements in trace file.
       2 unique SQL statements in trace file.
   24245 lines in trace file.
     728 elapsed seconds in trace file.Optimizer parameters:
NAME                                               TYPE        VALUE
optimizer_capture_sql_plan_baselines               boolean     FALSE
optimizer_dynamic_sampling                         integer     2
optimizer_features_enable                          string      11.2.0.3
optimizer_index_caching                            integer     0
optimizer_index_cost_adj                           integer     100
optimizer_mode                                     string      ALL_ROWS
optimizer_secure_view_merging                      boolean     TRUE
optimizer_use_invisible_indexes                    boolean     FALSE
optimizer_use_pending_statistics                   boolean     FALSE
optimizer_use_sql_plan_baselines                   boolean     TRUE                                                                                                 Can anyone help me figure out what's wrong?
This is a data warehouse, with up to date statistics. The DB is version 11.2.0.3.0
Thanks,
Dan

rp0428 wrote:
>
I trimmed the query down to the simplest that I could which still exhibited the problem
>
The DISTINCT isn't the issue. The issue is that the query you posted isn't necessary and doesn't appear to be represented in the plan that you posted.
That makes it hard to tell where the cardinality misestimates are coming from. How many records does the actual first query (the one with the group by) return? You have a SELECT * commented out - how many rows?No, it's not necessary, but then it isn't the full query. The estimates are still wrong when I pass the count columns through to the second query. The full query contains many more analytic functions in the second query, and some additions to the first. It could probably be cleaned up a little, but the current structure makes logical sense. Should I change the aggregates to analytics and move them into the second query? In any case, there definitely seems to be something wrong with the plan.
I don't know what you mean when you say "doesn't appear to be represented in the plan that you posted".
I just checked the first query and while the temp space has dropped to a reasonable amount, the number of rows in the hash join is still way off (I didn't notice before because I was looking at the temp space). The rows for d_chartitems and the index on chartevents are correct:
Plan hash value: 1249235674
| Id | Operation               | Name           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT        |                |   152M|    35G|       | 1366K (1)| 04:33:18 |
|   1 | VIEW                   |                |   152M|    35G|       | 1366K (1)| 04:33:18 |
|   2 |   WINDOW SORT           |                |   152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 3 |    HASH JOIN            |                |   152M| 4216M|       |   147K (2)| 00:29:36 |
|   4 |     TABLE ACCESS FULL   | D_CHARTITEMS   | 4832 | 96640 |       |     7   (0)| 00:00:01 |
|   5 |     INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M| 1683M|       |   147K (1)| 00:29:25 |
Predicate Information (identified by operation id):
   3 - access("CE"."ITEMID"="CI"."ITEMID")Edited by: danscott on Jul 10, 2012 5:43 PM
Edited by: danscott on Jul 11, 2012 6:28 AM

Query select 1 row Explain plan shows different no of rows

SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> set autot on
SQL> select session_id from dba_fga_audit_trail;
SESSION_ID
     24001
1 row selected.
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1613626607
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          | 41678 |   203K|   507   (1)| 00:00:07 |
|   1 | TABLE ACCESS FULL| FGA_LOG$ | 41678 |   203K|   507   (1)| 00:00:07 |
------------------------------------------------------------------------------In the above query it is selecting only one row
but in E Plan it is showing 41678 rows selected.
Am i wrong somewhere ?
Regards
Singh

The number of rows processed to get your one record

Several nested loop at the same level in an execution plan

Hi, I am using 11gR2, and I've seen a execution plan in the trace of my SQL query (also shown in pl/sql explain plan) with 4 nested loops all at the same level, what does this mean?
i.e.
- SELECT STATEMENT, GOAL = FIRST_ROWS
+ NESTED LOOPS
+ NESTED LOOPS
+ NESTED LOOPS
+ NESTED LOOPS
each NESTED LOOP can be expanded to 2 further actions, which make sense to me. e.g.
+ NESTED LOOPS
+ TABLE ACCESS BY INDEX ROWID
+ TABLE ACCESS BY INDEX ROWID
THANKS
Ye

>
why there are 4 Nested Loops
what is the final result set for the SELECT statement come from (any one of the 4)
the query run so slow in 11R2
>
So far you are the only one who knows what the query and execution plan are because you haven't posted them
>
Then you need to post the query, tell us what indexes are on the join columns and post the complete plan.
>
We can't even begin to explain why Oracle might have chosen the plan it did if we can't see the query and plan you want explained.
And if we only see the plan we might be able to tell you what Oracle is doing but without knowing what indexes might be on the join columns and the filter criteria columns we can't tell you why Oracle chose the plan it chose.
And the excerpt of the plan you did provide is incomplete. You removed the indenting possibly because you did not enclose it in 'code' tags (see the FAQ).
>
- SELECT STATEMENT, GOAL = FIRST_ROWS
+ NESTED LOOPS
+ NESTED LOOPS
+ NESTED LOOPS
+ NESTED LOOPS
>
There can't be four nested loops like that at the top level since the top level will be combining the result sets from it's children. A nested loop will have two children; like the last part you showed:
>
+ NESTED LOOPS
+ TABLE ACCESS BY INDEX ROWID
+ TABLE ACCESS BY INDEX ROWID
>
The two 'TABLE ACCESS ...' will be indented on a normal plan.
Without the query and plan there isn't much we can tell you.

Oracle 11g - Nested loops on outer joins

Hello,
I have a select query that was working with no problems. The results are used to insert data into a temp table.
Recently, it would not complete executing. The explain plan shows a cartesian. But, there could be problems with using nested loops on the outer join. Interestingly, when I copy production code and rename the temp table and rename the view, it works.
Can someone take a look at the code and help. Maybe offer a suggestion on tuning too? Thanks.
CREATE TABLE "CT"
( "TN" VARCHAR2(30) NOT NULL ENABLE,
"COL_NAME" VARCHAR2(30) NOT NULL ENABLE,
"CDE" VARCHAR2(5) NOT NULL ENABLE,
"CDE_DESC" VARCHAR2(80) NOT NULL ENABLE,
"CDE_STAT" CHAR(1));
insert into CT (TN, COL_NAME, CDE, CDE_DESC, CDE_STAT)
values ('INDSD', 'STCD', 'U', 'RF', 'A');
insert into CT (TN, COL_NAME, CDE, CDE_DESC, CDE_STAT)
values ('AT', 'TCD', '001', 'RL', 'A');
insert into CT (TN, COL_NAME, CDE, CDE_DESC, CDE_STAT)
values ('AT', 'TCD', '033', 'PFR', 'A');
CREATE TABLE "IPP"
( "IND_ID" NUMBER(9,0) NOT NULL ENABLE,
"PLCD" VARCHAR2(5) NOT NULL ENABLE,
"CBCD" VARCHAR2(5));
insert into IPP (IND_ID, PLCD, CBCD)
values (2007, 'AS', '04');
insert into IPP (IND_ID, PLCD, CBCD)
values (797098, 'AS', '34');
insert into IPP (IND_ID, PLCD, CBCD)
values (797191, 'AS','04');
CREATE TABLE "INDS"
( "OPCD" VARCHAR2(5) NOT NULL ENABLE,
"IND_ID" NUMBER(9,0) NOT NULL ENABLE,
"IND_CID" NUMBER(*,0),
"GFLG" VARCHAR2(1),
"HHID" NUMBER(9,0),
"DOB" DATE,
"DOB_FLAG" VARCHAR2(1),
"VCD" VARCHAR2(5),
"VTDTE" DATE,
"VPPCD" VARCHAR2(4),
"VRCDTE" DATE NOT NULL ENABLE,
"VDSID" NUMBER(9,0),
"VTRANSID" NUMBER(12,0),
"VOWNCD" VARCHAR2(5),
"RCDTE" DATE,
"LRDTE" DATE
insert into INDS (OPCD, IND_ID, IND_CID, GFLG, HHID, DOB, DOB_FLAG, VCD, VTDTE, VPPCD, VRCDTE, VDSID, VTRANSID, VOWNCD, RCDTE, LRDTE)
values ('USST', 2007, 114522319, '', 304087673, to_date('01-01-1980', 'dd-mm-yyyy'), 'F', '2', to_date('06-04-2011 09:21:37', 'dd-mm-yyyy hh24:mi:ss'), '', to_date('06-04-2011 09:21:37', 'dd-mm-yyyy hh24:mi:ss'), 1500016, null, 'USST', to_date('06-04-2011 09:21:37', 'dd-mm-yyyy hh24:mi:ss'), to_date('18-07-2012 21:52:53', 'dd-mm-yyyy hh24:mi:ss'));
insert into INDS (OPCD, IND_ID, IND_CID, GFLG, HHID, DOB, DOB_FLAG, VCD, VTDTE, VPPCD, VRCDTE, VDSID, VTRANSID, VOWNCD, RCDTE, LRDTE)
values ('USST', 304087678, 115242519, '', 304087678, to_date('01-01-1984', 'dd-mm-yyyy'), 'F', '2', to_date('06-04-2011 09:21:39', 'dd-mm-yyyy hh24:mi:ss'), '', to_date('06-04-2011 09:21:39', 'dd-mm-yyyy hh24:mi:ss'), 1500016, null, 'USST', to_date('06-04-2011 09:21:39', 'dd-mm-yyyy hh24:mi:ss'), to_date('18-07-2012 21:52:53', 'dd-mm-yyyy hh24:mi:ss'));
CREATE TABLE "INDS_TYPE"
( "IND_ID" NUMBER(9,0) NOT NULL ENABLE,
"STCD" VARCHAR2(5) NOT NULL ENABLE);
insert into INDS_type (IND_ID, STCD)
values (2007, 'U');
insert into INDS_type (IND_ID, STCD)
values (313250322, 'U');
insert into INDS_type (IND_ID, STCD)
values (480058122, 'U');
CREATE TABLE "PLOP"
( "OPCD" VARCHAR2(5) NOT NULL ENABLE,
"PLCD" VARCHAR2(5) NOT NULL ENABLE,
"PPLF" VARCHAR2(1));
insert into PLOP (OPCD, PLCD, PPLF)
values ('USST', 'SP', 'Y');
insert into PLOP (OPCD, PLCD, PPLF)
values ('PMUSA', 'ST', '');
insert into PLOP (OPCD, PLCD, PPLF)
values ('USST', 'RC', '');
CREATE TABLE "IND_T"
( "OPCD" VARCHAR2(5) NOT NULL ENABLE,
"CID" NUMBER(9,0) NOT NULL ENABLE,
"CBCD" VARCHAR2(5),
"PF" VARCHAR2(1) NOT NULL ENABLE,
"DOB" DATE,
"VCD" VARCHAR2(5),
"VOCD" VARCHAR2(5),
"IND_CID" NUMBER,
"RCDTE" DATE NOT NULL ENABLE
insert into IND_T (OPCD, CID, CBCD,PF, DOB, VCD, VOCD, IND_CID, RCDTE)
values ('JMC', 2007, '04', 'F',to_date('11-10-1933', 'dd-mm-yyyy'), '2', 'PMUSA', 363004880, to_date('30-09-2009 04:31:34', 'dd-mm-yyyy hh24:mi:ss'));
insert into IND_T (OPCD, CID, CBCD,PF, DOB, VCD, VOCD, IND_CID, RCDTE)
values ('JMC', 2008, '04', 'N',to_date('01-01-1980', 'dd-mm-yyyy'), '2', 'PMUSA', 712606335, to_date('05-04-2013 19:36:05', 'dd-mm-yyyy hh24:mi:ss'));
CREATE TABLE "IC"
( "CID" NUMBER(9,0) NOT NULL ENABLE,
"CF" CHAR(1));
insert into IC (CID, CF)
values (2007, 'N');
insert into IC (CID, CF)
values (100, 'N');
insert into IC (CID, CF)
values (200, 'N');
CREATE OR REPLACE FORCE VIEW "INDSS_V" ("OPCD", "IND_ID", "IND_CID", "GFLG", "HHID", "DOB", "DOB_FLAG", "VCD", "VTDTE", "VPPCD", "VRCDTE", "VDSID", "VTRANSID", "VOWNCD", "RCDTE", "LRDTE") AS
SELECT DISTINCT a.OPCD, a.IND_ID, a.IND_CID, a.GFLG, a.HHID,
a.DOB, a.DOB_flag, a.VCD, a.VTDTE,
a.VPPCD, a.VRCDTE, a.VDSID, a.VTRANSID,
a.VOWNCD, a.RCDTE, a.LRDTE
FROM INDS a, INDS_type b
WHERE a.IND_ID = b.IND_ID
AND b.STCD in (select CDE
from CT --database link
where TN = 'INDSD'
and COL_NAME = 'STCD'
and CDE_STAT = 'A') ;
--insert /*+ parallel(IND_T,2) */ into IND_T
select /*+ parallel(a,4) */
a.OPCD as OPCD
, a.IND_ID as CID
, b.CBCD as CBCD
, NULL as BFCD
, 'N' as PF
, a.DOB as DOB
, a.VCD as VCD
, a.VOWNCD as VOCD
, a.IND_CID as IND_CID
, a.RCDTE as RCDTE
from INDSS_V a
, (select /*+ parallel(IPP,4) */ * from IPP IPP , PLOP PLO
where plo.PLCD = ipp.PLCD
and PPLF='Y') b
, IC c
where a.IND_ID = b.IND_ID (+)
and a.OPCD = b.OPCD (+)
and a.IND_ID = c.CID
and c.CF = 'N';

Please consult
HOW TO: Post a SQL statement tuning request - template posting
Also format your code and post it using the [ code ] and [ /code ] tags. (Leave out the extra space after [ and before ])
Sybrand Bakker
Senior Oracle DBA
Edited by: sybrand_b on 10-apr-2013 17:57

SQL Tuning - Explain plan analysis

Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..
UNIT ENVT
==========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation                         | Name                     | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT                  |                          | 4739K|   646M|       | 85917   (1)| 00:19:12 |
|   1 | LOAD TABLE CONVENTIONAL          | F_DRV_FUEL_W             |       |       |       |            |          |
|   2 |   HASH UNIQUE                     |                          | 4739K|   646M|   726M| 85917   (1)| 00:19:12 |
|* 3 |    HASH JOIN RIGHT OUTER          |                          | 4739K|   646M|       | 7881   (3)| 00:01:46 |
|   4 |     VIEW                          |                          | 20936 |   756K|       | 1456   (1)| 00:00:20 |
|* 5 |      HASH JOIN RIGHT OUTER        |                          | 10468 |   572K|       |   594K (5)| 02:12:51 |
|   6 |       TABLE ACCESS FULL           | X_SNI_TRK_STP_P          | 2754 | 33048 |       |     5   (0)| 00:00:01 |
|   7 |       NESTED LOOPS OUTER          |                          | 10468 |   449K|       |   594K (5)| 02:12:51 |
|   8 |        TABLE ACCESS FULL          | X_SNI_FUEL_CMPLY_DTL_P   | 10468 |   184K|       |    14   (0)| 00:00:01 |
|   9 |        VIEW                       |                          |     1 |    26 |       |    57   (6)| 00:00:01 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    59 |       |    57   (6)| 00:00:01 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    28 |       |    27   (0)| 00:00:01 |
|* 13 |           VIEW                    |                          | 17659 |   534K|       |    29   (7)| 00:00:01 |
|* 14 |            WINDOW SORT PUSHED RANK|                          | 17659 |   448K|       |    29   (7)| 00:00:01 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P | 17659 |   448K|       |    27   (0)| 00:00:01 |
|* 16 |     HASH JOIN RIGHT OUTER         |                          | 4739K|   479M|    14M| 6404   (3)| 00:01:26 |
|* 17 |      TABLE ACCESS FULL            | XO_E_PER_ASSIGNMENT_P    |   276K|    11M|       | 2616   (2)| 00:00:36 |
|* 18 |      HASH JOIN                    |                          |   699K|    42M|    20M| 2704   (3)| 00:00:37 |
|* 19 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_PRD_P |   702K|    12M|       |   536   (3)| 00:00:08 |
|* 20 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_P     |   695K|    30M|       | 1202   (3)| 00:00:17 |
Predicate Information (identified by operation id):
   3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
   5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
              INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
       filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
              "X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1
              AND "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
49 rows selected.
UAT ENVT
=========
PLAN_TABLE_OUTPUT
Plan hash value: 891903485
| Id | Operation                         | Name                     | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT                  |                          |   998K|   139M|       | 34826   (1)| 00:07:47 |
|   1 | LOAD TABLE CONVENTIONAL          | F_DRV_FUEL_W             |       |       |       |            |          |
|   2 |   HASH UNIQUE                     |                          |   998K|   139M|   157M| 34826   (1)| 00:07:47 |
|* 3 |    HASH JOIN RIGHT OUTER          |                          |   998K|   139M|    44M| 18001   (2)| 00:04:02 |
|   4 |     VIEW                          |                          |   931K|    33M|       | 4250   (1)| 00:00:57 |
|* 5 |      HASH JOIN RIGHT OUTER        |                          | 62082 | 3576K|       |    25M (2)| 96:08:31 |
|   6 |       TABLE ACCESS FULL           | X_SNI_TRK_STP_P          | 5603 | 61633 |       |    10   (0)| 00:00:01 |
|   7 |       NESTED LOOPS OUTER          |                          | 30548 | 1431K|       |    25M (2)| 96:08:31 |
|   8 |        TABLE ACCESS FULL          | X_SNI_FUEL_CMPLY_DTL_P   | 30548 |   715K|       |    46   (3)| 00:00:01 |
|   9 |        VIEW                       |                          |     1 |    24 |       |   845   (2)| 00:00:12 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    57 |       |   845   (2)| 00:00:12 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    29 |       |   150   (2)| 00:00:03 |
|* 13 |           VIEW                    |                          |   151K| 4155K|       |   694   (2)| 00:00:10 |
|* 14 |            WINDOW SORT PUSHED RANK|                          |   151K| 3413K| 5376K|   694   (2)| 00:00:10 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P |   151K| 3413K|       |   150   (2)| 00:00:03 |
|* 16 |     HASH JOIN RIGHT OUTER         |                          |   998K|   103M|    15M| 11138   (2)| 00:02:30 |
|* 17 |      TABLE ACCESS FULL            | XO_E_PER_ASSIGNMENT_P    |   296K|    11M|       | 5060   (2)| 00:01:08 |
|* 18 |      HASH JOIN                    |                          | 1028K|    65M|    31M| 4555   (3)| 00:01:02 |
|* 19 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_PRD_P | 1037K|    19M|       | 1000   (2)| 00:00:14 |
|* 20 |       TABLE ACCESS FULL           | X_SNI_FUEL_PUR_TXN_P     | 1020K|    45M|       | 2088   (3)| 00:00:28 |
Predicate Information (identified by operation id):
   3 - access("X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_CMPLY_DTL_P"."FUEL_PUR_TXN_ID"(+))
   5 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PRVD_TRK_STP_CD"="X_SNI_TRK_STP_P"."CMDTA_CD"(+))
10 - filter("X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" IS NOT NULL)
11 - access("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_STP_DTL_ID"="PLN_STP_DTL_ID" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="PWR_NUM" AND "X_SNI_FUEL_PLN_STP_DTL_P"."PLN_GAL_QTY"="PLN_GAL_QTY")
12 - filter("X_SNI_FUEL_PLN_STP_DTL_P"."PLN_DTTM"="X_SNI_FUEL_CMPLY_DTL_P"."PLN_DT" AND
              "X_SNI_FUEL_PLN_STP_DTL_P"."PWR_NUM"="X_SNI_FUEL_CMPLY_DTL_P"."PWR_NUM")
13 - filter("R1"=1)
14 - filter(ROW_NUMBER() OVER ( PARTITION BY "PWR_NUM","PLN_DTTM" ORDER BY
              INTERNAL_FUNCTION("PLN_STP_DTL_ID") DESC )<=1)
16 - access("X_SNI_FUEL_PUR_TXN_P"."DRV_NUM"="XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+))
       filter("X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM"<="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_END_DT"(+) AND
              "X_SNI_FUEL_PUR_TXN_P"."TXN_DTTM">="XO_E_PER_ASSIGNMENT_P"."ASN_EFF_STRT_DT"(+))
17 - filter("XO_E_PER_ASSIGNMENT_P"."DRV_NUM"(+) IS NOT NULL AND
              "XO_E_PER_ASSIGNMENT_P"."ACTV_EMP_IND"(+)=1 AND "XO_E_PER_ASSIGNMENT_P"."PS_CURR_IND"(+)=1 AND
              "XO_E_PER_ASSIGNMENT_P"."PRSN_TYP_RNK_NUM"(+)=1)
18 - access("X_SNI_FUEL_PUR_TXN_PRD_P"."FUEL_PUR_TXN_ID"="X_SNI_FUEL_PUR_TXN_P"."FUEL_PUR_TXN_ID")
19 - filter("X_SNI_FUEL_PUR_TXN_PRD_P"."PS_CURR_IND"=1)
20 - filter("X_SNI_FUEL_PUR_TXN_P"."PS_CURR_IND"=1)
Note
   - SQL profile "SYS_SQLPROF_0139a0175fb30006" used for this statement

Ora DBA wrote:
Dear Experts,
In my 11.1.0.7 DB, I'm trying to figure out why one of my NEW ETL job (INSERT statement) in UAT is taking longer. I see same job in UNIT envt runs fairly quicker.
UAT run time > 5Hrs to insert 1.1 million records, UNIT run time < 10 mins to insert 750K records
I ran tuning advisor and have accepted the only recommendation, SQL profile that was shown to have 99% benefit and still see run time is over 5 hours (with or without SQLprofile). I have compared the explain plans in UAT and UNIT envt which are similar and also have same plan_hash_value. Explain plans are shared below:
It's obvious from UAT plan that NESTED LOOPS OUTER, HASH JOIN RIGHT OUTER are the one taking lot of CPU and time for operation execution.
Please share your inputs as to how this can be diagnosed. Thanks a lot..As a first step towards diagnosis, I would check following:
1) First step would be to isolate the problem. So you may want to verify if the SELECT part or the INSERT part is contributing more to run-time (It looks like the SELECT part but always good to confirm). That way, you can concentrate on, for e.g., tuning only SELECT part.
2) When trying to compare the runtime from 2 environments, ensure that you are using almost similar (if not same) data volumes and same tables/index structures
3) As both environments produce same plan, presumably the tables involved have similar pattern of statistics. But the actual data volume may be quite different. So check whether statistics are representative of actual data
4) Fortunately, your plan uses all FULL TABLE ACCESS and HASH JOIN (except one NESTED LOOP). So for a query that runs for more than 5 hours, you should be able to monitor individual steps using v$session_longops. As you are on 11G, you may also make use of Real-time SQL monitoring.
5) While it is not possible to decisively conclude anything based on EXPLAIN PLAN output, you may want to compare the PGA settings and TEMP file disk I/O capabilities of both environments. For e.g. in UNIT env, all the HASH JOINS that spill to disk are expected to be completed quicker than the corresponding HASH JOINS on UAT env. (Again, same volume of data would benefit the comparison here).
6) You may want to get rid of any HINTs used to check how CBO decides to process the query when left on its own.
7) Last but not the least, you may want to check the table design, especially as this query appears to involve lots of outer joins and analytical functions. Difficult to say anything conclusive without knowing the query but the following part of the plan suggests that there might be an opportunity to validate the logic used.
|   9 |        VIEW                       |                          |     1 |    26 |       |    57   (6)| 00:00:01 |
|* 10 |         FILTER                    |                          |       |       |       |            |          |
|* 11 |          HASH JOIN                |                          |     1 |    59 |       |    57   (6)| 00:00:01 |
|* 12 |           TABLE ACCESS FULL       | X_SNI_FUEL_PLN_STP_DTL_P |     1 |    28 |       |    27   (0)| 00:00:01 |
|* 13 |           VIEW                    |                          | 17659 |   534K|       |    29   (7)| 00:00:01 |
|* 14 |            WINDOW SORT PUSHED RANK|                          | 17659 |   448K|       |    29   (7)| 00:00:01 |
| 15 |             TABLE ACCESS FULL     | X_SNI_FUEL_PLN_STP_DTL_P | 17659 |   448K|       |    27   (0)| 00:00:01 |This looks like a self-join of a table with itself, combined with usage of analytic function. Both might not be necessary and may be re-written to either avoid self-join or the analytic function part or replace them with a simpler query, which, in turn may impact the CBO's choice of subsequent NESTED LOOP join.
Hope this helps.

Understanding explain plan

Oracle Gurus,
I am trying to understand the below explain plan which I generated using DBMS_XPLAN. This explain plan shows 380M cost, what do "M" and "K" mean here? If anyone has any good documentation to understand explain plan, please pass on.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | INSERT STATEMENT | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
| 1 | HASH UNIQUE | | 9 | 801 | 380M(100)| 09:11:35 | | | | | |
|* 2 | FILTER | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10002 | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | P->S | QC (RAND) |
|* 5 | HASH JOIN BUFFERED | | 3625K| 307M| 4282 (70)| 00:00:01 | | | Q1,02 | PCWP | |
| 6 | PX RECEIVE | | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 7 | PX SEND HASH | :TQ10000 | 362K| 14M| 1219 (52)| 00:00:01 | | | Q1,00 | P->P | HASH |
| 8 | PX BLOCK ITERATOR | | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWC | |
|* 9 | TABLE ACCESS FULL | TOP10_UL_SECTOR_LUCENT | 362K| 14M| 1219 (52)| 00:00:01 | 7 | 7 | Q1,00 | PCWP | |
| 10 | PX RECEIVE | | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10001 | 411K| 18M| 1427 (52)| 00:00:01 | | | Q1,01 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWC | |
|* 13 | TABLE ACCESS FULL | BH_UL_SECTOR_LUCENT | 411K| 18M| 1427 (52)| 00:00:01 | 182 | 212 | Q1,01 | PCWP | |
| 14 | SORT AGGREGATE | | 1 | 14 | | | | | | | |
| 15 | PARTITION RANGE ITERATOR| | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
|* 16 | INDEX SKIP SCAN | IDX2_BH_UL_SECTOR_LUCENT | 10 | 140 | 120 (100)| 00:00:01 | 182 | 212 | | | |
-----------------------------------------------------------------------------------------------------------------------------------------------------

Hello,
Once again K is number of (1000) rows fetched and M is for bytes repsentation. Check this oracle doc for reading xplan
Cost of the operation as estimated by the optimizer's query approach. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement; it is merely a weighted value used to compare costs of execution plans. The value of this column is a function of the CPU_COST and IO_COST columns
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
Regards

Explain plan on Update statement in function

All,
I have an update statement in a function and my explain plan shows:
"Optimizer"     "Cost"     "Cardinality"     "Bytes"
"UPDATE STATEMENT"     "ALL_ROWS"     "2"     "1"     "7"
"UPDATE user.<table_name>"     ""     ""     ""     ""
"INDEX(UNIQUE SCAN) <table_name>.<PK_column_cons>"     "ANALYZED"     "1"     "1"     "7"
Filtering is on index unique column, but cost is 1 what does that mean?
do i need to change my update statement in function?
Any ideas?
Regards,
~ORA

The cost is the optimizer's measure of how much effort it will take to execute the statement. For any statement the optimizer will evaluate a number of execution plans and choose the one with the lowest cost. I wouldn't worry too much about what it actually "means". However if you want to understand this subject in a lot more detail I would recommend the book Cost-Based Oracle Fundamentals by Jonathan Lewis.
For your update statement the optimizer has chosen to access a single row by the primary key index, which is probably good enough, so you should not need to change it.
The only faster way to access the data would be to use the row's ROWID directly. You would need to have fetched this explicitly in a previous SELECT statement, or you could use it implicitly with the WHERE CURRENT OF syntax for a cursor opened with FOR UPDATE.

Strange behavior of explain plan

Hello i don't know if this is the correct category for posting my issue.
I ma facing a strange behavior of the explain plan. What i mean!
I have a query which runs very fast and it is well optimized. the explain plan shows very good results in cost and execution time.
when i am running the query for a second or a third time is appearing a different explain plan with not such a good cost and execution time.
Could you please guide me what it might be wrong???
thanks a lot

HI i found the correct category
thanks

Explain Plan vs. V$SQL_PLAN

Hello everyone,
I'm trying to understand the difference between those two, I'm relying on the following Tom Kyte article :
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
In my following example I didn't use TKPROF as he did but AUTOTRACE / V$SQL_PLAN instead (since EXPLAIN PLAN shows a theoretical plan that can be used if this statement were to be executed and V$SQL_PLAN contains the actual plan used)
That's my code :
>
HR> ALTER SYSTEM FLUSH shared_pool ;
HR>
HR> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
HR>
HR> create index t_idx on test(id);
Index created.
HR>
HR> -- AUTOTRACE vs V$SQL round 1 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 30 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> SET AUTOTRACE OFF
HR>
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
>
Ok so in round 1, the optimizer decided to get the 1 row back using Index Range Scan both in "theory" and in "reality", it make sense.
Now its time for round 2 ... :)
>
HR> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
HR>
HR> commit ;
Commit complete.
HR>
HR>
HR> -- AUTOTRACE vs V$SQL round 2 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
1 I_VIEWTRCOL1
1001 rows selected.
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 30030 | 6 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1001 | 30030 | 6 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1001 | | 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
HR>
>
since explain plan is using always Hard Parse (and it used dynamic sampling) I would expect to see FTS in "theory"
can anyone explain me why in round 2 they both presented Index Range Scan.
Thanks ! :)

Explain plan can lie, autotrace - which just does an explain plan - can lie.
See:
http://oracle-randolf.blogspot.com/2012/01/autotrace-polluting-shared-pool.html
http://kerryosborne.oracle-guy.com/2010/02/autotrace-lies/
http://hoopercharles.wordpress.com/2010/01/11/explain-plan-lies-autotrace-lies-tkprof-lies-what-is-the-plan/
V$SQL_PLAN is the truth.
You didn't mention version but DBMS_XPLAN is the most convenient way to get your plan.
If the plan is cached, inserting 1000 rows is not going to change the plan.
SQL> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
SQL>
SQL> create index t_idx on test(id);
Index created.
SQL>
SQL> select id, object_name from test where id = 1;
        ID OBJECT_NAME
         1 ORA$BASE
SQL>
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST |     1 |    30 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
SQL> commit;
Commit complete.
SQL> select id, object_name from test where id = 1;
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST |     1 |    30 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL>

Sub Partitioning does not have considerable impact Explain Plan

Hi Guys,
I have a table that is list - list sub partitioned on Oracle 11g - 11.2.0.3.
The first partition is on the CIRCLE_ID column and the second sub partition is on the LOAD_DTTM.
Now i have tried 2 queries on the database
1 - select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM a1
where A1.CIRCLE_ID ='AK'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012';
2 - select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM a1
where A1.CIRCLE_ID ='AK'
AND to_char(a1.LOAD_DTTM) like '%MAR%'
Ideally the 2nd query should take a much higher time than the first query.
But the explain plan shows a difference of less than 1%.
Can you pls provide some insights as why Oracle is not understanding that subpartitioning will be faster?
Thanks,
Manish

Hi Dom
Thanks for your reply.
Is the first query using partition pruning? - Yes
Have you gathered stats, etc, etc? - No. All our queries always need to access the entire table and not a particular subset and the where criteria always uses partition and sub partition columns. so we dont see the need to collect stats. Can you pls advise what stats need to be collected and what will be the advantage of those?
Below are the output of the Explain Plan and Trace Output -
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter optimizer;
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi;
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
SQL> column sname format a20
SQL> column pname foramt 20
SP2-0158: unknown COLUMN option "foramt"
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select
2 sname
3 , pname
4 , pval1
5 ,pval2
6 from sys.aux_stats$;
from sys.aux_stats$
ERROR at line 6:
ORA-00942: table or view does not exist
SQL> explain plan for
select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012'
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3032220315
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)
| Time | Pstart| Pstop |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 41M| 1643M| 548M(100)
|999:59:59 | | |
| 1 | PARTITION LIST SINGLE | | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
| 2 | PARTITION LIST ITERATOR| | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
| 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement (level=2)
14 rows selected.
SQL> explain plan for
select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND to_char(a1.LOAD_DTTM) like '%MAR%';
2 3 4
Explained.
SQL> SQL> SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 189546713
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| T
ime | Pstart| Pstop |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 62M| 2521M| 5435M(100)|99
9:59:59 | | |
| 1 | PARTITION LIST SINGLE| | 62M| 2521M| 5435M(100)|99
9:59:59 | KEY | KEY |
| 2 | PARTITION LIST ALL | | 62M| 2521M| 5435M(100)|99
9:59:59 | 1 | 305 |
|* 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 62M| 2521M| 5435M(100)|99
9:59:59 | KEY | KEY |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter(TO_CHAR(INTERNAL_FUNCTION("A1"."LOAD_DTTM")) LIKE '%MAR%')
Note
PLAN_TABLE_OUTPUT
- dynamic sampling used for this statement (level=2)
19 rows selected.
SQL>
SQL> SET AUTOTRACE TRACEONLY ARRAYSIZE 100
SQL> select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012' 2 3 ;
49637012 rows selected.
Execution Plan
Plan hash value: 3032220315
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)
| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 41M| 1643M| 546M(100)
|999:59:59 | | |
| 1 | PARTITION LIST SINGLE | | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
| 2 | PARTITION LIST ITERATOR| | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
| 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
Note
- dynamic sampling used for this statement (level=2)
Statistics
0 recursive calls
7 db block gets
530220 consistent gets
33636 physical reads
0 redo size
644311477 bytes sent via SQL*Net to client
5460594 bytes received via SQL*Net from client
496372 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
49637012 rows processed
SQL> SET AUTOTRACE TRACEONLY ARRAYSIZE 100
SQL> select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND to_char(a1.LOAD_DTTM) like '%MAR%' 2 3
4 ;
219166976 rows selected.
Execution Plan
Plan hash value: 189546713
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| T
ime | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 228M| 9155M| 3552M(100)|99
9:59:59 | | |
| 1 | PARTITION LIST SINGLE| | 228M| 9155M| 3552M(100)|99
9:59:59 | KEY | KEY |
| 2 | PARTITION LIST ALL | | 228M| 9155M| 3552M(100)|99
9:59:59 | 1 | 274 |
|* 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 228M| 9155M| 3552M(100)|99
9:59:59 | KEY | KEY |
Predicate Information (identified by operation id):
3 - filter(TO_CHAR(INTERNAL_FUNCTION("A1"."LOAD_DTTM")) LIKE '%MAR%')
Note
- dynamic sampling used for this statement (level=2)
Statistics
38 recursive calls
107 db block gets
2667792 consistent gets
561765 physical reads
0 redo size
2841422984 bytes sent via SQL*Net to client
24108883 bytes received via SQL*Net from client
2191671 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
219166976 rows processed
SQL>
Thanks,
Manish

Query plan shows Cost: 0 Bytes: 851 Cardinality: 1

Hi,
Customer running 10.2.0.4 on linux 64 bit.
Explain plan shows:
SELECT STATEMENT ALL_ROWS Cost: 0 Bytes: 851 Cardinality: 1
8 FILTER
7 SORT ORDER BY Bytes: 851 Cardinality: 1
6 HASH JOIN OUTER Cost: 2,873,137 Bytes: 5,047,622,251 Cardinality: 5,931,401
4 HASH JOIN Cost: 1,696,501 Bytes: 4,567,178,770 Cardinality: 5,931,401
1 TABLE ACCESS FULL TABLE LIVE.INSTRUMENT Cost: 212,073 Bytes: 679,589,280 Cardinality: 1,595,280
3 PARTITION RANGE ALL Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
2 TABLE ACCESS FULL TABLE LIVE.DEALTRANS Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
5 TABLE ACCESS FULL TABLE LIVE.SMDBINSTRUMENT Cost: 1,169 Bytes: 4,958,172 Cardinality: 61,212
I understand that explain plans can be unreliable but:
1) why does cost show as 0? Its obviously much higher. Is there just not enough room?
2) why a cardinality of 1?
Thanks in advance,
Steve

Hi Someoneelse,
Not sure, i have a query into the client.
Thanks for responding.
Steve

Partition of table n Explain plan

I am a newbie for oracle partititon. Need help!!!
I have a created a partition table, range partition by key column datatype is 'timetamp'.
Stucture would be ::
CREATE TABLE sales
( prod_id       NUMBER(6)
, cust_id       NUMBER
, time_id       DATE
, amount_sold   NUMBER(10,2)
PARTITION BY RANGE (time_id)
( PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy'))
, PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy'))
, PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy'))
, PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy'))
The time i run below query, explain plan shows PStart as #1 and PStop as #4, but this date range access only one partition, explain plan must show particular partition. Also should it show partition name?
select * from sales where trunc(time_id)=trunc(sysdate-2811);

Thanks for the reply martin,I have tried below query still it goes for all partitions.Please refer to below Expalin Plan.
select * from sales where trunc(time_id) between trunc(sysdate-2811) and trunc(sysdate-2810) -1/86400
<PlanElement id="0" operation="SELECT STATEMENT" optimizer="ALL_ROWS" cost="42" cardinality="1" bytes="48" cpu_cost="1,321,416" io_cost="42" time="1">
<PlanElements>
<PlanElement id="1" operation="FILTER" qblock_name="SEL$1" filter_predicates="TRUNC(SYSDATE@!-2811)<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407">
<PlanElements>
<PlanElement id="2" operation="PARTITION RANGE" option="ALL" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" time="1">
<PlanElements>
<PlanElement object_ID="0" id="3" operation="TABLE ACCESS" option="FULL" object_owner="SONARDBO" object_name="SALES" object_type="TABLE" object_instance="1" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" qblock_name="SEL$1" filter_predicates="TRUNC(INTERNAL_FUNCTION("TIME_ID"))>=TRUNC(SYSDATE@!-2811) AND TRUNC(INTERNAL_FUNCTION("TIME_ID"))<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407" time="1" />

How Explain Plan Calculates the Bytes

Hi All,
I am using Oracle 10g edition 10.2.0.3.0.
Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
1) How bytes are calculcated?
2) What "Cost = 1" means?
3) What "%CPU = 0 means?
SQL> desc t_pdur_insulin_prof
Name
SAK_RECIP NOT NULL NUMBER(9)
SAK_CLAIM NOT NULL NUMBER(9)
SAK_DRUG NOT NULL NUMBER(9)
DTE_DISPENSE NOT NULL NUMBER(8)
CDE_PROF_TYPE NOT NULL CHAR(1)
SQL> explain plan for
2 select * from t_pdur_insulin_prof
3 where sak_recip = 10013819;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 438947110
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("SAK_RECIP"=10013819)
13 rows selected.
Thanks!

user2081225 wrote:
Hi All,
I am using Oracle 10g edition 10.2.0.3.0.
Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
1) How bytes are calculcated?
2) What "Cost = 1" means?
3) What "%CPU = 0 means?
SQL> desc t_pdur_insulin_prof
Name
SAK_RECIP NOT NULL NUMBER(9)
SAK_CLAIM NOT NULL NUMBER(9)
SAK_DRUG NOT NULL NUMBER(9)
DTE_DISPENSE NOT NULL NUMBER(8)
CDE_PROF_TYPE NOT NULL CHAR(1)
SQL> explain plan for
2 select * from t_pdur_insulin_prof
3 where sak_recip = 10013819;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 438947110
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("SAK_RECIP"=10013819)
13 rows selected.
Thanks!consider Reading The Fine Manual
http://docs.oracle.com/cd/E11882_01/server.112/e16638/optimops.htm#sthref981

TUNNING A SQL QUERY AND UNSERSTAND EXPLAIN PLAN

I was trying my handing in tunning sql queries -
Though I have manged to reduce the cost lil ..creating some index, but have genarated a g8 interesting in tunning - Can some experts ( I know there are lots available :-) ) help me on the approch on "HOW TO TUNE A QUERY"
moreover I also would like to understand - how to debug a explain plan, - please help ...
Regards..

Hi,
Welcome to this forum...
I would suggest your to read first the official documentations :
- The concepts of an Oracle DBMS (this is important to know, because Oracle structures, processes, objects (etc) are the building blocks of your database)
- SQL reference guide
- PL/SQL reference guide
and then at a later stage the Performance and tuning guide:
You can start there:
http://download.oracle.com/docs/cd/B14117_01/nav/portal_1.htm
Once it's done maybe read the Performance and tuning guide:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10752/toc.htm
(Chapter 19 explain ... how to interpret the explain plan ..)
I wish you good chance and be patient: I'm working with Oracle for more that 10 years and I'm still learning! ...
Rem: The Oracle website is full of interesting articles, and examples, just "search" your special points of interests ..

Explain Plan shows Nested Loops, Is it good or bad?

Similar Messages

Maybe you are looking for