How do i see query EXECUTION PLAN
Dear Experts ,
I'm using Toad, PL/SQL developer and working on very big query but its response is very slow could u please guide any one HOW I SEE EXECUTION PLAN of query to optimize further.
Faheem Latif
NetSol Technologies Limited Pakistan.
www.netsoltek.com, www.leasesoft.biz
Dear ,
Thank's for reply but it is showing this error.
"ORA-02404: specified plan table not found"
Faheem Latif
NetSol Technologies Limited Pakistan.
www.netsoltek.com, www.leasesoft.biz
Similar Messages
-
How i can find the execution plan
how i can find the execution plan for a quesry , and how i can compare two execution plan
Mohan,
Just create a table as follows
CREATE TABLE T1 (STATEMENT_ID VARCHAR2(30),TIMESTAMP DATE,OPERATION VARCHAR2(30),
OPTIONS VARCHAR2(30),OBJECT_NAME VARCHAR2(30),COST NUMBER(38),
ID NUMBER(38),PARENT_ID NUMBER(38), OBJECT_NODE VARCHAR2(128),
OBJECT_OWNER VARCHAR2(30),OBJECT_INSTANCE NUMBER(38),OBJECT_TYPE VARCHAR2(30),
OPTIMIZER VARCHAR2(255),SEARCH_COLUMNS NUMBER,POSITION NUMBER(38),
PARTITION_START VARCHAR2(255),PARTITION_STOP VARCHAR2(255),PARTITION_ID NUMBER(38),
CARDINALITY NUMBER(38),BYTES NUMBER(38),OTHER_TAG VARCHAR2(255),
OTHER LONG,REMARKS VARCHAR2(80),DISTRIBUTION VARCHAR2(30)
Now use the sql statements as
> EXPLAIN PLAN INTO T1 FOR (SELECT * FROM EMP);
> Select * from T1
this should do the job . . .
Regards,
K.T. Gandhi Karuna -
Hi,
I have a question about reading query execution plans. I don't understand what is meant by "Hash join" in a plan step. I understand "Nested_Loops" and "Merge_Join", but after looking at different documentations, I am still not clear about "Hash_Join". Please don't give links to Oracle documentation, because I have seen a lot of it, but it is still not clear. I also don't fully understand what is meant by a "Hash Table", what are all these "Hashesssssss"???
Please explain in your own words, if possible, and with the help of some example.
Thanks in Advance.,user566817 wrote:
Can any one else answer my question? I would be highly thankful.Hash joins are one of the 3 techniques used by Oracle to join to sets of data.
As a brief, and very very crude overview
Generally after applying the filter to one data source, the join key is hashed into a memory table (as described by link sb provided). The second data set areas filtered and it's join key is also hashed, but the hash is used to find matches in the memory table created by the first data source. Assuming no hash chaining, found matches are joins; if hassh chaining exists, the chain needs to be traversed to verify joins.
This, of course, has a lot of holes which would be filled in by the documentation and by external links that you do not seem to want to use.
(Remember: School papers need to cite references. Teachers these days DO check.) -
Explain SQL Query execution plan: Oracle
Dear Masters,
Kindly help me to understand execution plan for an SQL statement. I have following SQL execution plan for a query in system. How should I interpret it. I thank You in advace for your guidance.
SELECT STATEMENT ( Estimated Costs = 1.372.413 , Estimated #Rows = 0 )
5 NESTED LOOPS
( Estim. Costs = 1.372.413 , Estim. #Rows = 3.125 )
Estim. CPU-Costs = 55.798.978.498 Estim. IO-Costs = 1.366.482
2 TABLE ACCESS BY INDEX ROWID MSEG
( Estim. Costs = 1.326.343 , Estim. #Rows = 76.717 )
Estim. CPU-Costs = 55.429.596.575 Estim. IO-Costs = 1.320.451
Filter Predicates
1 INDEX RANGE SCAN MSEG~R
( Estim. Costs = 89.322 , Estim. #Rows = 60.069.500 )
Search Columns: 1
Estim. CPU-Costs = 2.946.739.229 Estim. IO-Costs = 89.009
Access Predicates
4 TABLE ACCESS BY INDEX ROWID MKPF
( Estim. Costs = 1 , Estim. #Rows = 1 )
Estim. CPU-Costs = 4.815 Estim. IO-Costs = 1
Filter Predicates
3 INDEX UNIQUE SCAN MKPF~0
Search Columns: 3
Estim. CPU-Costs = 3.229 Estim. IO-Costs = 0
Access PredicatesHi Panjak,
Yeahh, there's a huge unperformatic SQL statment, what I can see from this acces plan is:
1 DBO decided to start the query on index R on MSEG, using only part of the index (only one column) with no good uniqueness, accessing disk IO-Costs for this (60mi records), and expecting many interactions (loops) in memory to filter, see CPU-Costs.
So with the parameters you gave to SQL, they start in a very bad way.
2 After that program will access the MSEG commanded by what was found on First step, also with a huge loading from DB and filtering (another where criteria on MSEG fields, not found on index R), reducing the result set to 76.717 rows.
3/4 With this, program goes direct to primary key index on MKPF with direct access (optimized access) and follow to access database table MKPF.
5 At last will "loop" the result sets from MSEG and MKPF, mixing the tuplas generating the final result set.
Do you want to share your SQL, the parameters you are sending and code which generate it with us?
Regards, Fernando Da Ró -
How can I get an execution plan for a Function in oracle 10g
Hi
I have:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I would like to know if is possible to get an EXECUTION PLAN for a FUNCTION if so, how can I get it ?
RegardsYou can query the AWR data if your interesting SQL consumes enough resources.
Here is a SQL*Plus script I call MostCPUIntensiveSQLDuringInterval.sql (nice name eh?)
You'll need to know the AWR snap_id numbers for the time period of interest, then run it like this to show the top 20 SQLs during the interval:
@MostCPUIntensiveSQLDuringInterval 20The script outputs a statement to run when you are interested in looking at the plan for an interesting looking statement.
-- MostCPUintesticeSQLDuringInterval: Report on the top n SQL statements during an AWR snapshot interval.
-- The top statements are ranked by CPU usage
col inst_no format 999 heading 'RAC|Node'
col sql_id format a16 heading 'SQL_ID'
col plan_hash_value format 999999999999 heading 'Plan|hash_value'
col parsing_schema_name format a12 heading 'Parsing|Schema'
col module format a10 heading 'Module'
col pct_of_total format 999.99 heading '% Total'
col cpu_time format 999,999,999 heading 'CPU |Time (ms)'
col elapsed_time format 999,999,999 heading 'Elapsed |Time (ms)'
col lios format 9,999,999,999 heading 'Logical|Reads'
col pios format 999,999,999 heading 'Physical|Reads'
col execs format 99,999,999 heading 'Executions'
col fetches format 99,999,999 heading 'Fetches'
col sorts format 999,999 heading 'Sorts'
col parse_calls format 999,999 heading 'Parse|Calls'
col rows_processed format 999,999,999 heading 'Rows|Processed'
col iowaits format 999,999,999,999 heading 'iowaits'
set lines 195
set pages 75
PROMPT Top &&1 SQL statements during interval
SELECT diff.*
FROM (SELECT e.instance_number inst_no
,e.sql_id
,e.plan_hash_value
,e.parsing_schema_name
,substr(trim(e.module),1,10) module
,ratio_to_report(e.cpu_time_total - b.cpu_time_total) over (partition by 1) * 100 pct_of_total
,(e.cpu_time_total - b.cpu_time_total)/1000 cpu_time
,(e.elapsed_time_total - b.elapsed_time_total)/1000 elapsed_time
,e.buffer_gets_total - b.buffer_gets_total lios
,e.disk_reads_total - b.disk_reads_total pios
,e.executions_total - b.executions_total execs
,e.fetches_total - b.fetches_total fetches
,e.sorts_total - b.sorts_total sorts
,e.parse_calls_total - b.parse_calls_total parse_calls
,e.rows_processed_total - b.rows_processed_total rows_processed
-- ,e.iowait_total - b.iowait_total iowaits
-- ,e.plsexec_time_total - b.plsexec_time_total plsql_time
FROM dba_hist_sqlstat b -- begining snap
,dba_hist_sqlstat e -- ending snap
WHERE b.sql_id = e.sql_id
AND b.dbid = e.dbid
AND b.instance_number = e.instance_number
and b.plan_hash_value = e.plan_hash_value
AND b.snap_id = &LowSnapID
AND e.snap_id = &HighSnapID
ORDER BY e.cpu_time_total - b.cpu_time_total DESC
) diff
WHERE ROWNUM <=&&1
set define off
prompt to get the text of the SQL run the following:
prompt @id2sql &SQL_id
prompt .
prompt to obtain the execution plan for a session run the following:
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID'));
prompt or
prompt select * from table(DBMS_XPLAN.DISPLAY_AWR('&SQL_ID',NULL,NULL,'ALL'));
prompt .
set define on
undefine LowSnapID
undefine HighSnapIDI guess you'll need the companion script id2sql.sql, so here it is:
set lines 190
set verify off
declare
maxDisplayLine NUMBER := 150; --max linesize to display the SQL
WorkingLine VARCHAR2(32000);
CurrentLine VARCHAR2(64);
LineBreak NUMBER;
cursor ddl_cur is
select sql_id
,sql_text
from v$sqltext_with_newlines
where sql_id='&1'
order by piece
ddlRec ddl_cur%ROWTYPE;
begin
WorkingLine :='.';
OPEN ddl_cur;
LOOP
FETCH ddl_cur INTO ddlRec;
EXIT WHEN ddl_cur%NOTFOUND;
IF ddl_cur%ROWCOUNT = 1 THEN
dbms_output.put_line('.');
dbms_output.put_line(' sql_id: '||ddlRec.sql_id);
dbms_output.put_line('.');
dbms_output.put_line('.');
dbms_output.put_line('SQL Text');
dbms_output.put_line('----------------------------------------------------------------');
END IF;
CurrentLine := ddlRec.sql_text;
WHILE LENGTH(CurrentLine) > 1 LOOP
IF INSTR(CurrentLine,CHR(10)) > 0 THEN -- if the current line has an embeded newline
WorkingLine := WorkingLine||SUBSTR(CurrentLine,1,INSTR(CurrentLine,CHR(10))-1); -- append up to new line
CurrentLine := SUBSTR(CurrentLine,INSTR(CurrentLine,CHR(10))+1); -- strip off up through new line character
dbms_output.put_line(WorkingLine); -- print the WorkingLine
WorkingLine :=''; -- reset the working line
ELSE
WorkingLine := WorkingLine||CurrentLine; -- append the current line
CurrentLine :=''; -- the rest of the line has been processed
IF LENGTH(WorkingLine) > maxDisplayLine THEN -- the line is morethan the display limit
LineBreak := instr(substr(WorkingLine,1,maxDisplayLine),' ',-1); --find the last space before the display limit
IF LineBreak = 0 THEN -- there is no space, so look for a comma instead
LineBreak := substr(WorkingLine,instr(substr(WorkingLine,1,maxDisplayLine),',',-1));
END IF;
IF LineBreak = 0 THEN -- no space or comma, so force the line break at maxDisplayLine
LineBreak := maxDisplayLine;
END IF;
dbms_output.put_line(substr(WorkingLine,1,LineBreak));
WorkingLine:=substr(WorkingLine,LineBreak);
END IF;
END IF;
END LOOP;
--dbms_output.put(ddlRec.sql_text);
END LOOP;
dbms_output.put_line(WorkingLine);
dbms_output.put_line('----------------------------------------------------------------');
CLOSE ddl_cur;
END;
/ -
How to get the query execution time
Hi,
I am new to oracle and I am trying to get the execution time of a query.I tried the command set timing on and executed the query.But,the time it gives me is including the display of results.In my case,I ran a query against 50 million records and it is taking around 5 hours to display all the results.I like to know,how much time it take just to execute the query?Please help.
Thanks
Ravi.Maybe this way ?
TEST@db102 SQL> set timing on
TEST@db102 SQL> set autotrace traceonly
TEST@db102 SQL> select * from foo;
332944 rows selected.
Elapsed: 00:00:29.04
Execution Plan
Plan hash value: 1245013993
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 274K| 46M| 1071 (5)| 00:00:13 |
| 1 | TABLE ACCESS FULL| FOO | 274K| 46M| 1071 (5)| 00:00:13 |
Note
- dynamic sampling used for this statement
Statistics
288 recursive calls
0 db block gets
26570 consistent gets
4975 physical reads
0 redo size
35834383 bytes sent via SQL*Net to client
244537 bytes received via SQL*Net from client
22198 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
332944 rows processed
TEST@db102 SQL> -
How to get the SQL Execution Plan from complex Extractors ?
Hi
I am looking for a way to get the
SQL Execution Plan(s!)
from
Complex Extractors like 0CO_OM_CCA_9 ?
Anybody has got a suggestion ?
How to get this in SM50 ?
ThanXs
MartinIdentifying the query is the hard part. If you can identify it(based on table access or some such parameter, getting the execution plan is easy in ST04 .
-
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 |
------------------------------------------------------------------------------------------------------------------------------------------ -
How to clear out failed Execution Plans?
Hi everyone,
This should be an easy thing but I can't seem to figure out how to do it.
I created a custom execution plan and added every Financial Subject Area into the plan. Then I generated the parameters, clicked build and then ran it. The run failed.
I noticed that there was a pre-configured execution plan with "Financials_Oracle R12" and decided that what I really wanted to run was Financials_Oracle R12 and not my custom plan. So I clicked build for Financials_Oracle R12 execution plan and once that finished, I clicked "Run Now". Upon clicking run now it told me that my custom execution plan had finished with a failed status and until it completed successfully, no other plans could be ran. I really don't want my custom plan to complete successfully. I want to run the other plan instead.
How do I delete/clear out my failed run data so I can start a new execution plan?
Thanks for the help!
-JoeIn DAC under the EXECUTE window do the following:
- Navigate to the 'Current Run' tab.
- Highlight the failed execution plan.
- Right click and seleted 'Mark as completed.'
- Enter the numbers/text in the box.
Then:
- In the top toolbar select Tools --> ETL Management --> Reset Data Sources
- Enter the numbers/text in the boox.
Now you're ready to start the new execution plan.
Hope this helps.
- Austin -
How do I create custom execution plan in DAC
Hi,
I need to create custom execution plan in DAC to load data into set of tables. actually schema we are building having 2 custom dim tables, 8 OOTB tables (Fact and Dim). So I need to copy existing OOTB execution plan, remove unwanted tables, tasks ect and rebuild. But I don't know exact process to do that Could you please provide step by step details?
We are using OBIEE 10.1.3.4.1, BI Apps 7.9.6.1 and DAC client is on windows XP.
Appreciate your help!
Thanks
Jay.Hi,
I created new container which is a copy of Siebel 8.1.1 and then created new subject area, in tables child tab added one fact table and then clicked on assemble and clicked on save button. I got the message saying it is successfully assembled. I did checked tasks, and related dim tables cant see any for this new subject area. and another strage thing is I navigated to execution plans and again clicked on design tab now I cant see new subject area. when I try to add it again it is saying subject area with that name already available but I cant see it there. I did this twice but not able to fix the problem.
Appreciate your help!
Thanks
Jay. -
How Can I reduce Query Execution time with use of filter
Dear Experts,
In a query execution is faster when there is no product filter and these products can be a list contaning mare than 300 items.
I am using In operator for that filter.Maybe if you posted the quer[y][ies] we could get a better idea.
-
How to know exact query execution time.
Hi,
I want to know what is exact query execution time which excludes network access, constructing results. Please suggest me.
Thanks in advance,
Satish.GNot sure I know what you really want, but if this is a testing phase sort of thing and you are running on unix, there is the time command.
If you want something that is part of your application, you can run a timer in a separate Thread - for approximate time.
If you want more precise time, you can use java.util.Date - it has a method getTime(), which you can use before processing and again after processing and subtract the former from the later. -
How do you view the execution plan of a query?
I want to see if a particular index was used for a specific query....
Becareful. You are in the Forum of OBIEE. It's much more a database question.
You can read an plan with a lot of tool. Toad permit it and I assume that Sql Developer also must give it.
Otherwise, you can use the basic command of Oracle as explain plan :
http://gerardnico.com/wiki/database/oracle/explain_plan
Cheers
Nico -
How to know the query execution time
Hi All,
I want to know the execution time taken for a particular query, How should i get that information ?
say for example,
select * from emp
after getting the result, i want to know the time taken for completing the execution.
How ?
Inputs are welcome !BTW it was already written in a response to you yestreday:
Re: Query Plan
Gints Plivna
http://www.gplivna.eu -
How to reduce the query execution time
hai all,
We have created query on Purchasing Cube 0PUR_C01 for
Purchase Order (PO) analysis for single vendor materials, but it is taking long time to execute (about 45 sec...).
In the above Query we have used the following things:
In Columns:
i) Exceptional aggregation for maximum & minimum PO Net Price using reference characteristic as Calendar Day.
ii) Minimum PO Price value we have multiplied with Actual GR Quantity for the calculation of Impact of Lowest PO Net Price.
iii) Number of vendors calculated key figure.
In Rows:i) Only Material
In Filters:
i) Plant with variable select Option u2013 Optional.
ii) Calendar Year / Month with Select Option u2013 Optional.
iii) Material with excluded Unassigned (#).
iv) Vendor with excluded Unassigned (#).
Following are we have used for Performance:
i) Aggregates using Propose from query (only for this query).
ii) Partitioning on Calendar Year / Month (For 1 year 14 partitions) i.e. (04.2007 to 03.2008).
iii) Collapse.
iv) In RSRT we have set the following properties
Read Mode = H
Req.Status = 0
Catch Mode = 4
Persistence Mode = 3 (BLOB)
Optimization mode = 0.
Our inputs to this Query:
i) We are passing plant range 1201 to 1299.
ii) Calendar Year / Month 04.2007 to 03.2008.
So please suggest me how to reduce the execution time.
please help me.
Thanks,
kiran manyamHi,
First of all its a complete question with all the details. Good work.
As you partitioned the cube based on calmonth and you are also giving calmonth in selection, it will definitely work towards improved query performance.
As you are putting plant values in the selection, is there any aggregate available on plant characteristics? If not creating a aggregate on plant will help.
Regards,
Yogesh
Maybe you are looking for
-
Quicktime fails because 3ivx_dec.dll is not found
I keep getting a window titled "QuicktimePlayerMain:QuickTime Player.exe - Unable to find Component." "This application failed to start because 3ivx_dec.dll was not found. Reinstalling the application may fix this problem." I have un-installed and re
-
Aggregate Device not recognising Built-In Input
How do I get my Aggregate Device to recognise the 'Built-In Input" in my iMac? In the Audio Devices window, I have set my Aggregate Device to be the sound input master to allow me to choose 'Aggregate Device' as the Input Device in Logic Pro X . This
-
Hello I am writing a pl-sql which will perform SCD type 1. The Type 1 methodology overwrites old data with new data, and therefore does not track historical data at all. This is most appropriate when correcting certain types of data errors, such as t
-
Guys, I have to bring in 2 master data fields from R/3 into BW. I have decided to created three infoobjects to map to those fields and add those three infoobjects to my Custom infoobject (ZTYPE) as attributes. The problem is that this ZTYPE infoobj
-
Abobe Premiere Elements 12 Rendering Issue
After clicking "Render" button, the program runs about a few seconds and stop. Meanwhile, a error message pops up, asking to copy and paste the provided serial number on the given adobe website to get decode. When you do it, the website shows another