Explain plan - support latest Predicate columns
Will raptor support the predicate columns in explain plan? They are available in oracle 9.2.
I just added them.
-kris
Similar Messages
-
Explain plan cardinallity is way off compared to actual rows being returned
Database version 11.2.0.3
We have a small but rapidly growing datawarehouse which has OBIEE as its front end reporting tool. Our DBA has set up a automatic stats gathering method in OEM and we can see that it run and gathers stats on stale objects on a regular basis. So we know the statistics are upto date.
In checking some slow queries I can see that the cardinality being reported in explain plans is way off compared to what is actually being returned.
For example the actual number of rows returned are 8000 but the cardinality estimate is > 300,000.
Now as per an Oracle White paper(The Oracle Optimizer Explain the Explain Plan) having "multiple single column predicates on a single table" can affect cardinality estimates and in case of our query that is true. Here is the "WHERE Clause section" of the query
SQL> select D1.c1 as c1,
2 D1.c2 as c2,
3 D1.c3 as c3,
4 D1.c4 as c4,
5 D1.c5 as c5,
6 D1.c6 as c6,
7 D1.c7 as c7,
8 D1.c8 as c8,
9 D1.c9 as c9,
10 D1.c10 as c10,
11 D1.c11 as c11,
12 D1.c12 as c12,
13 D1.c13 as c13,
14 D1.c14 as c14,
15 D1.c15 as c15,
16 D1.c16 as c16
17 from (select D1.c4 as c1,
18 D1.c5 as c2,
19 D1.c3 as c3,
20 D1.c1 as c4,
21 D1.c6 as c5,
22 D1.c7 as c6,
23 D1.c2 as c7,
24 D1.c8 as c8,
25 D1.c9 as c9,
26 D1.c10 as c10,
27 D1.c9 as c11,
28 D1.c11 as c12,
29 D1.c2 as c13,
30 D1.c2 as c14,
31 D1.c12 as c15,
32 'XYZ' as c16,
33 ROW_NUMBER() OVER(PARTITION BY D1.c2, D1.c3, D1.c4, D1.c5, D1.c6, D1.c7, D1.c8, D1.c9, D1.c10, D1.c11, D1.c12 ORDER BY D1.c2 ASC, D1.c3 ASC, D1.c4 ASC, D1.c5 ASC, D1.c6 ASC, D1.c
ASC, D1.c8 ASC, D1.c9 ASC, D1.c10 ASC, D1.c11 ASC, D1.c12 ASC) as c17
34 from (select distinct D1.c1 as c1,
35 D1.c2 as c2,
36 'CHANNEL1' as c3,
37 D1.c3 as c4,
38 D1.c4 as c5,
39 D1.c5 as c6,
40 D1.c6 as c7,
41 D1.c7 as c8,
42 D1.c8 as c9,
43 D1.c9 as c10,
44 D1.c10 as c11,
45 D1.c11 as c12
46 from (select sum(T610543.GLOBAL1_EXCHANGE_RATE * case
47 when T610543.X_ZEB_SYNC_EBS_FLG = 'Y' then
48 T610543.X_ZEB_AIA_U_REVN_AMT
49 else
50 0
51 end) as c1,
52 T536086.X_ZEBRA_TERRITORY as c2,
53 T526821.LEVEL9_NAME as c3,
54 T526821.LEVEL1_NAME as c4,
55 T577698.PER_NAME_FSCL_YEAR as c5,
56 T577698.FSCL_QTR as c6,
57 T31796.X_ZEBRA_TERRITORY as c7,
58 T31796.X_OU_NUM as c8,
59 T664055.TERRITORY as c9,
60 T536086.X_OU_NUM as c10,
61 T526821.LEVEL4_NAME as c11
62 from W_INT_ORG_D T613144 /* Dim_ZEB_W_INT_ORG_D_POS_Client_Attr_Direct */,
63 W_ZEBRA_REGION_D T664055 /* Dim_ZEB_W_ZEBRA_REGION_D_POS_Client_Direct */,
64 W_DAY_D T577698 /* Dim_ZEB_W_DAY_D_Order_Invoice_Date */,
65 WC_PRODUCT_HIER_DH T526821 /* Dim_WC_PRODUCT_HIER_DH */,
66 W_PRODUCT_D T32069 /* Dim_W_PRODUCT_D */,
67 W_ORG_D T31796,
68 W_ORG_D T536086 /* Dim_ZEB_W_ORG_D_Reseller */,
69 W_ORDERITEM_TMP_F T610543 /* Fact_ZEB_W_ORDERITEM_F_Direct */
70 where (T610543.PR_OWNER_BU_WID = T613144.ROW_WID and
71 T577698.ROW_WID =
72 T610543.X_ZEB_AIA_TRXN_DT_WID and
73 T32069.ROW_WID = T526821.PROD_WID and
74 T32069.ROW_WID = T610543.ROOT_LN_PROD_WID and
75 T536086.ROW_WID = T610543.ACCNT_WID and
76 T31796.DATASOURCE_NUM_ID =
77 T610543.DATASOURCE_NUM_ID and
78 T31796.INTEGRATION_ID = T610543.VIS_PR_BU_ID and
79 T536086.DELETE_FLG = 'N' and
80 T610543.X_ZEB_DELETE_FLG = 'N' and
81 T613144.X_ZEB_REGION_WID = T664055.ROW_WID and
82 T577698.FSCL_DAY_OF_YEAR < 97 and
83 '2006' < T577698.PER_NAME_FSCL_YEAR and
84 T536086.X_OU_NUM <> '11073' and
85 T536086.X_ZEBRA_TERRITORY !=
86 'XX23' and
87 T536086.X_OU_NUM != '56791647728774' and
88 T536086.X_OU_NUM != '245395890' and
89 T536086.X_ZEBRA_TERRITORY !=
90 'STRATEGIC ACCTS 2' and
91 T526821.LEVEL2_NAME != 'Charges' and
92 T526821.LEVEL9_NAME != 'Unspecified' and
93 T536086.X_ZEBRA_TERRITORY !=
94 'XX1' and T536086.X_ZEBRA_TERRITORY !=
95 'XX2' and T536086.X_ZEBRA_TERRITORY !=
96 'XX3' and T536086.X_ZEBRA_TERRITORY !=
97 'XX4' and
98 (T536086.X_ZEBRA_TERRITORY in
99 ( ... In List of 22 values )) and
125 T32069.X_ZEB_EBS_PRODUCT_TYPE is null)
126 group by T31796.X_ZEBRA_TERRITORY,
127 T31796.X_OU_NUM,
128 T526821.LEVEL1_NAME,
129 T526821.LEVEL4_NAME,
130 T526821.LEVEL9_NAME,
131 T536086.X_OU_NUM,
132 T536086.X_ZEBRA_TERRITORY,
133 T577698.FSCL_QTR,
134 T577698.PER_NAME_FSCL_YEAR,
135 T664055.TERRITORY) D1) D1) D1
136 where (D1.c17 = 1)
137 /
Elapsed: 00:00:35.19
Execution Plan
Plan hash value: 3285002974
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2145M| 2123G| | 612K (1)| 03:03:47 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10012 | 2145M| 2123G| | 612K (1)| 03:03:47 | | | Q1,12 | P->S | QC (RAND) |
|* 3 | VIEW | | 2145M| 2123G| | 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
|* 4 | WINDOW NOSORT | | 2145M| 421G| | 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
| 5 | SORT GROUP BY | | 2145M| 421G| 448G| 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
| 6 | PX RECEIVE | | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,12 | PCWP | |
| 7 | PX SEND HASH | :TQ10011 | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,11 | P->P | HASH |
|* 8 | HASH JOIN BUFFERED | | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,11 | PCWP | |
| 9 | PX RECEIVE | | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,11 | PCWP | |
| 10 | PX SEND HASH | :TQ10009 | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | P->P | HASH |
| 11 | PX BLOCK ITERATOR | | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | PCWC | |
| 12 | TABLE ACCESS FULL | W_ORG_D | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | PCWP | |
| 13 | PX RECEIVE | | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,11 | PCWP | |
| 14 | PX SEND HASH | :TQ10010 | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,10 | P->P | HASH |
|* 15 | HASH JOIN BUFFERED | | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 16 | PX RECEIVE | | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10006 | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | P->P | BROADCAST |
| 18 | PX BLOCK ITERATOR | | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWC | |
| 19 | TABLE ACCESS FULL | W_ZEBRA_REGION_D | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWP | |
|* 20 | HASH JOIN | | 345K| 52M| | 1488 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 21 | JOIN FILTER CREATE | :BF0000 | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 22 | PX RECEIVE | | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 23 | PX SEND HASH | :TQ10007 | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | P->P | HASH |
| 24 | PX BLOCK ITERATOR | | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | PCWC | |
| 25 | TABLE ACCESS FULL | W_INT_ORG_D | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | PCWP | |
| 26 | PX RECEIVE | | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 27 | PX SEND HASH | :TQ10008 | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | P->P | HASH |
| 28 | JOIN FILTER USE | :BF0000 | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | PCWP | |
|* 29 | HASH JOIN BUFFERED | | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | PCWP | |
| 30 | JOIN FILTER CREATE | :BF0001 | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 31 | PX RECEIVE | | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 32 | PX SEND HASH | :TQ10004 | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | P->P | HASH |
| 33 | PX BLOCK ITERATOR | | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | PCWC | |
|* 34 | TABLE ACCESS FULL | W_ORG_D | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | PCWP | |
| 35 | PX RECEIVE | | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,08 | PCWP | |
| 36 | PX SEND HASH | :TQ10005 | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | P->P | HASH |
| 37 | JOIN FILTER USE | :BF0001 | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | PCWP | |
|* 38 | HASH JOIN BUFFERED | | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | PCWP | |
| 39 | PX RECEIVE | | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 40 | PX SEND HASH | :TQ10001 | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | P->P | HASH |
| 41 | PX BLOCK ITERATOR | | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | PCWC | |
|* 42 | TABLE ACCESS FULL | WC_PRODUCT_HIER_DH | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | PCWP | |
|* 43 | HASH JOIN | | 894K| 57M| | 1384 (2)| 00:00:25 | | | Q1,05 | PCWP | |
| 44 | JOIN FILTER CREATE | :BF0002 | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,05 | PCWP | |
| 45 | PX RECEIVE | | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,05 | PCWP | |
| 46 | PX SEND HASH | :TQ10002 | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | P->P | HASH |
| 47 | PX BLOCK ITERATOR | | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | PCWC | |
|* 48 | TABLE ACCESS FULL | W_PRODUCT_D | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | PCWP | |
| 49 | PX RECEIVE | | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,05 | PCWP | |
| 50 | PX SEND HASH | :TQ10003 | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | P->P | HASH |
| 51 | JOIN FILTER USE | :BF0002 | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | PCWP | |
|* 52 | HASH JOIN | | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | PCWP | |
| 53 | PX RECEIVE | | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,03 | PCWP | |
| 54 | PX SEND BROADCAST LOCAL| :TQ10000 | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | P->P | BCST LOCAL |
| 55 | PX BLOCK ITERATOR | | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | PCWC | |
|* 56 | TABLE ACCESS FULL | W_DAY_D | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | PCWP | |
| 57 | PX BLOCK ITERATOR | | 4801K| 215M| | 1199 (2)| 00:00:22 | 1 | 11 | Q1,03 | PCWC | |
|* 58 | TABLE ACCESS FULL | W_ORDERITEM_TMP_F | 4801K| 215M| | 1199 (2)| 00:00:22 | 1 | 44 | Q1,03 | PCWP | |
Note
- dynamic sampling used for this statement (level=5)
Statistics
498 recursive calls
2046 db block gets
1193630 consistent gets
74398 physical reads
0 redo size
655170 bytes sent via SQL*Net to client
11761 bytes received via SQL*Net from client
541 SQL*Net roundtrips to/from client
64 sorts (memory)
0 sorts (disk)
8090 rows processed
SQL>So my question is if, cardinality estimates are way off, is that an indicator that the explain plans being generated are sub-optimal?
Can you provide me with some tips or links to blog post or books on how I approach tuning such queries where cardinalities are not good?
Edited by: qqq on Apr 7, 2013 2:27 PMAs already asked in your other thread:
Please see the FAQ for how to post a tuning request and the information that you need to provide.
Part of that information is:
1. DDL for the table and indexes
2. The query being used
3. row counts for the table and for the predicates used in the query
4. info about stats. You did update the table and index stats didn't you?
5. The 'actual' execution plans.
An explain plan just shows what Oracle 'thinks' it is going to do. The actual plans show what Oracle actually 'did' do. Just because Oracle expected to save doesn't mean the savings were actually achieved.
When you post the plans use on the line before and on the line after to preserve formatting.
Your partial code is virtually unusable because of the missing conditions in the predicates. You need to use '!=' for 'not equals' if that's what those missing conditions are.
Please edit your post to use code tags, add the missing conditions and provide the other information needed for a tuning request. -
Time column of an explain plan
Hi,
I'm using Oracle version 10.2.0.3.0. I have 2 tables with 10 million records each. The DDL is as follows.
create table bigtable(col1 varchar2(20), col2 varchar2(20))
create table bigtablechild(col1 varchar2(20), col2 varchar(20))
bigtablechild.col1 is a foreign key to bigtable.col1. Below is the query and explain plan. Over several executions, the query runs for about 20 seconds before returning results. Could anyone please explain what the time column represents? It doesn't match the time it took to return results.
SQL> set autotrace on
SQL>
SQL> select b.col2
2 from bigtable a, bigtablechild b
3 where a.col1 = b.col1
4 and a.col1 = 'ABC6554';
COL2
XYZ6554
XYZ6554
XYZ6554
XYZ6554
XYZ6554
Execution Plan
Plan hash value: 4210396901
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 5 | 150 | 21538 (4)| 00:04:19 |
|* 1 | HASH JOIN | | 5 | 150 | 21538 (4)| 00:04:19 |
|* 2 | TABLE ACCESS FULL| BIGTABLE | 1 | 10 | 13124 (4)| 00:02:38 |
|* 3 | TABLE ACCESS FULL| BIGTABLECHILD | 5 | 100 | 8413 (5)| 00:01:41 |
Predicate Information (identified by operation id):
1 - access("A"."COL1"="B"."COL1")
2 - filter("A"."COL1"='ABC6554')
3 - filter("B"."COL1"='ABC6554')
Statistics
0 recursive calls
0 db block gets
93672 consistent gets
91845 physical reads
0 redo size
463 bytes sent via SQL*Net to client
396 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5 rows processedHi,
the values in the TIME column are calculated from cost using system I/O statistics. If dbms_stats.gather_system_stats has never been run, then these stats have default values which may be very far from the truth. In your case, the optimizer expects a single-block I/O read to take about 12 ms, while in reality it is closer to 1 ms, thus the discrepancy between the prediction and actual results.
In general, TIME column is not very helpful not just because of potentially incorrect I/O time estimates, but also because it is hard to predict how much data will be found in cash, so I would recommend not to pay too much attention to it (note, however, that A-time column, on the other hand, is extremely useful, but it's only available if rowsource statistics for the plan have been populated).
Best regards,
Nikolay -
Virtual column partitioning - explain plan takes lot of time.
I have some problem with table with partitioning based on virtual column.
Explain plan generates for some simple select 2-5 minutes,
but the same select but without part of where clausule generate in secounds.
In both query there is the same explain plan.
Could someone explain why?
Table:
CREATE TABLE "SUBSCRIPTION"
"CUSTOMER_ID" VARCHAR2(100 BYTE),
"IDENT_SOURCE_ID" VARCHAR2(20 BYTE),
"ACCOUNT_ID" VARCHAR2(100 BYTE),
"MSISDN" VARCHAR2(500 BYTE),
"IMSI" VARCHAR2(500 BYTE),
"SIM" VARCHAR2(500 BYTE),
"IMEI" VARCHAR2(500 BYTE),
"MEID" VARCHAR2(15 BYTE),
"EMAIL" VARCHAR2(100 BYTE),
"TELCOOP" VARCHAR2(1000 BYTE),
"MSISDN_TYPE" VARCHAR2(20 BYTE),
"GSM" NUMBER(1,0),
"CDMA" NUMBER(1,0),
"VALID_FROM" DATE,
"VALID_TO" DATE,
"MSISDN_HASH" NUMBER(3,0) GENERATED ALWAYS AS (MOD(TO_NUMBER(NVL2(RTRIM(TRANSLATE(NVL(SUBSTR("MSISDN",-3),NVL("MSISDN",'err')),'123456789','000000000'),'0'),'-1',NVL(SUBSTR("MSISDN",-3),"MSISDN"))),125)) VIRTUAL VISIBLE, --generali mod from 3 last digits of msisdn
) PARTITION BY LIST ( "MSISDN_HASH" )
PARTITION "PCHR" VALUES ( -1 )
PARTITION "P000" VALUES ( 0 )
PARTITION "P001" VALUES ( 1 )
... and so on till...
PARTITION "P124" VALUES (124)
PARALLEL 4;
Slow select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Fast select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86--Slower select trace:
Registered qb: SEL$1 0xf4ea2a20 (PARSER)
QUERY BLOCK SIGNATURE
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SPM: statement not found in SMB
SPM: statement not a candidate for auto-capture
Dynamic sampling level auto-adjusted from 6 to 6
Automatic degree of parallelism (ADOP)
Automatic degree of parallelism is disabled: Parameter.
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
OPTIMIZER INFORMATION
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
OJPPD - old-style (non-cost-based) JPPD
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
OST - old style star transformation
ST - new (cbqt) star transformation
CNT - count(col) to count(*) transformation
JE - Join Elimination
JF - join factorization
SLP - select list pruning
DP - distinct placement
qb - query block
LB - leaf blocks
DK - distinct keys
LB/K - average number of leaf blocks per key
DB/K - average number of data blocks per key
CLUF - clustering factor
NDV - number of distinct values
Resp - response cost
Card - cardinality
Resc - resource cost
NL - nested loops (join)
SM - sort merge (join)
HA - hash (join)
CPUSPEED - CPU Speed
IOTFRSPEED - I/O transfer speed
IOSEEKTIM - I/O seek time
SREADTIM - average single block read time
MREADTIM - average multiblock read time
MBRC - average multiblock read count
MAXTHR - maximum I/O system throughput
SLAVETHR - average slave I/O throughput
dmeth - distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
128: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
256: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
pgamax_size = 1258280 KB
parallel_query_default_dop = 32
db_file_multiblock_read_count = 16
Bug Fix Control Environment
PARAMETERS IN OPT_PARAM HINT
Column Usage Monitoring is ON: tracking level = 1
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
OBYE: Considering Order-by Elimination from view SEL$1 (#0)
Order-by elimination (OBYE)
OBYE: OBYE bypassed: no order by to eliminate.
CVM: Considering view merge in query block SEL$1 (#0)
query block SEL$1 (#0) unchanged
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
SU: Considering subquery unnesting in query block SEL$1 (#0)
Subquery Unnest (SU)
SJC: Considering set-join conversion in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: not performed
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
PM: PM bypassed: Outer query contains no views.
PM: PM bypassed: Outer query contains no views.
query block SEL$1 (#0) unchanged
FPD: Considering simple filter push in query block SEL$1 (#0)
"SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
try to generate transitive predicate from check constraints for query block SEL$1 (#0)
finally: "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
apadrv-start sqlid=12053738773107497463
call(in-use=8176, alloc=32712), compile(in-use=114912, alloc=116848), execution(in-use=175432, alloc=178928)
Peeked values of the binds in SQL statement
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "SUBSCRIPTION"."CUSTOMER_ID" "CUSTOMER_ID","SUBSCRIPTION"."IDENT_SOURCE_ID" "IDENT_SOURCE_ID","SUBSCRIPTION"."ACCOUNT_ID" "ACCOUNT_ID","SUBSCRIPTION"."MSISDN" "MSISDN","SUBSCRIPTION"."IMSI" "IMSI","SUBSCRIPTION"."SIM" "SIM","SUBSCRIPTION"."IMEI" "IMEI","SUBSCRIPTION"."MEID" "MEID","SUBSCRIPTION"."EMAIL" "EMAIL","SUBSCRIPTION"."TELCOOP" "TELCOOP" FROM "DBIDENT2"."SUBSCRIPTION" "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
kkoqbc: optimizing query block SEL$1 (#0)
call(in-use=8320, alloc=32712), compile(in-use=115880, alloc=116848), execution(in-use=175432, alloc=178928)
kkoqbc-subheap (create addr=0x2b24ebece950)
QUERY BLOCK TEXT
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
QUERY BLOCK SIGNATURE
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=0 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEEDNW: 714 millions instructions/sec (default is 100)
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
MBRC: -1 blocks (default is 16)
BASE STATISTICAL INFORMATION
Table Stats::
Table: SUBSCRIPTION Alias: SUBSCRIPTION Partition [87]
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
Index Stats::
Index: SUBSCRIPTION_NDX_ACCID Col#: 3
LVLS: 3 #LB: 121036 #DK: 9767936 LB/K: 1.00 DB/K: 1.00 CLUF: 13921256.00
Index: SUBSCRIPTION_NDX_CUSID Col#: 1 2 18
LVLS: 3 #LB: 142123 #DK: 24665396 LB/K: 1.00 DB/K: 1.00 CLUF: 24842146.00
Index: SUBSCRIPTION_NDX_EMAIL Col#: 9
LVLS: 2 #LB: 8365 #DK: 1361827 LB/K: 1.00 DB/K: 1.00 CLUF: 1361798.00
Index: SUBSCRIPTION_NDX_EXT1 Col#: 19
LVLS: 2 #LB: 65756 #DK: 67792 LB/K: 1.00 DB/K: 80.00 CLUF: 5446485.00
Index: SUBSCRIPTION_NDX_IMEI Col#: 7
LVLS: 2 #LB: 44539 #DK: 9199616 LB/K: 1.00 DB/K: 1.00 CLUF: 10413439.00
Index: SUBSCRIPTION_NDX_IMSI Col#: 5
LVLS: 3 #LB: 92914 #DK: 12846080 LB/K: 1.00 DB/K: 1.00 CLUF: 23472821.00
Index: SUBSCRIPTION_NDX_MEID Col#: 8
LVLS: 1 #LB: 132 #DK: 12585 LB/K: 1.00 DB/K: 1.00 CLUF: 18419.00
Index: SUBSCRIPTION_NDX_MSISDN Col#: 4 PARTITION [87]
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
Index: SUBSCRIPTION_NDX_SIM Col#: 6
LVLS: 2 #LB: 88153 #DK: 13169664 LB/K: 1.00 DB/K: 1.00 CLUF: 24727298.00
Index: SUBSCRIPTION_NDX_SRCID Col#: 2 17
LVLS: 2 #LB: 81729 #DK: 4 LB/K: 20432.00 DB/K: 257314.00 CLUF: 1029257.00
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:34:53.283
** Performing dynamic sampling initial checks. **
Column (#14):
NewDensity:0.000020, OldDensity:0.000366 BktCnt:254, PopBktCnt:22, PopValCnt:1, NDV:46252
Column (#14):
NewDensity:0.000163, OldDensity:0.000378 BktCnt:254, PopBktCnt:12, PopValCnt:1, NDV:5852
Column (#14): VALID_FROM( Part#: 87
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#14): VALID_FROM(
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#4):
NewDensity:0.000000, OldDensity:0.000000 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:9730048
Column (#4):
NewDensity:0.000013, OldDensity:0.000033 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:74848
Column (#4): MSISDN( Part#: 87
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Column (#4): MSISDN(
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
** Dynamic sampling initial checks returning TRUE (level = 6).
*** 2012-06-12 12:34:53.284
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("SUBSCRIPTION") FULL("SUBSCRIPTION") NO_PARALLEL_INDEX("SUBSCRIPTION") */ 1 AS C1, CASE WHEN "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss') THEN 1 ELSE 0 END AS C2 FROM "DBIDENT2"."SUBSCRIPTION" SAMPLE BLOCK (1.153706 , 1) SEED (1) "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) SAMPLESUB
*** 2012-06-12 12:36:44.452
** Executed dynamic sampling query:
level : 6
sample pct. : 1.153706
total partitions : 1
partitions for sampling : 1
actual sample size : 342182
filtered sample card. : 0
orig. card. : 218104
block cnt. table stat. : 11008
block cnt. for sampling: 11008
max. sample block cnt. : 128
sample block cnt. : 127
min. sel. est. : 0.00001260
** Not using dynamic sampling for single table sel. or cardinality.
DS Failed for : ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Column (#21):
NewDensity:0.002912, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:126, NDV:126
Column (#21): MSISDN_HASH( Part#: 87
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#21): MSISDN_HASH(
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#1):
NewDensity:0.000000, OldDensity:0.000241 BktCnt:254, PopBktCnt:31, PopValCnt:2, NDV:9768960
Column (#1):
NewDensity:0.000009, OldDensity:0.000250 BktCnt:254, PopBktCnt:36, PopValCnt:3, NDV:99208
Column (#1): CUSTOMER_ID( Part#: 87
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#1): CUSTOMER_ID(
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#2):
NewDensity:0.000639, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:3, NDV:3
Column (#2):
NewDensity:0.000786, OldDensity:0.000002 BktCnt:13365, PopBktCnt:13365, PopValCnt:3, NDV:3
Column (#2): IDENT_SOURCE_ID( Part#: 87
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
Column (#2): IDENT_SOURCE_ID(
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
ColGroup (#1, Index) SUBSCRIPTION_NDX_CUSID
Col#: 1 2 18 CorStregth: -1.00
ColGroup (#2, Index) SUBSCRIPTION_NDX_SRCID
Col#: 2 17 CorStregth: -1.00
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
kkofmx: index filter:"SUBSCRIPTION"."MSISDN_HASH"=86
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Access Path: index (AllEqRange)
Index: SUBSCRIPTION_NDX_MSISDN
resc_io: 6.00 resc_cpu: 36840
ix_sel: 0.000013 ix_sel_with_filters: 0.000013
***** Logdef predicate Adjustment ******
Final IO cst 0.00 , CPU cst 2300.00
***** End Logdef Adjustment ******
Cost: 6.01 Resp: 6.01 Degree: 1
Best:: AccessPath: IndexRange
Index: SUBSCRIPTION_NDX_MSISDN
Cost: 6.01 Degree: 1 Resp: 6.01 Card: 2.75 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Best so far: Table#: 0 cost: 6.0051 card: 2.7487 bytes: 291
****** Recost for parallel table scan *******
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:36:44.454
** Performing dynamic sampling initial checks. **
** TABLE SUBSCRIPTION Alias: SUBSCRIPTION : reused cached dynamic sampling result (failure).
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
Best:: AccessPath: TableScan
Cost: 672.42 Degree: 4 Resp: 672.42 Card: 2.75 Bytes: 97
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Join order aborted: cost > best plan cost
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:2000
Number of join permutations tried: 1
Enumerating distribution method (advanced)
Trying or-Expansion on query block SEL$1 (#0)
Transfer Optimizer annotations for query block SEL$1 (#0)
id=0 frofkks[i] (index start key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofkke[i] (index stop key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofand predicate="SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
Final cost for query block SEL$1 (#0) - All Rows Plan:
Best join order: 1
Cost: 6.0051 Degree: 1 Card: 3.0000 Bytes: 291
Resc: 6.0051 Resc_io: 6.0000 Resc_cpu: 43740
Resp: 6.0051 Resp_io: 6.0000 Resc_cpu: 43740
kkoqbc-subheap (delete addr=0x2b24ebece950, in-use=21280, alloc=32840)
kkoqbc-end:
call(in-use=252920, alloc=343912), compile(in-use=129048, alloc=133000), execution(in-use=192248, alloc=195240)
kkoqbc: finish optimizing query block SEL$1 (#0)
apadrv-end
call(in-use=252920, alloc=343912), compile(in-use=129960, alloc=133000), execution(in-use=192248, alloc=195240)
Starting SQL statement dump
user_id=115 user_name=xxx module=SQL*Plus action=
sql_id=afjvvjmx6tqgr plan_hash_value=1672204165 problem_type=3
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
sql_text_length=266
sql=explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH2
sql=4:MI:SS')
----- Explain Plan Dump -----
----- Plan Table -----
============
Plan Table
============
-----------------------------------------------------------------------------------------------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------+
| 0 | SELECT STATEMENT | | | | 6 | | | |
| 1 | PARTITION LIST SINGLE | | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID | SUBSCRIPTION | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 3 | INDEX RANGE SCAN | SUBSCRIPTION_NDX_MSISDN| 3 | | 3 | 00:00:01 | 88 | 88 |
-----------------------------------------------------------------------------------------------------------------------+
Predicate Information:
2 - filter("VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
3 - access("MSISDN"='600600600')
Content of other_xml column
===========================
nodeid/pflags: 1 1 db_version : 11.2.0.2
parse_schema : xxx
plan_hash : 1672204165
plan_hash_2 : 1960934971
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('optimizer_dynamic_sampling' 6)
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_RS_ASC(@"SEL$1" "SUBSCRIPTION"@"SEL$1" ("SUBSCRIPTION"."MSISDN"))
END_OUTLINE_DATA
Query Block Registry:
SEL$1 0xf4ea2a20 (PARSER) [FINAL]
call(in-use=259392, alloc=343912), compile(in-use=170344, alloc=270888), execution(in-use=344120, alloc=346656)
End of Optimizer State Dump
Dumping Hints
=============
====================== END SQL Statement Dump ======================
Edited by: user3754081 on 2012-06-12 08:07 -
Weird explain plan on multi-level structured XmlType column
Hello,
am running an explain on the follwing query on 11.2.0.2:
SELECT
T1.EVENT_ID,
ACTION_SUB_ID,
PARAM_KEY,
PARAM_VALUE,
TO_DATE('2013-12-10', 'YYYY-MM-DD')
FROM T_C_RMP_MNTRNG_XML_FULL_IL ,
XMLTABLE('/monitoring' PASSING XML_CONTENT COLUMNS
EVENT_ID VARCHAR2(4000) PATH 'eventId',
ACTIONS XMLTYPE PATH 'action'
) T1,
XMLTABLE('/action' PASSING T1.ACTIONS COLUMNS
ACTION_SUB_ID NUMBER(10,0) PATH 'actionSubId',
PARAMS xmltype PATH 'param'
) T2,
XMLTABLE('/param' PASSING T2.params columns
PARAM_KEY VARCHAR2(4000) PATH 'key',
PARAM_VALUE VARCHAR2(1000) PATH 'value'
) T3
WHERE MESSAGE_ID = 4972102 ;
Although MESSAGE_ID is the primary key of T_C_RMP_MNTRNG_XML_FULL_IL and thus there is only one record matching the condition, I get an explain plan with huge costs, 500MB of data and an estimated 10 hour runtime:
PLAN_TABLE_OUTPUT
Plan hash value: 4011854835
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 223K| 489M| 3111K (1)| 10:22:17 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 223K| 489M| 3111K (1)| 10:22:17 |
| 3 | NESTED LOOPS | | 140K| 11M| 1678 (1)| 00:00:21 |
|* 4 | INDEX RANGE SCAN | X1B | 1 | 53 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| T_OR_MON_ACTION | 140K| 4542K| 1675 (1)| 00:00:21 |
PLAN_TABLE_OUTPUT
|* 6 | INDEX RANGE SCAN | X3 | 140K| | 4 (25)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | X4G | 4083 | | 22 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION_PARAM | 2 | 4428 | 52 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("MESSAGE_ID"=4972102)
6 - access("SYS_ALIAS_0"."NESTED_TABLE_ID"="T_C_RMP_MNTRNG_XML_FULL_IL"."SYS_NC0001200013$")
7 - access("NESTED_TABLE_ID"="SYS_ALIAS_0"."SYS_NC0000500006$")
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement (level=2)
When I run the query, the result comes back within 0.3 seconds.
Why is the explain plan off like that?
Is this just the way it is, or is there something going wrong here?This is my table create statement:
CREATE TABLE QQRCSBI0.T_C_RMP_MNTRNG_XML_FULL_IL (
MESSAGE_ID NUMBER(22,0) NOT NULL ENABLE,
XML_EVAL_ID NUMBER(22,0),
VIN7 VARCHAR2(7 BYTE),
FLEET_ID VARCHAR2(50 BYTE),
CSC_SW_VERSION VARCHAR2(100 BYTE),
RECEIVED DATE,
XML_CONTENT SYS.XMLTYPE ,
DWH_LM_TS_UTC DATE NOT NULL ENABLE,
CONSTRAINT PK_C_RMP_MNTRNG_XML_FULL_IL5 PRIMARY KEY (MESSAGE_ID)
) NOLOGGING TABLESPACE CATALOG
VARRAY "XML_CONTENT"."XMLDATA"."ACTION" STORE AS TABLE "T_OR_MON_ACTION" (
NOLOGGING TABLESPACE "CATALOG"
VARRAY "PARAM" STORE AS TABLE "T_OR_MON_ACTION_PARAM" (
NOLOGGING TABLESPACE "CATALOG"
) RETURN AS LOCATOR
) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://mydomain.com/csc_monitoring_session.xsd" ELEMENT "monitoring";
I set all default table names in the schema to blank and registered the schema with genTables=false.
I am still running into problems retrieving the 3rd level T_OR_MON_ACTION_PARAM data. The query just crashes after a while because it is running out of either TEMP space or UNDO space (it keeps changing). I'll take a step back to re-evaluate and post another thread about that in a bit I guess...
You said "SQL*Plus explain plan, goes most of the time bananas" - is there a difference in what client (SqlPlus or SqlDeveloper) I use to get the explain plan? I thought the plan was generated by the DB and the clients just display the result, and the only difference is the way the clients display the plan?! -
What is the significance of "cost" column in explain plan
Hi,
Can anyone explain what is the meaning of the values which we get in the cost column in the explain plan..For Ex : Cost : 4500 . What does this value mean...and is it measured in which form of units...i mean seconds,nanoseconds etckingfisher,
Ok one more link for you but I shall quote the text also here,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i82005
The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory.
And few paragraphs down,
13.4.1.3.3 Cost
The cost represents units of work or resource used. The query optimizer uses disk I/O, CPU usage, and memory usage as units of work. So, the cost used by the query optimizer represents an estimate of the number of disk I/Os and the amount of CPU and memory used in performing an operation. The operation can be scanning a table, accessing rows from a table by using an index, joining two tables together, or sorting a row set. The cost of a query plan is the number of work units that are expected to be incurred when the query is executed and its result produced.
The access path determines the number of units of work required to get data from a base table. The access path can be a table scan, a fast full index scan, or an index scan. During table scan or fast full index scan, multiple blocks are read from the disk in a single I/O operation. Therefore, the cost of a table scan or a fast full index scan depends on the number of blocks to be scanned and the multiblock read count value. The cost of an index scan depends on the levels in the B-tree, the number of index leaf blocks to be scanned, and the number of rows to be fetched using the rowid in the index keys. The cost of fetching rows using rowids depends on the index clustering factor. See "Assessing I/O for Blocks, not Rows".
The join cost represents the combination of the individual access costs of the two row sets being joined, plus the cost of the join operation.
Now I guess if you read this part, it should be pretty clear what cost is.Cost is an evlaution of the resource that is estimated by Oracle for every step incurred in the uery execution.There are no of steps and each may involve doing IO,consuming CPU and/or using memory.Cost is a factor which oracle uses combining all of these 3 (depending on the version) together to propose the work done or expected to be done in exeuting a query.So this actualy should represent the time spent exactly on each and every step.That's what the objective frm cost is.But at the moment,this is not there.There amy be a situation that cost is shown as very high but query is working fine.There are woraround which can bring the cost down for example using and tweaking optimizer_index_cost_adj parameter , we can propose oracle regarding our indexes and it may pick up lesser cost evaluation.What is mentioned is that this model is becoming more and more mature and in the next releases, we may see that cost is representing exactly the time that we would spend inthe query.At the moment,its not there.So as Chris mentioned,Tuning for low cost only is not a good way.
I suggest you grab a copy of JL's book.He has explained it much better in his book.
Hope I said some thing useful.
Aman.... -
Invalid column name when executing explain plan
SQL Developer version 4.0, SQL Worksheet, Windows 2000, Database 9.2.0.6.
When attempted to run a explain plan on a simple two table join query, it generates error invalid column name. Removed aliases and simplify query to one table row count, and still get the same error. Even tried the schema owner and got the same error.
I decided to check the explain plan table and found out that it was from an older version. Recreated the explain plan table and was able to run the explain plan.
I'm just posting this in the event somebody else runs into the same problem.This was fixed in the 4.1 or 1215 build. Please update by downloading or check for updates.
-thanks
kris -
Understanding the COST column of an explain plan
Hello,
I executed the following query, and obtained the corresponding explain plan:
select * from isis.clas_rost where cour_off_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 2 10 1540
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 2 10 1540
INDEX RANGE SCAN ISIS CLAS_ROST_N2 1 10
I don't understand how these cost values add up. What is the significance of the cost in each row of the explain plan output?
By comparison, here is another plan output for the following query:
select * from isis.clas_rost where clas_rost_# = 28
Description COST Cardinality Bytes
SELECT STATEMENT, GOAL = FIRST_ROWS 1 1 154
TABLE ACCESS BY INDEX ROWID ISIS CLAS_ROST 1 1 154
INDEX UNIQUE SCAN ISIS CLAS_ROST_U1 1 1
Thanks!For the most part, you probably want to ignore the cost column. The cardinality column is generally what you want to pay attention to.
Ideally, the cost column is Oracle's estimate of the amount of work that will be required to execute a query. It is a unitless value that attempts to combine the cost of I/O and CPU (depending on the Oracle version and whether CPU costing is enabled) and to scale physical and logical I/O appropriately). As a unitless number, it doesn't really relate to something "real" like the expected number of buffer gets. It is also determined in part by initialization parameters,session settings, system statistics, etc. that may artificially increase or decrease the cost of certain operations.
Beyond that, however, cost is problematic because it is only as accurate as the optimizer's estimates. If the optimizer's estimates are accurate, that implies that the cost is reasonably representative (in the sense that a query with a cost of 200 will run in less time than a query with a cost of 20000). But if you're looking at a query plan, it's generally because you believe there may be a problem which means that you are inherently suspicious that some of the optimizer's estimates are incorrect. If that's the case, you should generally distrust the cost.
Justin -
Explain Plan doesn't show predicates.
Not sure what I'm not doing correctly but I don't see predicates in my explain plan. I'm using 1.1.2.25 and 9.2.0.5 Ent Ed with optimizer = choose. my compatible param is at 8.1.0 though, could that be the problem?
I can't say that I've ever seen the predicates in sql plus.
-
Explain plan window, "operation" column is very narrow in 2.1 EA2
When widened, it becomes narrow in next attempt to get an explain plan.
Hi Raghu,
SQL Dev 2.1 Prod.
A simple way to replicate this issue is :
- Invoke an execution plan for query against partitioned table
The execution plan gets narrowed every time partition start and partition stop column appear.
And execution plan against non-partitioned table will re-adjust the column width to its preserved size.
Regards,
Buntoro -
Explain plan needs resize columns best-fit
Is there an easy way to resize columns in the explain plan grid? They are difficult to resize if the values in them are long, especially the access and filter columns at the end.
There is only one way to resize these right now (and thats the one you are using).
-
:Z in predicate section of explain plan
Hi Friends,
What is the meaning of :Z in the predicate section of execution plan of a query ? I didnt understand it .
Also how do i get the execution plan to format properly?? Earlier using code it would get formatted properly.
create table table_x nologging as
select /*+ parallel(a,4) full(a,4) */
ban, subscriber_no , soc PP, effective_date , expiration_date
from table_a a
where service_type = 'P'
and soc = 'SDDVRP'
and effective_date <= sysdate
and (expiration_date > sysdate or expiration_date is null)
PLANS FROM CURSOR
SQL_ID fp0591aupqpwd, child number 0
Plan hash value: 679415194
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | CREATE TABLE STATEMENT | | | | 291K| | | | | |
| 1 | LOAD AS SELECT | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 7 | 315 | 291K| | | Q1,00 | P->S | QC (RAND) |
| 4 | PX BLOCK ITERATOR | | 7 | 315 | 291K| 1 | 97 | Q1,00 | PCWC | |
|* 5 | TABLE ACCESS FULL | table_a | 7 | 315 | 291K| 1 | 97 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
5 - access(:Z>=:Z AND :Z<=:Z)
filter(("SERVICE_TYPE"='P' AND "SOC"='SDDVRP' AND "EFFECTIVE_DATE"<=SYSDATE@! AND
("EXPIRATION_DATE">SYSDATE@! OR "EXPIRATION_DATE" IS NULL)))Hi Jonathan,
Thanks for explaining that, i understood it now .
Below is the format for explain plan using your suggestion. Seems it didnt work or i misunderstood your suggestions.
Also for some reason i dont see any preview option to see the output
<pre>
Plan hash value: 679415194
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | CREATE TABLE STATEMENT | | | | 291K| | | | | |
| 1 | LOAD AS SELECT | | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 7 | 315 | 291K| | | Q1,00 | P->S | QC (RAND) |
| 4 | PX BLOCK ITERATOR | | 7 | 315 | 291K| 1 | 97 | Q1,00 | PCWC | |
|* 5 | TABLE ACCESS FULL | table_a | 7 | 315 | 291K| 1 | 97 | Q1,00 | PCWP | |
</pre> -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Oracle not using its own explain plan
When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
2 /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
2 INTO
3 dt_test_bvpeek
4 SELECT
5 rownum,
6 CASE
7 WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
8 1
9 ELSE
10 MOD(rownum, 5)
11 END
12 END
13 FROM
14 dual
15 CONNECT BY
16 LEVEL <= 100000
17 /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
2 /
COUNT(*) COL1
80000 1
20000 4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
2 /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 78728 | 538K| 82 (52)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 | 538K| 82 (52)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 4
8 /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 21027 | 143K| 74 (21)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK | 21027 | 143K| 74 (21)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | DT_TEST_BVPEEK_I1 | 21077 | | 29 (28)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
2 /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David -
Query Performance and reading an Explain Plan
Hi,
Below I have posted a query that is running slowly for me - upwards of 10 minutes which I would not expect. I have also supplied the explain plan. I'm fairly new to explain plans and not sure what the danger signs are that I should be looking out for.
I have added indexes to these tables, a lot of which are used in the JOIN and so I expected this to be quicker.
Any help or pointers in the right direction would be very much appreciated -
SELECT a.lot_id, a.route, a.route_rev
FROM wlos_owner.tbl_current_lot_status_dim a, wlos_owner.tbl_last_seq_num b, wlos_owner.tbl_hist_metrics_at_op_lkp c
WHERE a.fw_ver = '2'
AND a.route = b.route
AND a.route_rev = b.route_rev
AND a.fw_ver = b.fw_ver
AND a.route = c.route
AND a.route_rev = c.route_rev
AND a.fw_ver = c.fw_ver
AND a.prod = c.prod
AND a.lot_type = c.lot_type
AND c.step_seq_num >= a.step_seq_num
PLAN_TABLE_OUTPUT
Plan hash value: 2447083104
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 333 | 33633 | 1347
(8)| 00:00:17 |
|* 1 | HASH JOIN | | 333 | 33633 | 1347
(8)| 00:00:17 |
|* 2 | HASH JOIN | | 561 | 46002 | 1333
(7)| 00:00:17 |
|* 3 | TABLE ACCESS FULL| TBL_CURRENT_LOT_STATUS_DIM | 11782 | 517K| 203
(5)| 00:00:03 |
PLAN_TABLE_OUTPUT
|* 4 | TABLE ACCESS FULL| TBL_HIST_METRICS_AT_OP_LKP | 178K| 6455K| 1120
(7)| 00:00:14 |
|* 5 | TABLE ACCESS FULL | TBL_LAST_SEQ_NUM | 8301 | 154K| 13
(16)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND
"A"."FW_VER"=TO_NUMBER("B"."FW_VER"))
2 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV" AND
"A"."FW_VER"="C"."FW_VER" AND "A"."PROD"="C"."PROD" AND "A"."LOT_T
YPE"="C"."LOT_TYPE")
filter("C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
3 - filter("A"."FW_VER"=2)
PLAN_TABLE_OUTPUT
4 - filter("C"."FW_VER"=2)
5 - filter(TO_NUMBER("B"."FW_VER")=2)
24 rows selected.Guys thank you for your help.
I changed the type of the offending column and the plan looks a lot better and results seem a lot quicker.
However I have added to my SELECT, quite substantially, and have a new explain plan.
There are two sections in particular that have a high cost and I was wondering if you seen anything inherently wrong or can explain more fully what the PLAN_TABLE_OUTPUT descriptions are telling me - in particular
INDEX FULL SCAN
PLAN_TABLE_OUTPUT
Plan hash value: 3665357134
| Id | Operation | Name | Rows
| Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | |
4 | 316 | 52 (2)| 00:00:01 |
|* 1 | VIEW | |
4 | 316 | 52 (2)| 00:00:01 |
| 2 | WINDOW SORT | |
4 | 600 | 52 (2)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID | TBL_HIST_METRICS_AT_OP_LKP |
1 | 71 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | |
4 | 600 | 51 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 7
5 | 5925 | 32 (0)| 00:00:01 |
|* 6 | INDEX FULL SCAN | UNIQUE_LAST_SEQ | 8
9 | 2492 | 10 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| TBL_CURRENT_LOT_STATUS_DIM |
PLAN_TABLE_OUTPUT
1 | 51 | 1 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | TBL_CUR_LOT_STATUS_DIM_IDX1 |
1 | | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | TBL_HIST_METRIC_AT_OP_LKP_IDX1 | 2
9 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter("SEQ"=1)
3 - filter("C"."FW_VER"=2 AND "A"."PROD"="C"."PROD" AND "A"."LOT_TYPE"="C"."L
OT_TYPE" AND
"C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
6 - access("B"."FW_VER"=2)
filter("B"."FW_VER"=2)
PLAN_TABLE_OUTPUT
8 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND "A
"."FW_VER"=2)
9 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV")
Maybe you are looking for
-
How to download Youtube to Realplayer when "Download" tab no longer appears?
Using the newly-installed Firefox 5, the "Download" tab no longer pops up at the upper right of the video screen as it used to when using the earlier version. How can this be corrected? Alternatively, can the oder version of Firefox be reinstalled?
-
Is there a known problem with NOT IN operator? The following statement returns "no rows selected" message SELECT col_a FROM tab_a WHERE col_a NOT IN ( SELECT col_b FROM tab_b); while the following two statements both return the expected result SELECT
-
How to know onhand quantity at a selected date
Hi, is there a concurrent ( or a PLSQL package ) which could give the onhand quantity of an item in storage at a given date . thanks.
-
Webservices for the ERM in SAP GRC AC 5.3.
Hello, I want to know where I can find all the webservices for the ERM in SAP GRC AC 5.3. Best Regards.
-
Liquify not working please help
When I open any image at all liquify will not work on them. The brush basicall picks up the whole image and moves it instead of reconstructing what I want to on the image. What is wrong? I have CS6