Execution time of a SQL

Hi,
I have a sql which loads a table (84 million rows) across the network from one instance to another in another server. How do I know the elapsed time during loading? ( I know this sql takes over 2 hrs to copy the table. But at any given (the sql running) time, How do I know how long will take the sql to complete? I am using toad.
The database is 10.2.0 on RHEL 4
Thanks,

Yes, I am using insert /* + APPEND */ into mytable as (select ......from sourceTable@SourceDB) ;
I don't know why they wrote this way, the query has been like this. I am just trying to learn more about this process. Actually I have done something to improve this by not loading the whole table and by just loading the rows that I want. But that's another story.
All I wanted to know is How to get the elapsed time? I don't know why they did not use data pump. I think because This loading process comes in middle of a long process. (A whole load of sql statements and pl/sql procedures). Also the source database is still in 8i. I think the datapump is from 9i only. So that was not also an option I think. (Please correct me if I am wrong).
But I also understand that over the network the elapsed time is little difficult to calculate. O.K consider that this copy of the table is not over the network and say that we are doing a select statement on a table which will select some million rows. Is there a way that I could know the elapsed time?

Similar Messages

  • How to find out the execution time of a sql inside a function

    Hi All,
    I am writing one function. There is only one IN parameter. In that parameter, i will pass one SQL select statement. And I want the function to return the exact execution time of that SQL statement.
    CREATE OR REPLACE FUNCTION function_name (p_sql IN VARCHAR2)
    RETURN NUMBER
    IS
    exec_time NUMBER;
    BEGIN
    --Calculate the execution time for the incoming sql statement.
    RETURN exec_time;
    END function_name;
    /

    Please note that wrapping query in a "SELECT COUNT(*) FROM (<query>)" doesn't necessarily reflect the execution time of the stand-alone query because the optimizer is smart and might choose a completely different execution plan for that query.
    A simple test case shows the potential difference of work performed by the database:
    Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
    Session altered.
    SQL>
    SQL> drop table count_test purge;
    Table dropped.
    Elapsed: 00:00:00.17
    SQL>
    SQL> create table count_test as select * from all_objects;
    Table created.
    Elapsed: 00:00:02.56
    SQL>
    SQL> alter table count_test add constraint pk_count_test primary key (object_id)
    Table altered.
    Elapsed: 00:00:00.04
    SQL>
    SQL> exec dbms_stats.gather_table_stats(ownname=>null, tabname=>'COUNT_TEST')
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.29
    SQL>
    SQL> set autotrace traceonly
    SQL>
    SQL> select * from count_test;
    5326 rows selected.
    Elapsed: 00:00:00.10
    Execution Plan
    Plan hash value: 3690877688
    | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |            |  5326 |   431K|    23   (5)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| COUNT_TEST |  5326 |   431K|    23   (5)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
            419  consistent gets
              0  physical reads
              0  redo size
         242637  bytes sent via SQL*Net to client
           4285  bytes received via SQL*Net from client
            357  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
           5326  rows processed
    SQL>
    SQL> select count(*) from (select * from count_test);
    Elapsed: 00:00:00.00
    Execution Plan
    Plan hash value: 572193338
    | Id  | Operation             | Name          | Rows  | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |               |     1 |     5   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE       |               |     1 |            |          |
    |   2 |   INDEX FAST FULL SCAN| PK_COUNT_TEST |  5326 |     5   (0)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
             16  consistent gets
              0  physical reads
              0  redo size
            412  bytes sent via SQL*Net to client
            380  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL>As you can see the number of blocks processed (consistent gets) is quite different. You need to actually fetch all records, e.g. using a PL/SQL block on the server to find out how long it takes to process the query, but that's not that easy if you want to have an arbitrary query string as input.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle:
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Can the format of a SQL Statement modify the execution time of an SQL ....

    Can the format of a SQL Statement modify the execution time of an SQL statement?
    Thanks in advance

    It depends on:
    1) What oracle version are you using
    2) What do you mean for "format"
    For example: if you're on Oracle9i and changing format means changing the order of the tables in the FROM clause and you're using Rule Based Optimizer then the execution plan and the execution time can be very different...
    Max
    [My Italian Oracle blog|http://oracleitalia.wordpress.com/2009/12/29/estrarre-i-dati-in-formato-xml-da-sql/]

  • Find start and end execution time of a sql statement?

    I am have databases with 10.2.0.3 and 9.2.0.8 on HP UNIX 11i and Windows 200x.
    I am not in a position to turn on sql tracing in production environment. Yet, I want to find when a sql statement started executing and when it ended. When I look at v$sql, it has information such FIRST_LOAD_TIME, LAST_LOAD_TIME etc. No where it has information last time statement began execution and when it ended execution.. It shows no of executions, elapsed time etc, but they are cumulative. Is there a way to find individual times (time information each time a sql statement was executed. – its start time, its end time ….)? If I were to write my own program how will I do it?
    Along the same line, when an AWR snapshot is shown, does it only include statements executed during that snapshot or it can have statements from the past if they have not been flushed from shared memory. If it only has statements executed in the snapshot period, how does it know when statement began execution?

    Hi,
    For oracle 10g you can use below query to find start and end time, you can see data for last seven days.
    select min(to_char(a.sample_time,'DD-MON-YY HH24:MI:SS')) "Start time", max(to_char(a.sample_time,'DD-MON-YY HH24:MI:SS')) "End Time", b.sql_text
    from dba_HIST_ACTIVE_SESS_HISTORY a,DBA_HIST_SQLTEXT b where
    a.sql_id=b.sql_id
    order by 1;
    Regards
    Jafar

  • Reduce the execution time of catproc.sql

    how can i reduce the time of execution of catproc.sql, I have increased the size of redo log files from 5m to 40m, but still performance hasn't improved much,
    any suggestion
    regards
    asif

    Is it still running? Almost half an hour now.
    By the time we find a solution maybe it's already done :)
    I don't think you could do much after it's already started. As long as it's not hung, it will finish sooner or later. Make sure there are no other applications runing on the server to compete CPU and diskio with oracle.

  • How to reduce execution time of this SQL?

    This SQL will output only 2 rows. I tried using hints (an index) but to no avail.
    http://www.freeimagehosting.net/uploads/cf214afcf1.jpg
    Or, is it NOT possible, limit of query optimization has reached?

    Rakesh jayappa wrote:
    Hi,
    Run the sql tuning advisory.
    Let me know recommendation.
    Kind Regards,
    Rakesh************************** Here is my tuning request **************************
    1.) The following SQL statement has been identified to perform poorly. It currently takes up to 12 seconds to execute, but it's supposed to take a second at most.
    This is the statement:
    select DISTINCT trunc(c.sst_post_date) as post_date
    from ac_t_sessn b , ac_t_ssntr c
    where
           b.ses_status = 0
              and b.ses_profit_center = c.sst_profit_center
              and b.ses_acct_year = c.sst_acct_year
              and b.ses_acct_period = c.sst_acct_period
              and b.ses_sessn_no = c.sst_sessn_no
       AND
             C.sst_post_mtd||C.sst_post_TYPE IN
           (SELECT Y.pst_post_mtd||Y.pst_post_type
            FROM ac_r_post_functions Y
           WHERE Y.pst_post_status IN (0,'2'))
    order by trunc(c.sst_post_date);It should return data from a table in a specific order.
    2.) The version of the database is Oracle9i Enterprise Edition Release *9.2.0.6.0*
    3.) These are the parameters relevant to the optimizer:
    UAT_UML@umltest>show parameter optimizer
    NAME                                 TYPE        VALUE
    optimizer_dynamic_sampling           integer     1
    optimizer_features_enable            string      9.2.0
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_max_permutations           integer     2000
    optimizer_mode                       string      CHOOSE
    UAT_UML@umltest>show parameter db_file_multi
    NAME                                 TYPE        VALUE
    db_file_multiblock_read_count        integer     16
    UAT_UML@umltest>show parameter db_block_size
    NAME                                 TYPE        VALUE
    db_block_size                        integer     8192
    UAT_UML@umltest>show parameter cursor_sharing
    NAME                                 TYPE        VALUE
    cursor_sharing                       string      EXACT
    UAT_UML@umltest>column sname format a20
    UAT_UML@umltest>column pname format a20
    UAT_UML@umltest>column pval2 format a20
    UAT_UML@umltest>select
      2             sname
      3           , pname
      4           , pval1
      5           , pval2
      6      from
      7           sys.aux_stats$;
    no rows selected4.) Here is the output of EXPLAIN PLAN:
    UAT_UML@umltest>select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id  | Operation              |  Name                | Rows  | Bytes |TempSpc| Cost  |
    |   0 | SELECT STATEMENT       |                      |   454 | 22700 |       |  5391 |
    |   1 |  SORT UNIQUE           |                      |   454 | 22700 |       |  5072 |
    |   2 |   HASH JOIN            |                      | 69384 |  3387K|  2592K|  4478 |
    |   3 |    INDEX FAST FULL SCAN| INDX_AC_T_SESSN      |   110K|  1294K|       |   244 |
    |   4 |    HASH JOIN           |                      |   416K|    15M|       |  3877 |
    |   5 |     TABLE ACCESS FULL  | AC_R_POST_FUNCTIONS  |    23 |   253 |       |     2 |
    |   6 |     TABLE ACCESS FULL  | AC_T_SSNTR           |  1790K|    46M|       |  3866 |
    Note: cpu costing is off, PLAN_TABLE' is old version5.) Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
    UAT_UML@umltest>set autotrace traceonly arraysize 100
    UAT_UML@umltest>
    UAT_UML@umltest>select DISTINCT trunc(c.sst_post_date) as post_date
      2  from ac_t_sessn b , ac_t_ssntr c
      3  where
      4  b.ses_status = 0
      5  and b.ses_profit_center = c.sst_profit_center
      6  and b.ses_acct_year = c.sst_acct_year
      7  and b.ses_acct_period = c.sst_acct_period
      8  and b.ses_sessn_no = c.sst_sessn_no
      9  AND
    10  C.sst_post_mtd||C.sst_post_TYPE IN (SELECT         Y.pst_post_mtd||Y.pst_post_type FROM ac_r_po
    st_functions Y
    11  WHERE Y.pst_post_status IN (0,'2'))
    12  order by trunc(c.sst_post_date);
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=5391 Card=454 Bytes=
              22700)
       1    0   SORT (UNIQUE) (Cost=5072 Card=454 Bytes=22700)
       2    1     HASH JOIN (Cost=4478 Card=69384 Bytes=3469200)
       3    2       INDEX (FAST FULL SCAN) OF 'INDX_AC_T_SESSN' (NON-UNIQU
              E) (Cost=244 Card=110433 Bytes=1325196)
       4    2       HASH JOIN (Cost=3877 Card=416304 Bytes=15819552)
       5    4         TABLE ACCESS (FULL) OF 'AC_R_POST_FUNCTIONS' (Cost=2
               Card=23 Bytes=253)
       6    4         TABLE ACCESS (FULL) OF 'AC_T_SSNTR' (Cost=3866 Card=
              1790555 Bytes=48344985)
    Statistics
              0  recursive calls
              0  db block gets
          42741  consistent gets
            171  physical reads
              0  redo size
            425  bytes sent via SQL*Net to client
            507  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
              2  rows processed
    UAT_UML@umltest>DISCONNECT
    Disconnected from Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.6.0 - Production6.) The TKPROF output snippet
    TKPROF: Release 11.2.0.1.0 - Development on Wed Oct 27 12:47:35 2010
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Trace file: umltest_ora_1604.trc
    Sort options: prsela  exeela  fchela 
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    select DISTINCT trunc(c.sst_post_date) as post_date
    from ac_t_sessn b , ac_t_ssntr c
    where
    b.ses_status = 0
    and b.ses_profit_center = c.sst_profit_center
    and b.ses_acct_year = c.sst_acct_year
    and b.ses_acct_period = c.sst_acct_period
    and b.ses_sessn_no = c.sst_sessn_no
    AND
    C.sst_post_mtd||C.sst_post_TYPE IN (SELECT         Y.pst_post_mtd||Y.pst_post_type FROM ac_r_post_functions Y
    WHERE Y.pst_post_status IN (0,'2'))
    order by trunc(c.sst_post_date)
    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        2      3.20       4.38        171      42741          0           2
    total        4      3.21       4.39        171      42741          0           2
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 445 
    Rows     Row Source Operation
          2  SORT UNIQUE
         24   HASH JOIN 
         11    INDEX FAST FULL SCAN OBJ#(62817) (object id 62817)
    2293715    HASH JOIN 
         31     TABLE ACCESS FULL OBJ#(67305)
    1790555     TABLE ACCESS FULL OBJ#(62828)
    alter session set sql_trace true
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        1      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
    Misses in library cache during execute: 1
    Optimizer mode: CHOOSE
    Parsing user id: 445 
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.00          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch        2      3.20       4.38        171      42741          0           2
    total        5      3.21       4.39        171      42741          0           2
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        2  user  SQL statements in session.
        0  internal SQL statements in session.
        2  SQL statements in session.
    Trace file: umltest_ora_1604.trc
    Trace file compatibility: 9.02.00
    Sort options: prsela  exeela  fchela 
           1  session in tracefile.
           2  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           2  SQL statements in trace file.
           2  unique SQL statements in trace file.
          51  lines in trace file.
          10  elapsed seconds in trace file. Any help would be greatly appreciated?

  • Where can i get the sql execution time ?

    Hi ,
    I want to check for a particular execution time of an sql statement
    from v$sqlarea shld i get both the cpu_time & elapsed_time ?
    the no seems very huge i.e --> 12592966663 and they are in nanosecons , milliseconds or secs ??
    is this the total time since it was in the library cache or the last time it ran it took 12592966663 ??
    kindly advise

    Hi ,
    But can i also check is this the cpu_time & elapsed_time for the most current execution or this is the total since it was last executed
    as the nos --> 13,518,633,330 when even divided by 1000,000(micro seconds) seems abit long as well
    tks & rdgs

  • Execution time of a query

    Hi,
    I am trying to find the execution time of a SQL query.
    How to do it?
    Regards.
    Ashish

    >I am trying to find the execution time of a SQL query.
    How to do it?
    Psuedo code:
    time = SystemTime() -- get the current system time
    RunSQL() -- run the SQL statement
    print( SystemTime()-time ) -- displays the difference in time
    Needless to say that this is utterly useless most of the time. The first time a query is run it may be subjected to a hard parse. The second time not. So the exact same SQL will show different execution times. This execution time measurement is useless as it does not tell you anything - except that there was a difference in time.
    The first time a query runs it make do a lot of physical I/O to read the data from disk. The second time around, with the data in the db buffer cache, it makes use of logical I/O. There is a significant difference in the execution of the exact same SQL. Again, the measurement of execution is meaningless. It does not tell you anything. One number versus another number. Nothing meaningful to compare.
    Fact. The very same SQL will have different execution times.
    So what do you hope to gain from measuring it?

  • How to get the execution time of a query

    Hi,
    Environment: 10.2.0.4.0
    Just wondering how I can get the query execution time? I am not interested in the query output nor do I want the statistics, just the execution time?
    Any suggestions will be appreciated
    Thanks in advance
    rogers42

    If you're using SQL*Plus
    SQL> set autotrace traceonly
    SQL> set timing on
    SQL> <<your query here>>SQL*Plus will fetch all the data and then report the query plan, execution statistics, and elapsed time. It will not display the actual data.
    SET TIMING ON alone tells SQL*Plus to display the execution time of each SQL statement-- the problem is that it also displays all the data which can skew the results because you're including the time required by SQL*Plus to pipe a bunch of data to the screen.
    Justin

  • SQL Tuning and OPTIMIZER - Execution Time with  " AND col .."

    Hi all,
    I get a question about SQL Tuning and OPTIMIZER.
    There are three samples with EXPLAIN PLAN and execution time.
    This "tw_pkg.getMaxAktion" is a PLSQL Package.
    1.) Execution Time : 0.25 Second
    2.) Execution Time : 0.59 Second
    3.) Execution Time : 1.11 Second
    The only difference is some additional "AND col <> .."
    Why is this execution time growing so strong?
    Many Thanks,
    Thomas
    ----[First example]---
    Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
    Connected as dbadmin2
    SQL>
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900 ;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |   220 |   880 |     5  (40)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |   220 |   880 |     5  (40)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
    13 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 0.25 seconds
    ----[/First]---
    ----[Second example]---
    Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
    Connected as dbadmin2
    SQL>
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900
      6    AND max_aktion.max_aktion_id <> 692;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |    11 |    44 |     6  (50)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |    11 |    44 |     6  (50)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
    14 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 0.59 seconds
    ----[/Second]---
    ----[Third example]---
    SQL> EXPLAIN PLAN FOR
      2  SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
      3                    FROM studie
      4                 ) max_aktion
      5  WHERE max_aktion.max_aktion_id < 900
      6    AND max_aktion.max_aktion_id <> 692
      7    AND max_aktion.max_aktion_id <> 392;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3201460684
    | Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time
    |   0 | SELECT STATEMENT     |             |     1 |     4 |     6  (50)| 00:00:
    |*  1 |  INDEX FAST FULL SCAN| SYS_C005393 |     1 |     4 |     6  (50)| 00:00:
    Predicate Information (identified by operation id):
       1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
                  "TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
    15 rows selected
    SQL>
    Execution time (PL/SQL Developer says): 1.11 seconds
    ----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
    Edited by: thomas_w on Jul 12, 2010 8:29 AM

    Hi,
    this is likely because SQL Developer fetches and displays only limited number of rows from query results.
    This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
    Query scans a table from the beginning and continue scanning until first 50 rows are selected.
    If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
    This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
    Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
    Look at this simple test to figure out how it works:
    CREATE TABLE studie AS
    SELECT row_number() OVER (ORDER BY object_id) studie_id,  o.*
    FROM (
      SELECT * FROM all_objects
      CROSS JOIN
      (SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
    ) o;
    CREATE INDEX studie_ix ON studie(object_name, studie_id);
    ANALYZE TABLE studie COMPUTE STATISTICS;
    CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
    RETURN NUMBER
    IS
    BEGIN
      RETURN action;
    END;
    /'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
    Query 1:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      1.22       1.29          0       1310          0          50
    total        3      1.22       1.29          0       1310          0          50
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         50  INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
          AND max_aktion.max_aktion_id > 800
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.01          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      8.40       8.62          0       9351          0          50
    total        3      8.40       8.64          0       9351          0          50
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         50  INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         50   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id = 600
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.72      19.16          0      19315          0           1
    total        3     18.73      19.16          0      19315          0           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
          1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
    Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
    Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
    Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
    Query 1:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.35      18.46          0      19315          0         899
    total        3     18.35      18.46          0      19315          0         899
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
        899  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
        899   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id < 900
          AND max_aktion.max_aktion_id > 800
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.79      18.86          0      19315          0          99
    total        3     18.79      18.86          0      19315          0          99
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
         99  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
         99   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
    SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
                         FROM studie
                  ) max_aktion
    WHERE max_aktion.max_aktion_id = 600
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1     18.69      18.84          0      19315          0           1
    total        3     18.69      18.84          0      19315          0           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93  (TEST)
    Rows     Row Source Operation
          1  INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: ALL_ROWS
          1   INDEX   MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
    Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
    Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
    Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned.

  • Execution time, elapsed time  of an sql query

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

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

  • 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

  • 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)

  • To Determine the Execution Time of a PL/SQL Block

    Hi
    I need to determine the total execution time taken by a PL/SQL code (Anonymous Block , Functions etc).
    Can anyone please let me know how can I determine the same?
    Regards
    Kapil.
    Edited by: KapilK on Mar 2, 2009 11:00 AM

    Kapil,
    When you launching your block using sql script or just typing the entire thing
    SQL> set timi on;
    SQL> BEGIN
      2    MYPROC;
      3    COMMIT;
      4  END;
      5  /
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:00.64Regards

  • Feature request - execution time in SQL Developer

    I am looking for some feature to detail the execution time of packages/stored procedures/functions. When a package completes execution, lets say, it took longer time than usual ; I would like to know which stored procedures or SQLs within took the longest time. I could trace the session. It will be very helpful if there is a feature on the tool.
    Thanks

    Look into PL/SQL Profiling. If you are on RDBMS version 11, then profiling command appears in context menu and toolbar.

Maybe you are looking for

  • EP 7.3 Browser compatability issue

    Hi All, We have implemented EP 7.3 SP 04. We could not access the portal in chrome or IE 11. It is giving an error that "Could not open iView. The iView is not compatible with your browser, operating system, or device. Contact your system administrat

  • ESS Business Packages Migration from Ehp3 to Ehp4 with Custom Changes

    Hello All, We are using ECC 6.0 With Ehp3 and We have the following versions of ESS and MSS Business Packages Installed. SAP_ESS 603 SP4 SAP_MSS 600 SP15 We have NWDI server also installed in this and made some Customizations in ESS Webdynpro Java ba

  • Blackberry white screen of death solution

    Hi all I have a problem with the screen of death, all I had to do is to change a battery and now my phone its working fine. Solution for problem is to get another battery. Let me know if it worked for you!!!! Regards Norman Magota

  • CS6 PDF Help file?

    I've looked for an Audition CS6 PDF help file and could not find one anywhere. Does anyone know if one is available? Thank you. Ted

  • Switching Between Flash and Other Applications

    Recently when I've been using Flash, if I switch to another application, then come back into flash, it hangs for about 5-10 seconds (beach ball spinning). If you're a flash developer you know how often you go back and forth from other applications an