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.

Similar Messages

Why the execution time increases with a while loop, but not with "Run continuously" ?

Hi all,
I have a serious time problem that I don't know how to solve because I don't know exactly where it comes from.
I command two RF switches via a DAQ card (NI USB-6008). Only one position at the same time can be selected on each switch. Basically, the VI created for this functionnality (by a co-worker) resets all the DAQ outputs, and then activates the desired ones. It has three inputs, two simp0le string controls, and an array of cluster, which contains the list of all the outputs and some informations to know what is connected (specific to my application).
I use this VI in a complex application, and I get some problems with the execution time, which increased each time I callled the VI, so I made a test VI (TimeTesting.vi) to figure out where the problem came from. In this special VI I record the execution time in a csv file to analyse then with excel.
After several tests, I found that if I run this test VI with the while loop, the execution time increases at each cycle, but if I remove the while loop and use the "Run continuously" funtionnality, the execution time remains the same. In my top level application I have while loops and events, and so the execution time increases too.
Could someone explain me why the execution time increases, and how can I avoid that? I attached my test VI and the necessary subVIs, as well as a picture of a graph which shows the execution time with a while loop and with the "run continuously".
Thanks a lot for your help!
Solved!
Go to Solution.
Attachments:
TimeTesting.zip ‏70 KB
Graph.PNG ‏20 KB

jul7290 wrote:
Thank you very much for your help! I added the "Clear task" vi and now it works properly.
If you are still using the RUn Continuously you should stop. That is meant strictly for debugging. In fact, I can't even tell you the last time I ever used it. If you want your code to repeat you should use loops and control the behavior of the code.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Execution time continues to increase while vi is running

I started with a vi which reads data from a WII remote (wiimote). The code works. I want to convert the acceleration data to velocity and displacement by numerical integration. Accurate conversion requires a measure of execution time. The vi correctly returns 9-11 ms when it first starts, however the measured intervals continue to increase in lenght as the vi runs. The measured interval goes from 10 ms to 80 ms after about 1 hour. I used a tick counter to measure the loop execution time. Any suggestions?
Attachments:
Simple Event Callback Roll Pitch. timed eventvi.vi ‏19 KB

Can you do some profiling to see which subVI could be the problem?
If you look at the task manager, how is the momery use over time?
Your timing systems seems flawed, because the execution of the first tick cound is poorly defined with respect to the rest of the code.
Some typical things to look out for.
growing arrays in shift registers
constantly opening references without ever closing them.
LabVIEW Champion . Do more with less code and in less time .

Execution time increase

hai guys,
Im currently developing a code that run 24 hours 7 days a week. My problem is the execution time increases as days pass by. As im tracing down the execution time ,the 1st day i start the to run the program execution time is 0.04 second but after 3 day it increases to 4.5 seconds .
then i indually tracked down the subvi that causing problem and find out that the problem is on writing to ini file.
The subvi function is to REPLACE the data (20 data )in a file every 10 second*not accumulating data just replace the old data . I open file replace data and close file every itteration and as day pass the execution time for this subvi increases.
Can any one help me to get a solution for the problem as time is a very important factor in my programming. the execution time is limited for less that 10 second.
thanks
regards
kokula

As David said, post the code.
Is there any reason why your are loggin to an .ini file? Does that mean you are using the LabVIEW config file functions?
I don't know if deallocating memory would help, or is even possible, without seeing your code. You either have a problem with resources continuously being created, but not being closed out. Or you have an ever growing array. This takes more memory over time, and slows down the code because LabVIEW has to move memory around to account for the ever larger array.
I bet if you let your program run long enough, it would eventually crash due to running out of memory.
By the way 47MB to 350 MB of memory consumption means the same thing as RAM usage increasing.

CVI XML Functions Execution Times Increase When Looped

I have written multiple functions using CVI that read XML files. I have confirmed in the Resource Tracking utility that i have cleaned up all of my lists, elements, documents, etc. I have found that when I loop any of the functions I have created, the execution times increase. The increase is small but it is noticable and does effect my execution.
Are there any other sources of memory that I need to deallocate? It seems that there is a memory leak somewhere but I am unable to see where this increase is located.
I am currently running LabWIndows/CVI 2009 on Windows 2008 Server. I have looped my functions using TestStand 4.2.1. Any help would be appreciated!
Thanks in advance,
Kyle
Solved!
Go to Solution.

HI Daniel,
Thanks for the quick response.
It is indeed slow down in execution speed when we loop. When looped, the XML reader is overwriting variables, not adding to an array. Our application is structured differently than my test case. We run a CVI function from TestStand that contains a series of commands, which contains the XML reading. The XML looping is really done in CVI. I used TestStand in my test case just to get execution times. Our psuedocode for the CVI function is as followed:
For loop (looping over values, like amplitude or frequency)
Reading the XML
Applying the data from the XML to set up some instrument(s)
Do something...
End loop
I can confirm that the instrument set up is not the cause of the slow down. We have written the same XML reading in C# and applied the values to the instrument setup and do not experience the slow down.
I tested with On-The-Fly Reporting enabled and the execution time continued to slow down.
I hope that answers all of your questions!
Thanks,
Kyle

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

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

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
Ram

