Executions Plans stored on CACHE
Hello Friends and Oracle Gurus...
I'm not much expert on Execution Plan but I have a select on Oracle 9.2.0.1.0 Windows 2003 server that takes too long since a few days ago...
When I look on E.Manager, Session Details... its doing a full table scan in one of my tables....
But just above the Execution Plan is a message saying..
EXECUTION PLAN STORED ON CACHE: MODE: ALL_ROWS
However, my OPTIMIZER_MODE is CHOOSE and all tables on select have statistics up to date...
How Did Oracle use this plan and how eliminate it and use another one? that would accept CHOOSE because the statistics?
Tks for everyone
Guys..
here is the select I was talking about
SELECT SUM(NOTAS_ITENS.QUANTIDADE),NOTAS_ITENS.CHAVE_NOTA, NOTAS_ITENS.NUMPED,SUM(NOTAS_ITENS.PESO_BRUTO),NOTAS_ITENS.CHAVE_ALMOXARIFADO,
NOTAS_ITENS.VALOR_TOTAL, NOTAS_ITENS.CHAVE,
PRODUTOS.CPROD, PRODUTOS.CODIGO, PRODUTOS.DESCRICAO, PRODUTOS.LOCACAO, PRODUTOS.VASILHAME,PRODUTOS.PESO_LIQUIDO,
UNIDADES.UNIDADE,
PERICULOSIDADE.DESCRICAO
FROM NOTAS_ITENS, PRODUTOS, UNIDADES, PERICULOSIDADE
WHERE (NOTAS_ITENS.CHAVE_PRODUTO = PRODUTOS.CPROD)
AND (NOTAS_ITENS.QUANTIDADE > 0)
AND (PRODUTOS.CHAVE_UNIDADE = UNIDADES.CHAVE)
AND (PRODUTOS.CHAVE_PERICULOSIDADE = PERICULOSIDADE.CHAVE(+))
AND ( CHAVE_NOTA IN
(SELECT CHAVE FROM NOTAS WHERE CHAVE = CHAVE AND (NOTAS.ATIVA = 'SIM') AND (NOTAS.IMPRESSO_ROMANEIO = 'NAO')))
GROUP BY PRODUTOS.CPROD, PRODUTOS.CODIGO, PRODUTOS.DESCRICAO, PRODUTOS.LOCACAO, PRODUTOS.VASILHAME, PRODUTOS.PESO_LIQUIDO,
UNIDADES.UNIDADE,
PERICULOSIDADE.DESCRICAO,
NOTAS_ITENS.CHAVE_NOTA, NOTAS_ITENS.NUMPED, NOTAS_ITENS.CHAVE_ALMOXARIFADO, NOTAS_ITENS.CHAVE, NOTAS_ITENS.VALOR_TOTAL
ORDER BY NOTAS_ITENS.CHAVE;
and here is the execution plan for him..
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=10615 Card=66372 Byt
es=11747844)
1 0 SORT (GROUP BY) (Cost=10615 Card=66372 Bytes=11747844)
2 1 HASH JOIN (Cost=8855 Card=66372 Bytes=11747844)
3 2 TABLE ACCESS (FULL) OF 'UNIDADES' (Cost=2 Card=30 Byte
s=240)
4 2 HASH JOIN (OUTER) (Cost=8851 Card=66372 Bytes=11216868
5 4 HASH JOIN (Cost=8696 Card=66372 Bytes=9225708)
6 5 TABLE ACCESS (FULL) OF 'PRODUTOS' (Cost=98 Card=19
01 Bytes=171090)
7 5 HASH JOIN (Cost=8584 Card=66387 Bytes=3252963)
8 7 VIEW OF 'index$_join$_005' (Cost=347 Card=13193
Bytes=171509)
9 8 HASH JOIN
10 9 HASH JOIN
11 10 INDEX (RANGE SCAN) OF 'NOTAS_ATIVA_IDX' (N
ON-UNIQUE) (Cost=140 Card=13193 Bytes=171509)
12 10 INDEX (RANGE SCAN) OF 'NOTAS_IMPRESSO_ROMA
NEIO' (NON-UNIQUE) (Cost=140 Card=13193 Bytes=171509)
13 9 INDEX (FAST FULL SCAN) OF 'NOTAS_PK' (UNIQUE
) (Cost=140 Card=13193 Bytes=171509)
14 7 TABLE ACCESS (FULL) OF 'NOTAS_ITENS' (Cost=8170
Card=265547 Bytes=9559692)
15 4 TABLE ACCESS (FULL) OF 'PERICULOSIDADE' (Cost=2 Card
=1 Bytes=30)
Estatística
0 recursive calls
0 db block gets
855476 consistent gets
83917 physical reads
0 redo size
1064 bytes sent via SQL*Net to client
368 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Note that the cost for the HASH JOIN is high-- Is there anyway to get it lower ?
Note that Oracle performs FTS on NOTAS_ITENS table which is quite big for ue... I tryied a lot of hints but none of them avoid FTS ...
Any tips ?
Similar Messages
-
SQL Query C# Using Execution Plan Cache Without SP
I have a situation where i am executing an SQL query thru c# code. I cannot use a stored procedure because the database is hosted by another company and i'm not allowed to create any new procedures. If i run my query on the sql mgmt studio the first time
is approx 3 secs then every query after that is instant. My query is looking for date ranges and accounts. So if i loop thru accounts each one takes approx 3 secs in my code. If i close the program and run it again the accounts that originally took 3 secs
now are instant in my code. So my conclusion was that it is using an execution plan that is cached. I cannot find how to make the execution plan run on non-stored procedure code. I have created a sqlcommand object with my queary and 3 params. I loop thru each
one keeping the same command object and only changing the 3 params. It seems that each version with the different params are getting cached in the execution plans so they are now fast for that particular query. My question is how can i get sql to not do this
by either loading the execution plan or by making sql think that my query is the same execution plan as the previous? I have found multiple questions on this that pertain to stored procedures but nothing i can find with direct text query code.
Bob;
I did the query running different accounts and different dates with instant results AFTER the very first query that took the expected 3 secs. I changed all 3 fields that i've got code for parameters for and it still remains instant in the mgmt studio but
still remains slow in my code. I'm providing a sample of the base query i'm using.
select i.Field1, i.Field2,
d.Field3 'Field3',
ip.Field4 'Field4',
k.Field5 'Field5'
from SampleDataTable1 i,
SampleDataTable2 k,
SampleDataTable3 ip,
SampleDataTable4 d
where i.Field1 = k.Field1 and i.Field4 = ip.Field4
i.FieldDate between '<fromdate>' and '<thrudate>'
and k.Field6 = <Account>
Obviously the field names have been altered because the database is not mine but other then the actual names it is accurate. It works it just takes too long in code as described in the initial post.
My params setup during the init for the connection and the command.
sqlCmd.Parameters.Add("@FromDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@ThruDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@Account", SqlDbType.Decimal);
Each loop thru the code changes these 3 fields.
sqlCommand.Parameters["@FromDate"].Value = dtFrom;
sqlCommand.Parameters["@ThruDate"].Value = dtThru;
sqlCommand.Parameters["@Account"].Value = sAccountNumber;
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
reader.Close();
One thing i have noticed is that the account field is decimal(20,0) and by default the init i'm using defaults to decimal(10) so i'm going to change the init to
sqlCmd.Parameters["@Account"].Precision = 20;
sqlCmd.Parameters["@Account"].Scale = 0;
I don't believe this would change anything but at this point i'm ready to try anything to get the query running faster.
Bob; -
How to find the time taken for creating execution plan alone
Hi,
Is there any way to find out the division between the time taken for query parsing, creating execution plan and actual data retrieval seperately? If I enable 'set timing on' I see the elapsed time which is the total time taken for all these 3.
Some of my queries are taking long time when I run it first time and so want to know what is it taking long, is it the parsing the query or creating the execution plan? (Since my queries run faster second time, I am assuming the major part was for parsing or creating the plan but not the data retrieval).
Also, where does Oracle keep the execution plan? Is it in the BUFFER_CACHE? if so, I tried flushing the buffer_cache and restarting the DB as well, but still the query execution seems faster compared to the first time. How long does Oracle keep the execution plan in the cache and is there anyway to increase this cache size?
Thanks in advance!user13169027 wrote:
Hi,
Is there any way to find out the division between the time taken for query parsing, creating execution plan and actual data retrieval seperately? If I enable 'set timing on' I see the elapsed time which is the total time taken for all these 3.
Some of my queries are taking long time when I run it first time and so want to know what is it taking long, is it the parsing the query or creating the execution plan? (Since my queries run faster second time, I am assuming the major part was for parsing or creating the plan but not the data retrieval).
The ideal way for finding the answer to your questions above, would be to perform a (sql) trace of your query executions. To see the difference in the trace-files, you might want to trace the first execution in one session, and the second execution in another session: so you get two different trace files, which you can then seperately tkprof, and investigate.
Also, where does Oracle keep the execution plan? Is it in the BUFFER_CACHE? if so, I tried flushing the buffer_cache and restarting the DB as well, but still the query execution seems faster compared to the first time. How long does Oracle keep the execution plan in the cache and is there anyway to increase this cache size?
Execution plans are held in the shared-pool, not the buffer-cache. As far as I know they will be kept in memory in an LRU way (least recently used), just like db-blocks are in the buffer-pool (I know this is not entirely correct, but for all practical purposes, think of it this way). -
How to delete stored execution plan?
Hello!
Version: 11.1.0.7.0
I need a function, which deletes a stored execution plan from the CBO by sql_id, to force a new hard-parse.
Background:
I have an application, which calles a lot of a select-statement (with bind), using a specific execution plan, lets say 'A'. This application will run and call in the next three days.
Now, I have recalculated the statistics of the table (by DBMS_STATS.GATHER_TABLE_STATS)
which is used for the query, to improve performance.
Now, the exexcution plan is good (say 'B'), and the query is fast, IF I copy the sql from the OEM to (any) other tool to get the execution plan...
But: The application still uses the plan 'A' (which still runs slow..).
(To opposite of the documentation! see Performance Tuning Guide, Chater 13.3.1 "When statistics are updated for a database object, Oracle invalidates any currently parsed SQL statements that access the object. The next time such a statement executes, the statement is re-parsed and the optimizer automatically chooses a new execution plan based on the new statistics.")
A short look into v$sql, v$sql_plan shows, that the application still uses the old sql_id, which has the wrong execution plan "A" stored.
The tested statements with plan B have the same sql, but other sql_id...Thank you for reading!
The solution is:
Add parameter no_invalidate => FALSE at the gather_table_stats call:
exec dbms_stats.gather_table_stats(ownname=>'xxxx', tabname=>'yyyy', no_invalidate=>FALSE); -
Execution plan caching in oracle
Does oracle store the explain plan in memory cache?
Edited by: :) on Aug 2, 2011 10:45 PMIt depends.
In general execution plan don't change if Oracle has found a sharable cursor in shared pool even if related table data change.
But it can depend on Oracle version, on the bind variables usage by the query (look for adaptative cursor sharing in 11G). It depends also if statistics for related tables and objects have been recomputed with some flag or not to invalidate plan (aka cursors).
Tom Kyte has written in his Expert Oracle book (page 148 that you can read online with Google Books):
>
The shared pool was designed so that query plans would be used over and over again.
>
Edited by: P. Forstmann on 2 août 2011 19:38
Edited by: P. Forstmann on 2 août 2011 19:42 -
How to write SQL in crystal report that can reuse SQL execution plan cache?
I write the following SQL with crystal report parameter fields, and it is connecting to SQL 2005
Select Name from Customer where CustID = '{?CustID}'
The SQL profiler show that It is an ad-hoc query, how to write parameterized SQL which can reuse Execution Plan.
Edited by: Chan Yue Wah on May 14, 2009 3:17 AMSince there are too many report, it is not possible rewrite all. Is that crystal report do not have option to change how it query the database ?
-
Hello ,
I am working on oracle 11g R2 on AIX.
One query was performing good around 20 sec. but suddenly it took more then 15 min.
We check that the sql executoin plan changes , it showing that order of operation changed like order of using indexes is different.
Now the new plan is not good.
we want to force the old plan of sql to use in future.
I read about sql plan management , it shows a manual method to create baseline and evolve the all plan. In one texample we found that
first query execution plan was created using with out index and then with index So, second plan was good and accepted.
But in this case we do not need to change any thing ,query is performing bad may be becasue changes order of operation ..
One other way to use hint , but for this we need to change sqls , which is not possiable in production now.
The issue is
For this we need to run the sql again and oracle may not create plan like old one.So we will not be having old good plan to accept.
All 2 execution plan are already in cache .
I am looking for a way using that we can set sql plan hash value ( of good plan) or any other id of that sql plan to force to use that plan only.
any idea how to do it ..Stored Outlines are deprecated.
OP:
To fix a specific plan you have two choices:
1. SQL Plan Baselines - assuming the "good" plan is in AWR still then the steps are along the lines of load old plan from AWR into sql tuning set using DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY and DBMS_SQLTUNE.LOAD_SQLSET then load plans from sqlset into sql plan baseline using DBMS_SPM.LOAD_PLANS_FROM_SQLSET.
2. Using SQL Profiles to fix the outline hints - so similar to a stored outline but using the sql profile mechanism - using the coe_xfr_sql_profile.sql script, part of an approach in Oracle support doc id 215187.1
But +1 for Nikolay's recommendation of understanding whether there is a root cause to this problem instability (plan instability being "normal", but flip flopping between "good" and "bad" being a problem). Cardinality feedback is an obvious possible influence, different peeked binds another, stat changes, etc. -
How to capture the execution plan for a query
HI All,
Can anyone please help me in finding out the command to capture the execution plan for a query.
Execution plan for select * from EMP where <Condtions>
it is getting executed successfully but i need to get the proper execution plan for the same.
Thanks971830 wrote:
i want to know where execution plan gets generated??
in PMON of server process or in shared pool??
i know that optimixer create execution plan..It is stored in Library Cache (present inside Shared Pool ).
select * from v$sql_plan;An absolute beautiful white paper :
Refer this -- www.sagelogix.com/sagelogix/SearchResults/SAGE015052
Also -- http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/XPVSP/Default.aspx
HTH
Ranit B. -
I'm having a problem where a sql suddenly takes several minutes to execute. This is a sequel that runs every day in production and executes fine, but suddenly it takes several minutes to finish. Websphere is set to time out after 2 minutes, it then executes a rollback command.
We think that this happends after the statistics job running in Oracle has been executed and the execution plan has been updated. It looks like the database connections created from websphere uses the old execution plan. Running the same sql from sqlplus takes only a few seconds, while from the application server it takes over 2 minutes (makes websphere time out)
We are running websphere 6.1, Oracle 10g. The questions...
After the statistics job has been executed, is the library cache flushed? and all sessions that was created will use the new execution plan? (does not look like it).
How do we force the application server to use the right execution plan - or Oracle is probably more correct to ask.The answer to your questions can be..
1.After the statistics job has been executed, is the library cache flushed? and all sessions that was created will use the new execution plan? (does not look like it).
When the statistics for object are collected, any cached execution plan referencing it will get invalidated.
2. How do we force the application server to use the right execution plan - or Oracle is probably more correct to ask.
You can make use of Stored Outlines. -
Query Rewrite (QSM-01263) and Views in Execution Plan
Hello!
I created a query rewrite enabled materialized view from a query, which contains only tables (no views). Query rewrite didn't work, so i checked the query with dbms_mview.explan_rewrite, which told my that my query contains references to views or dictionary tables. I checked my query again, but there are only tables, no views, no dictionary tables.
When I look in the execution plan of my query I see that the query optimizer generates views, I guess from my subquery (?). "A view definition was processed, either from a stored view...or as defined by steps...".
I suppose that's the reason why my query rewrite doesn't work. All my other mat views are working fine, so the usual parameters (query_rewrite_enabled, integrity, etc.) are set correctly.
Do you have any ideas how to get my query rewrite enabled work?
Thanks!Modifying the query (potentially with hints) so that Oracle doesn't do the view transformation would be one option.
-
How to corret an execution plan that shows wrong number of rows?
Using Oracle 10gR2 RAC (10.2.0.3) on SUSE Linux 9 (x86_64).
I have a partition table that has 5 million rows (5,597,831). However an execution plan against the table show that the table has 10 million rows.
Execution plan:
SELECT STATEMENT ALL_ROWS Cost : 275,751 Bytes : 443 Cardinality : 1
3 HASH GROUP BY Cost : 275,751 Bytes : 443 Cardinality : 1
2 PARTITION RANGE ALL Cost : 275,018 Bytes : 4,430,000,000 Cardinality : *10,000,000* Partition # : 2 Partitions accessed #1 - #6
1 TABLE ACCESS FULL TRACESALES.TRACE_BUSINESS_AREA Cost : 275,018 Bytes : 4,430,000,000 Cardinality : 10,000,000 Partition # : 2 Partitions accessed #1 - #6
Plan hash value: 322783426
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 443 | 275K (2)| 00:55:10 | | |
| 1 | HASH GROUP BY | | 1 | 443 | 275K (2)| 00:55:10 | | |
| 2 | PARTITION RANGE ALL| | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
| 3 | TABLE ACCESS FULL | TRACE_BUSINESS_AREA | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
How does one correct the explain plan?
The problem: Queries against the table are taking hours to complete. The problem started when the table was dropped then recreated with a new partition.
I have complete the drop and creation against several tables for several years without problems until now.
I have done the following: Analyzed statistics against the table, flushed buffer cache. Created a materialized view.
However users queries are taking several hours to complete, where before the addition of the partition the queries where taking 5 minutes to complete.
Thanks. BL.Yes, complete analysis of statistic was complete on indexes and against partitions.
Table creation statement:
CREATE TABLE TRACESALES.TRACE_BUSINESS_AREA
... *(400 columns)*
TABLESPACE "trace_OLAPTS"
PCTUSED 0
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL KEEP
PARTITION BY RANGE (YEAR)
PARTITION TRACE_06 VALUES LESS THAN ('2007')
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2006
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARTITION TRACE_07 VALUES LESS THAN ('2008')
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2007
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARTITION TRACE_08 VALUES LESS THAN ('2009')
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2008
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARTITION TRACE_09 VALUES LESS THAN ('2010')
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2009
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARTITION TRACE_10 VALUES LESS THAN ('2011')
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2010
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARTITION TRACE_11 VALUES LESS THAN (MAXVALUE)
NOLOGGING
NOCOMPRESS
TABLESPACE TRACE_2011
PCTFREE 15
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOCOMPRESS
CACHE
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
MONITORING;
*(index statements, constraints, triggers and security)*
Table caching is on and running in parallel degree 4 instances 1. -
Query Execution Plans Change between 2 servers even when we have same data.
Hi Friends,
Currently One of the Query which normally takes 15 seconds but it started taking 160 seconds.So same query was executed on the secondary site and the query returned in 15 seconds which is expected.Raised a call with ORacle and they are still investigating since 27th Sept.
Oracle version=11.2.0.2
OS=Solaris 10.
Issue DB execution plan
select * From tibex_openinghomemktok as of scn 17032999332 where meid='ME1'
call count cpu elapsed disk query current rows
Parse 1 0.12 0.12 0 0 0 0
Execute 1 161.20 161.21 55 1539719 206 0
Fetch 6 0.05 0.05 190 386 1 464
total 8 161.37 161.38 245 1540105 207 464
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 191
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
464 464 464 VIEW TIBEX_OPENINGHOMEMKTOK (cr=1540105 pr=245 pw=191 time=161246176 us cost=149 size=291 card=1)
464 464 464 TEMP TABLE TRANSFORMATION (cr=1540105 pr=245 pw=191 time=161245860 us)
0 0 0 LOAD AS SELECT (cr=27 pr=0 pw=1 time=24101 us)
13 13 13 HASH JOIN (cr=27 pr=0 pw=0 time=13149 us cost=35 size=1408 card=8)
1 1 1 TABLE ACCESS FULL TIBEX_TRADINGMETHODENUM (cr=2 pr=0 pw=0 time=83 us cost=5 size=14 card=1)
235 235 235 HASH JOIN (cr=25 pr=0 pw=0 time=12612 us cost=30 size=22356 card=138)
235 235 235 NESTED LOOPS OUTER (cr=21 pr=0 pw=0 time=11568 us cost=22 size=16560 card=138)
235 235 235 HASH JOIN (cr=20 pr=0 pw=0 time=10831 us cost=22 size=10074 card=138)
40 40 40 HASH JOIN (cr=18 pr=0 pw=0 time=8119 us cost=17 size=2200 card=40)
40 40 40 HASH JOIN OUTER (cr=12 pr=0 pw=0 time=5920 us cost=13 size=1320 card=40)
40 40 40 NESTED LOOPS (cr=10 pr=0 pw=0 time=4155 us cost=3 size=800 card=40)
80 80 80 VIEW index$_join$_018 (cr=6 pr=0 pw=0 time=4245 us cost=3 size=1040 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=3057 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=169 us cost=1 size=1040 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=4 pr=0 pw=0 time=152 us cost=0 size=7 card=1)(object id 1354685)
0 0 0 VIEW (cr=2 pr=0 pw=0 time=316 us cost=10 size=143 card=11)
0 0 0 HASH JOIN (cr=2 pr=0 pw=0 time=315 us cost=8 size=352 card=11)
0 0 0 MERGE JOIN (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
83 83 83 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=113 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
0 0 0 VIEW index$_join$_023 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
0 0 0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
80 80 80 VIEW index$_join$_024 (cr=6 pr=0 pw=0 time=1121 us cost=3 size=1760 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=1040 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=66 us cost=1 size=1760 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=57 us cost=1 size=1760 card=80)(object id 1354895)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=229 us cost=5 size=4950 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=384 us cost=0 size=47 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=135 us cost=0 size=0 card=1)(object id 1354925)
330 330 330 TABLE ACCESS FULL TIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=61 us cost=7 size=13860 card=330)
0 0 0 LOAD AS SELECT (cr=1539692 pr=55 pw=190 time=161190726 us)
12435 12435 12435 NESTED LOOPS (cr=1539692 pr=55 pw=0 time=158262964 us cost=109 size=284 card=1)
12435 12435 12435 FILTER (cr=1539688 pr=55 pw=0 time=158208902 us)
497400 497400 497400 NESTED LOOPS OUTER (cr=1539688 pr=55 pw=0 time=212847780 us cost=109 size=280 card=1)
497400 497400 497400 NESTED LOOPS (cr=544888 pr=55 pw=0 time=60349504 us cost=108 size=267 card=1)
497400 497400 497400 MERGE JOIN CARTESIAN (cr=47484 pr=55 pw=0 time=57182690 us cost=107 size=254 card=1)
12435 12435 12435 NESTED LOOPS (cr=47483 pr=55 pw=0 time=2368168 us cost=106 size=247 card=1)
13877 13877 13877 NESTED LOOPS (cr=33602 pr=55 pw=0 time=5930848 us cost=105 size=233 card=1)
1473 1473 1473 NESTED LOOPS (cr=212 pr=2 pw=0 time=9371 us cost=35 size=390 card=3)
13 13 13 HASH JOIN (cr=193 pr=1 pw=0 time=8029 us cost=34 size=116 card=1)
13 13 13 NESTED LOOPS (cr=191 pr=1 pw=0 time=7255 us cost=31 size=95 card=1)
338 338 338 HASH JOIN (cr=187 pr=1 pw=0 time=6329 us cost=31 size=2821 card=31)
13 13 13 VIEW VW_NSO_1 (cr=184 pr=1 pw=0 time=5958 us cost=26 size=26 card=1)
13 13 13 SORT GROUP BY (cr=184 pr=1 pw=0 time=5954 us cost=26 size=115 card=1)
65 65 65 NESTED LOOPS ANTI (cr=184 pr=1 pw=0 time=5898 us cost=25 size=115 card=1)
78 78 78 NESTED LOOPS (cr=102 pr=1 pw=0 time=6140 us cost=24 size=101 card=1)
78 78 78 NESTED LOOPS OUTER (cr=20 pr=1 pw=0 time=5341 us cost=23 size=94 card=1)
78 78 78 HASH JOIN (cr=19 pr=1 pw=0 time=5077 us cost=23 size=55 card=1)
13 13 13 HASH JOIN (cr=17 pr=1 pw=0 time=4056 us cost=17 size=352 card=8)
40 40 40 NESTED LOOPS (cr=13 pr=0 pw=0 time=3300 us cost=15 size=1480 card=40)
40 40 40 HASH JOIN OUTER (cr=9 pr=0 pw=0 time=2928 us cost=15 size=1320 card=40)
40 40 40 HASH JOIN (cr=7 pr=0 pw=0 time=1976 us cost=5 size=800 card=40)
40 40 40 INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=120 us cost=1 size=280 card=40)(object id 1354685)
80 80 80 VIEW index$_join$_044 (cr=6 pr=0 pw=0 time=1251 us cost=3 size=1040 card=80)
80 80 80 HASH JOIN (cr=6 pr=0 pw=0 time=1249 us)
80 80 80 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=70 us cost=1 size=1040 card=80)(object id 1354894)
80 80 80 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=3 pr=0 pw=0 time=135 us cost=1 size=1040 card=80)(object id 1354895)
0 0 0 VIEW (cr=2 pr=0 pw=0 time=295 us cost=10 size=143 card=11)
0 0 0 HASH JOIN (cr=2 pr=0 pw=0 time=293 us cost=8 size=352 card=11)
0 0 0 MERGE JOIN (cr=2 pr=0 pw=0 time=118 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=2 pr=0 pw=0 time=113 us cost=2 size=26 card=2)
83 83 83 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=1 pr=0 pw=0 time=116 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 135473
9)
0 0 0 VIEW index$_join$_049 (cr=0 pr=0 pw=0 time=0 us cost=3 size=1040 card=80)
0 0 0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX FAST FULL SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354894)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
78 78 78 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
13 13 13 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
0 0 0 INDEX FAST FULL SCAN XPKTIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=1040 card=80)(object id 1354895)
40 40 40 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=79 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=4 pr=1 pw=0 time=362 us cost=2 size=112 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=4 pr=1 pw=0 time=349 us cost=2 size=1216 card=16)
275 275 275 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=164 us cost=5 size=3025 card=275)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=136 us cost=0 size=39 card=1)
0 0 0 INDEX UNIQUE SCAN XPKTIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=52 us cost=0 size=0 card=1)(object id 1354925)
78 78 78 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGPERIOD (cr=82 pr=0 pw=0 time=343 us cost=1 size=7 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=144 us cost=0 size=0 card=1)(object id 1354899)
13 13 13 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGMETHODENUM (cr=82 pr=0 pw=0 time=252 us cost=1 size=14 card=1)
78 78 78 INDEX UNIQUE SCAN XPKTIBEX_TRADINGMETHODENUM (cr=4 pr=0 pw=0 time=98 us cost=0 size=0 card=1)(object id 1354897)
275 275 275 MERGE JOIN OUTER (cr=3 pr=0 pw=0 time=892 us cost=5 size=17875 card=275)
275 275 275 TABLE ACCESS BY INDEX ROWID TIBEX_CYCLEPERIODMAP (cr=2 pr=0 pw=0 time=401 us cost=2 size=4950 card=275)
275 275 275 INDEX FULL SCAN XPKTIBEX_CYCLEPERIODMAP (cr=1 pr=0 pw=0 time=115 us cost=1 size=0 card=275)(object id 1354681)
0 0 0 SORT JOIN (cr=1 pr=0 pw=0 time=207 us cost=3 size=47 card=1)
0 0 0 TABLE ACCESS FULL TIBEX_CYCLEPERIODMAPOVER (cr=1 pr=0 pw=0 time=17 us cost=2 size=47 card=1)
13 13 13 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=349 us cost=0 size=4 card=1)(object id 1354895)
13 13 13 VIEW (cr=2 pr=0 pw=0 time=52 us cost=2 size=336 card=16)
13 13 13 TABLE ACCESS FULL SYS_TEMP_0FD9D660D_F7392ACA (cr=2 pr=0 pw=0 time=49 us cost=2 size=1216 card=16)
1473 1473 1473 INDEX RANGE SCAN XPKTIBEX_INSTRUMENTBOARDMAP (cr=19 pr=1 pw=0 time=1378 us cost=1 size=504 card=36)(object id 1354759)
13877 13877 13877 TABLE ACCESS BY INDEX ROWID TIBEX_INSTRUMENTADMIN (cr=33390 pr=53 pw=0 time=2023879 us cost=27 size=103 card=1)
44576 44576 44576 INDEX RANGE SCAN SYS_C001331991 (cr=1277 pr=53 pw=0 time=43026 us cost=1 size=0 card=35)(object id 1354964)
12435 12435 12435 TABLE ACCESS BY INDEX ROWID TIBEX_INSTRACTIONENUM (cr=13881 pr=0 pw=0 time=81117 us cost=1 size=14 card=1)
13877 13877 13877 INDEX UNIQUE SCAN XPKTIBEX_INSTRACTIONENUM (cr=4 pr=0 pw=0 time=32628 us cost=0 size=0 card=1)(object id 1354753)
497400 497400 497400 BUFFER SORT (cr=1 pr=0 pw=0 time=323076 us cost=106 size=280 card=40)
40 40 40 INDEX RANGE SCAN XPKTIBEX_DAYSTRADINGCYCLEMAP (cr=1 pr=0 pw=0 time=61 us cost=1 size=280 card=40)(object id 1354685)
497400 497400 497400 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=497404 pr=0 pw=0 time=2609562 us cost=1 size=13 card=1)
497400 497400 497400 INDEX UNIQUE SCAN XPKTIBEX_TRADINGCYCLE (cr=4 pr=0 pw=0 time=1019970 us cost=0 size=0 card=1)(object id 1354895)
0 0 0 VIEW PUSHED PREDICATE (cr=994800 pr=0 pw=0 time=151415026 us cost=1 size=13 card=1)
0 0 0 HASH JOIN (cr=994800 pr=0 pw=0 time=150806856 us cost=7 size=32 card=1)
0 0 0 MERGE JOIN (cr=994800 pr=0 pw=0 time=19714460 us cost=4 size=209 card=11)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_HOLIDAYS (cr=994800 pr=0 pw=0 time=18729534 us cost=2 size=26 card=2)
41284200 41284200 41284200 INDEX FULL SCAN XPKTIBEX_HOLIDAYS (cr=497400 pr=0 pw=0 time=16264606 us cost=1 size=0 card=83)(object id 1354737)
0 0 0 SORT JOIN (cr=0 pr=0 pw=0 time=0 us cost=2 size=2412 card=402)
0 0 0 INDEX FULL SCAN XPKTIBEX_HOLIDAYTRADINGCYCLEMA (cr=0 pr=0 pw=0 time=0 us cost=1 size=2412 card=402)(object id 1354739)
0 0 0 TABLE ACCESS BY INDEX ROWID TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=2 size=26 card=2)
0 0 0 INDEX RANGE SCAN XAK1TIBEX_TRADINGCYCLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=2)(object id 1354894)
12435 12435 12435 INDEX UNIQUE SCAN XPKTIBEX_TRADINGPERIOD (cr=4 pr=0 pw=0 time=33106 us cost=0 size=4 card=1)(object id 1354899)
464 464 464 HASH JOIN SEMI (cr=386 pr=190 pw=0 time=30227 us cost=6 size=331 card=1)
5684 5684 5684 VIEW (cr=194 pr=190 pw=0 time=8864 us cost=2 size=582 card=2)
12435 12435 12435 TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=194 pr=190 pw=0 time=9137 us cost=2 size=272 card=2)
1267 1267 1267 VIEW VW_NSO_2 (cr=192 pr=0 pw=0 time=13710 us cost=3 size=80 card=2)
1267 1267 1267 HASH GROUP BY (cr=192 pr=0 pw=0 time=13074 us cost=3 size=38 card=2)
12435 12435 12435 VIEW (cr=192 pr=0 pw=0 time=11843 us cost=2 size=38 card=2)
12435 12435 12435 TABLE ACCESS FULL SYS_TEMP_0FD9D660E_F7392ACA (cr=192 pr=0 pw=0 time=5751 us cost=2 size=272 card=2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
Disk file operations I/O 1 0.00 0.00
direct path write temp 2 0.00 0.00
direct path sync 1 0.00 0.00
db file sequential read 55 0.00 0.00
SQL*Net message to client 6 0.00 0.00
db file scattered read 2 0.00 0.00
SQL*Net message from client 6 0.00 0.00Regards
NMHi,
Execution Plan after generating stats on TIBEX_TRADINGCYCLE.
Execution Plan
Plan hash value: 1209012613
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 291 | 130 (7)| 00:00:02 |
| 1 | VIEW | TIBEX_OPENINGHOMEMKTOK | 1 | 291 | 130 (7)| 00:00:02 |
| 2 | TEMP TABLE TRANSFORMATION | | | | | |
| 3 | LOAD AS SELECT | SYS_TEMP_0FD9D662B_FB42A6E1 | | | | |
|* 4 | HASH JOIN | | 8 | 1392 | 27 (12)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | TIBEX_TRADINGMETHODENUM | 1 | 14 | 5 (0)| 00:00:01 |
|* 6 | HASH JOIN | | 138 | 22080 | 21 (10)| 00:00:01 |
| 7 | NESTED LOOPS OUTER | | 138 | 16284 | 14 (15)| 00:00:01 |
|* 8 | HASH JOIN | | 138 | 9798 | 14 (15)| 00:00:01 |
|* 9 | HASH JOIN | | 40 | 2120 | 8 (13)| 00:00:01 |
| 10 | NESTED LOOPS OUTER | | 40 | 1240 | 5 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 40 | 800 | 3 (34)| 00:00:01 |
| 12 | VIEW | index$_join$_018 | 80 | 1040 | 3 (34)| 00:00:01 |
|* 13 | HASH JOIN | | | | | |
| 14 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 15 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 1 | 7 | 0 (0)| 00:00:01 |
| 17 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 18 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 19 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID | TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 21 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|* 22 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 23 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
| 26 | VIEW | index$_join$_024 | 80 | 1760 | 3 (34)| 00:00:01 |
|* 27 | HASH JOIN | | | | | |
| 28 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1760 | 1 (0)| 00:00:01 |
| 29 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1760 | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS FULL | TIBEX_CYCLEPERIODMAP | 275 | 4950 | 5 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 47 | 0 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
| 33 | TABLE ACCESS FULL | TIBEX_TRADINGPERIOD | 330 | 13860 | 7 (0)| 00:00:01 |
| 34 | LOAD AS SELECT | SYS_TEMP_0FD9D662C_FB42A6E1 | | | | |
| 35 | NESTED LOOPS | | 1 | 282 | 98 (5)| 00:00:02 |
|* 36 | FILTER | | | | | |
| 37 | NESTED LOOPS OUTER | | 1 | 278 | 98 (5)| 00:00:02 |
| 38 | NESTED LOOPS | | 1 | 267 | 97 (5)| 00:00:02 |
| 39 | MERGE JOIN CARTESIAN | | 1 | 254 | 96 (5)| 00:00:02 |
| 40 | NESTED LOOPS | | | | | |
| 41 | NESTED LOOPS | | 1 | 247 | 95 (5)| 00:00:02 |
| 42 | NESTED LOOPS | | 1 | 233 | 94 (5)| 00:00:02 |
| 43 | NESTED LOOPS | | 3 | 390 | 24 (17)| 00:00:01 |
|* 44 | HASH JOIN | | 1 | 116 | 23 (18)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 95 | 21 (20)| 00:00:01 |
| 46 | NESTED LOOPS OUTER | | 31 | 2821 | 21 (20)| 00:00:01 |
| 47 | NESTED LOOPS | | 31 | 1364 | 21 (20)| 00:00:01 |
| 48 | VIEW | VW_NSO_1 | 1 | 26 | 18 (17)| 00:00:01 |
| 49 | SORT GROUP BY | | 1 | 113 | 18 (17)| 00:00:01 |
| 50 | NESTED LOOPS ANTI | | 1 | 113 | 17 (12)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 99 | 16 (13)| 00:00:01 |
| 52 | NESTED LOOPS OUTER | | 1 | 92 | 15 (14)| 00:00:01 |
|* 53 | HASH JOIN | | 1 | 53 | 15 (14)| 00:00:01 |
|* 54 | HASH JOIN | | 8 | 336 | 9 (12)| 00:00:01 |
| 55 | NESTED LOOPS | | 40 | 1400 | 7 (15)| 00:00:01 |
| 56 | NESTED LOOPS OUTER | | 40 | 1240 | 7 (15)| 00:00:01 |
|* 57 | HASH JOIN | | 40 | 800 | 4 (25)| 00:00:01 |
|* 58 | INDEX RANGE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 40 | 280 | 1 (0)| 00:00:01 |
| 59 | VIEW | index$_join$_044 | 80 | 1040 | 3 (34)| 00:00:01 |
|* 60 | HASH JOIN | | | | | |
| 61 | INDEX FAST FULL SCAN | XAK1TIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 62 | INDEX FAST FULL SCAN | XPKTIBEX_TRADINGCYCLE | 80 | 1040 | 1 (0)| 00:00:01 |
| 63 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 64 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 65 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|* 66 | TABLE ACCESS BY INDEX ROWID| TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 67 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|* 68 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 69 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|* 71 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
|* 72 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | 4 | 0 (0)| 00:00:01 |
| 73 | VIEW | | 16 | 112 | 2 (0)| 00:00:01 |
| 74 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662B_FB42A6E1 | 16 | 1216 | 2 (0)| 00:00:01 |
| 75 | TABLE ACCESS FULL | TIBEX_CYCLEPERIODMAP | 275 | 3025 | 5 (0)| 00:00:01 |
| 76 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 39 | 0 (0)| 00:00:01 |
|* 77 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
| 78 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGPERIOD | 1 | 7 | 1 (0)| 00:00:01 |
|* 79 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGPERIOD | 1 | | 0 (0)| 00:00:01 |
|* 80 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGMETHODENUM | 1 | 14 | 1 (0)| 00:00:01 |
|* 81 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGMETHODENUM | 1 | | 0 (0)| 00:00:01 |
| 82 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAP | 31 | 558 | 2 (0)| 00:00:01 |
|* 83 | INDEX SKIP SCAN | XPKTIBEX_CYCLEPERIODMAP | 31 | | 1 (0)| 00:00:01 |
| 84 | TABLE ACCESS BY INDEX ROWID | TIBEX_CYCLEPERIODMAPOVER | 1 | 47 | 0 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | XPKTIBEX_CYCLEPERIODMAPOVER | 1 | | 0 (0)| 00:00:01 |
|* 86 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | 4 | 0 (0)| 00:00:01 |
| 87 | VIEW | | 16 | 336 | 2 (0)| 00:00:01 |
| 88 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662B_FB42A6E1 | 16 | 1216 | 2 (0)| 00:00:01 |
|* 89 | INDEX RANGE SCAN | XPKTIBEX_INSTRUMENTBOARDMAP | 36 | 504 | 1 (0)| 00:00:01 |
|* 90 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRUMENTADMIN | 1 | 103 | 27 (0)| 00:00:01 |
|* 91 | INDEX RANGE SCAN | SYS_C001331991 | 35 | | 1 (0)| 00:00:01 |
|* 92 | INDEX UNIQUE SCAN | XPKTIBEX_INSTRACTIONENUM | 1 | | 0 (0)| 00:00:01 |
|* 93 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRACTIONENUM | 1 | 14 | 1 (0)| 00:00:01 |
| 94 | BUFFER SORT | | 40 | 280 | 95 (5)| 00:00:02 |
|* 95 | INDEX RANGE SCAN | XPKTIBEX_DAYSTRADINGCYCLEMAP | 40 | 280 | 1 (0)| 00:00:01 |
| 96 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 1 | 13 | 1 (0)| 00:00:01 |
|* 97 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGCYCLE | 1 | | 0 (0)| 00:00:01 |
| 98 | VIEW PUSHED PREDICATE | | 1 | 11 | 1 (0)| 00:00:01 |
|* 99 | HASH JOIN | | 1 | 32 | 7 (29)| 00:00:01 |
| 100 | MERGE JOIN | | 3 | 57 | 4 (25)| 00:00:01 |
|*101 | TABLE ACCESS BY INDEX ROWID | TIBEX_HOLIDAYS | 1 | 13 | 2 (0)| 00:00:01 |
| 102 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYS | 83 | | 1 (0)| 00:00:01 |
|*103 | SORT JOIN | | 402 | 2412 | 2 (50)| 00:00:01 |
| 104 | INDEX FULL SCAN | XPKTIBEX_HOLIDAYTRADINGCYCLEMA | 402 | 2412 | 1 (0)| 00:00:01 |
| 105 | TABLE ACCESS BY INDEX ROWID | TIBEX_TRADINGCYCLE | 2 | 26 | 2 (0)| 00:00:01 |
|*106 | INDEX RANGE SCAN | XAK1TIBEX_TRADINGCYCLE | 2 | | 1 (0)| 00:00:01 |
|*107 | INDEX UNIQUE SCAN | XPKTIBEX_TRADINGPERIOD | 1 | 4 | 0 (0)| 00:00:01 |
|*108 | HASH JOIN SEMI | | 1 | 331 | 6 (34)| 00:00:01 |
|*109 | VIEW | | 2 | 582 | 2 (0)| 00:00:01 |
| 110 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_FB42A6E1 | 2 | 272 | 2 (0)| 00:00:01 |
| 111 | VIEW | VW_NSO_2 | 2 | 80 | 3 (34)| 00:00:01 |
| 112 | HASH GROUP BY | | 2 | 38 | 3 (34)| 00:00:01 |
| 113 | VIEW | | 2 | 38 | 2 (0)| 00:00:01 |
| 114 | TABLE ACCESS FULL | SYS_TEMP_0FD9D662C_FB42A6E1 | 2 | 272 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------------------------------ -
Tkprof not showing the Execution Plan for Statement
Hi all
using oracle 9i release 2
I have issued the following statements
alter session set sql_trace
alter session set events '10046 trace name context forever, level 12';
--then executed a pl-sql procedure
after reading the traceout outfile it shows the Execution plan for statements directly wirtten under begin and end block and doesnot displays the plan for the statements written like this
procedure a is
cursor b is
select ename,dname from dept a,emp b
where a.deptno=b.deptno;
begin
for x in a loop --plan not found but stats are written
select ename into v_ename from emp where empno=300; --does show the plan+stats
end;
what I am missing to get the actual plan in trace output file
thanks in advanceYou have to exit sql*plus after running the procedure, example tkprof is below:
declare
cursor c is
select ename, dname
from emp, dept
where emp.deptno = dept.deptno;
begin
for v_x in c
loop
dbms_output.put_line(v_x.ename || ' ' ||v_x.dname);
end loop;
end;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.06 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.06 0 0 0 1
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 68
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
SELECT ENAME, DNAME
FROM
EMP, DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 15 0.01 0.00 0 44 0 14
total 17 0.01 0.00 0 44 0 14
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 68 (recursive depth: 1)
Rows Row Source Operation
14 NESTED LOOPS
14 TABLE ACCESS FULL EMP
14 TABLE ACCESS BY INDEX ROWID DEPT
14 INDEX UNIQUE SCAN DEPT_PK (object id 40350)
Best Regards
Krystian Zieja / mob -
How to fix different execution plan for different bind variable values?
Please find the below query. The execution plan is fine. The problem That I am facing is in some cases for different bind variable values execution plan gets changed and degrades performance. I have used 6 tables here and all of the tables have histogram on all columns. Database version is Oracle 10g and the value of method_opt is 'For all columns size auto'
SELECT l.LineNumber INTO :b0
FROM Lines l ,LineVersions lv ,Statuses s
WHERE (((((((((((l.serviceContractId=:b1 AND l.LineId<>:b2)
AND lv.LineId=l.LineId) AND lv.StatusId=s.StatusId)
AND s.Code IN ('EPR','ERE','EEP','ERP','PRP','PRD','AAC'))
AND NOT (s.CODE='AAC' AND lv.activeto<TO_DATE(:b3,:b4)))
AND lv.EquipmentDetailId=:b5) AND lv.RouteDetailId=:b6)
AND (lv.cargoDetailId=:b7 OR lv.cargoDetailId IN
(SELECT i_cd1.cargoDetailId
FROM CargoDetails i_cd1 ,CargoDetails i_cd2 ,CargoCommodities i_cc1 ,
CargoCommodities i_cc2 WHERE
((((((i_cd2.cargoDetailId=:b7 AND i_cd1.cargoDetailId<>:b7)
AND i_cd1.ServiceContractId=:b1) AND i_cd1.cargoTypeId=i_cd2.cargoTypeId)
AND i_cc1.cargoDetailId=i_cd1.cargoDetailId)
AND i_cc2.cargoDetailId=i_cd2.cargoDetailId)
AND i_cc1.commodityId=i_cc2.commodityId))))
AND ((lv.customerGroupId IS NULL AND :b11=0) OR lv.customerGroupId IN
(SELECT cgm1.customerGroupId
FROM CustomerGroupMembers cgm1 ,CustomerGroupMembers cgm2 ,CustomerGroups cg1
WHERE (((cgm2.customerGroupId=:b11 AND cgm1.customerNoId=cgm2.customerNoId)
AND cg1.CustomerGroupId=cgm1.CustomerGroupId)
AND cg1.ServiceContractId=l.ServiceContractId)))) AND lv.linetype='C')
AND ROWNUM=1)
After searching in several blogs I have found the below solutions. Please see it and let me know it is correct or not
Solution 1:-Get rid of histogram that does nothing but messes up execution plan by giving below command
exec dbms_stats.gather_table_stats(owner, tablename, method_opt => 'for all columns size 1', cascade => true);
As 6 tables are there I need to execute above command 6 times.
Solution 2:- Use stored outline. Not sure how to get the best execution plan.
I am looking for answers ASAP. Thanks in advanceAs you have probably read, bind variables and histograms do not mix well.
Histograms suggest that you have skew in your data such that different values should get different plans
Bind variables exist so that SQL with different supplied values can be shared.
Mix the two together and at parse time with bind variable peeking you get plans for specific values shared for all values.
The solutions you have mentioned are the common approaches, together with a third - use literals not binds if you've got data skew (i.e. your histograms are justified) and don't want shared SQL.
I would have thought that getting rid of some of these histograms may be the right approach if you're none of your application SQL is using literals to benefit from them.
Can you confirm your version of Oracle.
Further reading:
http://jonathanlewis.wordpress.com/2009/05/06/philosophy-1/
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
http://richardfoote.wordpress.com/2008/01/04/dbms_stats-method_opt-default-behaviour-changed-in-10g-be-careful/ -
Hi all,
Is there a way to direct oracle to use the user defined execution plan for a given query without using hints. I can't change the code as it will be generated by the third part tool. Can I use outlines to force the queries to use the execution plan defined by me. In other words can I force the hint without changing the query?
Can I use stored outline to achieve this? If yes can I have some examples?
I tried finding the answer in the internet but unsuccessful...
Thanks in advance,
JaggyamHi,
Thank you very much for the response.
Sorry I forgot to mention the Oracle version. It is Oracle 9i release 2.
Can someone post the link for examples... All the info I found so far is very high level
Thanks,
Jaggyam
Maybe you are looking for
-
1.5.1 - printing problem with HP DesignJet 90
I made several 18" x 24" prints using 1.5 on the HP DJ 90 this morning and they printed fine, as they always have. After upgrading to 1.5.1, the first print ceased printing at 20", the next at 8". There were no other equipment changes before or after
-
Hi all, I'm trying to export an internal table to Excel, but I have a problem. As the internal table has about 1700 records, the function GUI_DOWNLOAD only download about 1600. I have already tried with method cl_gui_frontend_services = > gui_downloa
-
Why can't I get my iMessage & ICloud to work on my iPad???
Why can't I get my iMessage & ICloud to work on my iPad???
-
Flash video not reporting when finsihed
Using a flash video object in Flash 9 via netStream off my local hard drive I am finding when my long video reaches the end I don't get the expected NetSream.Play.Stop. I just get this from the netStream.onStatus at the end of the video status : NetS
-
Hi Since updating to ios 7.04 i have noticed the phone consumes so much more power. I have to charge the phone twice sometimes 3 times a day. WHY?