Oracle - select execution time
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.
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
at
That is not normal behaviour. I've never come across anything like that that wasn't explainable by some environment factor (e.g. someone else doing a big sort).
I ran a couple of tests:
(1) to insert 5000 rows 0.1 seconds
to insert 10000 rows 0.18 seconds
and
(2) to select 5000 rows joined with 200K row table 0.19 seconds
to select 10000 rows joined with 200K row table 0.2 seconds
Although the second is close, I grant you!
Cheers, APC
Similar Messages
-
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 -
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 -
Reduce execution time with selects
Hi,
I have to reduce the execution time in a report, most of the consumed time is in the select query.
I have a table, gt_result:
DATA: BEGIN OF gwa_result,
tknum LIKE vttk-tknum,
stabf LIKE vttk-stabf,
shtyp LIKE vttk-shtyp,
route LIKE vttk-route,
vsart LIKE vttk-vsart,
signi LIKE vttk-signi,
dtabf LIKE vttk-dtabf,
vbeln LIKE likp-vbeln,
/bshm/le_nr_cust LIKE likp-/bshm/le_nr_cust,
vkorg LIKE likp-vkorg,
werks LIKE likp-werks,
regio LIKE kna1-regio,
land1 LIKE kna1-land1,
xegld LIKE t005-xegld,
intca LIKE t005-intca,
bezei LIKE tvrot-bezei,
bezei1 LIKE t173t-bezei,
fecha(10) type c.
DATA: END OF gwa_result.
DATA: gt_result LIKE STANDARD TABLE OF gwa_result.
And the select query is this:
SELECT ktknum kstabf kshtyp kroute kvsart ksigni
k~dtabf
lvbeln l/bshm/le_nr_cust lvkorg lwerks nregio nland1 oxegld ointca
tbezei ttbezei
FROM vttk AS k
INNER JOIN vttp AS p ON ktknum = ptknum
INNER JOIN likp AS l ON pvbeln = lvbeln
INNER JOIN kna1 AS n ON lkunnr = nkunnr
INNER JOIN t005 AS o ON nland1 = oland1
INNER JOIN tvrot AS t ON troute = kroute AND t~spras = sy-langu
INNER JOIN t173t AS tt ON ttvsart = kvsart AND tt~spras = sy-langu
INTO TABLE gt_result
WHERE ktknum IN s_tknum AND ktplst IN s_tplst AND k~route IN s_route AND
k~erdat BETWEEN s_erdat-low AND s_erdat-high AND
l~/bshm/le_nr_cust <> ' ' "IS NOT NULL
AND k~stabf = 'X'
AND ktknum NOT IN ( SELECT tktknum FROM vttk AS tk
INNER JOIN vttp AS tp ON tktknum = tptknum
INNER JOIN likp AS tl ON tpvbeln = tlvbeln
WHERE l~/bshm/le_nr_cust IS NULL )
AND k~tknum NOT IN ( SELECT tknum FROM /bshs/ssm_eship )
AND ( o~xegld = ' '
OR ( o~xegld = 'X' AND
( ( n~land1 = 'ES'
AND ( nregio = '51' OR nregio = '52'
OR nregio = '35' OR nregio = '38' ) )
OR n~land1 = 'ESC' ) )
OR ointca = 'AD' OR ointca = 'GI' ).
Does somebody know how to reduce the execution time ?.
Thanks.Hi,
Try to remove the join. Use seperate selects as shown in example below and for the sake of selection, keep some key fields in your internal table.
Then once your final table is created, you can copy the table into GT_FINAL which will contain only fields you need.
EX
data : begin of it_likp occurs 0,
vbeln like likp-vbeln,
/bshm/le_nr_cust like likp-/bshm/le_nr_cust,
vkorg like likp-vkorg,
werks like likp-werks,
kunnr likr likp-kunnr,
end of it_likp.
data : begin of it_kna1 occurs 0,
kunnr like...
regio....
land1...
end of it_kna1 occurs 0,
Select tknum stabf shtyp route vsart signi dtabf
from VTTP
into table gt_result
WHERE tknum IN s_tknum AND
tplst IN s_tplst AND
route IN s_route AND
erdat BETWEEN s_erdat-low AND s_erdat-high.
select vbeln /bshm/le_nr_cust
vkorg werks kunnr
from likp
into table it_likp
for all entries in gt_result
where vbeln = gt_result-vbeln.
select kunnr
regio
land1
from kna1
into it_kna1
for all entries in it_likp.
similarly for other tables.
Then loop at gt result and read corresponding table and populate entire record :
loop at gt_result.
read table it_likp where vbeln = gt_result-vbeln.
if sy-subrc eq 0.
move corresponding fields of it_likp into gt_result.
gt_result-kunnr = it_likp-kunnr.
modify gt_result.
endif.
read table it_kna1 where kunnr = gt_result-vbeln.
if sy-subrc eq 0.
gt_result-regio = it-kna1-regio.
gt_result-land1 = it-kna1-land1.
modify gt_result.
endif.
endloop. -
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. -
Selecting only time in oracle forms
Hi all,
like date picker in oracle forms can i select the time in oracle forms into a text item.
i want to display the time in this format 10:10:30 a.m. and also i want to insert into the table
i have taken the data type of this column as varchar2(15) if i take date can i insert the time or varchar2 is ok.
my oracle forms version is 10g.
please reply...Hi, extreme
extreme wrote:
Hi all,
like date picker in oracle forms can i select the time in oracle forms into a text item.
i want to display the time in this format 10:10:30 a.m. and also i want to insert into the table
i have taken the data type of this column as varchar2(15) if i take date can i insert the time or varchar2 is ok.Better take column having data type date. You can insert date and time in the date field.
Just you need to change in forms.
Change the Data type Date to Datetime
to show only time, use format mask.
Hope this helps -
Oracle Execution Time for function inside view
Hi Guys,
i would like to ask if i call a function inside a view , how does it behave in term of execution time and performance
For Example i have a view as below
create or replace view CUST.CUST_VIEW
select a.nice , a.getCustomDisplay(a.name,a.pin,a.dos,b.master_key) as custom from CUST.customer as a , CUST.master as b
where a.idno = b.main_id_no
AND the function look like this
create or replace function getCustomDisplay(a varchar2,b varchar2,c varchar2,d varchar2)
begin
select * from CUST.MAPPING_MATRIX order by idno asc;
for loop
//logic goes here to determine the result return from matrix
end
My Question is for example
1. If i do select * from CUST.CUST_VIEW ( return 1000 records for example ) , so the function getCustomDisplay will be executed 1000 times also right ( that means select * from CUST.MAPPING_MATRIX order by idno asc; will also be executed 1000 times ) ?
2. If i do select * from CUST.CUST_VIEW where rownum <= 20 , how many times getCustomDisplay() function will be executed ?
The reason i ask this because recently we saw a few million execution times per day from AWR report for this query
"select * from CUST.MAPPING_MATRIX order by idno asc;"
But when i investigate , and put a logger whenever it call getCustomDisplay , the query above as mention in item no 2 only will be executed as many as the record that will be returned from ( view + where condition ).
3. will it affect performance if my view return a lot of records ? or is there any way to improve it?
ThanksHi
i have other solutions that seems work for reducing number of execution times but do you think its scalable and feasible ?
CREATE OR REPLACE package body ACER.TYPE_CAT_PASS_UTIL_TEST as
*/* Private package data */*
TYPE g_rec IS RECORD (
id_no VARCHAR2 (4),
type_pass VARCHAR2 (3),
scheme_ind VARCHAR2 (5),
cat_pass VARCHAR2 (2),
entrepass VARCHAR2 (2),
display_type_pass VARCHAR2 (15),
display_cat_pass VARCHAR2 (5),
display_type_pass_desc VARCHAR2 (80),
rule_id VARCHAR2 (5)
TYPE g_tab_type IS TABLE OF g_rec INDEX BY BINARY_INTEGER;
g_tab g_tab_type;
i BINARY_INTEGER;
procedure initializeTypePassMatrix(test IN varchar2) as
begin
if(g_tab.COUNT < 1)then
FOR appln_rec in (
SELECT tb_type_cat_pass_matrix.id_no,
tb_type_cat_pass_matrix.type_pass,
tb_type_cat_pass_matrix.scheme_ind,
tb_type_cat_pass_matrix.cat_pass,
tb_type_cat_pass_matrix.entrepass,
tb_type_cat_pass_matrix.display_type_pass,
tb_type_cat_pass_matrix.display_cat_pass,
tb_type_cat_pass_matrix.display_type_pass_desc,
tb_type_cat_pass_matrix.rule_id
FROM tb_type_cat_pass_matrix ORDER BY id_no asc)
LOOP
dbms_output.put_line('g_tab.COUNT before insert: ' || g_tab.COUNT);
i := g_tab.COUNT + 1;
g_tab (i).id_no := appln_rec.id_no;
g_tab (i).type_pass := appln_rec.type_pass;
g_tab (i).scheme_ind := appln_rec.scheme_ind;
g_tab (i).cat_pass := appln_rec.cat_pass;
g_tab (i).entrepass := appln_rec.entrepass;
g_tab (i).display_type_pass := appln_rec.display_type_pass;
g_tab (i).display_cat_pass := appln_rec.display_cat_pass;
g_tab (i).display_type_pass_desc:= appln_rec.display_type_pass_desc;
g_tab (i).rule_id := appln_rec.rule_id;
DBMS_OUTPUT.put_line ('g_tab.count after insert: ' || g_tab.COUNT);
END LOOP;
else
DBMS_OUTPUT.put_line ('g_tab>=1, no need to initialize');
end if;
exception
when others then
dbms_output.put_line('error happen'||DBMS_UTILITY.format_error_backtrace);
Logger.ERROR('TYPE_CAT_PASS_UTIL.initializeTypePassMatrix',SQLCODE,SQLERRM || ' ' ||DBMS_UTILITY.format_error_backtrace,'SYSTEM');
end initializeTypePassMatrix;
procedure populateTypeCatPassFullDesc(typePass IN varchar2, schemeInd IN varchar2,catPass IN varchar2,entrePass IN varchar2, displayTypePass IN OUT varchar2,displayTypePassDesc IN OUT varchar2, displayCatPass IN OUT varchar2 )is
v_displayTypePass varchar2(15) :='-';
v_displayTypePassDesc varchar2(100) :='-';
v_displayCatPass varchar2 (2):='-';
v_type_pass varchar2(3) := '';
v_scheme_ind varchar2(5) := '';
v_cat_pass varchar2(2);
v_entrepass varchar2(2);
v_flag_valid_1 boolean:=false;
v_flag_valid_2 boolean:=false;
v_flag_valid_3 boolean:=false;
v_flag_valid_4 boolean:=false;
v_appln_rec g_rec;
begin
dbms_output.put_line('line 1');
initializeTypePassMatrix('test');
FOR nomor in g_tab.FIRST .. g_tab.LAST
LOOP
v_appln_rec := g_tab(nomor);
dbms_output.put_line('line 2.1');
v_flag_valid_1 :=false;
v_flag_valid_2 :=false;
v_flag_valid_3 :=false;
v_flag_valid_4 :=false;
v_type_pass := v_appln_rec.type_pass;
v_scheme_ind := v_appln_rec.scheme_ind;
v_cat_pass := v_appln_rec.cat_pass;
v_entrepass := v_appln_rec.entrepass;
dbms_output.put_line('line 2.2');
if(typePass = v_type_pass or v_type_pass = 'NA') then
v_flag_valid_1:= true;
end if;
if(schemeInd = v_scheme_ind or v_scheme_ind='NA') then
v_flag_valid_2 := true;
elsif(schemeInd is null and v_scheme_ind is null) then
v_flag_valid_2 := true;
end if;
if(catPass = v_cat_pass or v_cat_pass='NA') then
v_flag_valid_3 := true;
elsif(catPass is null and v_cat_pass is null) then
v_flag_valid_3 := true;
end if;
if(entrePass = v_entrepass or v_entrepass='NA') then
v_flag_valid_4 := true;
end if;
if(v_flag_valid_1 = true and v_flag_valid_2 = true and v_flag_valid_3 = true and v_flag_valid_4 = true) then
v_displayTypePass := v_appln_rec.display_type_pass;
v_displayCatPass := v_appln_rec.display_cat_pass;
v_displayTypePassDesc := v_appln_rec.display_type_pass_desc;
dbms_output.put_line('rule id got :'||v_appln_rec.rule_id);
dbms_output.put_line('rule no got :'||v_appln_rec.id_no);
exit when (0 = 0);
end if;
END LOOP;
displayTypePass := v_displayTypePass;
displayCatPass := v_displayCatPass;
dbms_output.put_line('1type:' || v_displayTypePassDesc);
displayTypePassDesc := v_displayTypePassDesc;
dbms_output.put_line('2type:' || displayTypePassDesc);
dbms_output.put_line('type:' || v_displayTypePass);
dbms_output.put_line('cat :' || v_displayCatPass);
exception
when others then
dbms_output.put_line('error happen'||DBMS_UTILITY.format_error_backtrace);
Logger.ERROR('TYPE_CAT_PASS_UTIL.populateTypeCatPass',SQLCODE,SQLERRM || ' ' ||DBMS_UTILITY.format_error_backtrace,'SYSTEM');
end populateTypeCatPassFullDesc;
function getDisplayTypePass(typePass IN varchar2, schemeInd IN varchar2,catPass IN varchar2,entrePass IN varchar2) return varchar2 is
v_displayTypePass varchar2(15) :='-';
v_displayTypePassDesc varchar2(100) :='-';
v_displayCatPass varchar2(2) :='-';
begin
populateTypeCatPassFullDesc(typePass,schemeInd,catPass,entrePass,v_displayTypePass,v_displayTypePassDesc,v_displayCatPass);
return v_displayTypePass;
exception
when others then
dbms_output.put_line('error happen'||DBMS_UTILITY.format_error_backtrace);
Logger.ERROR('TYPE_CAT_PASS_UTIL.populateTypeCatPass',SQLCODE,SQLERRM || ' ' ||DBMS_UTILITY.format_error_backtrace,'SYSTEM');
end getDisplayTypePass;
end TYPE_CAT_PASS_UTIL_TEST;
By Using like above even i do query on select * from <some_view) it will be only one execution for
SELECT tb_type_cat_pass_matrix.id_no,*
**tb_type_cat_pass_matrix.type_pass,**
**tb_type_cat_pass_matrix.scheme_ind,**
**tb_type_cat_pass_matrix.cat_pass,**
**tb_type_cat_pass_matrix.entrepass,**
**tb_type_cat_pass_matrix.display_type_pass,**
**tb_type_cat_pass_matrix.display_cat_pass,**
**tb_type_cat_pass_matrix.display_type_pass_desc,**
**tb_type_cat_pass_matrix.rule_id**
**FROM tb_type_cat_pass_matrix ORDER BY id_no asc*
the key point is the initializeTypePassMatrix function but it seems the variable only works for one session ?
if i open new session it will be reset again . -
Oracle View that stores the Query execution time
Hi Gurus
i m using Oracle 10G in Unix. I wudiold like to know which Data dictionary view stores the execution of a query. If it is not stored then hw to find the query execution time other than (Set timing on) command. What is the use of elapsed time and what is the difference between execution time and elapsed time? How to calculate the execution time of a query.
THanks
RamIf you have a specific query you're going to run in SQL*Plus, just do
a 'set timing on' before you execute the query.
If you've got application SQL coming in from all over the place, you can
identify specific SQL in V$SQL/ and look at ELAPSED_TIME/EXECUTIONS
to get an average elapsed time.
If you've got an application running SQL, and you need to know the
specific timing of a specific execution (as opposed to an average),
you can use DBMS_SUPPORT to set trace in the session that your
application is running in, and then use TkProf to process the resulting
trace file. -
Oracle NoSQL YCSB - continuously increasing execution time
Greetings,
currently I am testing several nosql databases using YCSB. I am new to that type of databases, but I have already tested few of them. I am using VM with 2GB RAM and hosted on Win 7. Even though it is not recommended, since I am working in now capacity environment, I am using KVlite. But my problem is confusing and I can not find the reason. So, I have successfully loaded data and tested Oracle NoSQL using different workloads. However, with each execution, I get higher execution time. For example, if at 1st execution I get 20 seconds, if I shut database down and next day execute same workload again, I get 35 second execution time and so on.
Do you have any idea of what may be causing that? Like I said, I have been researching some nosql databases but I have never had that strange results.
Regards.To add to Robert's comment, the NoSQL DB documentation on KVLite states the following:
KVLite is a simplified version of Oracle NoSQL Database. It provides a single-node store
that is not replicated. It runs in a single process without requiring any administrative interface.
You configure, start, and stop KVLite using a command line interface.
KVLite is intended for use by application developers who need to unit test their Oracle NoSQL
Database application. It is not intended for production deployment, or for performance measurements.
Per the documentation, you can use KVLite to test out the API calls in your performance benchmarking application, but you should not use to it perform the actual performance testing. For performance testing, please install and use the Oracle NoSQL Database server. -
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/ -
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. -
Hi,
I got several xsql-files that uses aprox. 1 minute to execute by them selves. I want to run one xsql that includes them all, but it times out, and I get an server-error. Is there any way I can get the execution time down, or change the timeout-setting?
I am running the xsql that comes with 8.1.7
Terje K.If Oracle8i JServer is included in the Oracle 8i package, then yes. The database itself is not large (aprox. 50Mb with data), but the results of the queries can get somewhat large. Here is an example:
1. first I made a view:
create view view_section2_issue as SELECT SPVSPC.OPN, OPE, PCA, PCS, PCSR, OSC, PWTT, OVSM, PLWD, PCSOD, PDC, TO_CHAR(ISOD,'dd.MM.YY') AS ISOD, TO_CHAR(PCSOD,'dd.MM.YY') AS OD, PSCN, PMDP1, PMDP2, PMDP3, PMDP4, PMDP5, PMDP6, PMDP7, PMDP8, PMDP9, PMDP10, PMDP11, PMDP12,PDT1, PDT2, PDT3, PDT4, PDT5, PDT6, PDT7, PDT8, PDT9, PDT10, PDT11, PDT12, PMDC, PMCA, PMMDP, PMDT, PMLWD, PMWTT, PMSCN, PMNS, PMWTH, PMSCH, PMOD
from SPVSISSU, SPVSISS2, SPVSPCS2, SPVSPC
where SPVSISSU.OPN = SPVSPC.OPN
and SPVSISSU.ISS is not null
and SPVSISS2.OPN = SPVSISSU.OPN
and SPVSISS2.ISSUE = SPVSISSU.ISR2
and SPVSPCS2.OPCS = SPVSISS2.IOPCS
and SPVSPCS2.PCSR = SPVSISS2.IPCS_REV
then I made the query (with some cursors):
SELECT OPE, PCA, PCS, PCSR, OSC, PWTT, OVSM, PLWD, PCSOD, PDC, OD, PSCN, PMDP1, PMDP2, PMDP3, PMDP4, PMDP5, PMDP6, PMDP7, PMDP8, PMDP9, PMDP10, PMDP11, PMDP12, PDT1, PDT2, PDT3, PDT4, PDT5, PDT6, PDT7, PDT8, PDT9, PDT10, PDT11, PDT12, PMDC, PMCA, PMMDP, PMDT, PMLWD, PMWTT, PMSCN, PMNS, PMWTH, PMSCH, PMOD,
CURSOR( SELECT PNS, POD, PWTH, PSCH
FROM spvspcs4
WHERE spvspcs4.opn = view_section2_issue.opn
and spvspcs4.pcs = view_section2_issue.pcs
and spvspcs4.pcsr = view_section2_issue.pcsr ) as wallThickness,
CURSOR( SELECT PELM, SST, PDSTD, PFS, PTS, PTY, PMN, MDS, ESK, PRM, PAGEBREAK, PMELL, page, start_remark(opn,pcs,pcsr,pel,pell) starten,
end_remark(opn,pcs,pcsr,pel,pell,start_remark(opn,pcs,pcsr,pel,pell)) as slutt
FROM spvspcs6
WHERE spvspcs6.opn = view_section2_issue.opn
and spvspcs6.pcs = view_section2_issue.pcs
and spvspcs6.pcsr = view_section2_issue.pcsr ) as elements,
CURSOR( SELECT PVELM, VDS, PVFS, PVTS, PVRM, PMVELL
FROM spvspcs7
WHERE spvspcs7.opn = view_section2_issue.opn
and spvspcs7.pcs = view_section2_issue.pcs
and spvspcs7.pcsr = view_section2_issue.pcsr ) as vType,
CURSOR( SELECT PBLP, PAGEBREAK, LTXT
FROM spvspcs5
WHERE spvspcs5.opn = view_section2_issue.opn
and spvspcs5.pcs = view_section2_issue.pcs
and spvspcs5.pcsr = view_section2_issue.pcsr ) as kommentar,
CURSOR( SELECT count(*) as tot
FROM spvspcs5
WHERE pagebreak = 'P'
and spvspcs5.opn = view_section2_issue.opn
and spvspcs5.pcs = view_section2_issue.pcs
and spvspcs5.pcsr = view_section2_issue.pcsr ) as kpages,
CURSOR( SELECT count(*) as tot
FROM spvspcs6
WHERE pagebreak = 'P'
and spvspcs6.opn = view_section2_issue.opn
and spvspcs6.pcs = view_section2_issue.pcs
and spvspcs6.pcsr = view_section2_issue.pcsr ) as tpages
from view_section2_issue
where OPN = {@opn} -
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 -
Execution Time & Explain Plan Variations
I have a scenario here. I have 2 schemas; schema1 & schema2. I executed a lengthy SELECT statement of 5 TABLE JOIN in these 2 schemas. I am getting totally different execution time (one runs at 0.3 seconds & the other at 4 seconds) and a different Explain Plan. I assume that, since its the same SELECT statement in these schema, I should get the same Explain Plan. What could be the reason for these dissimilarities? Oracle Version: 9.2.0.8.0. I am ready to share the Explain Plan of these 2 schemas. But they are of length around 300 lines.
Thank you.There are many factors come in to play here.
1.) Size of all tables involved are same
2.) structures are also same
3.) Also indexes are same
4.) Also stats are up to date on both
5.) Constraints and other factors are also same.
regards
PravinAnd a few more.
6) session environments are the same
7) bind variable values are the same - or were at first execution
I'd change 4 to read Optimizer statistics are the same. (not up to date which is a bit vague).
In short if you are using the CBO and feed in the exact same inputs you will get the exact same plan, however typically you won't get the exact same inputs and so may get a different plan. If your query has a time element and the two queries are hard parsed at different times it may actually be impossible to get the same input - for example the percentage of a table that is returned by a predicate like
timestamp_col > sysdate - 1 will be estimated differently depending on the time of parsing for the same data.
That all said looking at the plans might reveal some obvious differences, though perhaps it might be better to point at a URL that holds the plans given the length you say they are.
Niall Litchfield
http://www.orawin.info/
null
Maybe you are looking for
-
i have this type : begin of my_string, invoice LIKE vbrp-vbeln, vbeln LIKE veda-vbeln, keydate LIKE vbrp-erdat, END OF my_string. but when i click on this data in ALV grid i get the next transaction but whitout the numbe
-
Happens when going to print.coupons.com. I click the "learn more" button on the message that the plugin has crashed, and I get sent to the Adobe Flash plugin crash info page on Firefox. They say just to reload the page. There is a button for this. I
-
Now on my second new Centro in 1 week: Same problems as first!!! At wits end...
What is the problem with this phone? Did you a'lls entire shipment of Centro's to the Cincinnati area come from a corrupted batch? Problem one: Random resets and accompanying crackling noise coming from speaker Problem two: Backlight will come on wit
-
Welcome page uploading incorrectly
My "Welcome" page is not loading correctly. In iWeb it all looks correct, but when I publish and look at it online, the "blog" page goes to a different page, and several of the other pages are named incorrectly. What can I do to correct?
-
WVC54GCA Firmware Upgrade Desktop App Stopped Working
Hello, I recently updated the firmware on 2 of my 3 WVC54GCA cameras to the latest version "v1.1.00 build 02". The cameras flashed fine and still have network connectivity and everyting appears fine. The desktop "Internet Home Monitoring Camera" so