Cost vs Execution Time
Query Without Index Hint
Cost is 11 and the execution time of the Query is 5 secs
Query With Index Hint
Cost is 3453 and the execution time for the query is 560 msecs.
Can anyone tell me which one I should be using the one with minimal cost or with minimal execution time?
Thanks
> Without Hint
The query uses Index I2 Excecution time 5 secs
With Hint
560msecs
And that explains the so-called CBO cost anomaly between the two.
When you add a hint to a query, you're forcing the CBO to change the "expense" of I/O paths and rate, for example, the forced (hinted) index as a cheaper path than the default index - as the CBO needs to "push" that hinted index up the chain as a cheaper path.
Costs are internally adjusted due to that hint in order to satisfy that hint (or at least try to). The resulting cost determined by the CBO is for all intends and purposes a random number when used as a comparison with the costs of same query without a hint or with a different hint.
Similar Messages
-
How query cost and execution time are releated ?
hi experts,
i am curious to know, how the query cost and execution time is related?
Query taking less time ,query cost is 65%, but query taking more time but query cost is 0%.
how to connect both and improve query performance.
Thanksi think you are refering to cost (relative to the batch) execution 65%, where there are more that one statement, it may compare the cost of each statement with in the batch
i assume it mainly take subtree cost and IO stat as cost, but in some cases i may wrong when there is multi line function and many other facter influence the cost, and i would say it depends on the query
cost is unit-less
The reason these costs exist is because of the query optimization SQL Server does: it does cost-based optimization, which means that the optimizer formulates a lot of different ways to execute the query, assigns a cost to each of these alternatives, and
chooses the one with the least cost. The cost tagged on each alternative is heurestically calculated, and is supposed to roughly reflect the amount of processing and I/O this alternative is going to take.
refer :
http://blogs.msdn.com/b/sqlqueryprocessing/archive/2006/10/11/what-is-this-cost.aspx
Thanks
Saravana kumar C -
How to get the total execution time from a tkprof file
Hi,
I have a tkprof file. How can I get the total execution time. Going through the file i guess the sum of "Total Waited" would give the total time in the section "Elapsed times include waiting on following events:"
. The sample of tkprof is given below.
SQL ID: gg52tq1ajzy7t Plan Hash: 3406052038
SELECT POSTED_FLAG
FROM
AP_INVOICE_PAYMENTS WHERE CHECK_ID = :B1 UNION ALL SELECT POSTED_FLAG FROM
AP_PAYMENT_HISTORY APH, AP_SYSTEM_PARAMETERS ASP WHERE CHECK_ID = :B1 AND
NVL(APH.ORG_ID, -99) = NVL(ASP.ORG_ID, -99) AND
(NVL(ASP.WHEN_TO_ACCOUNT_PMT, 'ALWAYS') = 'ALWAYS' OR
(NVL(ASP.WHEN_TO_ACCOUNT_PMT, 'ALWAYS') = 'CLEARING ONLY' AND
APH.TRANSACTION_TYPE IN ('PAYMENT CLEARING', 'PAYMENT UNCLEARING')))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 442 0.08 0.13 0 0 0 0
Fetch 963 0.22 4.72 350 16955 0 521
total 1406 0.31 4.85 350 16955 0 521
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 173 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 UNION-ALL (cr=38 pr=3 pw=0 time=139 us)
1 1 1 TABLE ACCESS BY INDEX ROWID AP_INVOICE_PAYMENTS_ALL (cr=5 pr=0 pw=0 time=124 us cost=6 size=12 card=1)
1 1 1 INDEX RANGE SCAN AP_INVOICE_PAYMENTS_N2 (cr=4 pr=0 pw=0 time=92 us cost=3 size=0 card=70)(object id 27741)
0 0 0 NESTED LOOPS (cr=33 pr=3 pw=0 time=20897 us)
0 0 0 NESTED LOOPS (cr=33 pr=3 pw=0 time=20891 us cost=12 size=41 card=1)
1 1 1 TABLE ACCESS FULL AP_SYSTEM_PARAMETERS_ALL (cr=30 pr=0 pw=0 time=313 us cost=9 size=11 card=1)
0 0 0 INDEX RANGE SCAN AP_PAYMENT_HISTORY_N1 (cr=3 pr=3 pw=0 time=20568 us cost=2 size=0 card=1)(object id 27834)
0 0 0 TABLE ACCESS BY INDEX ROWID AP_PAYMENT_HISTORY_ALL (cr=0 pr=0 pw=0 time=0 us cost=3 size=30 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 350 0.15 4.33
Disk file operations I/O 3 0.00 0.00
latch: shared pool 1 0.17 0.17
********************************************************************************user13019948 wrote:
Hi,
I have a tkprof file. How can I get the total execution time.
call count cpu elapsed disk query current rows
total 1406 0.31 4.85 350 16955 0 521TOTAL ELAPSED TIME is 4.85 seconds from line above -
How to find out the execution time of a sql inside a function
Hi All,
I am writing one function. There is only one IN parameter. In that parameter, i will pass one SQL select statement. And I want the function to return the exact execution time of that SQL statement.
CREATE OR REPLACE FUNCTION function_name (p_sql IN VARCHAR2)
RETURN NUMBER
IS
exec_time NUMBER;
BEGIN
--Calculate the execution time for the incoming sql statement.
RETURN exec_time;
END function_name;
/Please note that wrapping query in a "SELECT COUNT(*) FROM (<query>)" doesn't necessarily reflect the execution time of the stand-alone query because the optimizer is smart and might choose a completely different execution plan for that query.
A simple test case shows the potential difference of work performed by the database:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Session altered.
SQL>
SQL> drop table count_test purge;
Table dropped.
Elapsed: 00:00:00.17
SQL>
SQL> create table count_test as select * from all_objects;
Table created.
Elapsed: 00:00:02.56
SQL>
SQL> alter table count_test add constraint pk_count_test primary key (object_id)
Table altered.
Elapsed: 00:00:00.04
SQL>
SQL> exec dbms_stats.gather_table_stats(ownname=>null, tabname=>'COUNT_TEST')
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.29
SQL>
SQL> set autotrace traceonly
SQL>
SQL> select * from count_test;
5326 rows selected.
Elapsed: 00:00:00.10
Execution Plan
Plan hash value: 3690877688
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 5326 | 431K| 23 (5)| 00:00:01 |
| 1 | TABLE ACCESS FULL| COUNT_TEST | 5326 | 431K| 23 (5)| 00:00:01 |
Statistics
1 recursive calls
0 db block gets
419 consistent gets
0 physical reads
0 redo size
242637 bytes sent via SQL*Net to client
4285 bytes received via SQL*Net from client
357 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5326 rows processed
SQL>
SQL> select count(*) from (select * from count_test);
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 572193338
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 5 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| PK_COUNT_TEST | 5326 | 5 (0)| 00:00:01 |
Statistics
1 recursive calls
0 db block gets
16 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>As you can see the number of blocks processed (consistent gets) is quite different. You need to actually fetch all records, e.g. using a PL/SQL block on the server to find out how long it takes to process the query, but that's not that easy if you want to have an arbitrary query string as input.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Procedure execution time difference in Oacle 9i and Oracle 10g
Hi,
My procedure is taking time on
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 is 14 min.
same procedure is taking time on oracle Release 9.2.0.1.0 is 1 min.
1) Data is same in both environment.
2) Number of records are same 485 rows for cursor select statement.
3)Please guide me how to reduce the time in oracle 10g for procedure?
i have checked the explain plan for that cursor query it is different in both enviroment.
so i have analysis that procedure is taking time on cursor fetch into statement in oracle 10g.
example:-
create or replace procedure myproc
CURSOR cur_list
IS select num
from tbl
where exist(select.......
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';
OPEN cur_list;
LOOP
FETCH cur_list INTO cur_list; -----My procedure is taking time in this statement only for some list number. there are 485 list number.
end loop;
TRACE file for oracle 10g is look like this:-
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.37 0.46 0 2 0 0
Fetch 486 747.07 730.14 1340 56500700 0 485
total 488 747.45 730.60 1340 56500702 0 485
ORACLE 9i EXPLAIN PLAN FOR cursor query:-
Plan
SELECT STATEMENT CHOOSECost: 2 Bytes: 144 Cardinality: 12
18 INDEX RANGE SCAN UNIQUE LISL.LISL_LIST_PK Cost: 2 Bytes: 144 Cardinality: 12
17 UNION-ALL
2 FILTER
1 TABLE ACCESS FULL SLD.P Cost: 12 Bytes: 36 Cardinality: 1
16 NESTED LOOPS Cost: 171 Bytes: 141 Cardinality: 1
11 NESTED LOOPS Cost: 169 Bytes: 94 Cardinality: 1
8 NESTED LOOPS Cost: 168 Bytes: 78 Cardinality: 1
6 NESTED LOOPS Cost: 168 Bytes: 62 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID SLD.L Cost: 168 Bytes: 49 Cardinality: 1
3 INDEX RANGE SCAN UNIQUE SLD.PK_L Cost: 162 Cardinality: 9
5 INDEX UNIQUE SCAN UNIQUE SLD.SYS_C0025717 Bytes: 45,760 Cardinality: 3,520
7 INDEX UNIQUE SCAN UNIQUE SLD.PRP Bytes: 63,904 Cardinality: 3,994
10 TABLE ACCESS BY INDEX ROWID SLD.P Cost: 1 Bytes: 10,480 Cardinality: 655
9 INDEX UNIQUE SCAN UNIQUE SLD.PK_P Cardinality: 9
15 TABLE ACCESS BY INDEX ROWID SLD.GRP_E Cost: 2 Bytes: 9,447 Cardinality: 201
14 INDEX UNIQUE SCAN UNIQUE SLD.PRP_E Cost: 1 Cardinality: 29
13 TABLE ACCESS BY INDEX ROWID SLD.E Cost: 2 Bytes: 16 Cardinality: 1
12 INDEX UNIQUE SCAN UNIQUE SLD.SYS_C0025717 Cost: 1 Cardinality: 14,078
ORACLE 10G EXPLAIN PLAN FOR cursor query:-
SELECT STATEMENT ALL_ROWSCost: 206,103 Bytes: 12 Cardinality: 1
18 FILTER
1 INDEX FAST FULL SCAN INDEX (UNIQUE) LISL.LISL_LIST_PK Cost: 2 Bytes: 8,232 Cardinality: 686
17 UNION-ALL
3 FILTER
2 TABLE ACCESS FULL TABLE SLD.P Cost: 26 Bytes: 72 Cardinality: 2
16 NESTED LOOPS Cost: 574 Bytes: 157 Cardinality: 1
14 NESTED LOOPS Cost: 574 Bytes: 141 Cardinality: 1
12 NESTED LOOPS Cost: 574 Bytes: 128 Cardinality: 1
9 NESTED LOOPS Cost: 573 Bytes: 112 Cardinality: 1
6 HASH JOIN RIGHT SEMI Cost: 563 Bytes: 315 Cardinality: 5
4 TABLE ACCESS FULL TABLE SLD.E Cost: 80 Bytes: 223,120 Cardinality: 13,945
5 TABLE ACCESS FULL TABLE SLD.GRP_E Cost: 481 Bytes: 3,238,582 Cardinality: 68,906
8 TABLE ACCESS BY INDEX ROWID TABLE SLD.L Cost: 2 Bytes: 49 Cardinality: 1
7 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PK_L Cost: 1 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID TABLE SLD.P Cost: 1 Bytes: 16 Cardinality: 1
10 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PK_P Cost: 0 Cardinality: 1
13 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.SYS_C0011870 Cost: 0 Bytes: 13 Cardinality: 1
15 INDEX UNIQUE SCAN INDEX (UNIQUE) SLD.PRP Cost: 0 Bytes: 16 Cardinality: 1
so Please guide me how to reduce the time in oracle 10g for procedure?
1) Is this envrionment setting parameter?
2) I have to tune the query? but which is executing fine on oracle 9i?
so how to decrease the execution time?
Thanks in advance.SELECT l_nr
FROM x.ls b
WHERE b.cd = '01'
AND b.co_code = '001'
AND EXISTS (
SELECT T_L
FROM g.C
WHERE C_cd = '01'
AND C_co_code = '001'
AND C_flg = 'A'
AND C_eff_dt <= sysdate
AND C_end_dt >=
sysdate
AND C_type_code <> 1
AND C_type_code <> 1
AND targt_ls_type = 'C'
AND T_L <> 9999
AND T_L = b.l_nr
UNION ALL
SELECT l.T_L
FROM g.C C,
g.ep_e B,
g.ep ep,
g.e A,
g.lk_in l
WHERE l.cd = '01'
AND l.co_code = '001'
AND l.cd = C.C_cd
AND l.co_code = C.C_co_code
AND l.C_nbr = C.C_nbr
AND l.targt_ls_type = 'C'
AND lk_in_eff_dt <=
sysdate
AND lk_in_end_dt >=
( sysdate
+ 1
AND ( (logic_delte_flg = '0')
OR ( logic_delte_flg IN ('1', '3')
AND lk_in_eff_dt <> lk_in_end_dt
AND l.cd = ep.C_cd
AND l.co_code = ep.C_co_code
AND l.C_nbr = ep.C_nbr
AND l.ep_nbr = ep.ep_nbr
AND l.cd = A.e_cd
AND l.co_code = A.e_co_code
AND l.e_nbr = A.e_nbr
AND l.cd = B.cd
AND l.co_code = B.co_code
AND l.C_nbr = B.C_nbr
AND l.ep_nbr = B.ep_nbr
AND l.e_nbr = B.e_nbr
AND l.ep_e_rev_nbr = B.ep_e_rev_nbr
AND B.flg = 'A'
AND EXISTS (
SELECT A.e_nbr
FROM g.e A
WHERE A.e_cd = B.cd
AND A.e_co_code = B.co_code
AND A.e_nbr = B.e_nbr
AND A.e_type_code ^= 8)
AND C_type_code <> 10
AND C.C_type_code <> 13
AND l.T_L = b.l_nr)
--yes index is same -
Execution time of query on different indexes
Hello,
I have a query on the table, the execution time has hugh difference using different indexes on the table. The table has about 200,000 rows. Any explaination on it?
Thanks,
create table TB_test
( A1 number(9),
A2 number(9)
select count(*) from TB_test
where A1=123 and A2=456;
A. With index IDX_test on column A1:
Create index IDX_test on TB_test(A1);
Explain plan:
SELECT STATEMENT
Cost: 3,100
SORT AGGREGATE
Bytes: 38 Cardinality: 1
TABLE ACCESS BY INDEX ROWID TABLE TB_test
Cost: 3,100 Bytes: 36 Cardinality: 1
INDEX RANGE SCAN INDEX IDX_test
Cost: 40 Cardinality: 21,271
Execution time is : 5 Minutes
B. With index IDX_test on column A1 and A2:
Create index IDX_test on TB_test(A1, A2);
Explain plan:
SELECT STATMENT
Cost: 3 Bytes: 37 Cardinality: 1
SORT AGGREGATE
Bytes: 37 Cardinality: 1
INDEX RANGE SCAN INDEZ IDX_test
Cost: 3 Bytes 37 Cardinality:1
Execution time is: 1.5 SecondsAdditional you should check how many values you have in your table for the specific column values.
The following select might be helful for that.
select count(*) "total_count"
,count(case when A1=123 then 1 end) "A1_count"
,count(case when A1=123 and A2=456 then 1 end) "A1andA2_count"
from TB_test;Share your output of this.
I expect the value for A1_count still to be high. But the value for A1+A2_count relatively low.
However 5 minutes is far to long for such a small table. Even if you run it on a laptop.
There must be a reason why it is that slow.
First thing to consider would be to update your statistics for the table and the index.
Second thing could be that the table is very sparsly fillled. Meaning, if you frequently delete records from this table and load new data using APPEND hint, then the table will grow, because the free space from the deletes is never reused. Any table access in the execution plan, will be slower then needed.
A similar thing can happen, if many updates on previously empty columns are made on a table (row chaining problem).
So if you explain a little, how this table is filled and used, we could recognize a typical pattern that leads to performance issues.
Edited by: Sven W. on Nov 28, 2012 5:54 PM -
Reduce the execution time for the below query
Hi,
Please help me to reduce the execution time on the following query .. if any tuning is possible.
I have a table A with the columns :
ID , ORG_LINEAGE , INCLUDE_IND ( -- the org lineage is a string of ID's. If ID 5 reports to 4 and 4 to 1 .. the lineage for 5 will be stored as the string -1-4-5)
Below is the query ..
select ID
from A a
where INCLUDE_IND = '1' and
exists (
select 1
from A b
where b.ID = '5'
and b.ORG_LINEAGE like '%-'||a.ID||'-%'
order by ORG_LINEAGE;
The only constraint on the table A is the primary key on the ID column.
Following will be the execution plan :
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=406 Card=379 Bytes=2
653)
1 0 SORT (ORDER BY) (Cost=27 Card=379 Bytes=2653)
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'A' (Cost=24 Card
=379 Bytes=2653)
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'A' (Co
st=1 Card=1 Bytes=6)
5 4 INDEX (RANGE SCAN) OF 'ORG_LINEAGE'
(NON-UNIQUE)I order it by the org_lineage to get the first person. So it is a result problem? The order by doesn't give you the first person, it gives you a sorted result set (of which there may be zero, one, or thousands).
If you only want one row from that, then you're spending a lot of time tuning the wrong query.
How do you know which ORG_LINEAGE row you want?
Maybe it would help if you posted some sample data. -
SQL Tuning and OPTIMIZER - Execution Time with " AND col .."
Hi all,
I get a question about SQL Tuning and OPTIMIZER.
There are three samples with EXPLAIN PLAN and execution time.
This "tw_pkg.getMaxAktion" is a PLSQL Package.
1.) Execution Time : 0.25 Second
2.) Execution Time : 0.59 Second
3.) Execution Time : 1.11 Second
The only difference is some additional "AND col <> .."
Why is this execution time growing so strong?
Many Thanks,
Thomas
----[First example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900 ;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 220 | 880 | 5 (40)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 220 | 880 | 5 (40)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
13 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.25 seconds
----[/First]---
----[Second example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6 AND max_aktion.max_aktion_id <> 692;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 11 | 44 | 6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 11 | 44 | 6 (50)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
14 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.59 seconds
----[/Second]---
----[Third example]---
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6 AND max_aktion.max_aktion_id <> 692
7 AND max_aktion.max_aktion_id <> 392;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 1 | 4 | 6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 1 | 4 | 6 (50)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
15 rows selected
SQL>
Execution time (PL/SQL Developer says): 1.11 seconds
----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
Edited by: thomas_w on Jul 12, 2010 8:29 AMHi,
this is likely because SQL Developer fetches and displays only limited number of rows from query results.
This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
Query scans a table from the beginning and continue scanning until first 50 rows are selected.
If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
Look at this simple test to figure out how it works:
CREATE TABLE studie AS
SELECT row_number() OVER (ORDER BY object_id) studie_id, o.*
FROM (
SELECT * FROM all_objects
CROSS JOIN
(SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
) o;
CREATE INDEX studie_ix ON studie(object_name, studie_id);
ANALYZE TABLE studie COMPUTE STATISTICS;
CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
RETURN NUMBER
IS
BEGIN
RETURN action;
END;
/'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 1.22 1.29 0 1310 0 50
total 3 1.22 1.29 0 1310 0 50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
50 INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
50 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
AND max_aktion.max_aktion_id > 800
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 8.40 8.62 0 9351 0 50
total 3 8.40 8.64 0 9351 0 50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
50 INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
50 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id = 600
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.72 19.16 0 19315 0 1
total 3 18.73 19.16 0 19315 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.35 18.46 0 19315 0 899
total 3 18.35 18.46 0 19315 0 899
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
899 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
899 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
AND max_aktion.max_aktion_id > 800
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.79 18.86 0 19315 0 99
total 3 18.79 18.86 0 19315 0 99
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
99 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
99 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id = 600
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.69 18.84 0 19315 0 1
total 3 18.69 18.84 0 19315 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned. -
Query Database: reduce execution time
Hi to all,
I have Oracle 11g R2.
I want reduce to max the execution time of this my select:
SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON, a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC FROM ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001, 8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL), 'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1;
This query returns the name, city, postal code and address of a street of Italy. These datas are in ITALIA_GC table.
I already created an spatial index on GEOMETRY field of this table:
CREATE INDEX ITALIA_GC_IDX ON ITALIA_GC(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
How can I see the execution time (i need to know the execution time in milliseconds) of this query and how can I reduce to max it?
thank you very much in advance.
CrystalThank you.
I used explain plan and SQL*Trace/tkprof method.
What I would like to know is if the execution time are misured in seconds or milliseconds (I wish to know misure in millisecond).
The result of SQL*Trace/tkprof method is:
TKPROF: Release 11.2.0.1.0 - Development on Tue Jul 27 15:33:28 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: dbuir_ora_29053.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SQL ID: 1bf1x0q79c1rm
Plan Hash: 2374671442
SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON,
a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC
FROM
ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001,
8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL),
'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.02 0 30 2 0
Fetch 2 0.00 0.00 0 14 0 1
total 4 0.00 0.02 0 44 2 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85
Rows Row Source Operation
1 COUNT STOPKEY (cr=110 pr=0 pw=0 time=0 us)
1 TABLE ACCESS BY INDEX ROWID ITALIA_GC (cr=110 pr=0 pw=0 time=0 us cost=0 size=4142 card=1)
1 DOMAIN INDEX ITALIA_GC_IDX (cr=109 pr=0 pw=0 time=0 us cost=0 size=0 card=0)
SQL ID: 20y2xs9zmrbc5
Plan Hash: 4105568395
SELECT a."GEOMETRY"
FROM
"SPATIAL".ITALIA_GC a where a.rowid=:rid
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 20 0.00 0.00 0 0 0 0
Fetch 20 0.00 0.00 0 20 0 20
total 41 0.00 0.00 0 20 0 20
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85 (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY USER ROWID ITALIA_GC (cr=1 pr=0 pw=0 time=0 us cost=1 size=3831 card=1)
SQL ID: 9pxc8jgf3tj20
Plan Hash: 1946957531
SELECT diminfo, nvl(srid,-1)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = :own AND TABLE_NAME = NLS_UPPER(:tab)
AND '"'||COLUMN_NAME||'"' = :col
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 9 0 1
total 3 0.00 0.00 0 9 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 85 (recursive depth: 1)
Rows Row Source Operation
1 VIEW ALL_SDO_GEOM_METADATA (cr=9 pr=0 pw=0 time=0 us cost=25 size=654 card=2)
1 UNION-ALL (cr=9 pr=0 pw=0 time=0 us)
1 MERGE JOIN CARTESIAN (cr=9 pr=0 pw=0 time=0 us cost=6 size=81 card=1)
1 VIEW ALL_OBJECTS (cr=7 pr=0 pw=0 time=0 us cost=5 size=45 card=1)
1 FILTER (cr=7 pr=0 pw=0 time=0 us)
1 FILTER (cr=7 pr=0 pw=0 time=0 us)
1 NESTED LOOPS (cr=7 pr=0 pw=0 time=0 us cost=5 size=124 card=1)
1 NESTED LOOPS (cr=6 pr=0 pw=0 time=0 us cost=4 size=102 card=1)
1 TABLE ACCESS BY INDEX ROWID USER$ (cr=2 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
1 INDEX UNIQUE SCAN I_USER1 (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
1 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=4 pr=0 pw=0 time=0 us cost=3 size=84 card=1)
1 INDEX RANGE SCAN I_OBJ5 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 40)
1 INDEX RANGE SCAN I_USER2 (cr=1 pr=0 pw=0 time=0 us cost=1 size=22 card=1)(object id 47)
0 TABLE ACCESS BY INDEX ROWID IND$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)
0 INDEX UNIQUE SCAN I_IND1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 41)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=48 card=2)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
0 INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
0 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=72 card=2)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=23 card=1)
0 TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=12 card=1)
0 INDEX UNIQUE SCAN I_TRIGGER2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 162)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
0 INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
0 INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
0 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 VIEW (cr=0 pr=0 pw=0 time=0 us cost=2 size=13 card=1)
0 FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
0 VIEW (cr=0 pr=0 pw=0 time=0 us cost=1 size=16 card=1)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=0 size=78 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=0 size=65 card=1)
0 INDEX UNIQUE SCAN I_OLAP_CUBES$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 940)
0 TABLE ACCESS BY INDEX ROWID OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=52 card=1)
0 INDEX RANGE SCAN I_OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 944)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 INDEX FULL SCAN I_OLAP_CUBE_DIMENSIONS$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 928)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
0 INDEX FULL SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJ4 (cr=0 pr=0 pw=0 time=0 us cost=1 size=9 card=1)(object id 39)
1 BUFFER SORT (cr=2 pr=0 pw=0 time=0 us cost=6 size=36 card=1)
1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=2 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
1 INDEX RANGE SCAN SDO_GEOM_IDX (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=19 size=293 card=1)
0 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=18 size=238 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=18 size=225 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=17 size=221 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=16 size=213 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=15 size=209 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=14 size=201 card=1)
0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=13 size=196 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=12 size=185 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=11 size=181 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=9 size=172 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=8 size=144 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=7 size=123 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=6 size=120 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=90 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=54 card=1)
0 TABLE ACCESS BY INDEX ROWID USER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
0 INDEX UNIQUE SCAN I_USER1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
0 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
0 INDEX RANGE SCAN SDO_GEOM_IDX (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=3 size=36 card=1)
0 INDEX RANGE SCAN I_OBJ2 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 37)
0 TABLE ACCESS CLUSTER TAB$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=30 card=1)
0 INDEX UNIQUE SCAN I_OBJ# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 3)
0 TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=3 card=1)
0 INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
0 TABLE ACCESS CLUSTER COL$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=21 card=1)
0 TABLE ACCESS CLUSTER COLTYPE$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=28 card=1)
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=9 card=1)
0 INDEX RANGE SCAN I_OBJ3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 38)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 TABLE ACCESS CLUSTER SEG$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 9)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=5 card=1)(object id 36)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
0 INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=17 size=1300 card=100)
0 FIXED TABLE FULL X$KSPPCV (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
0 FIXED TABLE FULL X$KSPPI (cr=0 pr=0 pw=0 time=0 us cost=0 size=55 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
0 INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
0 FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
0 FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
********************************************************************************The result of Explain plan method is:
PLAN_TABLE_OUTPUT
Plan hash value: 2374671442
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 4142 | 0 (0) | 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ITALIA_GC | 49989 | 197M| 0 (0)| 00:00:01 |
|* 3 | DOMAIN INDEX | ITALIA_GC_IDX | | | 0 (0) | 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter(ROWNUM=1)
3 - access("MDSYS"."SDO_WITHIN_DISTANCE"("A"."GEOMETRY","MDSYS"."SDO_GEOMETRY"(2001
PLAN_TABLE_OUTPUT
,8307,"MDSYS"."SDO_POINT_TYPE"(13.8268523,41.491619,NULL),NULL,NULL),'DISTANCE=100 UNIT=M')='TRUE')
Note
- dynamic sampling used for this statement (level=2)
22 rows selected.thank you very much. -
Select - execution time strange behaviour
hi all,
when i executed an SQL - select (with joins and so on) - I have observed the following behaviour:
Query execution times are like: -
for 1000 records - 4 sec
5000 records - 10 sec
10000 records - 7 sec
25000 records - 16 sec
50000 records - 33 sec
I tested this behaviour with different sets of sqls on different sets of data. But in each of the cases, the behaviour is more or less the same.
Can any one explain - why Oracle takes more time to result 5000 records than that it takes to 10000. (In some cases, this behaviour can be observed at ~2000 to ~5000 )
Please note that this has not something to do with the SQLs as - i tested this with different sets of sql on different sets of data.
Can there be any Oracle`s internal reason - which can explain this behaviour?
regards
atat,
Things you need to check before you go further -
1) Are you using OPTIMIZER_MODE=CHOOSE or OPTIMIZER_MODE=RULE?
2) If you are using RULE then rewrite the queries or use some hints to help it along. If you're using a 3rd party application, then consider going to CHOOSE for the optimizer_mode.
3) If you're using CHOOSE (Cost Based Optimizer) then:
a) update your statistics. You can do this by creating a .cmd (or shell) file that logs into sqlplus or svrmgrl (better get use to sqlplus qs it isn't around qnymore in 9i), then call a sql file you will create(@c:\users\oracledba\analyze.sql for example). The analyze.sql file might look something like this:
#create a file to call in just a moment
spool c:\users\oracledba\anaylzed.sql
select 'analyze table' ||table_name|| 'compute statistics;' from dba_tables where owner NOT IN ('SYS', 'SYSTEM', 'DBA_USER', 'EXP_USER', 'QUEST', 'any_other_user_who_is_not_a_normal_user') and type <> 'TEMPORARY';
#execute the file you just created
@c:\users\oracledba\anaylzed.sql
spool off
b) This should give you an easy to use point-and-click way to anayle your tables. You can make a similar one for indexes as well. Don't run this thing every five minutes or you'll end up with crap. If possible, run it at a busy time of day but at a time when the performance impact caused by the script (which actually isn't much but does have an effect) won't be too drastic.
You also need to take a look at some additional OPTIMIZER_MODE accompanying parameters that will effect the time given to the CBO. Important ones are
a)optimizer_max_permutations (set to 1000 to limit the number of plans the optimizer examines before choosing the best plan. It can be as hig as 80000 but that is too many and research indicates that setting it to 1000 to start is good because the optimizer considers the fact that it only has 1000 shots at finding the best plan and derives the most likely first)
b)optimizer_index_caching (set to 95 which tells the optimizer that 95% of the time it will find the index in the cache and to use the index - typically this is set equal to your hit ratio)
c)optimizer_index_cost_adj is a bit more complicated (set it to a value that will tell Oracle how much cheaper it is to access the data via index vs. accessing it through full table scan. I'd start with 5 as a value and monitor it from there).
There are several other things you can do also - like creating bitmap indexes (assuming you've created indexes in the correct columns already).
If you send some more details about your environment etc we can provide more info.
Hope this helps,
The Infamous
Eric Cartman -
Execution time from explain plan
Hi
How can i get the execution time of a query from explain plan (not tkprof). I don't see the execution time in the plan table output.
ThanksExplain plan won't give execution time of a query because:
- it does not execute the query
- it only evaluates the execution plan and gives estimated costs
I dont't know if it is possible to deduce execution time from estimated cost.
Message was edited by:
Pierre Forstmann -
Execution time of same program makes big difference
Hello all,
The execution time of same program in PRD system and QAS system makes big difference.
The difference of data is not much(as system copy was run on a regular time schedule. And the system enviroments are exactly the same. However, while the program only cost 2-3 seconds in QAS, it cost 7-8 minutes in PRD.
It only happens when trying to join some tables together.
I've checked the execution plans of same search, they are different:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT , T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX , T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP , T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND T_00.BUKRS = 'MC51' AND T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND T_01.MANDT = '350' AND T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND T_01.PARTNER = T_00.REPKE AND T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
--- 12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
-- 9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
-- 6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
-- 4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
-- 2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
--- 8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
--- 11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
( Estim. Costs = 323 , Estim. #Rows = 2,380 )
Search Columns: 3
Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
Access Predicates Filter Predicates
PRD:
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
--- 12 NESTED LOOPS
( Estim. Costs = 208 , Estim. #Rows = 1 )
Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
-- 9 NESTED LOOPS
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
-- 6 NESTED LOOPS
Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
-- 4 NESTED LOOPS
Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
1 INDEX RANGE SCAN TZPA~0
Search Columns: 1
Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
Access Predicates
--- 3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Filter Predicates
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
Search Columns: 1
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
--- 8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 119 , Estim. #Rows = 1 )
Search Columns: 4
Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
Access Predicates Filter Predicates
--- 11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 89 , Estim. #Rows = 1 )
Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
( Estim. Costs = 88 , Estim. #Rows = 1 )
Search Columns: 4
Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
Access Predicates Filter Predicates
Could anyone tell me the reason? I've found note 724545 but not sure.
And, how to read the execution plan?(1 first or 12 first?)
Best Regards,
RobinHello Michael.
Thank you.
However, the sql statement is same:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT , T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX , T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP , T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND T_00.BUKRS = 'MC51' AND T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND T_01.MANDT = '350' AND T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND T_01.PARTNER = T_00.REPKE AND T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
--- 12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
-- 9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
-- 6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
-- 4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
-- 2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
--- 8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
--- 11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
( Estim. Costs = 323 , Estim. #Rows = 2,380 )
Search Columns: 3
Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
Access Predicates Filter Predicates
PRD:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT , T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX , T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP , T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '500' AND T_00.BUKRS = 'MC51' AND T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND T_01.MANDT = '500' AND T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND T_01.PARTNER = T_00.REPKE AND T_02.MANDT = '500' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
--- 12 NESTED LOOPS
| ( Estim. Costs = 208 , Estim. #Rows = 1 )
| Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
|-- 9 NESTED LOOPS
| | ( Estim. Costs = 120 , Estim. #Rows = 1 )
| | Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
| |-- 6 NESTED LOOPS
| | | Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
| | |-- 4 NESTED LOOPS
| | | | Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
| | | |-----1 INDEX RANGE SCAN TZPA~0
| | | | Search Columns: 1
| | | | Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
| | | | Access Predicates
| | | --- 3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
| | | | Estim. CPU-Costs = 210 Estim. IO-Costs = 0
| | | | Filter Predicates
| | | -
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
| | | Search Columns: 1
| | | Estim. CPU-Costs = 210 Estim. IO-Costs = 0
| | | Access Predicates
| | -
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
| | Search Columns: 2
| | Estim. CPU-Costs = 210 Estim. IO-Costs = 0
| | Access Predicates
| --- 8 TABLE ACCESS BY INDEX ROWID ZTM0108
| | ( Estim. Costs = 120 , Estim. #Rows = 1 )
| | Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
| -
7 INDEX RANGE SCAN ZTM0108~0
| ( Estim. Costs = 119 , Estim. #Rows = 1 )
| Search Columns: 4
| Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
| Access Predicates Filter Predicates
--- 11 TABLE ACCESS BY INDEX ROWID ZTM0135
| ( Estim. Costs = 89 , Estim. #Rows = 1 )
| Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
( Estim. Costs = 88 , Estim. #Rows = 1 )
Search Columns: 4
Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
Access Predicates Filter Predicates
Only difference is the client.
I see that QAS use index SA on table DIFT_POS_IDENT first, while PRD deal with table TZPA first...Is it the reason?
Best Regards,
Robin -
Query execution time estimation....
Hi All,
Is it possible to estimate query execution time using explain plan?
Thanks in advance,
Santosh.The cost estimated by the cost based optimizer is actually representing the time it takes to process the statement expressed in units of the single block read-time. Which means if you know the estimated time a single block read request requires you can translate this into an actual time.
Starting with Oracle 9i this information (the time to perform single block/multi block read requests) is actually available if you gather system statistics.
And this is what 10g actually does, as it shows an estimated TIME in the explain plan output based on these assumptions. Note that 10g by default uses system statistics, even if they are not explicitly gathered. In this case Oracle 10g uses the NOWORKLOAD statistics generated on the fly at instance startup.
Of course the time estimates shown by Oracle 10g may not even be close to the actual execution time as it is only an estimate based on a model and input values (statistics) and therefore might be way off due to several reasons, the same applies in principle to the cost shown.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
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 know query execution time in sql plus
HI
I want to know the query execution time in sql plus along with statistics
I say set time on ;
set autotrace on ;
select * from view where usr_id='abcd';
if the result is 300 rows it scrolls till all the rows are retrieved and finally gives me execution time as 40 seconds or 1 minute.. (this is after all the records are scrolled )
but when i execute it in toad it gives 350 milli seconds..
i want to see the execution time in sql how to do this
database server 11g and client is 10g
regards
rajwhat is the difference between .. the
statistics gathered in sql plus something like this and the one that i get from plan_table in toad?
how to format the execution plan I got in sqlplus in a proper understanding way?
statistics in sqlplus
tatistics
0 recursive calls
0 db block gets
164 consistent gets
0 physical reads
0 redo size
29805 bytes sent via SQL*Net to client
838 bytes received via SQL*Net from client
25 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
352 rows processedexecution plan in sqlplus... how to format this
xecution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=21 Card=1 Bytes=10
03)
1 0 HASH (UNIQUE) (Cost=21 Card=1 Bytes=1003)
2 1 MERGE JOIN (CARTESIAN) (Cost=20 Card=1 Bytes=1003)
3 2 NESTED LOOPS
4 3 NESTED LOOPS (Cost=18 Card=1 Bytes=976)
5 4 NESTED LOOPS (Cost=17 Card=1 Bytes=797)
6 5 NESTED LOOPS (OUTER) (Cost=16 Card=1 Bytes=685)
7 6 NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=556
8 7 NESTED LOOPS (Cost=14 Card=1 Bytes=427)
9 8 NESTED LOOPS (Cost=5 Card=1 Bytes=284)
10 9 TABLE ACCESS (BY INDEX ROWID) OF 'USR_XR
EF' (TABLE) (Cost=4 Card=1 Bytes=67)
11 10 INDEX (RANGE SCAN) OF 'USR_XREF_PK' (I
NDEX (UNIQUE)) (Cost=2 Card=1)
12 9 TABLE ACCESS (BY INDEX ROWID) OF 'USR_DI
M' (TABLE) (Cost=1 Card=1 Bytes=217)
13 12 INDEX (UNIQUE SCAN) OF 'USR_DIM_PK' (I
NDEX (UNIQUE)) (Cost=0 Card=1)
14 8 TABLE ACCESS (BY INDEX ROWID) OF 'HDS_FCT'
(TABLE) (Cost=9 Card=1 Bytes=143)
15 14 INDEX (RANGE SCAN) OF 'HDS_FCT_IX2' (IND
EX) (Cost=1 Card=338)
16 7 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_
COMM' (TABLE) (Cost=1 Card=1 Bytes=129)
17 16 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK'
(INDEX (UNIQUE)) (Cost=0 Card=1)
18 6 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_CO
MM' (TABLE) (Cost=1 Card=1 Bytes=129)
19 18 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK' (
INDEX (UNIQUE)) (Cost=0 Card=1)
20 5 TABLE ACCESS (BY INDEX ROWID) OF 'PROD_DIM' (TAB
LE) (Cost=1 Card=1 Bytes=112)
21 20 INDEX (UNIQUE SCAN) OF 'PROD_DIM_PK' (INDEX (U
NIQUE)) (Cost=0 Card=1)
22 4 INDEX (UNIQUE SCAN) OF 'CUST_DIM_PK' (INDEX (UNIQU
E)) (Cost=0 Card=1)
23 3 TABLE ACCESS (BY INDEX ROWID) OF 'CUST_DIM' (TABLE)
(Cost=1 Card=1 Bytes=179)
24 2 BUFFER (SORT) (Cost=19 Card=22 Bytes=594)
25 24 INDEX (FAST FULL SCAN) OF 'PROD_DIM_AK1' (INDEX (UNI
QUE)) (Cost=2 Card=22 Bytes=594)
Maybe you are looking for
-
Retriving all records in the value mapping cache using java
Hi, Is there a way to retrieve all records assuming I properly maintain some values in the value mapping using java? I know and I tried retrieving already using XIVMService.executeMapping but it seems that I can retrieve only 1 value at a time. For i
-
When I click on a hyperlink on a web page nothing happens. In fact I'm have to use the Safari browser to send this query.
-
When I change my meta data in iTunes why does it not get displayed in Sonos or MediaMonkey
Hello, I noticed that when I change the meta data in iTunes for example by right clicking an album -> get info and than change the Genre of the album and than click OK . It takes the changes in iTunes but I have a Sonos System and when I update my
-
Reporting a ML Bug on MacBooks from 2010 with Dedicated Graphic
Hello Guys, how are you? I found a bug in the Macbooks from 2010 with a Dedicated Graphic. As you can see on this video: http://www.youtube.com/watch?v=8mwQ4YR1w2s When Im try to take a selected area to printscreen with the CMD + Shift + 4 my mouse
-
Cursor list "snap to plot"-Cleaning
Hi! When I snap a cursor to a plot the context-menue shows lots of plots that arent actually in the graph anymore. How can I clean that up? Greets CtheR