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

Similar Messages

Validate/madatory in order to avoid long time for the program execution.

Below is my selction screen. I would like to do validations for specific fields to make them mandatory fields   as well.
Could you please suggeste me what are the fields that I can validate/madatory in order to avoid long time for the program run.
*Program selections
SELECTION-SCREEN : BEGIN OF BLOCK b1 WITH FRAME TITLE text-h01.
SELECT-OPTIONS : o_as4loc   FOR v_as4local,
                 o_ddlang   FOR ddlanguage,
                 o_vkorg    FOR vkorg     MEMORY ID vko,
                 o_auart    FOR auart              MEMORY     ID aat,
                 o_fdnam    FOR fdnam,
                 o_spart    FOR spart   MEMORY ID spa,
                 o_vbeln    FOR vbeln            MEMORY ID aun,
                 o_posnr    FOR posnr,
                 o_matnr    FOR matnr            MEMORY ID mat,
                 o_pltyp    FOR pltyp            MEMORY ID vpl,
                 o_j_3ar    FOR j_3arqda,
                 o_kzr00    FOR kbetr,                       " -ZR00
                 o_kalsm    FOR kalsmasd,
                 o_kmwst    FOR kbetr,                       " -MWST
                 o_kbmen    FOR kbmeng,
                 o_land1    FOR land1            MEMORY ID LND
SELECTION-SCREEN : END OF BLOCK b1.
Thanks in advance.

Hi,
Make key fields as well as fields on which there in an index in the database table mandatory.
Regards,
Abhijit G. Borkar

Execution time for web reports

Hello every one,
How to calculate execution time for web reports, for query execution we will go through RSRT, by giving query name and press execute + Debug button then select statistical data & Do not Cache buttons then press enter, after getting output press on back button, we will get duration of the query.....
But my question is , can we calculate execution time for webreport, if so can you please guide me.
and can you also tell me , if there is any RRI for one report, how to calculate execution time for these queries.
Ex : Query ABC have XYZ as its drilldown report , i need to calculate execution time for XYZ report via ABC report.
Thanks in advance,
Best Regards.
NP.

Hi,
For reports executed in java web you can add the parameter &PROFILING=X
to the URL in order to record the execution time. Please have a look at SAP note 1048691 for further information.
Best regards,
Janine

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

Can I reduce the execution time for a step in a TestStand ?

Hi,
I calculated the a single step execution time for TestStand Ver 2.0. It comes to around 20 milliseconds/step. Can I reduce this excution time ?
Are there any settings available for configuring execution time parameters except result logging and exception handlings to reduce the execution time ?

It's difficult to tell how you what time you are reporting for your step. Clearly we don't have control of the time it takes your code to execute. However, we are constantly working on reducing the overhead of calling the code. In addition, you don't mention the type of step you are calling. One way to have a common reference is to use the example \Examples\Benchmarks\Benchmarks.seq. Below have have posted the results of running this sequence with both tracing and result collection enabled and then disabled. I have a 700 MHz, 128 MB RAM, Dell PIII laptop. In this example there is no code within the code modules. You notice that calling a DLL has the least overhead with a minimum of 7.459 ms with tracing and results enabled and 0.092 ms with tracing and results disabled. Although not included below, if I enable results be disable tracing I get a minimum time of 0.201 ms, a 100x improvement on your time.
With Results and Tracing enabled.
7.578 milliseconds per step for CVI Standard Prototype - Object File
7.579 milliseconds per step for CVI Standard Prototype - DLL
7.459 milliseconds per step for DLL Flexible Prototype
8.589 milliseconds per step for DLL Flexible Prototype Numeric Limit
9.563 milliseconds per step for DLL Flexible Prototype Numeric Limit with Precondition
10.015 milliseconds per step for DLL Flexible Prototype Numeric Limit with Precondition and 4 Parameters
7.868 milliseconds per step for ActiveX Automation
8.892 milliseconds per step for LabVIEW Standard Prototype
With tracing and results disabled.
0.180 milliseconds per step for CVI Standard Prototype - Object File
0.182 milliseconds per step for CVI Standard Prototype - DLL
0.092 milliseconds per step for DLL Flexible Prototype
0.178 milliseconds per step for DLL Flexible Prototype Numeric Limit
0.277 milliseconds per step for DLL Flexible Prototype Numeric Limit with Precondition
0.400 milliseconds per step for DLL Flexible Prototype Numeric Limit with Precondition and 4 Parameters
0.270 milliseconds per step for ActiveX Automation
1.235 milliseconds per step for LabVIEW Standard Prototype

