INDEX Execution Time Difference
Hi,
I applied index in 3 columns of the table..... when i 1st executed the query it takes 345 secs but next time execution takes 45 secs,then again 17 secs and 8 secs.... I want to know why the execution time gets reduced here? please help me to understand this concept.........
Thanks in Advance.
when you run a query for the first time then oracle creates its hash value and execution plan and stores it in data dictionary cache and then it fetches the data from the datafile using I/O and that data is placed in the buffer cache so it takes more time. But when you run the query for second time it already has the hash value and execution plan and data in buffer cache so it takes less time.
Edited by: saurabh on Aug 23, 2012 12:29 PM
Similar Messages
-
Execution time difference between SELECT & UPDATE statement in JDBC Sender.
Hi Experts,
In my scenario, I have used the JDBC Sender Adapter with the SELECT and UPDATE statement.
Now the problem is in between the execution of Select and update statement, few more entries are coming in the same DB Table.
So result of this is updation take place for those entries which are not even picked up by the select statement.
Can we avoid this execution time difference between the SELECT & UPDATE statemet on JDBC Sender side???
Thanks & Regards
JageshHi
Use serializable option in additional parameters, now all new entries would also be updated. -
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 -
CREATE TABLE/INDEX execution times
Hello,
what are my options to optimize table and/or index creation times?
I have a script that creates something around 60 000 objects (maybe half index, half table) and while each operation takes no more than a second, this will result in a 17 hour execution time. So I'm looking for ways to decrease table creation by a fraction of a second :-/
What I can think of is that all of these operations end up writing to the same datafile (e.g. SYSTEM01.DBF), could it do any good to divide the system tablespace into more data files? Adding a datafile would only increase the quota, so I would have to regroup the data?
Or can I increase the number of redologs? Or temporarily add larger redolog files?
Here is an extract to demonstrate:
14:20:10 SQL> DROP TABLE PS_DOTL_PDS2_T2
14:20:10 2 /
Table dropped.
14:20:11 SQL> CREATE TABLE PS_DOTL_PDS2_T2 (PROCESS_INSTANCE DECIMAL(10) NOT NULL,
14:20:11 2 BUSINESS_UNIT VARCHAR2(5) NOT NULL,
14:20:11 3 PO_ID VARCHAR2(10) NOT NULL,
14:20:11 4 LINE_NBR INTEGER NOT NULL,
14:20:11 5 SCHED_NBR SMALLINT NOT NULL,
14:20:11 6 DISTRIB_LINE_NUM INTEGER NOT NULL,
14:20:11 7 BUSINESS_UNIT_REQ VARCHAR2(5) NOT NULL,
14:20:11 8 REQ_ID VARCHAR2(10) NOT NULL,
14:20:11 9 REQ_LINE_NBR INTEGER NOT NULL,
14:20:11 10 REQ_SCHED_NBR SMALLINT NOT NULL,
14:20:11 11 REQ_DISTRIB_NBR INTEGER NOT NULL,
14:20:11 12 ACCOUNT VARCHAR2(10) NOT NULL,
14:20:11 13 OPERATING_UNIT VARCHAR2(8) NOT NULL,
14:20:11 14 PRODUCT VARCHAR2(6) NOT NULL,
14:20:11 15 FUND_CODE VARCHAR2(5) NOT NULL,
14:20:11 16 CLASS_FLD VARCHAR2(5) NOT NULL,
14:20:11 17 PROGRAM_CODE VARCHAR2(5) NOT NULL,
14:20:11 18 BUDGET_REF VARCHAR2(8) NOT NULL,
14:20:11 19 AFFILIATE VARCHAR2(5) NOT NULL,
14:20:11 20 AFFILIATE_INTRA1 VARCHAR2(10) NOT NULL,
14:20:11 21 AFFILIATE_INTRA2 VARCHAR2(10) NOT NULL,
14:20:11 22 CHARTFIELD1 VARCHAR2(10) NOT NULL,
14:20:11 23 CHARTFIELD2 VARCHAR2(10) NOT NULL,
14:20:11 24 CHARTFIELD3 VARCHAR2(10) NOT NULL,
14:20:11 25 PROJECT_ID VARCHAR2(15) NOT NULL,
14:20:11 26 ALTACCT VARCHAR2(10) NOT NULL,
14:20:11 27 DEPTID VARCHAR2(10) NOT NULL,
14:20:11 28 MONETARY_AMOUNT DECIMAL(26, 3) NOT NULL,
14:20:11 29 DISTRIB_AMT DECIMAL(26, 3) NOT NULL,
14:20:11 30 PO_DT DATE,
14:20:11 31 CURRENCY_CD VARCHAR2(3) NOT NULL,
14:20:11 32 KK_CLOSE_PRIOR VARCHAR2(1) NOT NULL,
14:20:11 33 PO_STATUS VARCHAR2(2) NOT NULL,
14:20:11 34 MID_ROLL_STATUS VARCHAR2(1) NOT NULL,
14:20:11 35 CURRENCY_CD_BASE VARCHAR2(3) NOT NULL,
14:20:11 36 RT_TYPE VARCHAR2(5) NOT NULL) TABLESPACE PSAPP STORAGE (INITIAL
14:20:11 37 40000 NEXT 100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10
14:20:11 38 PCTUSED 80
14:20:11 39 /
Table created.
14:20:11 SQL> CREATE UNIQUE iNDEX PS_DOTL_PDS2_T2 ON PS_DOTL_PDS2_T2
14:20:11 2 (PROCESS_INSTANCE,
14:20:11 3 BUSINESS_UNIT,
14:20:11 4 PO_ID,
14:20:11 5 LINE_NBR,
14:20:11 6 SCHED_NBR,
14:20:11 7 DISTRIB_LINE_NUM,
14:20:11 8 BUSINESS_UNIT_REQ,
14:20:11 9 REQ_ID,
14:20:11 10 REQ_LINE_NBR,
14:20:11 11 REQ_SCHED_NBR,
14:20:11 12 REQ_DISTRIB_NBR) TABLESPACE PSINDEX STORAGE (INITIAL 40000 NEXT
14:20:11 13 100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10 PARALLEL
14:20:11 14 NOLOGGING
14:20:11 15 /
Index created.
14:20:11 SQL> ALTER INDEX PS_DOTL_PDS2_T2 NOPARALLEL LOGGING
14:20:11 2 /
Index altered.
14:20:11 SQL> DROP TABLE PS_DOTL_PDS2_T3
14:20:11 2 /
Table dropped.
14:20:12 SQL> CREATE TABLE PS_DOTL_PDS2_T3 (PROCESS_INSTANCE DECIMAL(10) NOT NULL,
14:20:12 2 BUSINESS_UNIT VARCHAR2(5) NOT NULL,
14:20:12 3 PO_ID VARCHAR2(10) NOT NULL,
14:20:12 4 LINE_NBR INTEGER NOT NULL,
14:20:12 5 SCHED_NBR SMALLINT NOT NULL,
14:20:12 6 DISTRIB_LINE_NUM INTEGER NOT NULL,
14:20:12 7 BUSINESS_UNIT_REQ VARCHAR2(5) NOT NULL,
14:20:12 8 REQ_ID VARCHAR2(10) NOT NULL,
14:20:12 9 REQ_LINE_NBR INTEGER NOT NULL,
14:20:12 10 REQ_SCHED_NBR SMALLINT NOT NULL,
14:20:12 11 REQ_DISTRIB_NBR INTEGER NOT NULL,
14:20:12 12 ACCOUNT VARCHAR2(10) NOT NULL,
14:20:12 13 OPERATING_UNIT VARCHAR2(8) NOT NULL,
14:20:12 14 PRODUCT VARCHAR2(6) NOT NULL,
14:20:12 15 FUND_CODE VARCHAR2(5) NOT NULL,
14:20:12 16 CLASS_FLD VARCHAR2(5) NOT NULL,
14:20:12 17 PROGRAM_CODE VARCHAR2(5) NOT NULL,
14:20:12 18 BUDGET_REF VARCHAR2(8) NOT NULL,
14:20:12 19 AFFILIATE VARCHAR2(5) NOT NULL,
14:20:12 20 AFFILIATE_INTRA1 VARCHAR2(10) NOT NULL,
14:20:12 21 AFFILIATE_INTRA2 VARCHAR2(10) NOT NULL,
14:20:12 22 CHARTFIELD1 VARCHAR2(10) NOT NULL,
14:20:12 23 CHARTFIELD2 VARCHAR2(10) NOT NULL,
14:20:12 24 CHARTFIELD3 VARCHAR2(10) NOT NULL,
14:20:12 25 PROJECT_ID VARCHAR2(15) NOT NULL,
14:20:12 26 ALTACCT VARCHAR2(10) NOT NULL,
14:20:12 27 DEPTID VARCHAR2(10) NOT NULL,
14:20:12 28 MONETARY_AMOUNT DECIMAL(26, 3) NOT NULL,
14:20:12 29 DISTRIB_AMT DECIMAL(26, 3) NOT NULL,
14:20:12 30 PO_DT DATE,
14:20:12 31 CURRENCY_CD VARCHAR2(3) NOT NULL,
14:20:13 32 KK_CLOSE_PRIOR VARCHAR2(1) NOT NULL,
14:20:13 33 PO_STATUS VARCHAR2(2) NOT NULL,
14:20:13 34 MID_ROLL_STATUS VARCHAR2(1) NOT NULL,
14:20:13 35 CURRENCY_CD_BASE VARCHAR2(3) NOT NULL,
14:20:13 36 RT_TYPE VARCHAR2(5) NOT NULL) TABLESPACE PSAPP STORAGE (INITIAL
14:20:13 37 40000 NEXT 100000 MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10
14:20:13 38 PCTUSED 80
14:20:13 39 /
Table created. It's a PeopleSoft database, during one of the upgrade steps, running on Oracle 11.2.0.3, Windows patchset #17 I believe. (Win2008R2_64)
As always any input or references are greatly appreciated.
Best regards.Hi,
See bellow. You can create deferred segment creation option of Oracle. Oracle will not spend time on extent allocation and can save you enormous amount of time overall.
http://www.oracle-base.com/articles/11g/segment-creation-on-demand-11gr2.php
What I can think of is that all of these operations end up writing to the same datafile (e.g. SYSTEM01.DBF), could it do any good to divide the system tablespace into more data files? >Adding a datafile would only increase the quota, so I would have to regroup the data?Why giving example of SYSTEM01.DBF? You should not be using system tablespace. Having multiple datafiles will not be helping you.
What do you mean by regroup of data?
Salman
Edited by: Salman Qureshi on Apr 10, 2013 4:02 PM -
Execution time difference between Statspack and DBM_Monitor trace
Hi Everyone,
We noticed that output of query execution time is quite differ between statspack and session tracing (DBMS_MONITOR) report. The query execution time in Statspack was 1402 sec and in session trace file was 312.25 Sec. FYI database version is 11.2.0.3 which is installed on platform OL 5.8
Both of the following reports (Staspack/tracing) was executed on same system and at the same time. Could you suggest why execution time is differ in staspack and session tracing?
Staspack execution time :-
Elapsed Elap per CPU Old
Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value
1402.50 1 1402.50 9.1 53.92 256,142 3247794574
select * from ( select * from ( select resourcecontentslocati
on,isprotocolname,ismimecontenttype,indexedmetatext,objectid,met
atext,valueaddxml,resourcetype,resourceviewedtime,iscmaresultid,
resourcelastviewedbyuser,issequencenumber,nvl(length(contents),0
Session tracing time:-
call count cpu elapsed disk query current rows
Parse 1 10.58 256.44 43364 153091 0 0
Execute 1 0.01 0.08 0 0 0 0
Fetch 143 2.09 55.72 25440 32978 0 1000
total 145 12.69 312.25 68804 186069 0 1000
Thanks
RajdeepHi,
First of all, please read the [url https://wikis.oracle.com/display/Forums/Forums+FAQ]FAQ page and find out how to use the code tags to format your output properly so that it's readable.
I don't want to work out the stats formatting but I'd guess that if you ran the query first time and the data was not cached, it would be slower than the 2nd query when it was cached. The stats should confirm this so please format them so we can see it properly.
Rob -
Same query on different RAC instance huge execution time difference
we have 3 nodes oracle 10gR2 RAC based on ASM. The 3rd node is the latest one we added into the cluster. All instances on 3 nodes using the same system parameters and same OS and same hardware
i found a weird problem, a same query i executed on node1 is way more faster than on node3 (1.5mins VS. 18mins). Then i did trace, surprising found the fetch time for node3 is longer than node1. Both nodes are at very low load. here is part of tracing for both nodes:
node1:
call count cpu elapsed disk query current rows
Parse 1 3.40 3.47 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 19.13 97.04 69938 269374 0 7
total 4 22.54 100.51 69938 269374 0 7
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 132 0.00 0.03
library cache lock 13 0.00 0.00
library cache pin 9 0.00 0.00
rdbms ipc reply 6 0.00 0.00
latch: shared pool 1 0.00 0.00
SQL*Net message to client 2 0.00 0.00
gc current block 2-way 2061 0.00 0.67
gc cr multi block request 76610 0.18 7.71
gc current block 3-way 801 0.00 0.33
gc cr block 3-way 3 0.00 0.00
gc cr block 2-way 30 0.00 0.01
db file scattered read 1167 0.02 3.66
gc cr grant 2-way 24739 0.00 4.81
db file sequential read 37363 0.12 57.35
latch: KCL gc element parent latch 7 0.00 0.00
db file parallel read 1465 0.05 5.86
latch: cache buffers lru chain 1 0.00 0.00
gc current grant 2-way 1 0.00 0.00
gc cr block busy 10 0.17 0.37
gc cr disk read 1 0.00 0.00
SQL*Net more data to client 5 0.00 0.00
SQL*Net message from client 2 436.40 436.40
node3
call count cpu elapsed disk query current rows
Parse 1 2.58 2.64 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 11.35 299.22 37084 269364 0 7
total 4 13.94 301.86 37084 269364 0 7
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 3 0.00 0.00
row cache lock 10 0.00 0.00
SQL*Net message to client 2 0.00 0.00
gc cr grant 2-way 23126 0.01 5.01
db file sequential read 37080 1.30 277.16
gc cr multi block request 1 0.00 0.00
db file scattered read 1 0.31 0.31
read by other session 721 0.03 2.12
gc buffer busy 1248 0.03 4.78
latch: cache buffers chains 5 0.00 0.00
gc current block 3-way 332 0.00 0.17
gc current block 2-way 834 0.00 0.30
latch: KCL gc element parent latch 1 0.00 0.00
gc current grant 2-way 1 0.00 0.00
SQL*Net more data to client 5 0.00 0.00
SQL*Net message from client 2 76.12 76.12
And all the execution plan are the same.
Could anybody please tell me why this happens?
Thanks!To me, it looks like node3 is not accessing storage as fast as node 1 is. Look at this:
db file sequential read 37363 0.12 57.35
db file sequential read 37080 1.30 277.16
both cases have roughly the same amount of reads/waits but the time waited is 5 times more in the second case. So this could indicate a problem, maybe something with the HBA or SAN path or something like that.
Bjoern -
Max execution time per pixel causing rendering differences between GPUs
Is there a maximum execution time different graphics cards
will process each pixel as part of the shader? When running the
Raytracing script (
http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&loc=en_us&extid=1634 018
) on my Macbook Pro (256MB ATI Radeon X1600) then many pixels come
out grey or black as the loop per pixel that is tracing the ray
takes longer than some built in execution limit.
I first noticed this with a filter I've been working on which
looks fine on my alu iMac (512MB Nvidia GeForce 8800 GS) but
rubbish on the Macbook Pro or older iMacs.
Are there ways around this limit like splitting long for or
while loops into smaller chunks, or is it just a hardwired max
execution time per pixel?I don't think you can time out on processing an individual
pixel, but I could be wrong. You could try reducing the number of
reflections in the filter and seeing if that fixes the problem. It
could be a math precision difference between the cards.
Shaders can (and will) time out, but individual pixels
shouldn't. It could also be a driver issue with the structure of
the filter. I have a x1600 mac book pro here and I'll try it out if
I get a chance. -
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 -
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 -
Do the execution time of the insert command depend upon the no the indexes
hi,
Do the execution time of the insert,update and delete command depend upon the no the indexes created for a table......
Edited by: [email protected] on Mar 4, 2009 3:02 AMsure,..
An index is a structure which contains entries pointing to the actual data in the table.
When you insert a record into a table, the data which should also be indexed is inserted in the index structure. This index data needs to be in a specific place, not just anywhere (as opposed to e.g. a heap table).
So this might lead to an update and insert in the index structure.
This is just to give you an idea. More on the subject in Tom Kyte's Expert Oracle Database Architecture and of course Oracle's documentation. -
what is the difference in execution time between a program written in C language and the same program made with LabView?
Hi Pepe
You cannot say which is faster, the LV or the C programm. The only way to be sure is to program in both environments and to check than. Check this for some benchmark examples:
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?OpenDocument&node=200059
Luca
Regards,
Luca -
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/ -
Same sqlID with different execution plan and Elapsed Time (s), Executions time
Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade -
9i 10g upgrade execution plan differences.
Hi all,
I am tring to find execution plan differences after I upgrade production system from 9i to 10gR2. So I have restored only needed tablespaces from my production system (9i) to a new machine and then upgraded thiat Oracle server to 10GR2. At this new server I run a script to get new execution plans of 10g. What suprises me is that query plans of 10g is different and most of new plans choose to access tables via indexes instead of full table scans stated in the original plans taken from 9i. My idea about those differences is that the optimizer takes some values for its cost formula from other system tables that I do not have in 10g server.I guess I am missing something which is not documented in upgrade book.
any idea?
Regards.9i database is my production database and I regularly run cron jobs for missing or stale statistics on all tables. So there is no possibility to hit a problem on object level statistics. I guess that I am missing something about system level statistics which are the part of the formula (single block read time etc) for cost calculating. So I tried to use setting some statastics via dbms_stat.set_system_statistics procedure, but it did not work.
Any idea?
Regards.
ALPER ÖNEY -
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.
Maybe you are looking for
-
Freezing and crashes in Mavericks
Hi! Having continuing issues with Mavericks — I was getting a few straight crashes but lately I've been getting full freezes where my music skips. It hangs for about three seconds then restarts. It's happened four or five times this week and I can't
-
Bug (?) with Corporate Connectivity is (not) Working check
Noticed something odd. In situations where: Direct Access client is offsite their Internet access is via WiFi they first have to enter their access credentials through a web-based captive portal before access is granted then the Corporate Connectivi
-
Flash Player not loading in IE
I have reinstalled IE and also Flash Player, still the flash does not work, I can only see a blank space where the flash has to load, anyone had this issues?
-
i went to the app store to download a new app on my ios 7 update and i popped up a thing that said i need to agree to the terms and conditions and when i clicked on send an email to accept it didnt do anything
-
Newbie having problems with image on form
In Design, I use both the "image" and "image field" tools to place a JPG image on my form, but the image does not show up on the form (the placement is there for the image, but not the image). How can I correct this problem?