If 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 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?
Thanks

Hi
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 .

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 AM

Hi,
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.

Execution time, elapsed time of an sql query

Can you please tell me how to get the execution time, elapsed time of an sql query

user8680248 wrote:
I am running query in the database
I would like to know how long the query take the time to completeWhy? That answer can be totally meaningless as the VERY SAME query on the VERY SAME data on the VERY SAME database in the VERY SAME Oracle session can and will show DIFFERENT execution times.
So why do you want to know a specific query's execution time? What do you expect that to tell you?
If you mean that you want to know how long an existing query being executed is still going to take - that's usually quite difficult to determine. Oracle does provide a view on so-called long operations. However, only certain factors of a query's execution will trigger that this query is a long operation - and only for those specific queries will there be long operation stats that provide an estimated completion time.
If your slow and long running query does not show in long operation, then Oracle does not consider it a long operation - it fails to meet the specific criteria and factors required as a long operation. This is not a bug or an error. Simply that your query does not meet the basic requirements to be viewed as a long operation.
Oracle however provides the developer with the means to create long operations (using PL/SQL). You need to know and do the following:
a) need to know how many units of work to do (e.g. how many fetches/loop iterations/rows your code will process)
b) need to know how many units of work thus far done
c) use the DBMS_APPLICATION_INFO package to create a long operation and continually update the operation with the number of work units thus far done
It is pretty easy to implement this in PL/SQL processing code (assuming requirements a and b can be met) - and provide long operation stats and estimated completion time for the DBA/operators/users of the database, waiting on your process to complete.

Query Execution Time for a Query causing ORA-1555

dear Gurus
I have ORA-01555 error , earlier I used the Query Duration mentioned in Alert Log and increased the Undo Retention as I did not find th UnDOBLKS column of v$undostat high for the time of occurence of ORA-01555..
But new ORA-01555 is coming whose query duration exceeds Undo Retention time..
My question -
1. Is it possible to accurately find the query duration time besides the Alert Log file ?

abhishek, as you are using an undo tablespace and have already increased the time that undo data is retained via undo_retention then you might want to consider the following ideas which were useful with 1555 error under manual rbs segment management.
1- Tune the query. The faster a query runs the less likely a 1555 will occur.
2- Look at the processing. If a process was reading and updating the same table while committing frequenctly then the process under manual rbs management would basically create its own 1555 error rather than just being the victum of another process changing data and the rbs data being overlaid while the long running query was still running. With undo management the process could be generating more data than can be held for the undo_retention period but because it is committed Oracle has been told it doesn't really have to keep the data for use rolling back a current transaction so it gets discarded to make room for new changes.
If you find item 2 is true then separating the select from the update will likely eliminate the 1555. You do this by building a driving table that has the keys of the rows to be updated or deleted. Then you use the driver to control accessing the target table.
3- If the cause of the 1555 is or may be delayed block cleanout then select * from the target prior to running the long running query.
Realistically you might need to increase the size of the undo tablespace to hold all the change data and the value of the undo_retention parameter to be longer than the job run time. Which brings up back to option 1. Tune every query in the process so that the job run time is reduced to optimal.
HTH -- Mark D Powell --
dear mark
Thanks for the excellent advise..I found that the error is coming because of frequent commits..which is item 2 as u righly mentioned ..
I think I need to keep a watch on the queries running , I was just trying to find the execution time for the queries..If there is any way to find the query duration without running a trace ..
regards
abhishek

ETL execution time want to reduce

Hi Everybody,
I am working on owb 10g with R2.
Environment is win 2003 server 64bit itanium server,
oracle 10 database in netap server mapped as I drive on 186 server where owb installed.
source files : oracle's staging schema
target : oracle target schema
Problem :
The problem is before 1 month our ETL process was taking 2 hrs to complete .
now a days 5 hrs...i dont know why.
any body suggest what I need to check in owb.
for optimization.