Estimate execution time for CTAS

Hi,
I am searching for long to find a way to estimate the execution time for CTAS commands. I am a DBA. Our users run CTAS commands to load millions of rows. The commands fetch data from 4-5 very big tables each with millions of records and process them using where clause and group by clause and finally create the table. All these things are coded in the CTAS command. These CTAS sometime takes long time like 5 , 8 Hrs. Users frequently ask me to find how long it's going to take. I use both OEM and TOAD. But I couldn't find the time estimated from these tools. I feel that there must be some way, but I don't know the method.
Can any body please help me in this regard?
Thanks & Regards
Ananda Basak

It depends on a number of factors chief among them how accurate your estimate needs to be but also including things like what version of Oracle you're using, how accurate your database statistics are, etc.
One option is to look at the TIME column in the plan. For example, if I wanted to do a CTAS to create a copy of the EMP table, the optimizer expects that to take on the order of a second. Of course, the optimizer's estimates are only estimates and are only as accurate as the database statistics that are in place. If the optimizer generates a bad plan, it's likely because the optimizer expects some operation to take much more or much less time than it does in reality in which case the optimizer's runtime estimate is likely to be way off.
SQL> explain plan for create table emp_copy as select * from emp;
Explained.
SQL> ed
Wrote file afiedt.buf
1 select *
2*   from table( dbms_xplan.display() )
SQL> /
PLAN_TABLE_OUTPUT
Plan hash value: 2748781111
| Id | Operation              | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE TABLE STATEMENT |          |    14 |   546 |     4   (0)| 00:00:01 |
|   1 | LOAD AS SELECT        | EMP_COPY |       |       |            |          |
|   2 |   TABLE ACCESS FULL    | EMP      |    14 |   546 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------Depending on the query plan, you may be able to query the GV$SESSION_LONGOPS table to track the progress of any long-running operations in your session. If your query plan involves a lot of full table scans, sorts that take more than a few seconds, hash joins, etc. then it is likely that you'll be able to chart the progress of a query over time by watching GV$SESSION_LONGOPS change. Of course, if your query is going to need to do many long-running operations, you'll need to a human to interpret the data a bit in order to figure out where in the plan Oracle currently is and how far along that means the entire query is.
SELECT *
FROM gv$session_longops
WHERE time_remaining > 0If you're using 11g and you have the performance and tuning pack licensed, you could also potentially use the V$SQL_PLAN_MONITOR view.
Justin

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

Execution time for Call Library Function Node

I am experimenting with the Call Library Function Node block in LabVIEW and am curious if it should be running faster than what I'm seeing. For testing purposes, I have compiled and transfered to my RT target the .out file from the KB article http://digital.ni.com/public.nsf/allkb/81D1172E3C28A5E4862575CC0076A230 (I'm using the vxworks 6.1 version). The function in the .out file just multiplies two inputs together, adds a constant, and returns the result. I have put this inside a 1 kHz timed loop with a commanded period of 1 ms and via the Ticks(ms) block and shift registers I calculate the amount of time per loop execution. This process is apparently taking 5 ms per cycle and to me that seems slow. Is that roughly the correct execution time for this kind of setup? I will attach my test .vi file.
What I'm using:
Windows 7
LabVIEW 2009 SP1
NI-cRIO 9024 with NI-RIO 3.4.0
Solved!
Go to Solution.
Attachments:
test DLL.vi ‏31 KB

