Execution Time in minutes

Hi,
it´s me again with another question.
The Execution Time in the test report (xml) is always displayed in seconds. How can I change this in minutes?
Thanks a lot.
Daniel

Thats not so easy to achive, because there is no option for this in the "Configure-->Report Options..." menu.
You could change the "Add Start Time XML" Step in the "AddReportHeader" Sequence in the ...\National Instruments\TestStand 3.1\Components\NI\Models\TestSTandModels\reportgen_xml.seq Sequence-File.
Another way would be to adjust the Stylesheet (...\National Instruments\TestStand 3.1\Components\NI\Models\TestSTandModels\StyleSheets\)
For both you need knowlwedge about XML...

Similar Messages

  • Execution time in minutes and seconds

    In the UUT Report, the Execution Time displays in seconds.  How can I get that to display in minutes and seconds.

    I'm just now getting to this, and I've decided to address this in the reportgen_html.seq.  In the step labelled "Add Execution Time", the expression reads,
    Locals.Header += "<TR><TD NOWRAP='NOWRAP'><B><LI>" + ResStr("MODEL", "RPT_HEADER_EXEC_TIME") + "</B><TD><B>" + (PropertyExists("Parameters.MainSequenceResults.TS.TotalTime") ? Str(Parameters.MainSequenceResults.TS.TotalTime, Parameters.ReportOptions.NumericFormat , 1, True) + ResStr("MODEL", "RPT_HEADER_SECONDS") : ResStr("MODEL", "RPT_NOT_APPLICABLE")) + "</B>\n"
    I found the RPT_HEADER_SECONDS constant and changed it to _MINUTES and changed the string.   I divided the Parameters.MainSequenceResults.TS.TotalTime by 60, and this all seems to work.  The only thing that's not working is that I'm updating the Parameters.ReportOptions.NumericFormat, and no matter what I do it keeps showing me 13 decimal points. 
    The Parameters.ReportOptions.NumericFormat is set to  %$.13f  (but I've tried several variations). 
    I just want it to display something like   21.63 minutes.  Also, what is the $ doing in that expression

  • Execution Time 1:35 minute

    Good morning everyone,
    We have several tables in DB and we are writing a query.
    Normally, execution time is 1 msec for most but A query took time 1:35 minute.
    The query return with 6 column that five is number, one is a string(10 words).
    If you have a chance, please help us usual.
    Thanks in advance,
    S!G
    Edited by: Sea!Gull on Sep 29, 2010 8:39 AM

    Hello,
    "Basically " , you can consider the use of a "lexical reference" as "text replacement" by Reports in the SQL query
    It means that Reports will replace the string &P_XXX by its values before submitting the SQL query to the DB
    Have you tried to do this "manually" and execute the result in SQL*Plus ?
    Regards

  • How to improve the execution time of my VI?

    My vi does data processing for hundreds of files and takes more than 20 minutes to commplete. The setup is firstly i use the directory LIST function to list all the files in a dir. to a string array. Then I index this string array into a for loop, in which each file is opened one at a time inside the loop, and some other sub VIs are called to do data analysis. Is there a way to improve my execution time? Maybe loading all files into memory at once? It will be nice to be able to know which section of my vi takes the longest time too. Thanks for any help.

    Bryan,
    If "read from spreadsheet file" is the main time hog, consider dropping it! It is a high-level, very multipurpose VI and thus carries a lot of baggage around with it. (you can double-click it and look at the "guts" )
    If the files come from a just executed "list files", you can assume the files all exist and you want to read them in one single swoop. All that extra detailed error checking for valid filenames is not needed and you never e.g. want it to popup a file dialog if a file goes missing, but simply skip it silently. If open generates an error, just skip to the next in line. Case closed.
    I would do a streamlined low level "open->read->close" for each and do the "spreadsheet string to array" in your own code, optimized to the exact format of your files. For example, notice that "read from spreadheet file" converts everything to SGL, a waste of CPU if you later need to convert it to DBL for some signal processing anyway.
    Anything involving formatted text is not very efficient. Consider a direct binary file format for your data files, it will read MUCH faster and take up less disk space.
    LabVIEW Champion . Do more with less code and in less time .

  • 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

  • Java program to calculate next execution time if one cron expression is giv

    In my project requirement i wanted to have one function which will calculate next execution time using cron expression.
    Here i have one cron expression which says every 25 minutes, i want to have one function which will be passed with cron expression and time and function should return next execution time.
    I was wondering if any ready function available for the same.
    Thanks in Advance

    [Did you check here?|http://www.lmgtfy.com/?q=java+cron+expression]

  • Execution time of query on different indexes

    Hello,
    I have a query on the table, the execution time has hugh difference using different indexes on the table. The table has about 200,000 rows. Any explaination on it?
    Thanks,
    create table TB_test
    ( A1 number(9),
    A2 number(9)
    select count(*) from TB_test
    where A1=123 and A2=456;
    A. With index IDX_test on column A1:
    Create index IDX_test on TB_test(A1);
    Explain plan:
    SELECT STATEMENT
    Cost: 3,100
    SORT AGGREGATE
    Bytes: 38 Cardinality: 1
    TABLE ACCESS BY INDEX ROWID TABLE TB_test
    Cost: 3,100 Bytes: 36 Cardinality: 1
    INDEX RANGE SCAN INDEX IDX_test
    Cost: 40 Cardinality: 21,271
    Execution time is : 5 Minutes
    B. With index IDX_test on column A1 and A2:
    Create index IDX_test on TB_test(A1, A2);
    Explain plan:
    SELECT STATMENT
    Cost: 3 Bytes: 37 Cardinality: 1
    SORT AGGREGATE
    Bytes: 37 Cardinality: 1
    INDEX RANGE SCAN INDEZ IDX_test
    Cost: 3 Bytes 37 Cardinality:1
    Execution time is: 1.5 Seconds

    Additional you should check how many values you have in your table for the specific column values.
    The following select might be helful for that.
    select count(*)  "total_count"
           ,count(case when A1=123 then 1 end) "A1_count"
           ,count(case when A1=123 and A2=456 then 1 end) "A1andA2_count"
    from TB_test;Share your output of this.
    I expect the value for A1_count still to be high. But the value for A1+A2_count relatively low.
    However 5 minutes is far to long for such a small table. Even if you run it on a laptop.
    There must be a reason why it is that slow.
    First thing to consider would be to update your statistics for the table and the index.
    Second thing could be that the table is very sparsly fillled. Meaning, if you frequently delete records from this table and load new data using APPEND hint, then the table will grow, because the free space from the deletes is never reused. Any table access in the execution plan, will be slower then needed.
    A similar thing can happen, if many updates on previously empty columns are made on a table (row chaining problem).
    So if you explain a little, how this table is filled and used, we could recognize a typical pattern that leads to performance issues.
    Edited by: Sven W. on Nov 28, 2012 5:54 PM

  • Execution of Coded UI scripts with least possible test execution time in Windows7 Operating system using Visual Studio Test Agent 2010 without VS2010 installed

    Hi All,
    We are trying to execute coded UI scripts without Visual Studio installed. We are using “Visual Studio Test Agent 2010” for executing coded UI scripts without VS2010 in Windows 7, it is working fine. Also we verified executing the same script with VS2010
    Premium, it works fine as well.
    Here the challenge we are facing is with the Test execution time.
    When we run the coded UI script with IE11-Windows 7 OS-Visual Studio 2010 Premium it takes
    3min 36sec to complete the execution whereas with IE11-Windows 7 OS-Visual Studio Test Agent 2010  it takes
    6min 40sec for the same script to execute (which is almost double the time it takes while executing using VS2010).
    My question is what may be the reason for this difference? and how we can reduce the test execution time when running from Test Agent 2010?
    Kindly let us know what is the best practice to execute the coded UI scripts with least test execution time in Windows 7 Operating system using Visual Studio Test Agent 2010 without VS2010
    installed.
    Looking forward for your positive response.
    Thanks in advance..!!

    Tina-Shi, Thanks for the information.
    As you mentioned, we tried to execute the coded UI test using Mstest.exe in command on VS2010 Premium and checked on the execution
    time, there was a slight difference.
    Please find below execution time.
    Using Mstest.exe in command on VS2010 Premium/Win7 – 3.47 minutes
    Using VS2010 Premium/Win7 – 3.53 minutes
    Using Test Agent/Win7 – 7.3 minutes
    Also, I closed all the other processes in Task manager before starting up the execution.
    Still , I am facing the same Issue. Could you please suggest any other way to reduce the scripting time of coded UI script execution
    through Test agent 2010.
    Looking forward for your earliest response.

  • Execution time is too high.

    Hi,
    I got several xsql-files that uses aprox. 1 minute to execute by them selves. I want to run one xsql that includes them all, but it times out, and I get an server-error. Is there any way I can get the execution time down, or change the timeout-setting?
    I am running the xsql that comes with 8.1.7
    Terje K.

    If Oracle8i JServer is included in the Oracle 8i package, then yes. The database itself is not large (aprox. 50Mb with data), but the results of the queries can get somewhat large. Here is an example:
    1. first I made a view:
    create view view_section2_issue as SELECT SPVSPC.OPN, OPE, PCA, PCS, PCSR, OSC, PWTT, OVSM, PLWD, PCSOD, PDC, TO_CHAR(ISOD,'dd.MM.YY') AS ISOD, TO_CHAR(PCSOD,'dd.MM.YY') AS OD, PSCN, PMDP1, PMDP2, PMDP3, PMDP4, PMDP5, PMDP6, PMDP7, PMDP8, PMDP9, PMDP10, PMDP11, PMDP12,PDT1, PDT2, PDT3, PDT4, PDT5, PDT6, PDT7, PDT8, PDT9, PDT10, PDT11, PDT12, PMDC, PMCA, PMMDP, PMDT, PMLWD, PMWTT, PMSCN, PMNS, PMWTH, PMSCH, PMOD
    from SPVSISSU, SPVSISS2, SPVSPCS2, SPVSPC
    where SPVSISSU.OPN = SPVSPC.OPN
    and SPVSISSU.ISS is not null
    and SPVSISS2.OPN = SPVSISSU.OPN
    and SPVSISS2.ISSUE = SPVSISSU.ISR2
    and SPVSPCS2.OPCS = SPVSISS2.IOPCS
    and SPVSPCS2.PCSR = SPVSISS2.IPCS_REV
    then I made the query (with some cursors):
    SELECT OPE, PCA, PCS, PCSR, OSC, PWTT, OVSM, PLWD, PCSOD, PDC, OD, PSCN, PMDP1, PMDP2, PMDP3, PMDP4, PMDP5, PMDP6, PMDP7, PMDP8, PMDP9, PMDP10, PMDP11, PMDP12, PDT1, PDT2, PDT3, PDT4, PDT5, PDT6, PDT7, PDT8, PDT9, PDT10, PDT11, PDT12, PMDC, PMCA, PMMDP, PMDT, PMLWD, PMWTT, PMSCN, PMNS, PMWTH, PMSCH, PMOD,
    CURSOR( SELECT PNS, POD, PWTH, PSCH
    FROM spvspcs4
    WHERE spvspcs4.opn = view_section2_issue.opn
    and spvspcs4.pcs = view_section2_issue.pcs
    and spvspcs4.pcsr = view_section2_issue.pcsr ) as wallThickness,
    CURSOR( SELECT PELM, SST, PDSTD, PFS, PTS, PTY, PMN, MDS, ESK, PRM, PAGEBREAK, PMELL, page, start_remark(opn,pcs,pcsr,pel,pell) starten,
    end_remark(opn,pcs,pcsr,pel,pell,start_remark(opn,pcs,pcsr,pel,pell)) as slutt
    FROM spvspcs6
    WHERE spvspcs6.opn = view_section2_issue.opn
    and spvspcs6.pcs = view_section2_issue.pcs
    and spvspcs6.pcsr = view_section2_issue.pcsr ) as elements,
    CURSOR( SELECT PVELM, VDS, PVFS, PVTS, PVRM, PMVELL
    FROM spvspcs7
    WHERE spvspcs7.opn = view_section2_issue.opn
    and spvspcs7.pcs = view_section2_issue.pcs
    and spvspcs7.pcsr = view_section2_issue.pcsr ) as vType,
    CURSOR( SELECT PBLP, PAGEBREAK, LTXT
    FROM spvspcs5
    WHERE spvspcs5.opn = view_section2_issue.opn
    and spvspcs5.pcs = view_section2_issue.pcs
    and spvspcs5.pcsr = view_section2_issue.pcsr ) as kommentar,
    CURSOR( SELECT count(*) as tot
    FROM spvspcs5
    WHERE pagebreak = 'P'
    and spvspcs5.opn = view_section2_issue.opn
    and spvspcs5.pcs = view_section2_issue.pcs
    and spvspcs5.pcsr = view_section2_issue.pcsr ) as kpages,
    CURSOR( SELECT count(*) as tot
    FROM spvspcs6
    WHERE pagebreak = 'P'
    and spvspcs6.opn = view_section2_issue.opn
    and spvspcs6.pcs = view_section2_issue.pcs
    and spvspcs6.pcsr = view_section2_issue.pcsr ) as tpages
    from view_section2_issue
    where OPN = {@opn}

  • Select - execution time strange behaviour

    hi all,
    when i executed an SQL - select (with joins and so on) - I have observed the following behaviour:
    Query execution times are like: -
    for 1000 records - 4 sec
    5000 records - 10 sec
    10000 records - 7 sec
    25000 records - 16 sec
    50000 records - 33 sec
    I tested this behaviour with different sets of sqls on different sets of data. But in each of the cases, the behaviour is more or less the same.
    Can any one explain - why Oracle takes more time to result 5000 records than that it takes to 10000. (In some cases, this behaviour can be observed at ~2000 to ~5000 )
    Please note that this has not something to do with the SQLs as - i tested this with different sets of sql on different sets of data.
    Can there be any Oracle`s internal reason - which can explain this behaviour?
    regards
    at

    at,
    Things you need to check before you go further -
    1) Are you using OPTIMIZER_MODE=CHOOSE or OPTIMIZER_MODE=RULE?
    2) If you are using RULE then rewrite the queries or use some hints to help it along. If you're using a 3rd party application, then consider going to CHOOSE for the optimizer_mode.
    3) If you're using CHOOSE (Cost Based Optimizer) then:
    a) update your statistics. You can do this by creating a .cmd (or shell) file that logs into sqlplus or svrmgrl (better get use to sqlplus qs it isn't around qnymore in 9i), then call a sql file you will create(@c:\users\oracledba\analyze.sql for example). The analyze.sql file might look something like this:
    #create a file to call in just a moment
    spool c:\users\oracledba\anaylzed.sql
    select 'analyze table' ||table_name|| 'compute statistics;' from dba_tables where owner NOT IN ('SYS', 'SYSTEM', 'DBA_USER', 'EXP_USER', 'QUEST', 'any_other_user_who_is_not_a_normal_user') and type <> 'TEMPORARY';
    #execute the file you just created
    @c:\users\oracledba\anaylzed.sql
    spool off
    b) This should give you an easy to use point-and-click way to anayle your tables. You can make a similar one for indexes as well. Don't run this thing every five minutes or you'll end up with crap. If possible, run it at a busy time of day but at a time when the performance impact caused by the script (which actually isn't much but does have an effect) won't be too drastic.
    You also need to take a look at some additional OPTIMIZER_MODE accompanying parameters that will effect the time given to the CBO. Important ones are
    a)optimizer_max_permutations (set to 1000 to limit the number of plans the optimizer examines before choosing the best plan. It can be as hig as 80000 but that is too many and research indicates that setting it to 1000 to start is good because the optimizer considers the fact that it only has 1000 shots at finding the best plan and derives the most likely first)
    b)optimizer_index_caching (set to 95 which tells the optimizer that 95% of the time it will find the index in the cache and to use the index - typically this is set equal to your hit ratio)
    c)optimizer_index_cost_adj is a bit more complicated (set it to a value that will tell Oracle how much cheaper it is to access the data via index vs. accessing it through full table scan. I'd start with 5 as a value and monitor it from there).
    There are several other things you can do also - like creating bitmap indexes (assuming you've created indexes in the correct columns already).
    If you send some more details about your environment etc we can provide more info.
    Hope this helps,
    The Infamous
    Eric Cartman

  • 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

  • Execution time of sql query differing a lot between two computer

    hi
    execution time of a query in my computer and more than 30 different computer is less than one second but on one of our
    customers' computers, execution time is more than ten minute. databases and data and queries are same. i re-install sql but problem remains. my sql is ms sql 2008 r2.
    any one has idea for this problem?

    Hi mahdi,
    Obviously, we can't get enough information to help you troubleshoot this issue. So, please elaborate your issue with more detail so that the community members can help you in more effecient manner.
    In addition, here is a good article regarding checklist for analyzing Slow-Running queries. Please see:
    http://technet.microsoft.com/en-us/library/ms177500(v=sql.105).aspx
    And SQL Server Profiler and Performance Monitor are good tools to troubleshoot performance issue, please see:
    Correlating SQL Server Profiler with Performance Monitor:
    https://www.simple-talk.com/sql/database-administration/correlating-sql-server-profiler-with-performance-monitor/
    Regards,
    Elvis Long
    TechNet Community Support

  • Slow query execution time

    Hi,
    I have a query which fetches around 100 records from a table which has approximately 30 million records. Unfortunately, I have to use the same table and can't go ahead with a new table.
    The query executes within a second from RapidSQL. The problem I'm facing is it takes more than 10 minutes when I run it through the Java application. It doesn't throw any exceptions, it executes properly.
    The query:
    SELECT aaa, bbb, SUM(ccc), SUM(ddd), etc
    FROM MyTable
    WHERE SomeDate= date_entered_by_user  AND SomeString IN ("aaa","bbb")
    GROUP BY aaa,bbbI have an existing clustered index on SomeDate and SomeString fields.
    To check I replaced the where clause with
    WHERE SomeDate= date_entered_by_user  AND SomeString = "aaa"No improvements.
    What could be the problem?
    Thank you,
    Lobo

    It's hard for me to see how a stored proc will address this problem. I don't think it changes anything. Can you explain? The problem is slow query execution time. One way to speed up the execution time inside the RDBMS is to streamline the internal operations inside the interpreter.
    When the engine receives a command to execute a SQL statement, it does a few things before actually executing the statement. These things take time. First, it checks to make sure there are no syntax errors in the SQL statement. Second, it checks to make sure all of the tables, columns and relationships "are in order." Third, it formulates an execution plan. This last step takes the most time out of the three. But, they all take time. The speed of these processes may vary from product to product.
    When you create a stored procedure in a RDBMS, the processes above occur when you create the procedure. Most importantly, once an execution plan is created it is stored and reused whenever the stored procedure is ran. So, whenever an application calls the stored procedure, the execution plan has already been created. The engine does not have to anaylze the SELECT|INSERT|UPDATE|DELETE statements and create the plan (over and over again).
    The stored execution plan will enable the engine to execute the query faster.
    />

  • One space  changes query execution time significantly. Why?

    Hello,
    my application works on Oracle DB 10.2. Today it started "hanging" on one a select query, which earlier took 1-2 seconds to execute (I waited for several minutes and then stopped it). The query is executed, using the following code:
    PreparedStatement pst = conn.prepareStatement("select ... ? ... ? ... ? ");
    pst.setInt(1, ...);
    pst.setString(2, ...);
    pst.setInt(3, ...);
    ResustSet rs = pst.executeQuery();
    So, it started hanging on the executeQuery() method call.
    I started experimenting and discovered, that any minimal change to the query (for example, adding 1 adjacent space to the space that is already present) has the result, that query executes in 1-2 seconds again! But if I remove this additional unnecessary space - the query hangs again. This was reproduced with both web application and console application. Computing statistics didn't help.
    Several hours later without any interference everything became OK - execution time of that query became 1-2 seconds. But for some time the system was, in fact, unavailable. Why could it happen, how 1 space could make such a great difference and how to prevent this situation in the future?

    As others already mentioned you might have a problem where for some unknown reason the execution plan changes from fast to bad.
    A completely different idea would be to rewrite the statement, maybe it is possible to find a way where you allways get good plans.
    For example I'm not sure if the subquery is needed. If it is then better use alias names inside the subquery too.
    Suggestion
    select distinct vv.vv_id, vv.value, vv.vocabs_voc_id, vv.com, vv.status, vv.code,
                vv.main_vv_id, vt.vocabs_tree_node_id as node_id
                from vocs_values vv left join vt_vv vt
                on vv.vv_id = vt.vocs_values_vv_id
                connect by prior vv.main_vv_id = vv.vv_id
                start with (vv.vocabs_voc_id = ?
                                and upper(vv.value) like ? 
                                and vv.status = ? ); When looking in more detail I see that you alread used an alias from the outer query inside the subquery. Is this correct?
    I added some other aliases in blue for the subquery to show you the difference.
    Problem?
    select distinct vv.vv_id, vv.value, vv.vocabs_voc_id, vv.com, vv.status, vv.code,
                vv.main_vv_id, vt.vocabs_tree_node_id as node_id
                from vocs_values vv left join vt_vv vt
                on vv.vv_id = vt.vocs_values_vv_id
                connect by prior vv.main_vv_id = vv.vv_id
                start with vv.vv_id in (select {color:blue}vv2.{color}vv_id
                                   from vocs_values {color:blue}vv2{color}
                                   where {color:blue}vv2.{color}vocabs_voc_id = ?
                                   and upper({color:red}vv.{color}value) like ? 
                                   and {color:blue}vv2.{color}status = ? );Shouldn't you replace {color:red}vv.{color} with {color:blue}vv2.{color}?
    Edited by: Sven W. on Nov 5, 2008 1:21 PM
    Edited by: Sven W. on Nov 5, 2008 1:26 PM

  • How to know query execution time in sql plus

    HI
    I want to know the query execution time in sql plus along with statistics
    I say set time on ;
    set autotrace on ;
    select * from view where usr_id='abcd';
    if the result is 300 rows it scrolls till all the rows are retrieved and finally gives me execution time as 40 seconds or 1 minute.. (this is after all the records are scrolled )
    but when i execute it in toad it gives 350 milli seconds..
    i want to see the execution time in sql how to do this
    database server 11g and client is 10g
    regards
    raj

    what is the difference between .. the
    statistics gathered in sql plus something like this and the one that i get from plan_table in toad?
    how to format the execution plan I got in sqlplus in a proper understanding way?
    statistics in sqlplus
    tatistics
             0  recursive calls
             0  db block gets
           164  consistent gets
             0  physical reads
             0  redo size
         29805  bytes sent via SQL*Net to client
           838  bytes received via SQL*Net from client
            25  SQL*Net roundtrips to/from client
             1  sorts (memory)
             0  sorts (disk)
           352  rows processedexecution plan in sqlplus... how to format this
    xecution Plan
      0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=21 Card=1 Bytes=10
             03)
      1    0   HASH (UNIQUE) (Cost=21 Card=1 Bytes=1003)
      2    1     MERGE JOIN (CARTESIAN) (Cost=20 Card=1 Bytes=1003)
      3    2       NESTED LOOPS
      4    3         NESTED LOOPS (Cost=18 Card=1 Bytes=976)
      5    4           NESTED LOOPS (Cost=17 Card=1 Bytes=797)
      6    5             NESTED LOOPS (OUTER) (Cost=16 Card=1 Bytes=685)
      7    6               NESTED LOOPS (OUTER) (Cost=15 Card=1 Bytes=556
      8    7                 NESTED LOOPS (Cost=14 Card=1 Bytes=427)
      9    8                   NESTED LOOPS (Cost=5 Card=1 Bytes=284)
    10    9                     TABLE ACCESS (BY INDEX ROWID) OF 'USR_XR
             EF' (TABLE) (Cost=4 Card=1 Bytes=67)
    11   10                       INDEX (RANGE SCAN) OF 'USR_XREF_PK' (I
             NDEX (UNIQUE)) (Cost=2 Card=1)
    12    9                     TABLE ACCESS (BY INDEX ROWID) OF 'USR_DI
             M' (TABLE) (Cost=1 Card=1 Bytes=217)
    13   12                       INDEX (UNIQUE SCAN) OF 'USR_DIM_PK' (I
             NDEX (UNIQUE)) (Cost=0 Card=1)
    14    8                   TABLE ACCESS (BY INDEX ROWID) OF 'HDS_FCT'
              (TABLE) (Cost=9 Card=1 Bytes=143)
    15   14                     INDEX (RANGE SCAN) OF 'HDS_FCT_IX2' (IND
             EX) (Cost=1 Card=338)
    16    7                 TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_
             COMM' (TABLE) (Cost=1 Card=1 Bytes=129)
    17   16                   INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK'
              (INDEX (UNIQUE)) (Cost=0 Card=1)
    18    6               TABLE ACCESS (BY INDEX ROWID) OF 'USR_MEDIA_CO
             MM' (TABLE) (Cost=1 Card=1 Bytes=129)
    19   18                 INDEX (UNIQUE SCAN) OF 'USR_MEDIA_COMM_PK' (
             INDEX (UNIQUE)) (Cost=0 Card=1)
    20    5             TABLE ACCESS (BY INDEX ROWID) OF 'PROD_DIM' (TAB
             LE) (Cost=1 Card=1 Bytes=112)
    21   20               INDEX (UNIQUE SCAN) OF 'PROD_DIM_PK' (INDEX (U
             NIQUE)) (Cost=0 Card=1)
    22    4           INDEX (UNIQUE SCAN) OF 'CUST_DIM_PK' (INDEX (UNIQU
             E)) (Cost=0 Card=1)
    23    3         TABLE ACCESS (BY INDEX ROWID) OF 'CUST_DIM' (TABLE)
             (Cost=1 Card=1 Bytes=179)
    24    2       BUFFER (SORT) (Cost=19 Card=22 Bytes=594)
    25   24         INDEX (FAST FULL SCAN) OF 'PROD_DIM_AK1' (INDEX (UNI
             QUE)) (Cost=2 Card=22 Bytes=594)

Maybe you are looking for