Thanks for reply sir,
as you suggest a query for checking the execution time in desc order, I am sending you little bit o/p for today date execution.
MAP_NAME
START_TIM END_TIME ELAPSE_TIME NUMBER_ERRORS NUMBER_LOGICAL_ERRORS
NUMBER_RECORDS_SELECTED NUMBER_RECORDS_INSERTED NUMBER_RECORDS_UPDATED
NUMBER_RECORDS_DELETED NUMBER_RECORDS_DISCARDED NUMBER_RECORDS_MERGED
"M_CONTRACT_SUMMARY_M2__V_1"
20-NOV-07 20-NOV-07 1056 0 0
346150 0 346052
0 0 0
MAP_NAME
START_TIM END_TIME ELAPSE_TIME NUMBER_ERRORS NUMBER_LOGICAL_ERRORS
NUMBER_RECORDS_SELECTED NUMBER_RECORDS_INSERTED NUMBER_RECORDS_UPDATED
NUMBER_RECORDS_DELETED NUMBER_RECORDS_DISCARDED NUMBER_RECORDS_MERGED
"M_POLICY_SUSPENCE_V_1"
20-NOV-07 20-NOV-07 884 0 0
246576 0 0
0 0 246576
MAP_NAME
START_TIM END_TIME ELAPSE_TIME NUMBER_ERRORS NUMBER_LOGICAL_ERRORS
NUMBER_RECORDS_SELECTED NUMBER_RECORDS_INSERTED NUMBER_RECORDS_UPDATED
NUMBER_RECORDS_DELETED NUMBER_RECORDS_DISCARDED NUMBER_RECORDS_MERGED
"M_ACTIVITY_AMT_DETAIL_M3_V_1"
20-NOV-07 20-NOV-07 615 0 0
13927 13927 0
0 0 0
==================================
I think Elapse time depend on No of rec selected and inserted merge wahtever be...if rec are reduce then time also reduce but compare to before (when ETL got finished within 2 hrs), so we got more than 100 sec's diffrence b/w that time and now .
source tables analyzed daily before mapping execution started. and target tables analyzed at evening time .
As a remeber from last that day nothing any major changes made in ETL mappings. one day there was a problem arise that source_loc for another Process Wonders ( As i told before there are total 3 main Process runs Sun , Wonders and Life_asia,in which sun and wonders are scheduled) so we have correct that loc and deployed the all mappings as requier msg from control center.
then mappings runs fine but Execution time increased by 1 hrs more(5 hrs+) than before (3-4hr).
and normal time was
2 hrs for LifeAsia.
30 mnt for wonders
15 mnts for Sun.
Can you Suggest me what i can do for temp/permanent solution of this problem.
according to our System config...
1 tb hdd.in which 2-300 gb free
4 gb ram
64 bit windows os
Used temp tablespace 99 % with auto-extendable
Used target table space 93-95%....
data load incrementaly daily.
load window was 5am to 8 am which is now a days going upto 12 .30 pm
after which matview going to refresh.
after which reports and cubes refresh.
So all process going to delay and this is live process .
suggest me if any info u want .
abt hardware config , we need to increase some...? like ram ....memory..etc.
@wait for reply...

Variable execution time

Hi,
I am executing a query using parallel hint whose execution time varies when i am executing it continuously.
I created all the required indexes and the query uses all those indexes.
For example ::
1st time ---->3.20 sec
2nd time ---->1.34 sec
3rd time ----->5.41 sec
4th time ----->2.5 sec
5th time ----->5.8 sec
Can any one explain me why it is taking different execution time.
Thanks
srikar

TRACE/TKPROF will give you exact timings.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#PFGRF01010
http://www.oracle-base.com/articles/10g/SQLTrace10046TrcsessAndTkprof10g.php
http://www.oracle-base.com/articles/8i/TKPROFAndOracleTrace.php
Don't expect the execution time of a query to be always 100% the same if you run that query multiple times.
Workload changes, data changes, what's in LRU/MRU changes, etc.

Queries taking high execution time for zero count

Hi,
i have procedures executing as jobs.
the procedures take a lot of time to execute when the cursor count is zero.
what might be the reason for this?

GreenHorn wrote:
cursor 1 - select a.col1, b.col1,decode(c.col1,1,c.col1,2,c.col2,null) col3 from a,b,c
where joing conditions
and nvl(c.col3,c.col4) = b.col3
and c.col5 is null
cursor 2 - cursor 1 - select a.col1, b.col1,decode(c.col1,1,c.col1,2,c.col2,null) col3 from a,b,c
where joing conditions
and a.timestamp > sysdate-1
and nvl(c.col3,c.col4) = b.col3
and c.col5 is not nulll
cursor 2 first updates the values of col5 to null
cursor 1 recalculates the value of col5 and updates it.
c is a partitioned table and partition code is also present in the where condition.One question: Since you say that the cursor is "updating", but the cursor is a query, does this mean that you're performing row-by-row processing in a loop?
If yes, you might be better off with doing this in one or two plain SQL statements, which is probably much faster.
Another question: You say that after taking the described measures the performance was significantly better but became again worse after a couple of days again, is this right?
Can you provide more details, what "good" and "bad" performance means, e.g. in terms of execution time?
You might want to check if the execution plans change between the "good" performance and the "bad" performance.
If your table continuously gets data deleted and for some reason the deleted rows are not re-used, e.g. by using direct-path inserts to add new data, then your segment might become larger and larger and you would need to re-organize the table if you use regularly full table scans against it.
The execution plan posted is not really helpful. Try to use DBMS_XPLAN.DISPLAY to get a proper output including the "Predicate Information" section below the plan and specify to which of the two statements the plan corresponds.
Use the {noformat}{noformat} tags to format the plan output properly here in mono-space fonts.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Edited by: Randolf Geist on Dec 12, 2008 9:57 AM
Note regarding execution plan added

Oracle NoSQL YCSB - continuously increasing execution time

Similar Messages

Maybe you are looking for