First off, the way you are doing timing isn't necessarily accurate because you don't know when the tick count VI is being called. For example, if it gets called on one iteration after your call library node executes, and the next iteration it gets called before the CLFN it executes, the subtraction doesn't include the call of the CLFN so you aren't seeing the true time it is taking for the dll to be called.
Where it says "error" on the top left hand corner of your loop. left click and choose previous iteration timing. Also, do you have the ability to choose a 1 Mhz clock? Are you sure it's actually being run on the RT and not on your PC? Running it on the PC would definitely make it difficult to execute at a 1 kHz rate.
CLA, LabVIEW Versions 2010-2013

Execution Time for T.Code

Hi Experts,
I want to know the exact execution time for a t.code. I check it in ST03 or ST03n but I can't get proper data. In ST03 I get the average and total response time but I want the exact ececution or response time.
Waiting for your inputs.
Regards,
Nisit

From SAP
For old verions
In ST03 transaction
click on "Performance Database" tab
Then double click on Total
It will open Dialogue box CHOOSE TIME PERIOD ,select the time period and then click on the required date
Then Click on Transaction Profile ,here it will give the list of transaction executed and its execution time
In STO3N , you will find "TRANSACTION PROFILE" under Analysis views, when you double click on it will give present days Transaction codes executed.
If you want the month data then go to Export mode in ST03n ,you will get the data "TRANSACTION PROFILE" under Analysis views .
Regards,
Beena

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

How to find the Execution Time for Java Code?

