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
Similar Messages
-
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
ThanksHi,
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 -
Plan shows SQL execution time Hrs 999:59:59 Sec.
Dear Masters,
Today my development team reported that the below query is taking more time. When I check the plan for my shok it is showing Hrs 999:59:59 Sec.
Kindly help me in tuning this query.
I am using oracle 10.2.0.3 version.
SELECT
S_INVLOC.NAME , S_ORDER.ACCNT_ID , S_ORDER.APPR_BY_EMP_ID , S_ORDER.BL_CON_ID , S_ORDER.BL_OU_ID , S_ORDER.CARRIER_CD , S_ORDER.CONTACT_ID , S_ORDER.CURCY_CD , S_ORDER.TAX_EXEMPT_FLG ,
S_ORDER.REQ_SHIP_DT , S_ORDER.SHIP_ADDR_ID , S_ORDER.SHIP_CON_ID , S_ORDER.SHIP_METH_CD , S_ORDER.SHIP_OU_ID , S_ORDER.STATUS_CD , S_ORDER.TAX_EXEMPT_NUM , S_ORDER.TAX_EXEMPT_REASON ,
S_ORDER.OPTY_ID , S_ORDER.BU_ID PR_VIS_ORG_ID , S_ORDER.PROMO_ID , S_ORDER.PRI_LST_ID , S_ORDER.AGREE_ID AGREEMENT_ID , S_ORDER.ENTLMNT_ID ENTITLEMENT_ID , S_ORDER.SR_ID ,
S_ORDER.BILLABLE_FLG , S_ORDER_ITEM.ROW_ID , S_ORDER_ITEM.ORDER_ID , S_ORDER_ITEM.LN_NUM , S_ORDER_ITEM.PROD_ID , S_ORDER_ITEM.ADJ_UNIT_PRI , S_ORDER_ITEM.BASE_UNIT_PRI ,
S_ORDER_ITEM.CARRIER_CD CARRIER_CD1 , S_ORDER_ITEM.EXTD_QTY , S_ORDER_ITEM.QTY_SHIPPED , S_ORDER_ITEM.REQ_SHIP_DT REQ_SHIP_DT1 , S_ORDER_ITEM.SHIP_ADDR_ID SHIP_ADDR_ID1 ,
S_ORDER_ITEM.SHIP_CON_ID SHIP_CON_ID1 , S_ORDER_ITEM.SHIP_METH_CD SHIP_METH_CD1 , S_ORDER_ITEM.STATUS_CD STATUS_CD1 , S_ORDER_ITEM.PROD_STATUS_CD , S_ORDER_ITEM.PROD_NAME ,
S_ORDER_ITEM.LOANER_FLG , S_ORDER_ITEM.DISCNT_METH_CD , S_ORDER_ITEM.SHIP_OU_ID SHIP_OU_ID1 , S_ORDER_ITEM.STATUS_DT , S_ORDER_ITEM.MUST_DLVR_BY_DT , S_ORDER_ITEM.ACTION_CD ,
S_ORDER_ITEM.ROLLUP_PRI , S_PROD_INT.NAME NAME1 , A.NAME NAME2 , B.NAME NAME3 , S_VOL_DISCNT.NAME NAME4 , ACCNT.PR_INDUST_ID , POSCRTDORG.OU_ID CREATED_BY_ORG_ID ,
POSOWNERORG.OU_ID PR_OWNER_ORG_ID , PAROITEM.LN_NUM , PAROITEM.PROD_ID , SHIPOITEM.CITY , SHIPOITEM.COUNTRY , SHIPOITEM.ZIPCODE , SHIPO.CITY , SHIPO.COUNTRY , SHIPO.ZIPCODE ,
BILL.CITY , BILL.COUNTRY , BILL.ZIPCODE , S_CAMP_CON.PR_CALL_LST_ID SEGMENT_ID , S_ORDER.DCP_ID OFFER_ID , APPRBYPOS.PR_HELD_POSTN_ID , POSOWNERORG.ROW_ID , POSOWNERORG.PR_EMP_ID ,
S_ENTLMNT.PAR_AGREE_ID , ROOTOITEM.PROD_ID ROOT_LN_PROD_ID , ROOTOITEM.LN_NUM ROOT_LN_NUM , S_ORDER.PR_POSTN_ID , S_CAMP_CON.CAMP_LD_WAVE_ID , S_SRC.REGION_ID , OPRI.COST_PRI ,
S_ORDER_ITEM.ORDER_ITM_CURCY_CD OITM_CURCY_CD , ROOTOITEM.ORDER_ITM_CURCY_CD ROOTOITM_CURCY_CD , S_ORDER_ITEM.ORDER_ITM_EXCH_DT OITM_AMT_DT , S_ORDER.ORDER_EXCH_DT ,
S_ORDER_ITEM.CREATED , S_ORDER_ITEM.NET_PRI , S_ORDER_ITEM.CRSE_OFFR_ID , S_ORDER_ITEM.PRI_LST_ID OITM_PRI_LST_ID , ROOTOITEM.PRI_LST_ID ROOTOITM_PRI_LST_ID ,
OWNORG.PRTNR_FLG , VISORG.PRTNR_FLG , S_CAMP_LD_WAVE.LAUNCHED_TS , QUOTE.CREATED , S_ORDER.ACTIVE_FLG , S_ORDER.APPROVED_FLG , PARPROD.PROD_TYPE_CD , ROOTPROD.PROD_TYPE_CD ,
S_PROD_INT.PRICE_TYPE_CD , S_SRC.PROG_END_DT , S_SRC.PROG_START_DT , S_SRC.ROW_ID , S_ORDER.CREATED , OWNORG.ROW_ID , 0 AS X_CUSTOM , S_ORDER_ITEM. X_PHONE_NUMBER ,
S_ORDER_ITEM.X_BACKEND_SERVICE_ID , S_ORDER_ITEM.SERVICE_NUM , S_ORDER_ITEM.BILL_ACCNT_ID , S_ORDER_X.ATTRIB_04 , S_ORDER_X.ATTRIB_30 , S_ORDER_X.ATTRIB_31
FROM
SIEBEL.V_ORDER_ITEM S_ORDER_ITEM, SIEBEL.S_ORDER_ITEM PAROITEM, SIEBEL.S_ORDER_ITEM ROOTOITEM, SIEBEL.S_ORDER, SIEBEL.S_VDISCNT_ITEM A, SIEBEL.S_VOL_DISCNT, SIEBEL.S_PROD_INT,
SIEBEL.S_VDISCNT_ITEM B, SIEBEL.S_INVLOC, SIEBEL.S_ORG_EXT ACCNT, SIEBEL.S_POSTN POSOWNERORG, SIEBEL.S_CONTACT CRTD, SIEBEL.S_CONTACT APPRBYPOS, SIEBEL.S_POSTN POSCRTDORG,
SIEBEL.S_ADDR_ORG SHIPOITEM, SIEBEL.S_ADDR_ORG SHIPO, SIEBEL.S_ADDR_ORG BILL, SIEBEL.S_CAMP_CON, SIEBEL.S_ENTLMNT, SIEBEL.S_SRC, SIEBEL.S_ORDER_ITM_PRI OPRI,
SIEBEL.S_CAMP_LD_WAVE, SIEBEL.S_DOC_QUOTE QUOTE, SIEBEL.S_ORG_EXT OWNORG, SIEBEL.S_ORG_EXT OWNORG1, SIEBEL.S_ORG_EXT VISORG1, SIEBEL.S_ORG_EXT VISORG,
SIEBEL.S_PROD_INT PARPROD, SIEBEL.S_PROD_INT ROOTPROD, SIEBEL.S_ORDER_X
WHERE
S_ORDER_ITEM.ORDER_ID = S_ORDER.ROW_ID
AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID = ROOTOITEM.ROW_ID
AND S_ORDER_ITEM.PAR_ORDER_ITEM_ID = PAROITEM.ROW_ID(+)
AND S_ORDER_ITEM.PROD_ID = S_PROD_INT.ROW_ID(+)
AND S_ORDER_ITEM.SRC_INVLOC_ID = S_INVLOC.ROW_ID(+)
AND S_ORDER_ITEM.VOL_DISCNT_ITEM_ID = A.ROW_ID(+)
AND S_ORDER_ITEM.VOL_DISCNT_ID = S_VOL_DISCNT.ROW_ID(+)
AND S_ORDER_ITEM.VOL_UPSELL_ITEM_ID = B.ROW_ID(+)
AND S_ORDER_ITEM.SHIP_ADDR_ID = SHIPOITEM.ROW_ID(+)
AND S_ORDER.PR_POSTN_ID = POSOWNERORG.ROW_ID(+)
AND S_ORDER_ITEM.CREATED_BY = CRTD.ROW_ID(+)
AND CRTD.PR_HELD_POSTN_ID = POSCRTDORG.ROW_ID(+)
AND S_ORDER.ACCNT_ID = ACCNT.ROW_ID(+)
AND S_ORDER.CAMP_CON_ID = S_CAMP_CON.ROW_ID(+)
AND S_ORDER.SHIP_ADDR_ID = SHIPO.ROW_ID(+)
AND S_ORDER.BL_ADDR_ID = BILL.ROW_ID(+)
AND S_ORDER.APPR_BY_EMP_ID = APPRBYPOS.ROW_ID(+)
AND S_ORDER.ENTLMNT_ID = S_ENTLMNT.ROW_ID(+)
AND S_ORDER.PROMO_ID = S_SRC.ROW_ID(+)
AND S_ORDER_ITEM.ROW_ID = OPRI.PAR_ROW_ID(+)
AND S_CAMP_CON.CAMP_LD_WAVE_ID = S_CAMP_LD_WAVE.ROW_ID(+)
AND S_ORDER.QUOTE_ID = QUOTE.ROW_ID(+)
AND POSOWNERORG.OU_ID = OWNORG1.ROW_ID(+)
AND OWNORG1.PAR_BU_ID = OWNORG.ROW_ID(+)
AND S_ORDER.BU_ID = VISORG1.ROW_ID(+)
AND VISORG1.PAR_BU_ID = VISORG.ROW_ID(+)
AND PAROITEM.PROD_ID = PARPROD.ROW_ID(+)
AND ROOTOITEM.PROD_ID = ROOTPROD.ROW_ID(+)
AND S_ORDER_ITEM.ORDER_ID = S_ORDER_X.PAR_ROW_ID(+)
AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID IS NOT NULL;Execution Plan is : select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 73463824
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3170K| 12G| 4100G (4)|999:59:59 |
| 1 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 2 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 3 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 4 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 5 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 6 | NESTED LOOPS | | 3170K| 12G| 4100G (4)|999:59:59 |
| 7 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 8 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 9 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 10 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 11 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 12 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 13 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 14 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 15 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 16 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 17 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 18 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 19 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 20 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 21 | NESTED LOOPS | | 3170K| 9911M| 4100G (4)|999:59:59 |
| 22 | NESTED LOOPS OUTER | | 3108K| 4927M| 2569K (2)| 01:08:47 |
| 23 | NESTED LOOPS OUTER | | 3108K| 4835M| 115K (14)| 00:03:06 |
| 24 | NESTED LOOPS OUTER | | 3108K| 4782M| 115K (14)| 00:03:06 |
| 25 | NESTED LOOPS OUTER | | 3108K| 4660M| 112K (12)| 00:03:02 |
| 26 | NESTED LOOPS OUTER | | 3108K| 4417M| 112K (12)| 00:03:02 |
| 27 | NESTED LOOPS OUTER | | 3108K| 4227M| 112K (12)| 00:03:02 |
| 28 | NESTED LOOPS OUTER | | 3108K| 3943M| 112K (12)| 00:03:02 |
| 29 | NESTED LOOPS OUTER | | 3108K| 3178M| 111K (11)| 00:02:59 |
| 30 | TABLE ACCESS FULL | S_ORDER | 3108K| 2413M| 109K (9)| 00:02:56 |
| 31 | TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_CAMP_CON | 1 | 96 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | S_CAMP_CON_P1 | 1 | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_ENTLMNT | 1 | 64 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | S_ENTLMNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 82 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_CAMP_LD_WAVE | 1 | 41 | 1 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | S_CAMP_LD_WAVE_P1 | 1 | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 18 | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 31 | 1 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 |
|* 47 | VIEW | V_ORDER_ITEM | 1 | 1616 | 1318K (4)| 00:35:19 |
| 48 | NESTED LOOPS | | 3128K| 1372M| 1318K (4)| 00:35:19 |
| 49 | INDEX FAST FULL SCAN | S_ETL_I_IMG_25_M2 | 3128K| 32M| 2756 (11)| 00:00:05 |
|* 50 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 449 | 2 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_VOL_DISCNT | 1 | 134 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_VOL_DISCNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
|* 60 | TABLE ACCESS FULL | S_ORDER_ITM_PRI | 1 | 45 | 0 (0)| 00:00:01 |
| 61 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 33 | 1 (0)| 00:00:01 |
|* 62 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | 1 (0)| 00:00:01 |
| 63 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 58 | 1 (0)| 00:00:01 |
|* 64 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 65 | TABLE ACCESS BY INDEX ROWID | S_ORDER_X | 1 | 36 | 2 (0)| 00:00:01 |
|* 66 | INDEX RANGE SCAN | S_ORDER_X_U1 | 1 | | 2 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 2 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 69 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 20 | 1 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 1 (0)| 00:00:01 |
|* 72 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 73 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 76 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 |
|* 78 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 60 | 2 (0)| 00:00:01 |
|* 80 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 81 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 24 | 2 (0)| 00:00:01 |
|* 82 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 83 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 84 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 85 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 86 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 87 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 88 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 89 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 |
|* 90 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID"(+))
34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID"(+))
36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID"(+))
38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID"(+))
40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID"(+))
42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID"(+))
44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID"(+))
46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID"(+))
47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID")
50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL)
51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID")
53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID"(+))
55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID"(+))
57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID"(+))
59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID"(+))
60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID"(+))
PLAN_TABLE_OUTPUT
62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID"(+))
64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID"(+))
66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID"(+))
68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID"(+))
70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID"(+))
72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID"(+))
74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID"(+))
76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID"(+))
78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID"(+))
80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID")
82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID"(+))
84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID"(+))
86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID"(+))
88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID"(+))
90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID"(+))
132 rows selected.Edited by: KODS on Dec 13, 2012 2:11 PMOutput of : select * from table(dbms_xplan.display_cursor('4nn6jbvwf0b2k', null, 'iostats last'));
PLAN_TABLE_OUTPUT
SQL_ID 4nn6jbvwf0b2k, child number 0
S_ORDER.APPR_BY_EMP_ID ,
S_ORDER.CARRIER_CD ,
S_ORDER.CURCY_CD ,
S_ORDER.SHIP_ADDR_ID,
S_ORDER.SHIP_METH_CD ,
S_ORDER.TAX_EXEMPT_NUM ,
S_ORDER.BU_IDID ,EASON ,
S_ORDER.PRI_LST_ID ,
S_ORDER.ENTLMNT_ID ENTITLEMENT_ID ,
S_ORDER_ITEM.ROW_ID ,,
S_ORDER_ITEM.PROD_ID,
S_ORDER_ITEM.BASE_UNIT_PRI ,
S_
Plan hash value: 73463824
| Id | Operation | Name | E-Rows |
| 1 | NESTED LOOPS OUTER | | 3170K|
| 2 | NESTED LOOPS OUTER | | 3170K|
| 3 | NESTED LOOPS OUTER | | 3170K|
| 4 | NESTED LOOPS OUTER | | 3170K|
| 5 | NESTED LOOPS OUTER | | 3170K|
| 6 | NESTED LOOPS | | 3170K|
| 7 | NESTED LOOPS OUTER | | 3170K|
| 8 | NESTED LOOPS OUTER | | 3170K|
| 9 | NESTED LOOPS OUTER | | 3170K|
| 10 | NESTED LOOPS OUTER | | 3170K|
| 11 | NESTED LOOPS OUTER | | 3170K|
| 12 | NESTED LOOPS OUTER | | 3170K|
| 13 | NESTED LOOPS OUTER | | 3170K|
| 14 | NESTED LOOPS OUTER | | 3170K|
| 15 | NESTED LOOPS OUTER | | 3170K|
| 16 | NESTED LOOPS OUTER | | 3170K|
| 17 | NESTED LOOPS OUTER | | 3170K|
| 18 | NESTED LOOPS OUTER | | 3170K|
| 19 | NESTED LOOPS OUTER | | 3170K|
| 20 | NESTED LOOPS OUTER | | 3170K|
| 21 | NESTED LOOPS | | 3170K|
| 22 | NESTED LOOPS OUTER | | 3108K|
| 23 | NESTED LOOPS OUTER | | 3108K|
| 24 | NESTED LOOPS OUTER | | 3108K|
| 25 | NESTED LOOPS OUTER | | 3108K|
| 26 | NESTED LOOPS OUTER | | 3108K|
| 27 | NESTED LOOPS OUTER | | 3108K|
| 28 | NESTED LOOPS OUTER | | 3108K|
| 29 | NESTED LOOPS OUTER | | 3108K|
| 30 | TABLE ACCESS FULL | S_ORDER | 3108K|
| 31 | TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG | 1 |
|* 32 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 |
|* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_CAMP_CON | 1 |
|* 36 | INDEX UNIQUE SCAN | S_CAMP_CON_P1 | 1 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_ENTLMNT | 1 |
|* 38 | INDEX UNIQUE SCAN | S_ENTLMNT_P1 | 1 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 |
|* 40 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_CAMP_LD_WAVE | 1 |
|* 42 | INDEX UNIQUE SCAN | S_CAMP_LD_WAVE_P1 | 1 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 |
|* 44 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 |
|* 46 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 |
|* 47 | VIEW | V_ORDER_ITEM | 1 |
| 48 | NESTED LOOPS | | 3128K|
| 49 | INDEX FAST FULL SCAN | S_ETL_I_IMG_25_M2 | 3128K|
|* 50 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 51 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 |
|* 53 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_VOL_DISCNT | 1 |
|* 55 | INDEX UNIQUE SCAN | S_VOL_DISCNT_P1 | 1 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 |
|* 57 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 |
|* 59 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
|* 60 | TABLE ACCESS FULL | S_ORDER_ITM_PRI | 1 |
| 61 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 |
|* 62 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 |
| 63 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 64 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 65 | TABLE ACCESS BY INDEX ROWID | S_ORDER_X | 1 |
|* 66 | INDEX RANGE SCAN | S_ORDER_X_U1 | 1 |
| 67 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 |
|* 68 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 |
| 69 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 |
|* 70 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 |
| 71 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 |
|* 72 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 |
| 73 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 74 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 76 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 78 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 79 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 80 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 81 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 82 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 83 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 84 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 85 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 86 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 87 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 88 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 89 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 90 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
Predicate Information (identified by operation id):
32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID")
PLAN_TABLE_OUTPUT
34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID")
36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID")
38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID")
40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID")
42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID")
44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID")
46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID")
47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID")
50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL)
51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID")
53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID")
55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID")
57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID")
59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID")
60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID")
62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID")
64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID")
66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID")
68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID")
70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID")
72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID")
74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID")
76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID")
78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID")
80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID")
82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID")
84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID")
86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID")
88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID")
90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID")
Note
- Warning: basic plan statistics not available. These are only collected when:
* hint 'gather_plan_statistics' is used for the statement or
* parameter 'statistics_level' is set to 'ALL', at session or system level
154 rows selected. -
When I see the Visualize Plan for SQLScript it show Create Temp Index at many Places.
It also shows unsupported operator order CS_JOIN over CS_AGGREGATION.
Why does hana create Temp Index and how to get rid of it.Just browsing for some more information on this operation, and it just happened that my favorite VizPlan expert has chimed in here
I have a scenario where I am using a nested SQLScript based calc view. One view (child view) retrieves a relatively small data set, then the main CV takes that and joins with a bunch of other data from another schema.
When I started out, just the nested portion of (child calc view), takes roughly 800ms to return it's resultset, for which I was pleased. Now, when I added some other joins onto that dataset in the main CV, I am seeing my runtime spike to approximately 16 seconds, with 15 seconds being spent on a "Create Temp Index" process that only results in 12 rows (from what I can see).
Now the question becomes - since I have identified where 95+% of my runtime is being generated, how can I really pinpoint what operation is causing this? I was thinking the ID column (shown in the details) may offer some clues if one knew how to locate the details in a system table somewhere?
Otherwise, all I can see in the VizPlan is that YES there is a long running component, but I have no idea what it might be, therefore can't do anything about it
Regards,
Justin -
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
SinghThe number of rows processed to get your one record
-
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" /> -
Diff in explain plan of 9i and 10g
I am beginner and just started my dba career. Please can you help me by giving me the differences between a explain plan executed in oracle 9i and 10g. Why is there variations in the cost,cardinality and bytes. Is it that 9is explain plan is executed in a different way when compared to 10g's. Please help me out regarding the same.
Are your generating it against same sets of rows or using different tables ? we would love to see more information and could you please your explain plan on the board ?
hare krishna
Alok -
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,
ManishHi 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 -
What are the privileges required for explain plan in Oracle 11g database
I am facing the problem in doing a explain plan for a view in Oracle 11g database. When I select from the view like this:
select * from zonewisearpu
It does a select on the view but when I give explain plan like
explain plan for
select * from zonewisearpu
I get the error like insufficient privileges.
Please let me know if things are getting missed out as I guess system level privileges are required to execute this.
I hope, my question is clear.
It’s a humble request to revert urgently if possible as I need to complete a task and do not know the way out.
Regards975148 wrote:
Thanks for your reply. I have found out that an explain plan is possible on the user's own objects and is not possible on the granted objects from a different schema. For eg, if I do a explain plan on a view querying on tables from a different view, it would not allow the explain plan to proceed. This could mean that explain plan needs different privileges than just a select.
Requesting for a revert to this.
Here is a simple test case that I have perfomed
SQL> create user test1 identified by test1;
User created.
SQL> create user test2 identified by test1;
User created.
SQL> grant connect, resource to test1,test2;
Grant succeeded.
SQL> create table test1.tab1 as select * from v$session;
Table created.
SQL> connect test2/test1
Conencted.
SQL> show user
USER is "TEST2"
SQL>
SQL> explain plan for
2 select sid,serial#,status,username from test1.tab1 where username<> '';
Explained.
SQL>
So, as can be seen I am able to do a explain plan from user test2 for tables belong to user test1.
As far as privileges are concerned, following is the list
SQL> select * from dba_role_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE GRANTED_ROLE ADM DEF
TEST1 CONNECT NO YES
TEST1 RESOURCE NO YES
TEST2 CONNECT NO YES
TEST2 RESOURCE NO YES
SQL>
SQL> select grantee,owner,table_name,privilege from dba_tab_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE OWNER TABLE_NAME PRIVILEGE
TEST2 TEST1 TAB1 SELECT
SQL>
SQL> select * from dba_sys_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE PRIVILEGE ADM
TEST1 UNLIMITED TABLESPACE NO
TEST2 UNLIMITED TABLESPACE NO
SQL> -
DECODE is changing the explain plan
I have a statement with a decode function in the where clause like this:
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)When I a pass -1 as parameter for cropgroup the filter would result in "AND '-1' = '-1' and the statement is executed in less than 2 seconds. When I leave out this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan is so much different and why not using index scans in the statement without decode.
Below the explain plans and tkprofs for 1 (without decode) and 2 (with decode).
*explain 1*
{code}
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 7080 | 2413K| | 43611 (2)|
| 1 | SORT ORDER BY | | 7080 | 2413K| 5224K| 43611 (2)|
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN | | 7156 | 2438K| | 43075 (2)|
| 4 | TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745 | 363K| | 83 (0)|
|* 5 | HASH JOIN OUTER | | 7156 | 2292K| | 42991 (2)|
|* 6 | HASH JOIN | | 7156 | 1355K| | 42907 (2)|
|* 7 | HASH JOIN | | 6987 | 1187K| | 19170 (2)|
|* 8 | HASH JOIN | | 6947 | 963K| | 10376 (1)|
|* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3 | 144 | | 3 (0)|
| 10 | NESTED LOOPS | | 6907 | 897K| | 8577 (1)|
|* 11 | HASH JOIN | | 2264 | 187K| | 1782 (2)|
| 12 | TABLE ACCESS BY INDEX ROWID | SAMPLE | 190 | 4370 | | 17 (0)|
| 13 | NESTED LOOPS | | 2264 | 152K| | 107 (1)|
| 14 | NESTED LOOPS | | 12 | 552 | | 25 (0)|
|* 15 | TABLE ACCESS FULL | SDG_USER | 12 | 288 | | 13 (0)|
| 16 | TABLE ACCESS BY INDEX ROWID| SDG | 1 | 22 | | 1 (0)|
|* 17 | INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0)|
|* 18 | INDEX RANGE SCAN | FK_SAMPLE_SDG | 597 | | | 2 (0)|
| 19 | TABLE ACCESS FULL | SAMPLE_USER | 1078K| 16M| | 1669 (1)|
|* 20 | INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0)|
| 21 | TABLE ACCESS FULL | ALIQUOT_USER | 3403K| 29M| | 1781 (3)|
| 22 | TABLE ACCESS FULL | TEST | 3423K| 104M| | 8775 (2)|
|* 23 | TABLE ACCESS FULL | RESULT | 3435K| 65M| | 23718 (2)|
| 24 | VIEW | PLATE | 21787 | 2851K| | 84 (2)|
|* 25 | FILTER | | | | | |
| 26 | TABLE ACCESS FULL | PLATE | 21787 | 574K| | 84 (2)|
|* 27 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 28 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 31 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID" IS NULL
OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+
*/ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND
"GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
3 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
5 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
6 - access("TEST_ID"="TEST_ID")
7 - access("ALIQUOT_ID"="ALIQUOT_ID")
8 - access("ALIQUOT_ID"="ALIQUOT_ID")
9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
11 - access("SAMPLE_ID"="SAMPLE_ID")
15 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
"U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR))
17 - access("SDG_ID"="SDG_ID")
18 - access("SDG_ID"="SDG_ID")
20 - access("SAMPLE_ID"="SAMPLE_ID")
23 - filter("NAME"='End result')
25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
27 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
28 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
30 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
- 'PLAN_TABLE' is old version
{code}
*tkprof 1*
{code}
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.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
SELECT sdu.u_crop_group,
sd.name as sdg_name,
ad.variety_name,
ad.batch_number,
a.name as aliquot_name,
sau.u_box_code as box_code,
sau.u_box_position as box_position,
t.name as test_name,
r.original_result,
plt.name as plate_name,
concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
lims_sys.sdg_user sdu,
lims_sys.sample sa,
lims_sys.sample_user sau,
lims_sys.aliquot a,
lims_sys.aliquot_user au,
lims_sys.test t,
lims_sys.result r,
lims_sys.plate plt,
lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
--AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 1.15 1.16 0 0 0 0
Fetch 1 8.53 16.10 227649 241266 0 500
total 3 9.68 17.27 227649 241266 0 500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
500 SORT ORDER BY (cr=241266 pr=227649 pw=0 time=16104631 us)
21311 FILTER (cr=241266 pr=227649 pw=0 time=16246749 us)
21311 HASH JOIN (cr=241266 pr=227649 pw=0 time=16225434 us)
17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr=374 pr=0 pw=0 time=69 us)
21311 HASH JOIN RIGHT OUTER (cr=240892 pr=227649 pw=0 time=16170607 us)
21895 VIEW PLATE (cr=316 pr=0 pw=0 time=43825 us)
21895 FILTER (cr=316 pr=0 pw=0 time=43823 us)
21895 TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=31 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311 HASH JOIN (cr=240576 pr=227649 pw=0 time=16106174 us)
21311 HASH JOIN (cr=133559 pr=121596 pw=0 time=9594130 us)
21311 HASH JOIN (cr=94323 pr=83281 pw=0 time=6917067 us)
21311 HASH JOIN (cr=86383 pr=75547 pw=0 time=5509672 us)
7776 HASH JOIN (cr=8134 pr=0 pw=0 time=285364 us)
7776 TABLE ACCESS BY INDEX ROWID SAMPLE (cr=572 pr=0 pw=0 time=27152 us)
7876 NESTED LOOPS (cr=377 pr=0 pw=0 time=488287 us)
99 HASH JOIN (cr=160 pr=0 pw=0 time=4168 us)
99 TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1209 us)
5719 TABLE ACCESS FULL SDG (cr=107 pr=0 pw=0 time=17 us)
7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=623 us)(object id 45990)
1079741 TABLE ACCESS FULL SAMPLE_USER (cr=7562 pr=0 pw=0 time=24 us)
3307948 TABLE ACCESS FULL ALIQUOT (cr=78249 pr=75547 pw=0 time=3331129 us)
3406836 TABLE ACCESS FULL ALIQUOT_USER (cr=7940 pr=7734 pw=0 time=556 us)
3406832 TABLE ACCESS FULL TEST (cr=39236 pr=38315 pw=0 time=3413192 us)
3406832 TABLE ACCESS FULL RESULT (cr=107017 pr=106053 pw=0 time=6848487 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
total 3 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
1 FAST DUAL (cr=0 pr=0 pw=0 time=3 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 3 1.15 1.16 0 0 0 1
Fetch 2 8.53 16.10 227649 241266 0 501
total 8 9.68 17.27 227649 241266 0 502
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 30 0.00 0.00 0 0 0 0
Execute 30 0.00 0.00 0 0 0 0
Fetch 30 0.00 0.00 0 40 0 10
total 90 0.00 0.00 0 40 0 10
Misses in library cache during parse: 0
3 user SQL statements in session.
30 internal SQL statements in session.
33 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Trace file compatibility: 10.01.00
Sort options: default
8 sessions in tracefile.
3 user SQL statements in trace file.
30 internal SQL statements in trace file.
33 SQL statements in trace file.
6 unique SQL statements in trace file.
633 lines in trace file.
23 elapsed seconds in trace file.
{code}explain 2
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 71 | 24779 | 857 (1)|
| 1 | SORT ORDER BY | | 71 | 24779 | 857 (1)|
|* 2 | FILTER | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | RESULT | 1 | 20 | 4 (0)|
| 4 | NESTED LOOPS | | 72 | 25128 | 856 (1)|
| 5 | NESTED LOOPS | | 70 | 23030 | 576 (1)|
|* 6 | HASH JOIN OUTER | | 69 | 20493 | 369 (1)|
| 7 | NESTED LOOPS | | 69 | 11247 | 285 (0)|
| 8 | NESTED LOOPS | | 69 | 10626 | 147 (0)|
| 9 | NESTED LOOPS | | 23 | 2438 | 78 (0)|
| 10 | NESTED LOOPS | | 23 | 2070 | 32 (0)|
| 11 | NESTED LOOPS | | 1 | 67 | 15 (0)|
| 12 | NESTED LOOPS | | 1 | 45 | 14 (0)|
|* 13 | TABLE ACCESS FULL | SDG_USER | 1 | 24 | 13 (0)|
| 14 | TABLE ACCESS BY INDEX ROWID| DWH_ABS_DETERMINATION | 1 | 21 | 1 (0)|
|* 15 | INDEX UNIQUE SCAN | PK_DWH_ABS_DETERMINATION | 1 | | 0 (0)|
| 16 | TABLE ACCESS BY INDEX ROWID | SDG | 1 | 22 | 1 (0)|
|* 17 | INDEX UNIQUE SCAN | PK_SDG | 1 | | 0 (0)|
| 18 | TABLE ACCESS BY INDEX ROWID | SAMPLE | 190 | 4370 | 17 (0)|
|* 19 | INDEX RANGE SCAN | FK_SAMPLE_SDG | 597 | | 2 (0)|
| 20 | TABLE ACCESS BY INDEX ROWID | SAMPLE_USER | 1 | 16 | 2 (0)|
|* 21 | INDEX UNIQUE SCAN | PK_SAMPLE_USER | 1 | | 1 (0)|
|* 22 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3 | 144 | 3 (0)|
|* 23 | INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | 2 (0)|
| 24 | TABLE ACCESS BY INDEX ROWID | ALIQUOT_USER | 1 | 9 | 2 (0)|
|* 25 | INDEX UNIQUE SCAN | PK_ALIQUOT_USER | 1 | | 1 (0)|
| 26 | VIEW | PLATE | 21787 | 2851K| 84 (2)|
|* 27 | FILTER | | | | |
| 28 | TABLE ACCESS FULL | PLATE | 21787 | 574K| 84 (2)|
|* 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | 0 (0)|
| 30 | TABLE ACCESS BY INDEX ROWID | TEST | 1 | 32 | 3 (0)|
|* 31 | INDEX RANGE SCAN | FK_TEST_ALIQUOT | 1 | | 2 (0)|
|* 32 | INDEX RANGE SCAN | FK_RESULT_TEST | 2 | | 2 (0)|
|* 33 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | 0 (0)|
|* 34 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | 0 (0)|
|* 35 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | 0 (0)|
|* 36 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID"
IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS
(SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS
(SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
3 - filter("NAME"='End result')
6 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
13 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
"U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR) AND
DECODE(:CROPCODE,(-1),'-1',"U_CROP_GROUP")=DECODE(:CROPCODE,(-1),'-1',:CROPCODE))
15 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
17 - access("SDG_ID"="SDG_ID")
19 - access("SDG_ID"="SDG_ID")
21 - access("SAMPLE_ID"="SAMPLE_ID")
22 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
23 - access("SAMPLE_ID"="SAMPLE_ID")
25 - access("ALIQUOT_ID"="ALIQUOT_ID")
27 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("ALIQUOT_ID"="ALIQUOT_ID")
32 - access("TEST_ID"="TEST_ID")
33 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
34 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
35 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
36 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
- 'PLAN_TABLE' is old version
tkprof 2
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:28:26 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.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
SELECT sdu.u_crop_group,
sd.name as sdg_name,
ad.variety_name,
ad.batch_number,
a.name as aliquot_name,
sau.u_box_code as box_code,
sau.u_box_position as box_position,
t.name as test_name,
r.original_result,
plt.name as plate_name,
concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
lims_sys.sdg_user sdu,
lims_sys.sample sa,
lims_sys.sample_user sau,
lims_sys.aliquot a,
lims_sys.aliquot_user au,
lims_sys.test t,
lims_sys.result r,
lims_sys.plate plt,
lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.45 0.87 0 0 0 0
Fetch 1 1.00 0.99 0 221420 0 500
total 3 1.46 1.86 0 221420 0 500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
500 SORT ORDER BY (cr=221420 pr=0 pw=0 time=992364 us)
21311 FILTER (cr=221420 pr=0 pw=0 time=1128970 us)
21311 TABLE ACCESS BY INDEX ROWID RESULT (cr=221420 pr=0 pw=0 time=1086345 us)
42623 NESTED LOOPS (cr=217549 pr=0 pw=0 time=30006317 us)
21311 NESTED LOOPS (cr=174880 pr=0 pw=0 time=809278 us)
21311 NESTED LOOPS (cr=110117 pr=0 pw=0 time=553538 us)
21311 HASH JOIN OUTER (cr=46182 pr=0 pw=0 time=319102 us)
21311 TABLE ACCESS BY INDEX ROWID ALIQUOT (cr=45866 pr=0 pw=0 time=193037 us)
29088 NESTED LOOPS (cr=39885 pr=0 pw=0 time=320084 us)
7776 NESTED LOOPS (cr=24267 pr=0 pw=0 time=156721 us)
7776 NESTED LOOPS (cr=937 pr=0 pw=0 time=78954 us)
99 NESTED LOOPS (cr=454 pr=0 pw=0 time=3826 us)
99 NESTED LOOPS (cr=253 pr=0 pw=0 time=2833 us)
99 TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1531 us)
99 TABLE ACCESS BY INDEX ROWID DWH_ABS_DETERMINATION (cr=200 pr=0 pw=0 time=956 us)
99 INDEX UNIQUE SCAN PK_DWH_ABS_DETERMINATION (cr=101 pr=0 pw=0 time=438 us)(object id 46965)
99 TABLE ACCESS BY INDEX ROWID SDG (cr=201 pr=0 pw=0 time=707 us)
99 INDEX UNIQUE SCAN PK_SDG (cr=101 pr=0 pw=0 time=330 us)(object id 46071)
7776 TABLE ACCESS BY INDEX ROWID SAMPLE (cr=483 pr=0 pw=0 time=16261 us)
7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=562 us)(object id 45990)
7776 TABLE ACCESS BY INDEX ROWID SAMPLE_USER (cr=23330 pr=0 pw=0 time=64710 us)
7776 INDEX UNIQUE SCAN PK_SAMPLE_USER (cr=15554 pr=0 pw=0 time=33728 us)(object id 46012)
21311 INDEX RANGE SCAN FK_ALIQUOT_SAMPLE (cr=15618 pr=0 pw=0 time=43423 us)(object id 45346)
21895 VIEW PLATE (cr=316 pr=0 pw=0 time=43833 us)
21895 FILTER (cr=316 pr=0 pw=0 time=21936 us)
21895 TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=37 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311 TABLE ACCESS BY INDEX ROWID ALIQUOT_USER (cr=63935 pr=0 pw=0 time=182479 us)
21311 INDEX UNIQUE SCAN PK_ALIQUOT_USER (cr=42624 pr=0 pw=0 time=99160 us)(object id 45386)
21311 TABLE ACCESS BY INDEX ROWID TEST (cr=64763 pr=0 pw=0 time=219096 us)
21311 INDEX RANGE SCAN FK_TEST_ALIQUOT (cr=42669 pr=0 pw=0 time=129354 us)(object id 46222)
21311 INDEX RANGE SCAN FK_RESULT_TEST (cr=42669 pr=0 pw=0 time=125893 us)(object id 45940)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
total 3 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
1 FAST DUAL (cr=0 pr=0 pw=0 time=6 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 2 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 2 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.01 0.00 0 0 2 0
Execute 3 0.45 0.87 0 0 0 1
Fetch 2 1.00 0.99 0 221420 0 501
total 8 1.46 1.87 0 221420 2 502
Misses in library cache during parse: 2
Misses in library cache during execute: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 43 0.01 0.00 0 0 12 0
Execute 128 0.00 0.01 0 0 0 0
Fetch 178 0.00 0.00 0 383 0 465
total 349 0.01 0.02 0 383 12 465
Misses in library cache during parse: 5
Misses in library cache during execute: 5
3 user SQL statements in session.
128 internal SQL statements in session.
131 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
3 user SQL statements in trace file.
128 internal SQL statements in trace file.
131 SQL statements in trace file.
19 unique SQL statements in trace file.
1352 lines in trace file.
287 elapsed seconds in trace file. -
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> -
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,
~ORAThe 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 lotHI i found the correct category
thanks -
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
Maybe you are looking for
-
24" iMac refurb - kernal panic after apple logo
I received a refurbished 24" C2D iMac on Friday and it seemed to be in perfect condition. Everything worked, and all of the updates were applied. Upon returning to the office on Monday, there was a kernal panic when awakening it. It also consistently
-
I can´t remember the security code to unblock my iPod touch and when I try to synchronize it with iTunes I can´t because it ask me to introduce the code that I don´t remember. In my iPod says that it is desactivated and I need to connect to iTunes...
-
After using my new iPhone 5 for a few months I tried to sync it to my computer but it said I had to wipe it first, I don't know if it means everything or just the music. Half of my music transferred to my iTunes library and the other half I can get t
-
Hi all, I need a possibility to <b>convert Web Reports</b> designed in WAD <b>into PDF</b>. SAP help portal says: 'You access BEx Web applications and reports in the portal. You can then convert these into PDF files and print them.' (http://help.sap.
-
Hi Friends, My case is I have customized a new company code in existing system. In that i made a mistake in ECCS level. I saved Company Code, Cross Company Code, ECCS Settings in one transport request. Now i want to transport only the Company Code, C