Execution time of same program makes big difference

Hello all,
The execution time of same program in PRD system and QAS system makes big difference.
The difference of data is not much(as system copy was run on a regular time schedule. And the system enviroments are exactly the same. However, while the program only cost 2-3 seconds in QAS, it cost 7-8 minutes in PRD.
It only happens when trying to join some tables together.
I've checked the execution plans of same search, they are different:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '350' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
---   12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
--   9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
--   6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
--   4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
--   2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 323 , Estim. #Rows = 2,380 )
                   Search Columns: 3
                   Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
                   Access Predicates Filter Predicates
PRD:
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
---   12 NESTED LOOPS
( Estim. Costs = 208 , Estim. #Rows = 1 )
Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
--   9 NESTED LOOPS
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
--   6 NESTED LOOPS
Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
--   4 NESTED LOOPS
Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
1 INDEX RANGE SCAN TZPA~0
Search Columns: 1
Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
Access Predicates
---   3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Filter Predicates
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
Search Columns: 1
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 120 , Estim. #Rows = 1 )
Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 119 , Estim. #Rows = 1 )
Search Columns: 4
Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 89 , Estim. #Rows = 1 )
Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 88 , Estim. #Rows = 1 )
                   Search Columns: 4
                   Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
                   Access Predicates Filter Predicates
Could anyone tell me the reason? I've found note 724545 but not sure.
And, how to read the execution plan?(1 first or 12 first?)
Best Regards,
Robin

Hello Michael.
Thank you.
However, the sql statement is same:
QAS:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '350' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '350' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '350' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 666 , Estimated #Rows = 72 )
---   12 HASH JOIN
( Estim. Costs = 666 , Estim. #Rows = 72 )
Estim. CPU-Costs = 37,505,220 Estim. IO-Costs = 663
Access Predicates
--   9 HASH JOIN
( Estim. Costs = 268 , Estim. #Rows = 51 )
Estim. CPU-Costs = 18,679,663 Estim. IO-Costs = 267
Access Predicates
--   6 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 38 )
Estim. CPU-Costs = 264,164 Estim. IO-Costs = 25
--   4 NESTED LOOPS
( Estim. Costs = 25 , Estim. #Rows = 27 )
Estim. CPU-Costs = 258,494 Estim. IO-Costs = 25
--   2 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
( Estim. Costs = 25 , Estim. #Rows = 24 )
Estim. CPU-Costs = 253,454 Estim. IO-Costs = 25
Filter Predicates
1 INDEX RANGE SCAN DIFT_POS_IDENT~SA
( Estim. Costs = 1 , Estim. #Rows = 554 )
Search Columns: 1
Estim. CPU-Costs = 29,801 Estim. IO-Costs = 1
Access Predicates
3 INDEX RANGE SCAN TRACT_POSCONTEXTID
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
5 INDEX UNIQUE SCAN TZPA~0
Search Columns: 2
Estim. CPU-Costs = 210 Estim. IO-Costs = 0
Access Predicates
---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
( Estim. Costs = 242 , Estim. #Rows = 2,540 )
Estim. CPU-Costs = 10,811,361 Estim. IO-Costs = 241
7 INDEX RANGE SCAN ZTM0108~0
( Estim. Costs = 207 , Estim. #Rows = 2,540 )
Search Columns: 3
Estim. CPU-Costs = 9,790,330 Estim. IO-Costs = 207
Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
( Estim. Costs = 397 , Estim. #Rows = 2,380 )
Estim. CPU-Costs = 11,235,469 Estim. IO-Costs = 396
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 323 , Estim. #Rows = 2,380 )
                   Search Columns: 3
                   Estim. CPU-Costs = 10,288,477 Estim. IO-Costs = 323
                   Access Predicates Filter Predicates
PRD:
SQL Statement
SELECT
T_00.RANL , T_00.XALLB , T_00.REPKE , T_00.REWHR , T_00.HKONT ,   T_00.ZTMNAIBRX , T_00.GSART ,
T_00.ZTMHOYMNX , T_00.ZTMSBKBNX ,   T_00.ZTMSHDAYZ , T_00.ZTMMBHZKP , T_01.BAL_SH_CUR ,
T_01.ZTMSIHONP ,   T_02.SECURITY_ID , T_02.SECURITY_ACCOUNT
FROM
ZTM0108 T_00, ZTM0135 T_01, TRACV_POSCONTEXT T_02
WHERE
T_00.MANDT = '500' AND   T_00.BUKRS = 'MC51' AND   T_00.ZTMMCSNGX = '200806' AND
T_02.SECURITY_ACCOUNT = '0001' AND   T_01.MANDT = '500' AND   T_01.BUKRS = T_00.BUKRS AND
T_01.ZTMMCSNGX = T_00.ZTMMCSNGX AND   T_01.PARTNER = T_00.REPKE AND   T_02.MANDT = '500' AND
T_02.SECURITY_ID = T_00.RANL
Execution Plan
SELECT STATEMENT ( Estimated Costs = 209 , Estimated #Rows = 1 )
---   12 NESTED LOOPS
      |    ( Estim. Costs = 208 , Estim. #Rows = 1 )
      |    Estim. CPU-Costs = 18.996.864 Estim. IO-Costs = 207
      |--   9 NESTED LOOPS
      |   |   ( Estim. Costs = 120 , Estim. #Rows = 1 )
      |   |   Estim. CPU-Costs = 10.171.528 Estim. IO-Costs = 119
      |   |--   6 NESTED LOOPS
      |   |   |   Estim. CPU-Costs = 27.634 Estim. IO-Costs = 0
      |   |   |--   4 NESTED LOOPS
      |   |   |   |   Estim. CPU-Costs = 27.424 Estim. IO-Costs = 0
      |   |   |   |-----1 INDEX RANGE SCAN TZPA~0
      |   |   |   |       Search Columns: 1
      |   |   |   |       Estim. CPU-Costs = 5.584 Estim. IO-Costs = 0
      |   |   |   |       Access Predicates
      |   |   |   ---   3 TABLE ACCESS BY INDEX ROWID DIFT_POS_IDENT
      |   |   |       |   Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |   |       |   Filter Predicates
      |   |   |       -
2 INDEX RANGE SCAN DIFT_POS_IDENT~PT
      |   |   |               Search Columns: 1
      |   |   |               Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |   |               Access Predicates
      |   |   -
5 INDEX RANGE SCAN TRACT_POSCONTEXTID
      |   |           Search Columns: 2
      |   |           Estim. CPU-Costs = 210 Estim. IO-Costs = 0
      |   |           Access Predicates
      |   ---   8 TABLE ACCESS BY INDEX ROWID ZTM0108
      |       |   ( Estim. Costs = 120 , Estim. #Rows = 1 )
      |       |   Estim. CPU-Costs = 10.143.893 Estim. IO-Costs = 119
      |       -
7 INDEX RANGE SCAN ZTM0108~0
      |               ( Estim. Costs = 119 , Estim. #Rows = 1 )
      |               Search Columns: 4
      |               Estim. CPU-Costs = 10.142.167 Estim. IO-Costs = 119
      |               Access Predicates Filter Predicates
      ---   11 TABLE ACCESS BY INDEX ROWID ZTM0135
          |    ( Estim. Costs = 89 , Estim. #Rows = 1 )
          |    Estim. CPU-Costs = 8.825.337 Estim. IO-Costs = 88
10 INDEX RANGE SCAN ZTM0135~0
                   ( Estim. Costs = 88 , Estim. #Rows = 1 )
                   Search Columns: 4
                   Estim. CPU-Costs = 8.823.742 Estim. IO-Costs = 88
                   Access Predicates Filter Predicates
Only difference is the client.
I see that QAS use index SA on table DIFT_POS_IDENT first, while PRD deal with table TZPA first...Is it the reason?
Best Regards,
Robin

Similar Messages

What is the difference in execution time between a program written in C language and the same program made with LabView?

what is the difference in execution time between a program written in C language and the same program made with LabView?

Hi Pepe
You cannot say which is faster, the LV or the C programm. The only way to be sure is to program in both environments and to check than. Check this for some benchmark examples:
http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F?OpenDocument&node=200059
Luca
Regards,
Luca

Adding a column makes big difference with a simple query

Hello All,
The oracle environment I am working with is
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
and
PL/SQL Release 9.2.0.8.0 - Production
I have a question for the following 2 queries. The only difference is that first one has an extra field than the second one. That extra field makes big difference regarding excution time. One is 4 seconds and the other is 5 minutes. Could anyone help me to understand why? Thank you for your help! -Susan
4 Seconds
================================================================
select distinct B.A_CA.CA_ID, B.A_CA.CE_ID
from B.A_CA, B.CA_LIST_DTLS
where UPPER(deleted(B.A_CA.CA_ID) = 'N'
and UPPER(B.CA_LIST_DTLS.CA_LIST_NAME) = 'SW'
and B.A_CA.CA_ID = B.CA_LIST_DTLS.CA_ID ;
5 minutes
==============================================================
select distinct B.A_CA.CA_ID
from B.A_CA, B.CA_LIST_DTLS
where UPPER(deleted(B.A_CA.CA_ID) = 'N'
and UPPER(B.CA_LIST_DTLS.CA_LIST_NAME) = 'SW'
and B.A_CA.CA_ID = B.CA_LIST_DTLS.CA_ID ;
Below is the function
=============================================================
FUNCTION deleted ( in_ca_id IN B.A_CA.CA_ID%TYPE ) RETURN VARCHAR2 IS
n_result VARCHAR2(20);
cnt NUMBER :=0;
cursor cur is
SELECT COUNT(*)
from B.A_CA
where B.A_CA.CA_ID=in_ca_id
and (B.A_CA.COMPLAINT_FLAG = 'Y'
or B.A_CA.DELETE_FLAG = 'Y') ;
BEGIN
OPEN cur;
FETCH cur INTO cnt;
CLOSE cur;
If cnt >0 then
n_result := 'Y';
else
n_result := 'N';
end if;
RETURN n_result;
EXCEPTION
WHEN NO_DATA_FOUND THEN
return 'N/A';
END;
Edited by: 849989 on Apr 5, 2011 10:25 AM

Explain plan for two queries:
The fast one:
Plan
SELECT STATEMENT CHOOSE Cost: 4,223 Bytes: 116,032 Cardinality: 2,072
5 SORT UNIQUE Cost: 4,223 Bytes: 116,032 Cardinality: 2,072
4 NESTED LOOPS Cost: 4,212 Bytes: 116,032 Cardinality: 2,072
1 TABLE ACCESS FULL B.CA_LIST_DTLS Cost: 68 Bytes: 87,024 Cardinality: 2,072
3 TABLE ACCESS BY INDEX ROWID B.A_CA Cost: 2 Bytes: 14 Cardinality: 1
2 INDEX UNIQUE SCAN UNIQUE B.A_CA_PK Cost: 1 Cardinality: 1
The slow one:
Plan
SELECT STATEMENT CHOOSE Cost: 305 Bytes: 111,888 Cardinality: 2,072
4 SORT UNIQUE Cost: 305 Bytes: 111,888 Cardinality: 2,072
3 HASH JOIN Cost: 295 Bytes: 111,888 Cardinality: 2,072
1 TABLE ACCESS FULL B.CA_LIST_DTLS Cost: 68 Bytes: 87,024 Cardinality: 2,072
2 INDEX FAST FULL SCAN UNIQUE B.A_CA_PK Cost: 225 Bytes: 131,928 Cardinality: 10,994
Edited by: 849989 on Apr 5, 2011 11:49 AM

Ideal execution time for any program

Hi,
Is there any method to determine the ideal execution time for a program ?
Or else how to determine that ?
I just wanted the max. time that a program can take so that the performance would not be hampered.
Thanks,
Binay.

did you ask for the 'ideal execution time' or 'how to measure execution times'?
The second question was answered in one of your other questions.
Optimization:
Do SQL Trace, go to Summary by SQL statement, check 10 Top contributions (time = duration).
Try to optimize them, note minimal time per record, if larger than 10.000 microsecodns, then you should index usage.
Do SE30, go to hit list, sort by net time, again address 10 Top contributions, try to optimize, check the coding.
Do optimization and trace again, check again 10 Top contributions ....
Siegfried

Is it better to load several apps at the same time, or one at a time? Does it make a difference?

I have replaced the "Login Items" functionality with an Automator app that runs when I log in. It asks if I want to load all my startup items now, or just cancel it. I have several startup items, including some utility apps, but also bigger apps like Safari and iTunes.
I currently do this by "Get Specified Finder Items" providing a list of the apps, and then "Open Finder Items," opening all of them at once so they are all loading up simultaneously. I then wait for a while until my CPU has calmed down and everything is ready to go (which is the reason for moving them to an Automator workflow in the first place; I can cancel loading if I don't want to wait).
Would it be better to open one, wait for it to load, open the next, etc.? Would this have any effect on performance as far as either the time it takes to load up or the efficiency of the computer as it operates with all of these things loaded?
Just curious. It would be difficult to actually test, since i imagine the difference would be small if any.

I don't think it makes any difference.

Huge difference in Execution time in same Query with different Parameter

Hi Experts,
We are facing an unique problem once we are executing the query in HANA SQL prompt. This Query was generated from BObj and executing in HANA system. Once this query running with following condition, it is taking almost 7-00 minute to execute and returning around 924 rows.
<< WHERE
Table__1."LOGSYS" IN ('RKGCLNT102')
AND
Table__1."CompanyCode" IN ('7240','7245')
AND
Table__1."Plant" IN ……………… >
However if we run the same query with some different plant, It is taking only 2 second. Please find the Query here.
<< WHERE
Table__1."LOGSYS" IN ('RKGCLNT102')
AND
Table__1."CompanyCode" IN ('7245','7600')
AND
Table__1."Plant" IN ……………… >
This is really an unexpected behavior and we are not able to get the actual reason why it is behaving like this.
Could anyone please help to analyze this issue to fine the root cause.
Thanks in Advance.
Regards
Satrajit.

Hi there
Unfortunately you provided too few information to analyze the issue.
Maybe the underlying tables have very skew data and the first select has to read a larger share of the base tables.
Maybe the columns had been unloaded before and the first query had to load them into memory first.
Is the runtime always bad with the one and always good with the other set of parameters?
Have you checked the PlanViz for both versions? How do these differ?
- Lars

Execution of TestStand-Sequence in LabVIEW via TS-API: Different Execution times for same sequence

Hello Forum-Members,
I have a problem concerning the execution of an TestStand-Sequence in LabVIEW. I have created a VI that offers the ability to choose a TestStand-Sequence-File and then executes the sequence using the TestStand-API. The implementation is based on an example in C++-Application found following this link:
http://forums.ni.com/t5/NI-TestStand/Unreleased-references-using-engine-API-in-C/m-p/2927314#M46034
The implementation works quite solid in case the VI is executed the first time. The VI processes the chosen sequence in a acceptable duration.
But in case the execution is started a second time, the execution of the sequence takes ca. 30sec more than in the first case.
Until now I have not found a solution and hope someones got a hint concerning this problem...
I am using LabVIEW 2013 and TestStand 2013.
I have attached my own VI, a sample sequence with a small sample VI, so you can reproduce the problem.
Kind regards,
TobiKi
Solved!
Go to Solution.
Attachments:
Exe-TestStand-Sequence.vi ‏25 KB
Sequenz.vi ‏8 KB
Test-Sequenz.seq ‏5 KB

Hi Norbert,
first thanks for your answer.
What would be a reasonable way to replace the "Execution.WaitForEndEx"? My first idea is to get the respective thread of the execution and use the "Thread.WaitForEnd".
To clarify my problem:
The execution of the sequence itself takes longer time and so the execution of the calling VI. I have attached pictures of the log file of the first and second execution.
Further I don't get any dialog popups during the shutdown of TestStand. (I have activated the "ReportObjectLeaks" using the "DebugOptions") While developing the attached VI I've gotten several popups. But these popups disappeared after closing all references.
Maybe you have another hint how to locate the problem.
TobiKi
Attachments:
FirstExecution_20-08-2014.png ‏16 KB
SecondExecution_20-08-2014.png ‏16 KB

Execution time optimizing labview code

Hi,
I would like to optimize my labview program. Is there a way I can plot
the execution time of my program as a function of some parameter I am
changing in my program. I was thinking of placing the entire program in
a while loop and then changing the parameter during each loop iteration
and then outputting the time that the program takes to execute as a
function of the parameter. The problem is how would I obtain the
execution time.
Thank you,
-Tim

Here a re a few more tips:
Running on a typical multipurpose OS will will make things a bit unpredictable because you never know what else is running so you should always repeat each run many times (then take the fastest, not the average, of all corresponding times).
Make sure that each run takes a few hundred milliseconds to get accurate values.
For timing purposes, it might be worth to temporarily raise the execution priority. The results will be much more reproducible (at the expense of useablility).
LabVIEW Champion . Do more with less code and in less time .

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.

Reduce execution time

How to reduce the execution time of this code?
Loop at porder1.
SELECT aufnr bstmg hsdat sgtxt bwart charg FROM mseg INTO
(porder-aufnr,porder-bstmg,porder-hsdat,porder-sgtxt,porder-bwart,
porder-charg)
                                         WHERE matnr = porder1-matnr AND
                                               aufnr = porder1-aufnr AND
                                               werks = porder1-pwerk AND
                                               ( bwart = '101' OR
                                                 bwart = '102' ).
Endselect.
Endloop.
Regards
Praju .

Hi prajwal.
I would like to suggest,
It is possible to reduce the time of execution by Increasing the number of fields in the WHERE clause as only those specific number of records are fetched which results in comparatively less execution time.
Also, SAP has designed such powerfull tools like Transactions - ST05, ST07, ST30, and many more
I would like to suggest you a couple of references relating to your case,
[SDN - Reference for Long execution time during processing of a select query|/thread/477540 [original link is broken];
[SDN - Reference for Reducing the Execution time of the program - Tools|How can i reduce time of execution;
[SDN - Reference for solutions to reduce the execution time of a program|How to reduce my query execution time?;
Hope that's usefull.
Good Luck & Regards.
Harsh Dave

Execution time in microseconds

Hi,
Can someone tell me what should be the ideal execution time of a program in microseconds. My program consists of 2586 lines and has almost around 10 subroutines and some 10 function modules. Could you suggest me how the execution time is determined for a program.
Thanks,
Binay.

You can use simple command like
declare three variables :
data : a Type i,
b type i,
c type i.
start-of-selection.
Write the command in staring
get runtime field a. -> will have intial start time
write the one more command in last
get runtime field b. -> this is final time
c = b - a. -> c will have total execution time in micro seconds
or
you can use ST05 Transaction to find out the time,here you need count the all times.
Thanks
Seshu

Transaction Execution Time

Hii,
Is there any procedure to check execution time of Transaction.
For E.g How we know Trigger time for output
Regards
Amit
Edited by: Amit Gupta on Dec 2, 2008 5:43 AM

Hi Amit,
Normally the performance can be tested with the tcode SM30 and ST05( select queries) , this is done by the ABAPers to know the performance of the program.
Basis team has another set of tcodes ST03 through which they know the execution time of the program , pls check with them.
Regards,
Vvieks

How to get previous days execution time?

Hello All,
I have below 3 tables in my Oracle Database --
1) Table jobs
Job ID Job Name
1      ABC
2      PQR
3      XYZ
2) Table Job_Tasks
Task_ID   TASK_NAME Job_ID
T1              T_ABC            1
T2              T_ABE            1
T3             T_ABD            1
T4             T_PQS            2
T5             T_PQT            2
T6             T_PQU            2
T7             T_XYA            3
T8             T_XYZZ           3
T9             T_XYYA           3
3) Job_LOG_Table
JOB_SEQ JOB_ID JOB_NAME   START_TIME END_TIME           STATUS
1111              1        ABC    06/09/2013 11:00     06/09/2013 13:00   COMPL
1234              1        ABC    07/09/2013 11:30     07/09/2013 13:30   COMPL
1235              1        ABC    08/09/2013 11:30     08/09/2013 13:30   COMPL
1244              1        ABC    09/09/2013 11:00     09/09/2013 13:00   COMPL
1354              1        ABC    10/09/2013 11:30      10/09/2013 13:30   RUNNING
Question Is --
   I would like to display the job status from yesterday and from time 20:00 onwards.. ie. it should display the job_SEQ 1354. ( start_time >= (sysdate-1)||'20:00:00') and also want to disaply previous days execution time for same job (ie. for 9th Sep).
The result should be --   Job_name PREV_START_TIME, PREV_END_TIME, TODAYS_START_TIME, TODAYS_END_TIME, STATUS
As I am displaying the jobs from yesterday 20:00 hour onwards.. I am unable to get previous execution time for the same job.
I tried with Analylitical function LAG but it's showing PREV_START_TIME.and PREV_END_TIME as BLANK.
Could you please help me to resolve the issue?
Thank you in advance.

As suggessted by Mike, below is the modification I have done in my sql and I think it's working now....
I will check for more volume of data and confirm. --
select original_sql as
select w.job_id,
w.job_name,
r.start_time,
r.end_time,
r.status
from
jobs w,
job_log_table r
where
r.job_id=w.job_id
select job_id,job_name,
(select start_time from job_log_table j where j.job_id=os.job_id and j.start_time>=sysdate-2 and rownum <2) prev_start_time,
start_time,
end_time,
status
from Original_sql os
where
os.start_time>=to_date(to_char(sysdate-1,'DD/MM/YYYY') || ' 20:00:00','Dd/MM/YYYYHH24:MI:Ss')
as of now, I am getting the below result --
job_id, job_name prev_start_time,      prev_end_time,            curr_start_time,           curr_end_time,           status
       1           ABC 09/09/2013 11:30   09/09/2013 13:00      10/09/2013 11:30          10/09/2013 13:30          RUNNING
Thank you !

As a novice computer user, I wonder why I'm often getting "white-out" (program/app I'm working in goes totally blank onscreen). If it makes a difference, I'm working 99% of the time on battery, not AC, power. What causes this?

As a novice computer user, I wonder why I'm often getting "white-out" (program/app/site I'm working in goes totally blank onscreen). This is when I'm Internet online. If it makes a difference, I'm working 99% of the time on battery, not AC, power. Some of the possibilities I'm guessing are: glitches in my Verizon FiOS Wi-Fi providership?; staying too long on a site that's waiting for me to finish and "Submit"?; computer hardware prob (yikes, I hope not! It's brand new). Any ideas out there?

When this 'white-out' occurs, is the display 100% white with no error message and no menu bar?
Does this occur when you are using Wi Fi or connected to the Internet via the Ethernet cable?
Ciao.

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Execution time of same program makes big difference

Similar Messages

Maybe you are looking for