Explain Plan is disabled - why?
Hi
I was using SqlDeveloper 1.0 and had no problems using the Explain Plan feature. Now I upgraded to 1.1 (did not migrate settings) and now the explain plan button is always greyed out. Am I missing something to enable the explain plan feature?
Thanks
Are all the buttons grayed out on the worksheet or just the explain plan button? If you look at your worksheet, is the drop list on the right hand side populated? i.e does it display your user connection? If not, select your connection in the drop kist and the icons will change from gray to available.
You say in your message that you upgraded to 1.1. I assume you did a fresh install in a new directory.
Regards
Sue
Similar Messages
-
Hi,
When I take an Explain Plan using TKPROF it gives the following error:
Error in CREATE TABLE of EXPLAIN PLAN table: APPS.prof$plan_table
ORA-00955: name is already used by an existing object
parse error offset: 18
EXPLAIN PLAN option disabled.
And the Explain Plan is snot displayed in the o/p file for all the queries.
Can any one help me on this.
Thanks,
KiranHi kiran
When I take an Explain Plan using TKPROF it gives the following error:
Error in CREATE TABLE of EXPLAIN PLAN table: APPS.prof$plan_table
ORA-00955: name is already used by an existing object
parse error offset: 18
EXPLAIN PLAN option disabled.
********************************************************************************What is your Db verssion and EBS? What is your kprof syntax. By the way please check those doc adn see its helpful:
Run Adadmin To Recreate Grants And Synonyms ORA-20000 ORA-00955 In Synonyms Loop:create_synonym(GL,PLAN_TABLE,APPS,PLAN_TABLE) [ID 437714.1]
TKPROF With Explain Fails With ORA-00903 invalid table name [ID 257294.1]
OERR: ORA 955 is already used by an existing object [ID 18549.1]
Also check:
Re: TKPROF and Explain Plan
Regard
Helios -
"Execute Explain Plan" button disabled
I'm using the 1.1.3 version of SQL Developer included in the Oracle 11g distribution for Windows.
After connecting to a database and executing a query, I am unable to view its execution plan because the explain plan button is greyed-out. The connected user has the PLAN_TABLE table in its schema.Are all the buttons grayed out on the worksheet or just the explain plan button? If you look at your worksheet, is the drop list on the right hand side populated? i.e does it display your user connection? If not, select your connection in the drop kist and the icons will change from gray to available.
You say in your message that you upgraded to 1.1. I assume you did a fresh install in a new directory.
Regards
Sue -
Explain plan generating it self taking very long time !!! What to do ?
Hi,
I am trying to generate explain plan for a query which is running more than 2 hours. I am trying to generate explain plan for query by "explin plan for select ..." but it self is taking very long time.
Kindly suggest me how to reduce time for explain plan ? Secondly why explain plan itself taking very long time ?
thanks & regards
PKPJust guessing here, but I've experienced this behaviour when I did two explain's within a second. This is because a plan is identified by a statement_id or, if you don't provide a statement_id, by the timestamp (of DATE datatype). So if you execute two explain plans within the second (using a script), it has two sets of data with the same primary key. The hierarchical query that needs to be executed to provide you the nicely indented text, will exponentially expand in this case.
Maybe time to clean up your plan_table ?
Hope this helps.
Regards,
Rob. -
Differenet Explain Plan for Same Query
DB Version : 11.2.0.3
OS Version : AIX 6
I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
First Query Statement :
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120131 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120131 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '950'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan for First Query :
PLAN_TABLE_OUTPUT
Plan hash value: 3901722890
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 2866 | 134K| 197 (3)| 00:00:03 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 2866 | 134K| 197 (3)| 00:00:03 | | |
|* 4 | SORT ORDER BY STOPKEY | | 2866 | 333K| 197 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 2866 | 333K| 196 (2)| 00:00:03 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 1419 | 148K| 196 (2)| 00:00:03 | | |
|* 7 | HASH JOIN | | 1419 | 141K| 196 (2)| 00:00:03 | | |
| 8 | NESTED LOOPS | | 91 | 1911 | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | INDEX FULL SCAN | PK_SUNITUSERGROUP | 91 | 1001 | 1 (0)| 00:00:01 | | |
| 12 | PARTITION RANGE SINGLE | | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 13 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 14 | INDEX SKIP SCAN | IX_RMESG | 415 | | 14 (15)| 00:00:01 | 2 | 2 |
|* 15 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | 0 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
7 - access("X_INST0_UNIT_NAME"="UNIT")
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
"RMESG"."MESG_FRMT_NAME"='Swift')
14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='950')
15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
40 rows selected.
Second query
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120117 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120117 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '548'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan For Second Query :
PLAN_TABLE_OUTPUT
Plan hash value: 4106071428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | | |
| 3 | VIEW | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
|* 4 | SORT ORDER BY STOPKEY | | 1073 | 124K| | 2622 (1)| 00:00:32 | | |
| 5 | NESTED LOOPS | | 1073 | 124K| | 2621 (1)| 00:00:32 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 531 | 56817 | | 2621 (1)| 00:00:32 | | |
| 7 | NESTED LOOPS | | 531 | 54162 | | 2621 (1)| 00:00:32 | | |
| 8 | NESTED LOOPS | | 543 | 49413 | | 2621 (1)| 00:00:32 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | | 0 (0)| 00:00:01 | | |
| 11 | PARTITION RANGE SINGLE | | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
|* 12 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
| 13 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 14 | BITMAP AND | | | | | | | | |
| 15 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
|* 16 | INDEX RANGE SCAN | IX_SENDER | 25070 | | | 894 (1)| 00:00:11 | 2 | 2 |
PLAN_TABLE_OUTPUT
| 17 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
| 18 | SORT ORDER BY | | | | 408K| | | | |
|* 19 | INDEX RANGE SCAN | IX_RMESG | 25070 | | | 1405 (1)| 00:00:17 | 2 | 2 |
|* 20 | INDEX UNIQUE SCAN | PK_SUNITUSERGROUP | 1 | 11 | | 0 (0)| 00:00:01 | | |
|* 21 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | | 0 (0)| 00:00:01 | | |
|* 22 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
45 rows selected.
Table Structure TEMPSEARCHRESULT
CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
T_AID NUMBER(3),
T_UMIDL NUMBER(10),
T_UMIDH NUMBER(10),
X_CREA_DATE_TIME_MESG DATE
ON COMMIT PRESERVE ROWS
NOCACHE;
CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
(T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);Again Thank you For your amazing Answer.
For indexes it's a balance. Check this query which is Simple
Select * from RMESGI generated Explain Plan for it to see effect of indexes .
PLAN_TABLE_OUTPUT
Plan hash value: 1686435785
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 11M| 8920M| 376K (1)| 01:15:20 | | |
| 1 | PARTITION RANGE ALL| | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
| 2 | TABLE ACCESS FULL | RMESG | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
CREATE TABLE RMESG(
aid NUMBER(3) NOT NULL,
mesg_s_umidl NUMBER(10) NOT NULL,
mesg_s_umidh NUMBER(10) NOT NULL,
mesg_validation_requested CHAR(18) NOT NULL,
mesg_validation_passed CHAR(18) NOT NULL,
mesg_class CHAR(16) NOT NULL,
mesg_is_text_readonly NUMBER(1) NOT NULL,
mesg_is_delete_inhibited NUMBER(1) NOT NULL,
mesg_is_text_modified NUMBER(1) NOT NULL,
mesg_is_partial NUMBER(1) NOT NULL,
mesg_crea_mpfn_name CHAR(24) NOT NULL,
mesg_crea_rp_name CHAR(24) NOT NULL,
mesg_crea_oper_nickname CHAR(151) NOT NULL,
mesg_crea_date_time DATE NOT NULL,
mesg_mod_oper_nickname CHAR(151) NOT NULL,
mesg_mod_date_time DATE NOT NULL,
mesg_frmt_name VARCHAR2(17) NOT NULL,
mesg_nature CHAR(14) NOT NULL,
mesg_sender_x1 CHAR(11) NOT NULL,
mesg_sender_corr_type VARCHAR2(24) NOT NULL,
mesg_uumid VARCHAR2(50) NOT NULL,
mesg_uumid_suffix NUMBER(10) NOT NULL,
x_own_lt CHAR(8) NOT NULL,
x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
x_category CHAR(1) NOT NULL,
archived NUMBER(1) NOT NULL,
restored NUMBER(1) NOT NULL,
mesg_related_s_umid CHAR(16) NULL,
mesg_status CHAR(12) NULL,
mesg_crea_appl_serv_name CHAR(24) NULL,
mesg_verf_oper_nickname CHAR(151) NULL,
mesg_data_last NUMBER(10) NULL,
mesg_token NUMBER(10) NULL,
mesg_batch_reference VARCHAR2(46) NULL,
mesg_cas_sender_reference VARCHAR2(40) NULL,
mesg_cas_target_rp_name VARCHAR2(20) NULL,
mesg_ccy_amount VARCHAR2(501) NULL,
mesg_copy_service_id VARCHAR2(4) NULL,
mesg_data_keyword1 VARCHAR2(80) NULL,
mesg_data_keyword2 VARCHAR2(80) NULL,
mesg_data_keyword3 VARCHAR2(80) NULL,
mesg_delv_overdue_warn_req NUMBER(1) NULL,
mesg_fin_ccy_amount VARCHAR2(24) NULL,
mesg_fin_value_date CHAR(6) NULL,
mesg_is_live NUMBER(1) NULL,
mesg_is_retrieved NUMBER(1) NULL,
mesg_mesg_user_group VARCHAR2(24) NULL,
mesg_network_appl_ind CHAR(3) NULL,
mesg_network_delv_notif_req NUMBER(1) NULL,
mesg_network_obso_period NUMBER(10) NULL,
mesg_network_priority CHAR(12) NULL,
mesg_possible_dup_creation VARCHAR2(8) NULL,
mesg_receiver_alia_name VARCHAR2(32) NULL,
mesg_receiver_swift_address CHAR(12) NULL,
mesg_recovery_accept_info VARCHAR2(80) NULL,
mesg_rel_trn_ref VARCHAR2(80) NULL,
mesg_release_info VARCHAR2(32) NULL,
mesg_security_iapp_name VARCHAR2(80) NULL,
mesg_security_required NUMBER(1) NULL,
mesg_sender_x2 VARCHAR2(21) NULL,
mesg_sender_x3 VARCHAR2(21) NULL,
mesg_sender_x4 VARCHAR2(21) NULL,
mesg_sender_branch_info VARCHAR2(71) NULL,
mesg_sender_city_name VARCHAR2(36) NULL,
mesg_sender_ctry_code VARCHAR2(3) NULL,
mesg_sender_ctry_name VARCHAR2(71) NULL,
mesg_sender_institution_name VARCHAR2(106) NULL,
mesg_sender_location VARCHAR2(106) NULL,
mesg_sender_swift_address CHAR(12) NULL,
mesg_sub_format VARCHAR2(6) NULL,
mesg_syntax_table_ver VARCHAR2(8) NULL,
mesg_template_name VARCHAR2(32) NULL,
mesg_trn_ref VARCHAR2(16) NULL,
mesg_type CHAR(3) NULL,
mesg_user_issued_as_pde NUMBER(1) NULL,
mesg_user_priority_code CHAR(4) NULL,
mesg_user_reference_text VARCHAR2(30) NULL,
mesg_zz41_is_possible_dup NUMBER(1) NULL,
x_fin_ccy CHAR(3) NULL,
x_fin_amount NUMBER(21,4) NULL,
x_fin_value_date DATE NULL,
x_fin_ocmt_ccy CHAR(3) NULL,
x_fin_ocmt_amount NUMBER(21,4) NULL,
x_receiver_x1 CHAR(11) NULL,
x_receiver_x2 VARCHAR2(21) NULL,
x_receiver_x3 VARCHAR2(21) NULL,
x_receiver_x4 VARCHAR2(21) NULL,
last_update DATE NULL,
set_id NUMBER(10) NULL,
mesg_requestor_dn VARCHAR2(101) NULL,
mesg_service VARCHAR2(31) NULL,
mesg_request_type VARCHAR2(31) NULL,
mesg_identifier VARCHAR2(31) NULL,
mesg_xml_query_ref1 VARCHAR2(101) NULL,
mesg_xml_query_ref2 VARCHAR2(101) NULL,
mesg_xml_query_ref3 VARCHAR2(101) NULL,
mesg_appl_sender_reference VARCHAR2(51) NULL,
mesg_payload_type VARCHAR2(31) NULL,
mesg_sign_digest_reference VARCHAR2(41) NULL,
mesg_sign_digest_value VARCHAR2(51) NULL,
mesg_use_pki_signature NUMBER(1) NULL
PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
I always remember TOM Quote "full scans are not evil, indexes are not good"
Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
Thank you
Osama -
Why tkprof did not show explain plan for some sql statements
Hi,
I did a trace for one of the session, hoping to find the explain plan for its tkprof. However, I only get this:
INSERT INTO AUDIT_TABLE
VALUES
( :B1 , :B2 , :B3 , :B4 , :B5 , :B6 , :B8 , :B7 )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 3698 8.08 59.41 3348 566 19092 3698
Fetch 0 0.00 0.00 0 0 0 0
total 3699 8.08 59.42 3348 566 19092 3698
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 30 (recursive depth: 2)
********************************************************************************Any idea why the explain plan is missing?
Also looking at the above statistics, what can I conclude?Thanks John. What's ur take on this statistics then?
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1798 12.23 36.75 1758 5404 7418 1798
Fetch 0 0.00 0.00 0 0 0 0
total 1798 12.23 36.75 1758 5404 7418 1798
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 30 (recursive depth: 1)
******************************************************************************** -
Why can the explain plan be different from 2 exact set of structures
hi,
i have from a view some base tables let's say A , B, C & D
this query is running very slow . so from the same database , i created tables A1 , B1, C1,& D1 from the above tables.
i created some new indexes on A1 to D1 tables and the results returned to me is fast.
i did an exlain plan
so i drop the indexes on the original A to D table and created the new indexes as per A1 to D1 and analyzed them. and i also did an explain plan
but the query is still running slow and also the explain plan is different to the one from A1 to D1 (the one that running fast)
pls help me to understand how/why can this happen ?
tks & rdgshi,
precisely i could have been providing insufficient information but i am too inexperienced to be able to give you the required information and i am also not very sure where i could get the info so that you all can advise me further.
but this is from the user_tables , the only difference i see is that
under LOGGING table A to E is 'YES'
TABLE_NAME TABLESPACE_NAME PCT_FREE LOGGING BACKED_UP NUM_ROWS BLOCKS CACHE TABLE_LOCK PARTITIONED
A1 OWNER1 10 NO N 37332 883 N ENABLED NO
B1 OWNER1 10 NO N 43458 861 N ENABLED NO
C1 OWNER1 10 NO N 823828 7826 N ENABLED NO
D1 OWNER1 10 NO N 881176 14646 N ENABLED NO
E1 OWNER1 10 NO N 18868 223 N ENABLED NO
A OWNER1 10 YES N 37040 880 N ENABLED NO
B OWNER1 10 YES N 43386 880 N ENABLED NO
C OWNER1 10 YES N 823820 7684 N ENABLED NO
D OWNER1 50 YES N 880948 26624 N ENABLED NO
E OWNER1 10 YES N 18690 244 N ENABLED NOtks & rdgs -
Why the explain plan incorrent?
I have a sql in oracle10.2.03:
select *
from (select a.*
from t_user a, t_message b
where b.user_id = a.row_id and a.user_type = 1
order by b.happen_time desc)
where rownum <= 5
there are indexes on column a.user_type,b.user_id,b.happen_time, and has been analyzed. a.user_type=1 only have 1/1000 records
the explain plan is below:
cost Cardinary Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 30 5 3790
COUNT STOPKEY
VIEW BMTEST 30 6 4548
NESTED LOOPS 30 6 1158
TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 13 1524118 24385888
INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 1 177
INDEX UNIQUE SCAN BMTEST PK_USER 1 1
Oracle use the index full scan descending on the happen_time. the cost only has 30.
After I add hint on the sql on the user_id of t_message
select *
from (select /*+index (b idx_message_1)*/ a.*
from t_user a, t_message b
where b.user_id = a.row_id and a.user_type = 1
order by b.happen_time desc)
where rownum <= 5
the explain plan change to:
cost Cardinary Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 5020 5 3790
COUNT STOPKEY
VIEW BMTEST 5020 54707 41467906
SORT ORDER BY STOPKEY 5020 54707 10558451
TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 26 515 8240
NESTED LOOPS 2707 54707 10558451
TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 106 18762
INDEX RANGE SCAN BMTEST IDX_USER_2 1 106
INDEX RANGE SCAN BMTEST IDX_MESSAGE_1 1 515
INDEX UNIQUE SCAN BMTEST PK_USER 1 1
The cost is 5020, but the execute usage time only is 100ms, and the first SQL does not add hint usage 20s.
Why the lower cost waste more time, if the cost caculate is incorrect?
Edited by: [email protected] on Sep 11, 2008 9:14 PM[email protected] wrote:
But i am afraid i use a misunderstand title for this post,my doubt is why oracle get a large cost with the sql execute few time but get a small cost with the sql execute long time.The cost of a query isn't a particularly good proxy for runtime. It is perfectly reasonable for a query with a cost of 1000 to run more quickly than a query with a cost of 100. The cost of queries is only directly comparable between different plans in the same 10053 trace file.
[email protected] wrote:
All the indexed columns are both analyzed by the command or by DBMS_STATS package and the cpu costing is enabled.But what order are the commands being run? And why is the ANALYZE command being used to gather optimizer stats.
In the first plan:
INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
Why this index full scan cost only 1? how did oracle get this number? Is there formula to caculate the cost of index full scan? I have read the article named "Cost Based Oracle Fundamentals" and there is no introduce how to caculate it.
I think this abnormality cost makes the cost of next step "NESTED LOOPS" very smal and finally lead this abnormality result.1) Which article are you talking about? Are you talking about Jonathan Lewis's book "Cost Based Oracle Fundamentals"? Or are you referring to a different article somewhere?
2) Can you post the query plans formatted via DBMS_XPLAN.DISPLAY (including the predicate information and enclose the output in the \[pre\] and \[pre\] tags to preserve white space?
Justin
Justin -
Why the content of the Explain Plan not show out?
Why the content of the Explain Plan not show out?
I am using Oracle 11g.
I already ran the utlxplan.sql sctipt and I also set serveroutput on.
SQL> set autotrace on
SQL> EXPLAIN PLAN FOR SELECT*FROM DEMO_TABLE WHERE OWNER='HR';
Explained.
Elapsed: 00:00:00.67When you say:
My release 10.2 database display the Explain Plan automatically.
How to make 11.1.0.6 Oracle database to display the Explain Plan automatically.What do you mean? Specifically, what commands are you executing in the 10.2 database, that displays the execution plan "automatically"?
Are you saying that if you execute the same command in 11.1.0.6, you don't get a similar result? What happens? Do you get an error?
For both the 10.2 case and the 11.1.0.6 case, post the full output of the commands you're executing, and the result you are seeing.
Then, maybe someone can help you.
When you post the output, please encapsulate it in a pair "code" tags, which is the word "code" without the quotes, surrounded by a pair of curly braces {}.
When you do this correctly, the output looks like:
This is output from my execution plan run.and is much easier to read.
Don't be afraid to use the preview tab to see if your message will be posted with the correct formatting.
-Mark -
Why two different explain plan for same objects?
Believe or not there are two different databases, one for processing and one for reporting, plan is show different for same query. Table structure and indexes are same. It's 11G
Thanks
Good explain plan .. works fine..
Plan
SELECT STATEMENT ALL_ROWSCost: 12,775 Bytes: 184 Cardinality: 1
27 SORT UNIQUE Cost: 12,775 Bytes: 184 Cardinality: 1
26 NESTED LOOPS
24 NESTED LOOPS Cost: 12,774 Bytes: 184 Cardinality: 1
22 HASH JOIN Cost: 12,772 Bytes: 178 Cardinality: 1
20 NESTED LOOPS SEMI Cost: 30 Bytes: 166 Cardinality: 1
17 NESTED LOOPS Cost: 19 Bytes: 140 Cardinality: 1
14 NESTED LOOPS OUTER Cost: 16 Bytes: 84 Cardinality: 1
11 VIEW DSSADM. Cost: 14 Bytes: 37 Cardinality: 1
10 NESTED LOOPS
8 NESTED LOOPS Cost: 14 Bytes: 103 Cardinality: 1
6 NESTED LOOPS Cost: 13 Bytes: 87 Cardinality: 1
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_FAMILY_TBL Cost: 10 Bytes: 51 Cardinality: 1
1 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9 Cardinality: 1
5 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3 Bytes: 36 Cardinality: 1
4 INDEX RANGE SCAN INDEX DSSADM.STAN_JB_FN_IDX Cost: 2 Cardinality: 1
7 INDEX UNIQUE SCAN INDEX (UNIQUE) DSSODS.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0 Cardinality: 1
9 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOBCODE_TBL_RPT Cost: 1 Bytes: 16 Cardinality: 1
13 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PSXLATITEM_RPT Cost: 2 Bytes: 47 Cardinality: 1
12 INDEX RANGE SCAN INDEX DSSODS.PK_DRV_RIXLATITEM_RPT Cost: 1 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_JOBCODE Cost: 3 Bytes: 56 Cardinality: 1
15 INDEX RANGE SCAN INDEX DSSADM.DIM_JOBCODE_EXPDT1 Cost: 2 Cardinality: 1
19 TABLE ACCESS BY INDEX ROWID TABLE DSSODS.DRV_PS_JOB_RPT Cost: 11 Bytes: 438,906 Cardinality: 16,881
18 INDEX RANGE SCAN INDEX DSSODS.DRV_PS_JOB_JOBCODE_RPT Cost: 2 Cardinality: 8
21 INDEX FAST FULL SCAN INDEX (UNIQUE) DSSADM.Z_PK_JOBCODE_PROMPT_TBL Cost: 12,699 Bytes: 66,790,236 Cardinality: 5,565,853
23 INDEX RANGE SCAN INDEX DSSADM.DIM_PERSON_EMPL_RCD_SEQ_KEY Cost: 1 Cardinality: 1
25 TABLE ACCESS BY INDEX ROWID TABLE DSSADM.DIM_PERSON_EMPL_RCD Cost: 2 Bytes: 6 Cardinality: 1 This bad plan ... show merge join cartesian and full table ..
Plan
SELECT STATEMENT ALL_ROWSCost: 3,585 Bytes: 237 Cardinality: 1
26 SORT UNIQUE Cost: 3,585 Bytes: 237 Cardinality: 1
25 NESTED LOOPS SEMI Cost: 3,584 Bytes: 237 Cardinality: 1
22 NESTED LOOPS Cost: 3,573 Bytes: 211 Cardinality: 1
20 MERGE JOIN CARTESIAN Cost: 2,864 Bytes: 70,446 Cardinality: 354
17 NESTED LOOPS
15 NESTED LOOPS Cost: 51 Bytes: 191 Cardinality: 1
13 NESTED LOOPS OUTER Cost: 50 Bytes: 180 Cardinality: 1
10 HASH JOIN Cost: 48 Bytes: 133 Cardinality: 1
6 NESTED LOOPS
4 NESTED LOOPS Cost: 38 Bytes: 656 Cardinality: 8
2 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 14 Bytes: 448 Cardinality: 8
1 INDEX RANGE SCAN INDEX REPORT2.STAN_PROM_JB_IDX Cost: 6 Cardinality: 95
3 INDEX RANGE SCAN INDEX REPORT2.SETID_JC_IDX Cost: 2 Cardinality: 1
5 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DIM_JOBCODE Cost: 3 Bytes: 26 Cardinality: 1
9 INLIST ITERATOR
8 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_FAMILY_TBL Cost: 10 Bytes: 51 Cardinality: 1
7 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_FAMILY_TBL_CL_SETID Cost: 9 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PSXLATITEM_RPT Cost: 2 Bytes: 47 Cardinality: 1
11 INDEX RANGE SCAN INDEX REPORT2.PK_DRV_RIXLATITEM_RPT Cost: 1 Cardinality: 1
14 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORT2.DRV_PS_JOBCODE_TBL_SEQ_KEY_RPT Cost: 0 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOBCODE_TBL_RPT Cost: 1 Bytes: 11 Cardinality: 1
19 BUFFER SORT Cost: 2,863 Bytes: 4,295,552 Cardinality: 536,944
18 TABLE ACCESS FULL TABLE REPORT2.DIM_PERSON_EMPL_RCD Cost: 2,813 Bytes: 4,295,552 Cardinality: 536,944
21 INDEX RANGE SCAN INDEX (UNIQUE) REPORT2.Z_PK_JOBCODE_PROMPT_TBL Cost: 2 Bytes: 12 Cardinality: 1
24 TABLE ACCESS BY INDEX ROWID TABLE REPORT2.DRV_PS_JOB_RPT Cost: 11 Bytes: 1,349,920 Cardinality: 51,920
23 INDEX RANGE SCAN INDEX REPORT2.DRV_PS_JOB_JOBCODE_RPT Cost: 2 Cardinality: 8user550024 wrote:
I am really surprise that the stat for good sql are little old. I just computed the states of bad sql so they are uptodate..
There is something terribly wrong..Not necessarily. Just using the default stats collection I've seen a few cases of things suddenly going wrong. As the data increases, it gets closer to an edge case where the inadequacy of the statistics convinces the optimizer to do a wrong plan. To fix, I could just go into dbconsole, set the stats back to a time when they worked, and locked them. In most cases it's definitely better to figure out what is really going on, though, to give the optimizer better information to work with. Aside from the value of learning how to do it, for some cases it's not so simple. Also, many think the default settings of the database statistic collection may be wrong in general (in 10.2.x, at least). So much depends on your application and data that you can't make too many generalizations. You have to look at the evidence and figure it out. There is still a steep learning curve for the tools to look at the evidence. People are here to help with that.
Most of the time it works better than a dumb rule based optimizer, but at the cost of a few situations where people are smarter than computers. It's taken a lot of years to get to this point. -
Why bother to use explain plan?
All my colleagues used the third party applications, Crystal Report or TAOD, to query data from the 10g R2 database for some kind of reporting. The problem is they always created the query with multiple outer join (> 10 tables) and they WRITE the codes without using the explain plan. They simply used the query for result of the moment and the query they wrote only were used for few time (< 3), because the manager requested the report kept changing the requirement. They did it on both Dev and Prod
I think it is bad practice, how can I convience them to change their practice?The concept that something is ad hoc and therefore doesn't matter can break down pretty quickly when a bright light is shined upon it. But what you are fighting here is more a question of politics than technology.
If the system is still chugging along at an acceptable speed, no end-user complaints, and practices in your organization range from sloppy to lazy you should probably just polish up your resume and move to a job where people care about professional standards and doing a good job.
To change a practice such as this usually one must get to the level of childish schoolyard play and create a competitive atmosphere. Take one of those slow queries and tune it. Challenge someone to do better than you did. Offer a beer to anyone that can write it more efficiently than you did, etc. Make it a game.
But don't be surprised if the reason they aren't running explain plan is that:
1. They don't know how
2. They know how but don't know how to read the output
3. They know how to read the output but haven't a clue what to do about it.
As an example ... I know a lot of people that think they know how to output an explain plan. In truth not 10% of them understand this:
SELECT * FROM TABLE(dbms_xplan.display_cursor('cpm9ss48qd32f', 0));
http://www.psoug.org/reference/dbms_xplan.html
Which is really rather sad. -
Hi,
I am quite new to use explain plan in oracle.
I want to know what are the important factors that we should emphasize to optimize a SQL query.
Thanks in Advance,
DilipIf I had to identify key SQL tuning factors to look for in relation to an explain plan I would say that number one is to verify that the plan is driving on the right tables in the proper order.
Second looking at the SQL make sure it is not written in such a manner as to disable the use of available indexes such as when a trunc is done on an indexed date column so it can be compared equal to another date when a >= date value of midnight and < midnight of first day not desired could be used instead enabling use of the index on the date column by the optimizer. Implicit conversions of join column data types can also disable use of an index.
Third, if the CBO is doing something other than what you expected do not just assume it is wrong. Try to figure out why it is doing what it is doing and then try to determine if it is right or wrong. I have caught people trying to tune SQL because they knew the plan was wrong, but did not actually test it before spending a lot of time to develop a different path that ran slower than the optimzer plan.
HTH -- Mark D Powell -- -
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 -
Different explain plan between 10.2.0.3 and 10.2.0.4
Had a problem with an explain plan changing after upgrade from 10.2.0.3 to 10.2.0.4. Managed to simplify as much as possible for now:
Query is :
SELECT * FROM m_promo_chk_str
WHERE (m_promo_chk_str.cust_cd) IN (
SELECT cust_cd
FROM s_usergrp_pda
GROUP BY cust_cd)
On 10.2.0.3 explain plan is:
| 0 | SELECT STATEMENT | | 1 | 1227 | 26 (16)| 00:00:01 |
|* 1 | HASH JOIN SEMI | | 1 | 1227 | 26 (16)| 00:00:01 |
| 2 | TABLE ACCESS FULL | M_PROMO_CHK_STR | 1 | 1185 | 14 (0)| 00:00:01 |
| 3 | VIEW | VW_NSO_1 | 137 | 5754 | 11 (28)| 00:00:01 |
| 4 | HASH GROUP BY | | 137 | 548 | 11 (28)| 00:00:01 |
| 5 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 9 (12)| 00:00:01 |
On 10.2.0.4 with same data is:
| 0 | SELECT STATEMENT | | 1 | 1201 | 46 (5)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 1201 | 46 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 1 | 1201 | 45 (3)| 00:00:01 |
| 3 | TABLE ACCESS FULL| M_PROMO_CHK_STR | 1 | 1197 | 29 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 15 (0)| 00:00:01 |
Explain plan is reasonable for when M_PROMO_CHK_STR is empty, however we have the case where stats are gathered when table is empty, but table is then populated and the query runs slowly. I understand that this is not a problem with the database exactly, but want to try to understand why the different behaviour.
Will look into CBO trace tommorrow, but for now anyone want to share any thoughts?PatHK wrote:
Here is further simplification to reproduce the different behaviour - I think about as simple as I can get it!
SELECT * FROM dual WHERE (dummy) IN (SELECT dummy FROM dual GROUP BY dummy);
On 10.2.0.3
| 0 | SELECT STATEMENT | | 1 | 4 | 5 (20)| 00:00:01 |
| 1 | NESTED LOOPS SEMI | | 1 | 4 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
|* 3 | VIEW | VW_NSO_1 | 1 | 2 | 3 (34)| 00:00:01 |
| 4 | SORT GROUP BY | | 1 | 2 | 3 (34)| 00:00:01 |
| 5 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |On 10.2.0.4
| 0 | SELECT STATEMENT | | 1 | 4 | 4 (0)| 00:00:01 |
| 1 | SORT GROUP BY NOSORT| | 1 | 4 | 4 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 4 | 4 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 |
Timur's suggestion to look at a 10053 trace file is a good idea. It might be the case that someone disabled complex view merging in the 10.2.0.3 database instance. See the following:
_complex_view_merging
http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/
Here is a test you might try on both database versions:
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=TRUE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST1';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=FALSE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST2';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';The first plan output:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 8 (100)| |
| 1 | SORT GROUP BY NOSORT| | 1 | 4 | 8 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 4 | 8 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("DUMMY"="DUMMY")The second plan output:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 9 (100)| |
| 1 | NESTED LOOPS SEMI | | 1 | 4 | 9 (12)| 00:00:01 |
| 2 | TABLE ACCESS FULL | DUAL | 1 | 2 | 4 (0)| 00:00:01 |
|* 3 | VIEW | VW_NSO_1 | 1 | 2 | 5 (20)| 00:00:01 |
| 4 | SORT GROUP BY | | 1 | 2 | 5 (20)| 00:00:01 |
| 5 | TABLE ACCESS FULL| DUAL | 1 | 2 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("DUMMY"="$nso_col_1")From the first 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
_pga_max_size = 368640 KB
pgamax_size is the only parameter non-default value which could affect the optimizer.
From the second 10053 trace file:
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
_pga_max_size = 368640 KB
_complex_view_merging = false
*********************************This section in the first 10053 trace seems to show the complex view merging:
SU: Considering interleaved complex view merging
SU: Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
CVM: CBQT Marking query block SEL$683B0107 (#2)as valid for CVM.
CVM: Merging complex view SEL$683B0107 (#2) into SEL$5DA710D3 (#1).
qbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM (SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY") "VW_NSO_2","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
vqbcp:******* UNPARSED QUERY IS *******
SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY"
CVM: result SEL$5DA710D3 (#1).
******* UNPARSED QUERY IS *******
SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM "SYS"."DUAL" "DUAL","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="DUAL"."DUMMY" GROUP BY "DUAL"."DUMMY","DUAL".ROWID,"DUAL"."DUMMY"
Registered qb: SEL$C9C6826C 0x155e2020 (VIEW MERGE SEL$5DA710D3; SEL$683B0107)
signature (): qb_name=SEL$C9C6826C nbfros=2 flg=0
fro(0): flg=0 objn=258 hint_alias="DUAL"@"SEL$1"
fro(1): flg=0 objn=258 hint_alias="DUAL"@"SEL$2"
FPD: Considering simple filter push in SEL$C9C6826C (#1)
FPD: Current where clause predicates in SEL$C9C6826C (#1) :
"DUAL"."DUMMY"="DUAL"."DUMMY"
kkogcp: try to generate transitive predicate from check constraints for SEL$C9C6826C (#1)
predicates with check contraints: "DUAL"."DUMMY"="DUAL"."DUMMY"
after transitive predicate generation: "DUAL"."DUMMY"="DUAL"."DUMMY"
finally: "DUAL"."DUMMY"="DUAL"."DUMMY"
CVM: Costing transformed query.
kkoqbc-start
: call(in-use=25864, alloc=65448), compile(in-use=115280, alloc=118736)
kkoqbc-subheap (create addr=000000001556CD70)This is the same section from the second 10053 trace:
SU: Considering interleaved complex view merging
SU: Transform an ANY subquery to semi-join or distinct.
CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
FPD: Considering simple filter push in SEL$5DA710D3 (#1)
FPD: Current where clause predicates in SEL$5DA710D3 (#1) :
"DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
predicates with check contraints: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
after transitive predicate generation: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
finally: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
FPD: Considering simple filter push in SEL$683B0107 (#2)
FPD: Current where clause predicates in SEL$683B0107 (#2) :
CVM: Costing transformed query.
kkoqbc-start
: call(in-use=25656, alloc=65448), compile(in-use=113992, alloc=114592)
kkoqbc-subheap (create addr=00000000157E9078)Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Problems with explain plan and statement
Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AMtobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Maybe you are looking for
-
Safari will not open after new update??? Please help =(
Was prompted Safari 4.1 update was ready, I clicked update, restarted my iMac. Then attempted to open up Safari from dock but no window opened. I also clicked open new window, but nothing happened. I quit Safari, but it gave me a message that I had 2
-
Doubt in Integration Scenario Creation
Hi All, My scenario is file to Idoc.Need to create a Integration Scenario. I have stored all the Interface and Mapping objects in teh same Software Component Version (say SWCA). So in Integration Scenario, What will be the Sender and Receiver Softwar
-
I can't pair my MacBook with my iPhone 5c
I can't pair my MacBook with my iPhone 5c. Any suggestions on how to do it? I've tried switching Bluetooth off and on again, toying with AirDrop, but nothing works. There MUST be an easy way to send a file from the iPhone directly to the MacBook, rig
-
I recently deleted a number of Unit of Measure values. Unfortunately, I deleted approximately 5 of them that were in use. I have identified which ones we need to reenter. Question - would it be better to restore all unit of measure values that wer
-
Criticisms? First package for r5u870-svn
NOTE: see below for finished product So I'm building a Pkgbuild for the fun of learning how to do so. In particular this one is for the r5u870 webcam driver which downloads from the svn and not a static source. Thus far I have this: # contributor: or