* Hi everyone , i want to calculate the execution time for my process in java
* The following was the ouput for my coding,
O/P:-
This run took 0 Hours ;1.31 Minutes ;78.36 Seconds
*** In the above output , the output should come exactly what hours , minutes and seconds for my process,
but in my code the minutes are converted into seconds(It should not)...
* Here is my coding,
    static long start_time;
    public static void startTime()
        start_time = System.currentTimeMillis();
    public static void endTime()
        DecimalFormat df = new DecimalFormat("##.##");
        long end_time = System.currentTimeMillis();
        float t = end_time - start_time;
        float sec = t / 1000;
        float min = 0, hr = 0;
        if (sec > 60) {
            min = sec / 60;
        if (min > 60) {
            hr = min / 60;
        System.out.println("This run took " + df.format(hr) + " Hours ;"+ df.format(min) + " Minutes ;" + df.format(sec) + " Seconds");
    }* How to Calcualte exact timing for my process....
* Thanks

* Hi flounder, Is following code will wotk perfectly?
     public static void endTime()
          DecimalFormat df = new DecimalFormat("##.##");
          long end_time = System.currentTimeMillis();
          float t = end_time - start_time;
          float sec = t / 1000;
          float min = 0, hr = 0;
          while(sec >= 60){
     min++;
     sec = sec -60;
     if (min >= 60){
     min = 0; //or min = min -60;
     hr++;
          System.out.println("This run took " + df.format(hr) + " Hours ;"+ df.format(min) + " Minutes ;" + df.format(sec) + " Seconds");
     }

How can i calculate execution time for methods?

I'm making a project that i want to calculate execution time for a
method in "miliseconds" or "microseconds".You see,I have a sort algorithm and i want to calculate execution time of this algorithm.How can i do?
Thanks...

Just remembered.
The answer you get isn't trustworthy below a hundred millis, so you may need to sort a hundred or a thousand times to get a reasonable elapsed time. You also need to run the test five or ten times and take an average. In Windows you should fire up the Task Manager and be sure that your other CPU usage is as near to zero as you can get.

How to get execution time for a view inside procedure ?

Hi,
I want execution time for all the views in my database. I tried "execute immediate" but it does not seem to work.
It is not waiting to complete the execution of view to go to next step.
If I am executing the same statement in sqlplus, it is displaying correct time.
Here is my code:
Begin
output_file := UTL_FILE.FOpen ('RECORDING',v_FileName, 'W', 32767);
Open viewcur;
Loop
Fetch viewcur into v_view_name;
     Exit when viewcur%notfound;
     SELECT to_char(systimestamp,'DD-MON-YYYY HH24:MI:SS.FF') into v_start_time from dual;
     v_stmt := 'Select * from ' ||v_view_name ;
     Execute Immediate v_stmt;
SELECT to_char(systimestamp,'DD-MON-YYYY HH24:MI:SS.FF') into v_end_time from dual;
v_record_str := v_start_time||','||v_view_name||','||v_end_time;
     UTL_FILE.PUT_LINE(output_file, v_record_str);
End Loop;
Close viewcur;
utl_file.fClose(output_file);
End ;
Oracle version: 11.1.0.6.0

Hi,
Running with a user with dba privileges:
DECLARE
    CURSOR viewcur IS
        SELECT table_name
        FROM   dictionary d
        WHERE d.table_name LIKE 'ALL_A%';
    output_file UTL_FILE.file_type;
    v_FileName VARCHAR2(30) := 'TEST_VIEW_TIME.TXT';
    v_view_name dictionary.table_name%TYPE;
    v_start_time varchar2(30);
    v_end_time varchar2(30);
    v_record_str varchar2(200);
    v_stmt varchar2(200);
BEGIN
    output_file := UTL_FILE.FOpen('EXT_FILES', v_FileName, 'W', 32767);
    OPEN viewcur;
    LOOP
        FETCH viewcur
            INTO v_view_name;
        EXIT WHEN viewcur%NOTFOUND;
        SELECT TO_CHAR(systimestamp, 'DD-MON-YYYY HH24:MI:SS.FF')
        INTO   v_start_time
        FROM   dual;
        v_stmt := 'Select * from ' || v_view_name;
        EXECUTE IMMEDIATE v_stmt;
        SELECT TO_CHAR(systimestamp, 'DD-MON-YYYY HH24:MI:SS.FF')
        INTO   v_end_time
        FROM   dual;
        v_record_str := v_start_time || ',' || v_view_name || ',' || v_end_time;
        UTL_FILE.PUT_LINE(output_file, v_record_str);
    END LOOP;
    CLOSE viewcur;
    utl_file.fClose(output_file);
END;
/TEST_VIEW_TIME.TXT:
02-JUL-2009 11:48:47.953000,ALL_ARGUMENTS,02-JUL-2009 11:48:47.953000
02-JUL-2009 11:48:47.953000,ALL_ALL_TABLES,02-JUL-2009 11:48:47.953000
02-JUL-2009 11:48:47.953000,ALL_ASSOCIATIONS,02-JUL-2009 11:48:47.953000
02-JUL-2009 11:48:47.953000,ALL_AUDIT_POLICIES,02-JUL-2009 11:48:47.999000
02-JUL-2009 11:48:47.999000,ALL_AUDIT_POLICY_COLUMNS,02-JUL-2009 11:48:48.093000
02-JUL-2009 11:48:48.093000,ALL_AWS,02-JUL-2009 11:48:48.187000
02-JUL-2009 11:48:48.187000,ALL_AW_PS,02-JUL-2009 11:48:48.187000
02-JUL-2009 11:48:48.187000,ALL_APPLY,02-JUL-2009 11:48:48.343000
02-JUL-2009 11:48:48.343000,ALL_APPLY_PARAMETERS,02-JUL-2009 11:48:48.421000
02-JUL-2009 11:48:48.421000,ALL_APPLY_KEY_COLUMNS,02-JUL-2009 11:48:48.437000
02-JUL-2009 11:48:48.437000,ALL_APPLY_CONFLICT_COLUMNS,02-JUL-2009 11:48:48.781000
02-JUL-2009 11:48:48.781000,ALL_APPLY_TABLE_COLUMNS,02-JUL-2009 11:48:48.828000
02-JUL-2009 11:48:48.828000,ALL_APPLY_DML_HANDLERS,02-JUL-2009 11:48:48.890000
02-JUL-2009 11:48:48.890000,ALL_APPLY_PROGRESS,02-JUL-2009 11:48:48.968000
02-JUL-2009 11:48:48.968000,ALL_APPLY_ERROR,02-JUL-2009 11:48:49.015000
02-JUL-2009 11:48:49.015000,ALL_APPLY_ENQUEUE,02-JUL-2009 11:48:49.234000
02-JUL-2009 11:48:49.234000,ALL_APPLY_EXECUTE,02-JUL-2009 11:48:49.281000
02-JUL-2009 11:48:49.281000,ALL_AW_PROP,02-JUL-2009 11:48:49.531000
02-JUL-2009 11:48:49.546000,ALL_AW_OBJ,02-JUL-2009 11:48:49.578000
02-JUL-2009 11:48:49.578000,ALL_AW_PROP_NAME,02-JUL-2009 11:48:49.609000
02-JUL-2009 11:48:49.609000,ALL_AW_AC,02-JUL-2009 11:48:49.624000
02-JUL-2009 11:48:49.624000,ALL_AW_AC_10G,02-JUL-2009 11:48:49.640000Regards,

Different execution times for back ground jobs - why?

We have few jobs scheduled and each time they run, we see a different execution times. Some times, it increases and some times it decreases steeply . What could be the reasons?
Note:
1. We have the same load of jobs on the system in all the cases.
2. We haven't changed any settings at system level.
3. Data is more or less at the same range in all the executions.
4. We mainly run these jobs
Thanks,
Kiran
Edited by: kiran dasari on Mar 29, 2010 7:12 PM

Thank you Sandra.
We have no RFC calls or other instances. Ours is a very simple system. We have two monster jobs, the first one for HR dataand second an extract program to update a Z table for BW loads.
Our basis and admin confirmed that there are no network issues
Note: We are executing these jobs over the weekend nights.
Thanks,
Kiran

Long execution times for TestStand conditional statements

I have two test stations – one here, one at the factory in China that has been operating for about a year. The test program uses TestStand 3.1 and calls primarily dll's developed using CVI. Up until a couple months ago, both test stations performed in a similar manner, then the computer at the factory died and was replaced with a new, faster computer. Now the same test sequence at the factory take three times as long to execute (30 min at the facotry, 10min here).
I have recoded the execution time at various point during the execution, and have found that the extra times seems to be occurring during the evaluation of conditional statements in TestStand (i.e. for loops, if statements, case statements). For example, one particular ‘for’ evaluation takes 30 ms on the test station here, but takes 400 ms at the test station at the factory (note: this is just the evaluation of the for condition, not the execution of the steps contained within the for loop).
The actual dll calls seem to be slightly faster with the new computer.
Also the ‘Module Times’ reported don’t seem to match the actual time for the module for the computer at the factory. For example, for the following piece of TestStand code:
Label1
Subsequence Call
Label2
I record the execution time to the report text in both Label1 and Label2. Subtracting one from the other gives me about 18 seconds. However the ‘Module Time’ recorded for ‘Subsequence Call’ is only 3.43 seconds.
Any body have any ideas why the long execution time with the new computer? I always setup the computers in exactly the same way, but maybe there is a TestStand setting somewhere that I have missed? Keep in mind, both test stations are running exactly the same revision of code.

Got some more results from the factory this morning:
1) Task Manager shows that the TestExec.exe is the only thing using CPU to any significant degree. Also CPU Usage History show that the CPU Usage never reaches 100%.
2) I sent a new test program that will log test execution time in more places. Longer execution times are seen in nearly every area of the program, but one area where this is very dramatic is the time taken to return from one particular subsequence call. In this subsequence I log the time just before the <End Group> at then end of Main. There is nothing in Cleanup. I then log the time immediately after returning from this sequence. On the test system I have here this takes approximately 160 ms. On the test system at the factory this takes approximately 14.5 seconds! The program seems to be hanging here for some reason. Every time this function is called the same thing happens and for the same amount of time (and this function is called about 40 times in the test program, so this is kill me).

Ideal execution time for any program

Similar Messages

Maybe you are looking for