Query takes time to execute

I am creating a jsp application . . . .I am retreiving some values from my database oracle 10g..my query taking time to execute even in isql plus..am uisng tomcat5 and oracle 10gR2..can anyone pls tell me why it happens...my query fetches data from four tables...i dont know exactly why its taking so muc time say 50seconds...when i run the application in my local host it retrievs fast when i do that in server it creates a problem..
Actually it works fine when i deployed in my client server it takes time sometimes it takes atmost one minute
1.pls tell me how can i test my query about the performance
2.is der any command in oracle to test
3.how much bytes it takes

Look at this thread...
When your query takes too long ...

Similar Messages

  • Query takes time to execute. Review this query and give me a possible quere

    SELECT DISTINCT A.REFERENCE_NUMBER
    FROM A,B,C
    WHERE DF_N_GET_CONTRACT_STATUS (A.REFERENCE_NUMBER, TRUNC (SYSDATE)) = 1
    AND ( B.CHQ_RTN_INDICATOR IS NULL AND B.CHALLAN_NUMBER IS NULL
    AND C.INSTRUMENT_TYPE IN (1, 2) AND C.MODULE_CODE = 5 )
    AND ( A.HEADER_KEY = B.HEADER_KEY AND C.HEADER_KEY = B.HEADER_KEY);
    This query takes 3 minutes to execute. I want to improve the performance so that it can execute with in seconds.
    Table A has 10 lakhs record.
    Table B has 3.7 lakhs record.
    Table C has 5.3 lakhs record. Consider DF_N_GET_CONTRACT_STATUS as function. REFERENCE_NUMBER is the type of Varchar2(20).
    Plz give me a correct logical and fastest execution query for the same.
    Thanks in advance.

    I would agree with the post from Santosh above that you should review the guidelines for posting a tuning request. This is VERY important. It is impossile to come up with any useful suggestions without the proper information.
    In the case of your query, I would probably focus my attention on the function that you have defined. What happens if the condition using the DF_N_GET_CONTRACT_STATUS function is removed? Does it still take 3 minutes?
    SELECT reference_number
    from (
      SELECT DISTINCT A.REFERENCE_NUMBER
      FROM A,B,C
      WHERE ( B.CHQ_RTN_INDICATOR IS NULL AND B.CHALLAN_NUMBER IS NULL
      AND C.INSTRUMENT_TYPE IN (1, 2) AND C.MODULE_CODE = 5 )
      AND ( A.HEADER_KEY = B.HEADER_KEY AND C.HEADER_KEY = B.HEADER_KEY)
    where DF_N_GET_CONTRACT_STATUS(reference_number, trunc(sysdate)) = 1;Of course, the query above really depends on the cardinality of the returned data..... which is impossible to know without following the posting guidelines. This query could return anywhere between 0 rows and 2x10^17 rows. And in the latter case evaluating the function at the end wouldn't make any difference.
    Also, do you really need the distinct? Does it make any difference? Most of the time that I see distinct, to me it either means the query is wrong or the data model is wrong.

  • Query taking time to execute

    Hello,
    i have created one query based on inventory cube 0IC_C03. when i am executing the infocube based on a particular date i am able to see the output but when i am executing the query on the basis of that particular date given while executing the cube the query is taking long time to execute and throwing a message of time limit exceed.
    could anyone suggest me why the query is showing such nessage along with resolution.
    Thanks,
    Kumkum
    Edited by: kumkum basu on Nov 29, 2010 2:33 PM

    Hi,
    There can be number of reason.
    What you can do is:-
    put the unwanted characteristics in Free Characteristics
    Remove unwanted cell reference
    Try using partitions in cubes
    Use aggregates for summarised data.
    f the above options doesnt work, then try pre-caching.This will definitely help!
    Use proper selections to get small subset of data.
    Goto RSRT>> type your query name>> Query properties>> select cache mode=4
    In addition to RSRT, ST05 (sql trace), SE30 (runtime analysis) and system statistics (ST03) may help you in identifying performance issues with a report.
    Thanks,.
    Saveen Kumar

  • Simple query takes time to run

    Hi,
    I have a simple query whcih takes about 20 mins to run.. here is the TKPROF forit:
      SELECT
        SY2.QBAC0,
        sum(decode(SALES_ORDER.SDCRCD,'USD', SALES_ORDER.SDAEXP,'CAD', SALES_ORDER.SDAEXP /1.0452))
      FROM
        JDE.F5542SY2  SY2,
        JDE.F42119  SALES_ORDER,
        JDE.F0116  SHIP_TO,
        JDE.F5542SY1  SY1,
       JDE.F4101  PRODUCT_INFO
    WHERE
        ( SHIP_TO.ALAN8=SALES_ORDER.SDSHAN  )
        AND  ( SY1.QANRAC=SY2.QBNRAC and SY1.QAOTCD=SY2.QBOTCD  )
        AND  ( PRODUCT_INFO.IMITM=SALES_ORDER.SDITM  )
        AND  ( SY2.QBSHAN=SALES_ORDER.SDSHAN  )
        AND  ( SALES_ORDER.SDLNTY NOT IN ('H ','HC','I ')  )
        AND  ( PRODUCT_INFO.IMSRP1 Not In ('   ','000','689')  )
        AND  ( SALES_ORDER.SDDCTO IN  ('CO','CR','SA','SF','SG','SP','SM','SO','SL','SR')  )
        AND  (
        ( SY1.QACTR=SHIP_TO.ALCTR  )
        AND  ( PRODUCT_INFO.IMSRP1=SY1.QASRP1  )
      GROUP BY
      SY2.QBAC0
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.07       0.07          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch       10     92.40     929.16     798689     838484          0         131
    total       12     92.48     929.24     798689     838484          0         131
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 62 
    Rows     Row Source Operation
        131  SORT GROUP BY
    3535506   HASH JOIN 
    4026100    HASH JOIN 
        922     TABLE ACCESS FULL OBJ#(187309)
    3454198     HASH JOIN 
      80065      INDEX FAST FULL SCAN OBJ#(30492) (object id 30492)
    3489670      HASH JOIN 
      65192       INDEX FAST FULL SCAN OBJ#(30457) (object id 30457)
    3489936       PARTITION RANGE ALL PARTITION: 1 9
    3489936        TABLE ACCESS FULL OBJ#(30530) PARTITION: 1 9
      97152    TABLE ACCESS FULL OBJ#(187308)
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.07       0.07          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch       10     92.40     929.16     798689     838484          0         131
    total       13     92.48     929.24     798689     838484          0         131
    Misses in library cache during parse: 1kindly suggest how to resolve this...
    OS is windows and its 9i DB...
    Thanks

    > ... you want to get rid of the IN statements.
    They prevent Oracle from usering the index.
    SQL> create table mytable (id,num,description)
      2  as
      3   select level
      4        , case level
      5          when 0 then 0
      6          when 1 then 1
      7          else 2
      8          end
      9        , 'description ' || to_char(level)
    10     from dual
    11  connect by level <= 10000
    12  /
    Table created.
    SQL> create index i1 on mytable(num)
      2  /
    Index created.
    SQL> exec dbms_stats.gather_table_stats(user,'mytable')
    PL/SQL procedure successfully completed.
    SQL> set autotrace on explain
    SQL> select id
      2       , num
      3       , description
      4    from mytable
      5   where num in (0,1)
      6  /
                                        ID                                    NUM DESCRIPTION
                                         1                                      1 description 1
    1 row selected.
    Execution Plan
    Plan hash value: 2172953059
    | Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |         |  5001 |   112K|     2   (0)| 00:00:01 |
    |   1 |  INLIST ITERATOR             |         |       |       |            |          |
    |   2 |   TABLE ACCESS BY INDEX ROWID| MYTABLE |  5001 |   112K|     2   (0)| 00:00:01 |
    |*  3 |    INDEX RANGE SCAN | I1      |  5001 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("NUM"=0 OR "NUM"=1)Regards,
    Rob.

  • Query takes forever to execute

    This query executes forever:
    select count(*)
    from VIEW_DOCUMENT
    where exists
    select VIEW_DOCUMENT_ITEM.documentID
    from VIEW_DOCUMENT_ITEM
    where VIEW_DOCUMENT_ITEM.documentID=VIEW_DOCUMENT.documentID
    Here's what's inside VIEW_DOCUMENT_ITEM:
    select *
    from DOCUMENT_ITEM
    join VIEW_USER
    If I replace "join VIEW_USER" with "join USER" the query executes normally in few seconds!
    This makes no sense because here's what's in VIEW_USER:
    select * from USER
    Does anybody know what are possible causes for this strange behaviour?

    Actually my query is much more complex, this is simplified version.
    In original query it's 100% not cartesian join.
    Result of my query is 2710 and result of Sven's query is 2711.
    My question is only why does joining a table work normally and why does joining a view "select * from table" take forever.
    I can't see execution plan because my query never ends. I have to kill the Linux process.
    Here is TKPROF output, I don't know what this stuff means:
    TKPROF: Release 10.2.0.1.0 - Production on Tue Mar 4 14:21:57 2008
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Trace file: orcl_ora_29715.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
    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: ALL_ROWS
    Parsing user id: 64 
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    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
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse       58      0.00       0.01          0          0          0           0
    Execute    308      0.05       0.06          0          0          0           0
    Fetch      758      0.03       0.16         38       1188          0        2086
    total     1124      0.10       0.24         38       1188          0        2086
    Misses in library cache during parse: 13
    Misses in library cache during execute: 13
        1  user  SQL statements in session.
      308  internal SQL statements in session.
      309  SQL statements in session.
    Trace file: orcl_ora_29715.trc
    Trace file compatibility: 10.01.00
    Sort options: prsela  exeela  fchela 
           1  session in tracefile.
           1  user  SQL statements in trace file.
         308  internal SQL statements in trace file.
         309  SQL statements in trace file.
          14  unique SQL statements in trace file.
        3007  lines in trace file.
           0  elapsed seconds in trace file.

  • Query takes time

    Hi All
    one of my query is taking too much time and really appreciate that if you people guide me how to get it fast. I'm using Oracle 11g Enterprise Release 11.2.0.2.0 64 bit version. My query is below and this query extract around 1 million records.
    Query
    Select distinct group_number grp_nbr, ltrim(group_number,'0') trimed_grp_nbr,section_code sct, enrolment_groups.group_id,
    enrolment_groups.segment_code,market_sgmt_attr_ascns.role_type_code,market_sgmt_attr_ascns.part_attr_type_code,
    nvl((select 'Y' from info where ltrim(info.grp_nbr,'0')=group_number
    and ltrim(rtrim(info.sct))=section_code
    and subscriber_id_type='S'),'N') Mandatory_flag,
    min(to_date(coverage_period.enr.group_eff_date)) over (partition by enrolment_groups.group_id) Min_Effective_date,
    nvl((select 'Y' from info where ltrim(info.grp_nbr,'0')=group_number
    and ltrim(rtrim(info.sct))=section_code
    and subscriber_id_type='S' and id_code='1'),'N') identification_flag
    from coverage_period,
    enrolment_groups,
    market_sgmt_attr_ascns
    Where ltrim(coverage_period.grp_nbr,'0')=enrolment_groups.group_number
    and ltrim(rtrim(coverage_period.sct))=enrolment_groups.section_code
    and enrolment_groups.segment_code=market_sgmt_attr_ascns.segment_code
    and market_sgmt_attr_ascns='GRP'
    and market_sgmt_attr_ascns.part_attr_type_code='ABR-PART'
    and group_number||'/'section_code in
    Select ltrim(info.grp_nbr,'0')||'/'||ltrim(rtrim(info.sct)) g_s
    from info
    where 1=1
    and info.subscriber_id_type='S')
    I have to get million of records and this query will take too much time. I really appreciate if you could help me out. Thanks
    Regards
    Shumail

    I'm working as an ETL Developer and I created a package in SQL Developer and my select query returned around 1 million rows and then these rows inserted into one of my table by using insert into table statement.
    I don't understand what do you mean by this statement
    it must do a SORT to get the distinct rows.
    I did one mistake, my whole package insert around 1 million records and if I'm talking about this specific query then it return only 88 rows and it will take like 5 minutes and I use the same select logic means IN clause and other clauses through out my my package by using Union but my package will take too much time. My concern is that is there any way to change this query logic to get result faster.
    For example
    I use in clause to compare group_number and section_code as well as some other stuff like I use 'Select 'Y' .........' in some places. Please help me out that is there any other way to query these statement to get result faster. Thanks
    Edited by: 976593 on Apr 10, 2013 7:17 PM
    Edited by: 976593 on Apr 10, 2013 7:22 PM

  • FM SWW_WI_ADMIN_CANCEL takes time to execute

    Hi All,
    I have used FM SWW_WI_ADMIN_CANCEL in a report to logically delete workitems. When i execute the FM through SE37 it completes execution within seconds. However when i execute the report , time taken for execution of the FM is very high ( almost 3-4 minutes for a single workitem).
    Please advise how this issue can be fixed.
    Thanking you in anticipation,
    Chinmay

    You should post this in the workflow forum and not in this one. This one is for SRM related issues. You can find the workflow forum [here.|SAP Business Workflow;
    Regarding your problem, I don't think it is a problem with the Fm but with the workflow. Search here on SDN for a document on upgrading from 4.6C to ECC for workflow. There are some actions which should be performed I think.
    Regards,
    Martin

  • Auto scaling takes time to execute the rules

    Hi,
    I am using the windows azure application. In that I am using the scaling feature provided into the azure portal. Here, I have configured the rule to scale up my web role instance by 1 if CPU load increases up to certain limit. and the reverse rule that for
    decrementing the role instance.
    However, I tried to increase my system load. and checked the scaling feature. So, here I observed that the rules gets satisfied to auto scale the role instance by 1 but it took around 12-15 min to execute it.
    NOTE: I have set the rule checking time duration to 5 min.
    Please help me.

    Thank you for your response.
    But I guess this will not solve my problem. Let me elaborate my problem in detail.
    I have a site hosted on azure environment. To make the site performance better we are doing some research out of that one attempt we did is the performance test. So in that we are increasing the load on our site to check how it works with heavy user load.
    And we observed that when web roles CPU usage goes beyond 50% then we gets lower response from our site. So get the better performance we have used the scaling feature from azure portal. and configured the rule that if CPU usage goes beyond 50% then scale
    up the web role instance. Here, we observed that when CPU usage goes beyond 50% at the same time scaling doesn't triggered and we got lower response from our site and then after 12-15 min scaling rules got executed and at that time CPU usage was around 70%
    but the triggered in auto scaling was for the 50% condition. In short we are experiencing delay in executing rule. Please help.

  • Query taking time when MVIEW is used!!!

    Dear All,
    Whenever i try and execute a query involving Materialized View(MVIEW), more often i have seen that if the query takes *5hrs* to execute and MVIEW refresh is every *2hrs*, it'll throw error as "error -- precedeing line from ...".
    I just wanted to confirm if there will be a problem in conditions where query execution is overlapping the then next MVIEW refresh???
    ** Sorry could not provide the exact error

    So what do you think what ORACLE is doing? Giving you the "latest" update? Of course not, you have read consistency,so as soon as the data changed, your query reads from UNDO. Is the MV a "fast" or "complete" refresh? If its "fast" if should not matter too much, depending on the amount of updates. But I bet it's "complete".
    How long does the refresh go? That should be < 2h right? So your query will not get substantial slower when using the source of the MV directly.
    5h is massive. I bet that can be done better. If not (wanna bet ? ;-) ) how long does the query take without MV refresh (for a test)? Then you can put the MV data in a temp table and use that for a start.
    And get your error handler right.
    -- andy

  • Query with different parameter take different time to execute.

    Hi,
    I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
    I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.
    on below query
    WHERE substr(GENRE_ID,0,2) = 10 and GENRE_ID != 10) take 54 seconds
    WHERE substr(GENRE_ID,0,2) = 20 and GENRE_ID != 20) take 5 seconds
    The explain plan give exact same result for both queries.
    I have follow Re: 3. How to  improve the performance of my query? / My query is running slow. for optimizer but the problem still there.
    And we have rebuilt all indexes.
    Anyone can help me? I need any advises for this problem.
    Note:
    Song table only have 570K records and Song_vod table 1100 records.
    Query:
    select *
    from(
    select rownum rowno, a.*
    from(
    select a.SONG_VOD_ID, a.SONG_ID, a.VOD_TITLE, a.ALBUM_ID, a.ARTIST_ID, a.VOD_ISSUE_DATE, a.VOD_ORDER_ISSUE_DATE, a.VOD_ADULT_YN, a.VOD_L_IMG_PATH, a.VOD_M_IMG_PATH, a.VOD_S_IMG_PATH, a.RECOMMEND_CNT, a.OPPOSE_CNT, get_song_name(a.SONG_ID) SONG_NAME, get_album_name(a.ALBUM_ID) ALBUM_NAME, get_artist_name(a.ARTIST_ID) ARTIST_NAME, VOD_ISSUE_DATE vodIssueDate
    from SONG_VOD a inner join SONG b on a.SONG_ID = b.SONG_ID
    where a.LC_STATUS_CD = 'CS0006'
    AND (b.GENRE_ID
    in (
    select GENRE_ID
    from MD_GENRE
    WHERE substr(GENRE_ID,0,2) = 10
    and GENRE_ID != 10)
    OR b.GENRE_ID
    in (
    select GENRE_ID
    from MD_GENRE
    WHERE substr(GENRE_ID,0,2) = '40'
    and GENRE_ID != '40'
    ) order by a.REG_DATE desc, a.SONG_VOD_ID desc
    ) a WHERE rownum <= 0 + 30
    Thank you,
    Regards
    -=Rika Chaniago=-

    907814 wrote:
    I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
    I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.This is to be expected. Even an IDENTICAL query can (and often will) have DIFFERENT execution times.
    The typical reason is how fast the query process can get to the data block(s) containing the relevant row(s). Is that data block still on disk and require expensive and slow physical I/O to move it into the buffer cache for use? Is that data block already cached for much faster logical I/O access? If in memory, is there any contention in getting a latch for the chain the data block hangs off from (how hot is that block)? Etc.
    The run-time environment is not static. Thus execution times of queries (called cursors in Oracle) is not static. Execution times are expected to vary.
    Some basics. SQL code is source code. SQL code needs to be parsed and converted into a set of instructions that the server can execute. So it is similar to C/C++. SQL source code needs to be compiled. This executable code in Oracle is called a cursor.
    Like your code, the cursor can be executed with different input variables (bind variables). However, that code would have been compiled using certain assumptions about the data. And that executable code may work fine for some input data, and work not so okay for other input data. As the input parameter values are not not equal. E.g. there are a 1000 rows to process when employee type parameter is "employee" and only 10 rows when it is "manager". The code could have been compiled with the assumption that 10 rows would be the average for all input parameters - the Cost Based Optimiser needs to base its decision on the best execution path for that SQL source code on certain assumptions about the data. These may not always be correct. (usually due incorrect or stale stats about the data)
    Thus you also need to look at what the execution plan is (the URL for which has already been supplied).
    The Oracle® Database Performance Tuning Guide is at http://www.oracle.com/pls/db112/portal.all_books

  • Automatic DOP take more time to execute query

    We upgraded database to oracle 11gR2. While testing Automatic DOP feature with our existing query it takes more time than with parallel.
    Note: No constrains or Index created on table to gain performance while loading data (5000records / sec)
    Os : Sun Solaris 64bit
    CPU = 8
    RAM = 7456M
    Default parameter settings:
    parallel_degree_policy               string      MANUAL
    parallel_degree_limit                string      CPU
    parallel_threads_per_cpu             integer     2
    arallel_degree_limit                 string      CPU
    cpu_count                            integer     8
    parallel_threads_per_cpu             integer     2
    resource_manager_cpu_allocation      integer     8
    Query:
    SELECT COUNT(*)
    from (
    SELECT
    /*+ FIRST_ROWS(50), PARALLEL */
    Query gets executed in 22minutes : execution plan
      COUNT(*)
          9600
    Elapsed: 00:22:10.71
    Execution Plan
    Plan hash value: 3765539975
    | Id  | Operation           | Name             | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |                  |     1 |    21 |  2164K  (1)| 07:12:52 |       |   |
    |   1 |  SORT AGGREGATE     |                  |     1 |    21 |            |          |       |   |
    |   2 |   PARTITION RANGE OR|                  | 89030 |  1825K|  2164K  (1)| 07:12:52 |KEY(OR)|KEY(OR)|
    |*  3 |    TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 |  1825K|  2164K  (1)| 07:12:52 |KEY(OR)|KEY(OR)|Automatic DOP Query: parameters set
    alter session set PARALLEL_DEGREE_POLICY = limited;
    alter session force parallel query ;Query:
    SELECT COUNT(*)
    from (
    SELECT /*+ FIRST_ROWS(50), PARALLEL*/
    This query takes more than 2hrs to execute
    COUNT(*)
          9600
    Elapsed: 02:07:48.81
    Execution Plan
    Plan hash value: 127536830
    | Id  | Operation              | Name             | Rows  | Bytes | Cost (%CPU)| Time     | Pstart|Pstop |    TQ   |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT       |                  |     1 |    21 |   150K  (1)| 00:30:01 |       |      |         |      |            |
    |   1 |  SORT AGGREGATE        |                  |     1 |    21 |            |          |       |      |         |      |            |
    |   2 |   PX COORDINATOR       |                  |       |       |            |          |       |      |         |      |            |
    |   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |    21 |            |          |       |      |  Q1,00  | P->S | QC (RAND)  |
    |   4 |     SORT AGGREGATE     |                  |     1 |    21 |            |          |       |      |  Q1,00  | PCWP |            |
    |   5 |      PX BLOCK ITERATOR |                  | 89030 |  1825K|   150K  (1)| 00:30:01 |KEY(OR)|KEY(OR)|  Q1,00 | PCWC |            |
    |*  6 |       TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 |  1825K|   150K  (1)| 00:30:01 |KEY(OR)|KEY(OR)|  Q1,00 | PCWP |            |
    Note
    - automatic DOP: Computed Degree of Parallelism is 16 because of degree limitcan some one help us to find out where we did wrong or any pointer will really helpful to resolve an issue.
    Edited by: Sachin B on May 11, 2010 4:05 AM

    Generated AWR report for ADOP
    Foreground Wait Events                       DB/Inst: HDB/hdb  Snaps: 158-161
    -> s  - second, ms - millisecond -    1000th of a second
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> ordered by wait time desc, waits desc (idle events last)
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    direct path read                522,173     0    125,051     239    628.4   99.3
    db file sequential read             663     0        156     235      0.8     .1
    log file sync                       165     0        117     712      0.2     .1
    Disk file operations I/O            267     0         63     236      0.3     .1
    db file scattered read              251     0         36     145      0.3     .0
    control file sequential re          217     0         32     149      0.3     .0
    library cache load lock               2     0         10    4797      0.0     .0
    cursor: pin S wait on X               3     0          9    3149      0.0     .0
    read by other session                 5     0          2     429      0.0     .0
    kfk: async disk IO              613,170     0          2       0    737.9     .0
    sort segment request                  1   100          1    1007      0.0     .0
    os thread startup                    16     0          1      43      0.0     .0
    direct path write temp                1     0          1     527      0.0     .0
    latch free                           51     0          0       2      0.1     .0
    kksfbc child completion               1   100          0      59      0.0     .0
    latch: cache buffers chain           19     0          0       2      0.0     .0
    latch: shared pool                   36     0          0       1      0.0     .0
    PX Deq: Slave Session Stat           21     0          0       1      0.0     .0
    library cache: mutex X               45     0          0       1      0.1     .0
    CSS initialization                    2     0          0       6      0.0     .0
    enq: KO - fast object chec            1     0          0      11      0.0     .0
    buffer busy waits                     3     0          0       1      0.0     .0
    cursor: pin S                         9     0          0       0      0.0     .0
    CSS operation: action                 2     0          0       1      0.0     .0
    direct path write                     1     0          0       2      0.0     .0
    jobq slave wait                  17,554   100      8,942     509     21.1
    PX Deq: Execute Reply             4,060    95      7,870    1938      4.9
    SQL*Net message from clien           96     0      5,756   59962      0.1
    PX Deq: Execution Msg               618    56        712    1152      0.7
    KSV master wait                      11     0          0       2      0.0
    PX Deq: Join ACK                     16     0          0       1      0.0
    PX Deq: Parse Reply                  14     0          0       1      0.0
    Background Wait Events                       DB/Inst: HDB/hdb  Snaps: 158-161
    -> ordered by wait time desc, waits desc (idle events last)
    -> Only events with Total Wait Time (s) >= .001 are shown
    -> %Timeouts: value of 0 indicates value was < .5%.  Value of null is truly 0
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % bg
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    control file sequential re        6,249     0      2,375     380      7.5   55.6
    control file parallel writ        2,003     0        744     371      2.4   17.4
    db file parallel write            1,604     0        503     313      1.9   11.8
    log file parallel write             861     0        320     371      1.0    7.5
    db file sequential read             363     0        151     415      0.4    3.5
    db file scattered read              152     0         64     421      0.2    1.5
    Disk file operations I/O            276     0         21      77      0.3     .5
    os thread startup                   316     0         15      48      0.4     .4
    ADR block file read                  24     0         11     450      0.0     .3
    rdbms ipc reply                      17    12          7     403      0.0     .2
    Data file init write                  6     0          6    1016      0.0     .1
    direct path write                    21     0          6     287      0.0     .1
    log file sync                         7     0          6     796      0.0     .1
    ADR block file write                 10     0          4     414      0.0     .1
    enq: JS - queue lock                  1     0          3    2535      0.0     .1
    ASM file metadata operatio        1,801     0          2       1      2.2     .0
    db file parallel read                30     0          1      40      0.0     .0
    kfk: async disk IO                  955     0          1       1      1.1     .0
    db file single write                  1     0          0     415      0.0     .0
    reliable message                     10     0          0      23      0.0     .0
    latch: shared pool                   75     0          0       2      0.1     .0
    latch: call allocation               26     0          0       2      0.0     .0
    CSS initialization                    7     0          0       6      0.0     .0
    asynch descriptor resize            352   100          0       0      0.4     .0
    undo segment extension                2   100          0       5      0.0     .0
    CSS operation: action                 9     0          0       1      0.0     .0
    CSS operation: query                 42     0          0       0      0.1     .0
    latch: parallel query allo            4     0          0       0      0.0     .0
    rdbms ipc message                37,948    97    104,599    2756     45.7
    DIAG idle wait                   16,762   100     16,927    1010     20.2
    ASM background timer              1,724     0      8,467    4912      2.1
    shared server idle wait             282   100      8,465   30019      0.3
    pmon timer                        3,123    90      8,465    2711      3.8
    wait for unread message on        8,381   100      8,465    1010     10.1
    dispatcher timer                    141   100      8,463   60019      0.2
    Streams AQ: qmn coordinato          604    50      8,462   14010      0.7
    Streams AQ: qmn slave idle          304     0      8,462   27836      0.4
    smon timer                           35    71      8,382  239496      0.0
    Space Manager: slave idle         1,621    99      8,083    4986      2.0
    PX Idle Wait                      2,392    99      4,739    1981      2.9
    class slave wait                     46     0        623   13546      0.1
    KSV master wait                       2     0          0      27      0.0
    SQL*Net message from clien            7     0          0       1      0.0
    Wait Event Histogram                         DB/Inst: HDB/hdb  Snaps: 158-161
    -> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
    -> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
    -> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
    -> Ordered by Event (idle events last)
                                                        % of Waits
                               Total
    Event                      Waits  <1ms  <2ms  <4ms  <8ms <16ms <32ms  <=1s   >1s
    ADR block file read           24                                     100.0
    ADR block file write          10                                     100.0
    ADR file lock                 12 100.0
    ASM file metadata operatio  1812  99.0    .3    .4                      .2    .1
    CSS initialization             9                   100.0
    CSS operation: action         11  90.9   9.1
    CSS operation: query          54 100.0
    Data file init write           6        16.7  16.7                    16.7  50.0
    Disk file operations I/O     533  88.7   2.6    .6               1.5    .2   6.4
    PX Deq: Signal ACK EXT         4 100.0
    PX Deq: Signal ACK RSG         2 100.0
    PX Deq: Slave Session Stat    21  42.9  28.6  28.6
    SQL*Net break/reset to cli     6 100.0
    SQL*Net message to client    102 100.0
    SQL*Net more data to clien     4 100.0
    asynch descriptor resize     527 100.0
    buffer busy waits              4  75.0        25.0
    control file parallel writ  2003   9.3    .5          .0    .1        90.0
    control file sequential re  6466  10.6    .0    .0    .0    .1    .2  89.0
    cursor: pin S                  9 100.0
    cursor: pin S wait on X        3                          33.3  33.3        33.3
    db file parallel read         30                           6.7  30.0  63.3
    db file parallel write      1604   7.4    .1                .6  16.5  75.5
    db file scattered read       403   3.7    .2   2.5  13.6  14.9   3.5  61.5
    db file sequential read     1017  12.3    .8   2.3   7.3   6.6   2.0  68.8
    db file single write           1                                     100.0
    direct path read           522.2   2.2   2.1    .1    .0   1.8  17.9  75.9
    direct path write             22         4.5                     4.5  90.9
    direct path write temp         1                                     100.0
    enq: JS - queue lock           1                                           100.0
    enq: KO - fast object chec     1                         100.0
    enq: PS - contention           1 100.0
    kfk: async disk IO         614.1 100.0                                  .0
    kksfbc child completion        1                                     100.0
    latch free                    58  46.6  27.6  15.5  10.3
    latch: cache buffers chain    19  36.8  10.5  52.6
    latch: call allocation        26  76.9  11.5         7.7         3.8
    latch: parallel query allo     4 100.0
    latch: shared pool           111  44.1  28.8  27.0
    library cache load lock        2                                           100.0
    library cache: mutex X        45  84.4   8.9   4.4   2.2
    log file parallel write      861  10.0          .1    .1              89.5    .2
    log file sync                172   6.4                                90.1   3.5
    os thread startup            332                                     100.0
    rdbms ipc reply               18  72.2                                11.1  16.7
    read by other session          5                                     100.0
    reliable message              11  81.8   9.1                           9.1
    sort segment request           1                                     100.0
    undo segment extension         2  50.0                    50.0
    ASM background timer        1724    .8    .6    .1                      .6  97.9
    DIAG idle wait             16.8K                                     100.0
    KSV master wait               13   7.7  23.1  61.5                     7.7
    PX Deq: Execute Reply       4060    .4          .0    .0          .1   3.4  96.0
    PX Deq: Execution Msg        617  34.7   1.5   2.4   1.5   1.5    .2    .8  57.5
    PX Deq: Join ACK              16  93.8                     6.3
    PX Deq: Parse Reply           14  71.4   7.1  14.3   7.1
    PX Idle Wait                2384    .0                                  .6  99.3
    SQL*Net message from clien   103  82.5         1.0   1.9               1.0  13.6
    Space Manager: slave idle   1621                                        .2  99.8
    Streams AQ: qmn coordinato   604  50.0                                      50.0
    Wait Event Histogram                         DB/Inst: HDB/hdb  Snaps: 158-161
    -> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
    -> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
    -> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
    -> Ordered by Event (idle events last)Edited by: Sachin B on May 11, 2010 4:52 AM

  • Query takes large time to execute

    Hi,
    These are interview questions:
    1. If the query takes lot of time to execute, what should be the preliminary analysis done by a DBA
    2. If we have system, users, rollback and temporary tablespaces, 2 disks disk1 and disk2, how should the tablespaces be distributed on the disks
    I am interested to know the answers. Kindly respond
    Thanks and Regards
    Sumit Sharma

    2. If we have system, users, rollback and temporary tablespaces, 2 disks disk1 and disk2, how should the tablespaces be distributed on the disks
    2 disk are not enough for a good distribution but however you could the best possible with that.
    Really the optimal distribution of disk must be so:
    DISK1: Tablespaces of data, One Controlfile, Redo Logs ( 1 member per group )
    DISK2: Redo Logs ( 1 member per group ), One Controlfile
    DISK3: Tablespaces for Indexes, Redo Logs ( 1 member per group ), One Controlfile
    DISK4: Archives, Rollback Segments
    Joel Pérez
    http://otn.oracle.com/experts

  • What is the reason for query take more time to execute

    Hi,
    What is the reason for the query take more time inside procedure.
    but if i execute that query alone then it excute within a minutes.
    query includes update and insert.

    I have a insert and update query when I execute
    without Procedure then that query execute faster but
    If I execute inside procedure then It takes 2 hours
    to execute.Put you watch 2 hours back and the problem will disappear.
    do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
    What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
    Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
    To begin with something take a look at this
    When your query takes too long ...
    especially the part regarding the trace.
    Bye Alessandro

  • Urgen!! Query takes lots of time to execute and the production is in effect

    Hi,
    We have some data loading script. This scripts takes lots of time to execute. As Iam new to tunning please do let me know what is the wrong with the query !!
    Thanks In advance
    Query:
    =========
    INSERT /*+ PARALLEL */ INTO ris.ris_pi_profile
    (ID,COUNTRY_OF_CITIZENSHIP,IMMIGRATION_STATUS,SSN,DOB,GENDER,
    ETHNICITY,RACE,DEPARTMENT,DIVISION,INSTITUTION_ID,INST_EMAIL,EFFECT_DATE,ACADEMIC_TITLE,ACADEMIC_POSITION,
    OTH_PER_DATA,PCT_RESEARCH,PCT_TEACHING,PCT_CLINICAL,PCT_ADMIN,PCT_OTHER,PCT_TRAINING)
    SELECT
    ap.id,
    p.citizen_cd,
    decode(p.visa_cd,'CV',0,'F1',1,'H1',2,'H1B',3,'H2',4,'J1',5,'J2',6,'O1',7,'PR',8,'PRP',9,'TC',10,'TN',11,'TNN',12),
    (select n.soc_sec_num from sa.name n where n.name_id = p.name_id),
    (select n.birth_date from sa.name n where n.name_id = p.name_id),
    (select decode(n.gender_cd,'F',1,'M',2,0) from sa.name n where n.name_id = p.name_id),
    (select decode(n.ethnic_cd,'H',1) from sa.name n where n.name_id = p.name_id),
    (select decode(n.ethnic_cd,'A',2,'B',3,'I',1,'P',4,'W',5) from sa.name n where n.name_id = p.name_id),
    a.dept_name,
    a.div_name,
    a.inst_id,
    (select n.email from sa.name n where n.name_id = p.name_id),
    a.eff_date,
    ac.acad_pos_desc,
    p.acad_pos_cd,
    0,
    p.research_pct,
    p.teach_pct,
    p.patient_pct,
    p.admin_pct,
    p.other_pct,
    p.course_pct
    FROM
    appl1 ap,
    sa.personal_data p,
    sa.address a,
    sa.academic_pos_cd ac,
    profile_pi f
    WHERE
    p.project_role_cd='PI'
    and ap.appl_id=f.appl_id
    and p.appl_id=f.appl_id
    and p.name_id=f.name_id
    and a.addr_id=f.addr_id
    and p.acad_pos_cd=ac.acad_pos_cd
    AND EXISTS (select 1 from ris.ris_institution i WHERE i.id = a.inst_id)
    AND EXISTS (select 1 from sa.academic_pos_cd acp WHERE acp.acad_pos_cd = p.acad_pos_cd);
    In the execution PLan I see lots of Nested loop, Hash Join
    Index( Unique scan)
    Table Access by ( Index rowid)
    This query is fast in Test DB but ver very slow in prod DB. Need your help Urgent.
    Minaz

    When your query takes too long...
    When your query takes too long ...

  • Query take more time to execute

    Hi
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performance
    thank's

    [email protected] wrote:
    I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performanceI have a query that is using even more time to execute. Do I win?

Maybe you are looking for