Update query takes much time to execute

Hi Experts,
I need help regarding performance of the query.
update TEST_TAB
set fail=1, msg='HARD'
where id in (
select src.id from TEST_TAB src
inner join TEST_TAB l_1 on src.email=l_1.email and l_1.database_id=335090 and l_1.msg='HARD' and l_1.fail=1
inner join TEST_TAB l_2 on src.email=l_2.email and l_2.database_id=338310 and l_2.msg='HARD' and l_2.fail=1
inner join TEST_TAB l_3 on src.email=l_3.email and l_3.database_id=338470 and l_3.msg='HARD' and l_3.fail=1
where src.database_id=1111111;
This query is running for too long, takes >1 hour and it updates 26000 records.
But, if we run inner select query
select src.id from TEST_TAB src
inner join TEST_TAB l_1 on src.email=l_1.email and l_1.database_id=335090 and l_1.msg='HARD' and l_1.fail=1
inner join TEST_TAB l_2 on src.email=l_2.email and l_2.database_id=338310 and l_2.msg='HARD' and l_2.fail=1
inner join TEST_TAB l_3 on src.email=l_3.email and l_3.database_id=338470 and l_3.msg='HARD' and l_3.fail=1
where src.database_id=1111111
It takes <1 minute to execute.
Please give me suggetions in the update query so that i will improve performance of the query.

SELECT src.id FROM lead src
        inner join lead l_1 ON src.email=l_1.email AND
l_1.database_id=335090 AND l_1.bounce_msg_t='HARD' AND l_1.failed=1
        inner join lead l_2 ON src.email=l_2.email AND
l_2.database_id=338310 AND l_2.bounce_msg_t='HARD' AND l_2.failed=1
        inner join lead l_3 ON src.email=l_3.email AND
l_3.database_id=338470 AND l_3.bounce_msg_t='HARD' AND l_3.failed=1
    WHERE src.database_id=264170;
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=ALL_ROWS          1             10453                              
  TABLE ACCESS BY INDEX ROWID     LEAD     1       32       27                              
    NESTED LOOPS          1       130       10453                              
      HASH JOIN          1       98       10426                              
        HASH JOIN          199       12 K     6950                              
          TABLE ACCESS BY INDEX ROWID     LEAD     202       6 K     3476                              
            INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
          TABLE ACCESS BY INDEX ROWID     LEAD     94 K     3 M     3473                              
            INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
        TABLE ACCESS BY INDEX ROWID     LEAD     202       6 K     3476                              
          INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
      INDEX RANGE SCAN     LEAD_IDX_4     24             3   Update for one row.
     UPDATE lead SET failed=1, bounce_msg_t='HARD'
WHERE id IN (SELECT src.id FROM lead src
inner join lead l_1 ON src.email=l_1.email AND
l_1.database_id=335090 AND l_1.bounce_msg_t='HARD' AND l_1.failed=1
inner join lead l_2 ON src.email=l_2.email AND
l_2.database_id=338310 AND l_2.bounce_msg_t='HARD' AND l_2.failed=1
inner join lead l_3 ON src.email=l_3.email AND
l_3.database_id=338470 AND l_3.bounce_msg_t='HARD' AND l_3.failed=1
WHERE src.database_id=264170
     AND ROWNUM=1)
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
UPDATE STATEMENT Optimizer Mode=ALL_ROWS          1             10456                              
  UPDATE     LEAD                                               
    NESTED LOOPS          1       32       10456                              
      VIEW     VW_NSO_1     1       13       10453                              
        SORT UNIQUE          1       130                                    
          COUNT STOPKEY                                                    
            TABLE ACCESS BY INDEX ROWID     LEAD     1       32       27                              
              NESTED LOOPS          1       130       10453                              
                HASH JOIN          1       98       10426                              
                  HASH JOIN          199       12 K     6950                              
                    TABLE ACCESS BY INDEX ROWID     LEAD     202       6 K     3476                              
                      INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
                    TABLE ACCESS BY INDEX ROWID     LEAD     94 K     3 M     3473                              
                      INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
                  TABLE ACCESS BY INDEX ROWID     LEAD     202       6 K     3476                              
                    INDEX RANGE SCAN     LEAD_DATABASE_FK_I     94 K           259                              
                INDEX RANGE SCAN     LEAD_IDX_4     24             3                              
      TABLE ACCESS BY INDEX ROWID     LEAD     1       19       2                              
        INDEX UNIQUE SCAN     LEADS_PK     1             1 

Similar Messages

  • Why update query takes  long time ?

    Hello everyone;
    My update query takes long time.  In  emp  ( self testing) just  having 2 records.
    when i issue update query , it takes long time;
    SQL> select  *  from  emp;
      EID  ENAME     EQUAL     ESALARY     ECITY    EPERK       ECONTACT_NO
          2   rose              mca                  22000   calacutta                   9999999999
          1   sona             msc                  17280    pune                          9999999999
    Elapsed: 00:00:00.05
    SQL> update emp set esalary=12000 where eid='1';
    update emp set esalary=12000 where eid='1'
    * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:01:11.72
    SQL> update emp set esalary=15000;
    update emp set esalary=15000
      * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:02:22.27

    Hi  BCV;
    Thanks for your reply but it doesn't provide output,  please  see   this.
    SQL> update emp set esalary=15000;
    ........... Lock already occured.
    >> trying to trace  >>
    SQL> select HOLDING_SESSION from dba_blockers;
    HOLDING_SESSION
                144
    SQL> select sid , username, event from v$session where username='HR';
    SID USERNAME     EVENT
       144   HR    SQL*Net message from client
       151   HR    enq: TX - row lock contention
       159   HR    SQL*Net message from client
    >> It  does n 't  provide  clear output about  transaction lock >>
    SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
      2  BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
      3  request
      4  FROM v$lock, v$session
      5  WHERE v$lock.TYPE = 'TX'
      6  AND v$lock.SID = v$session.SID
      7  AND v$session.username = USER;
      no rows selected
    SQL> select MACHINE from v$session where sid = :sid;
    SP2-0552: Bind variable "SID" not declared.

  • 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

  • Query takes much time while sum of yearly bases amount

    I have made query on the basis of joing to get payroll data it's woking fine but when we accumulate this on yearly basis while giving parameter from and to date then it takes much time, so how can we optimise this.
    please advice.

    this is query
    SELECT paa.assignment_id,MAX(EFFECTIVE_DATE) effective_date,
    paypa.business_group_id,paypa.payroll_id,
    nvl(SUM(decode(pet.element_type_id,10,decode(pivf.name,'Pay Value',TO_NUMBER(NVL(prrv.result_value, 0))))),0) AMOUNT
    FROM pay_assignment_actions paa,
    pay_payroll_actions paypa,
    pay_run_results prr,
    pay_element_types_f pet,
    pay_element_classifications pec,
    pay_run_result_values prrv,
    pay_input_values_f pivf
    where paypa.payroll_ACTION_id = paa.payroll_ACTION_id
    AND prr.assignment_ACTION_id = paa.assignment_ACTION_id
    AND paypa.action_status = 'C'
    AND paa.action_status = 'C'
    and paypa.action_type in ('Q','R')
    AND pet.element_type_id = prr.element_type_id
    AND pec.classification_id = pet.classification_id
    AND pivf.input_value_id=prrv.input_value_id
    AND prr.run_result_id = prrv.run_result_id
    AND pivf.element_type_id = pet.element_type_id
    AND paypa.effective_date BETWEEN pivf.effective_start_date AND pivf.effective_end_date
    AND paypa.effective_date BETWEEN pet.effective_start_date AND pet.effective_end_date
    AND paypa.effective_date between to_date('01-JUL-2010') AND TO_DATE('30-JUN-2011')
    group by paa.assignment_id,paypa.business_group_id,paypa.payroll_id
    any idea for this ,how can we improve performance,althoug it's woking fine without using group by function
    Edited by: oracle0282 on Mar 31, 2011 11:36 PM

  • 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

  • Query takes long time to execute.

    Hi All,
    I have one query that takes 5 minutes to execute.
    The query depends on four tables.
    The table IBS_WORK_BANKDATA and IBS_ORG_BANKDATA contains 25 lack records. Table IBS_CURRENCYMASTER have 250 records and IBS_CURRENCYEEXCHANGERATE have 50 records.
    Out put of query contains 3500 records.
    Oracle version is 9.0.1.1 and OS is windows 2003 server.
    Query:
    select distinct trim(wrk.bd_alcd) as ALCD, wrk.bd_typecd as TypeCD, wrk.bd_forcd as FORCD, wrk.bd_curcd as CURCD,
    wrk.bd_councd as COUNCD, wrk.bd_sectcd as SECCD,
    wrk.bd_matcd as MATCD, wrk.bd_c_u_cd as C_U_CD, wrk.bd_s_u_cd as S_U_CD,
    0 as Org_FCBal,0 as ORG_Bal,case when wrk.bd_type='O' then wrk.bd_fc_bal else 0 end as Main_FCBal,
    case when wrk.bd_type='O' then (wrk.bd_fc_bal * nvl(exchg.cer_exchangerate, 1)) else 0 end as main_Bal,
    wrk.bd_rs_int,wrk.bd_rs_bal,wrk.bd_fc_int,wrk.bd_fc_bal,
    ' ' as TrackChangs
    from ibs_work_bankdata wrk inner join ibs_org_bankdata org ON org.bd_yrqtr = wrk.bd_yrqtr and org.bd_bkcode=wrk.bd_bkcode and org.bd_forcd = wrk.bd_forcd
    and wrk.BD_YRQTR=20044 and wrk.BD_BKCODE ='000'
    and wrk.BD_ALCD = '51' and wrk.BD_FORCD ='IN' and wrk.BD_TYPECD = '11'
    left join ibs_currencymaster curmst on curmst.cur_code = wrk.bd_curcd
    left join ibs_currencyexchangerate exchg on exchg.cer_currencyid = curmst.cur_id
    and exchg.cer_yearqtr = 20051 and exchg.CER_ACTIVE=1
    Explain Plan:
    SELECT STATEMENT, GOAL = CHOOSE               Cost=26     Cardinality=1     Bytes=157
    SORT UNIQUE               Cost=26     Cardinality=1     Bytes=157
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_ORG_BANKDATA     Cost=2     Cardinality=204     Bytes=2856
    NESTED LOOPS               Cost=26     Cardinality=1     Bytes=157
    NESTED LOOPS OUTER               Cost=24     Cardinality=1     Bytes=143
    NESTED LOOPS OUTER               Cost=23     Cardinality=1     Bytes=93
    TABLE ACCESS BY INDEX ROWID     Object owner=RBI     Object name=IBS_WORK_BANKDATA     Cost=22     Cardinality=1     Bytes=52
    INDEX SKIP SCAN     Object owner=RBI     Object name=IBS_WORK_BANKDATA_IDX     Cost=7     Cardinality=1     
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYMASTER     Cost=1     Cardinality=178     Bytes=7298
    TABLE ACCESS FULL     Object owner=RBI     Object name=IBS_CURRENCYEXCHANGERATE     Cost=1     Cardinality=19     Bytes=950
    INDEX RANGE SCAN     Object owner=RBI     Object name=IBS_ORG_BANKDATA_IDX     Cost=1     Cardinality=204     
    Please help me.
    Thanks in advance,
    Prathamesh.

    Hi prathemesh,
    Check whether the tables accessed by the query are recently analyzed.
    Thanks,
    Sathis.

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

  • Query taking much time to execute

    The following query is taking more than 4hrs to execute.
    select  l_extendedprice , count(l_extendedprice) from dbo.lineitem group by  l_extendedprice
    Cardinality of table : 6001215 ( > 6 million)
    Index on l_extendedprice is there
    ReadAheadLobThreshold = 500
    Database version 7.7.06.09
    I need to optimize this query. Kindly suggest way out.
    Thanks
    Priyank

    Data Cache :      80296 KB
    Ok, that's 8 Gigs for cache.
    The index takes 16335 pages à 8 KB = 130.680 KB = 128 MB.
    Fits completely into RAM - the same is true for the additional temp resultset.
    So once the index has been read to cache I assume the query is a lot quicker than 4 hours.
    6 Data Volumes
    first 3 of size 51.200 KB
    other 3 of size  1,048,576 KB
    Well, that's not the smartest thing to do.
    That way the larger volumes will get double the I/O requests which eventually saturates the I/O channel.
    Yes looking at the cardinality of the table lots of I/O required but still more than 4 hrs is quite unrealistic. Some tuning is required.
    We're not talking about the cardinality here - you want all the data.
    We talk pages then.
    And as we've seen, the table is not touched for this query.
    Instead the smaller index is completely read in a index only strategy.
    Loading 128MB from disk, creating temporary data in the same size and spilling out the information (and thereby reading the 128 MB temp size again) in 4 hours add up to ca. 384 MB/4 hours = 96 MB/hour = 1,6 MB/minute.
    Not too good really - I suspect that the I/O system here is not the quickest one.
    You may want to activate the time measurement and set the DB Analyzer interval to 120 secs.
    Then activate Command and Resourcemonitor and look for statements taking longer than 10 minutes.
    Now run your statement again and let us know the information from Command/Resourcemonitor and check for warnings in the DBanalyzer output.
    regards,
    Lars

  • Query takes long time to execute on exceptional cases

    Hi Tuning Experts,
    My query runs on prod db on daily basis on fixed scheduled time, out of seven days, for 1-2 exeptional days it takes 7-10 hr which takes 10-15 min on rest of the days.
    I want to do RCA for it, so please help me how i can proceed. either i go with
    AUTOTRACE,TKPROF, EXPLAIN PLAN or STATSPACK, which is best method to find out the real culprit.
    Regards
    Asif

    To answer your question...
    Running AUTOTRACE and EXPLAIN PLAN against the query in your development environment won't help diagnose the abnormal executions in production. Statspack is a global thing. It's a good thing to run but probably of insufficient granularity for here.
    TKPROF is an anlyzing tool. You need something to analyze. Read this article on Interpreting Wait Events to find out how to set the 10046 event to gather evidence.
    Cheers, APC

  • Owb job taking too much time to execute

    While creating a job in OWB, I am using three tables,a joiner and an aggregator which are all joined through another joiner to load into the final table. The output is coming correct but the sql query generated is very complex having so many sub-queries. So, its taking so much time to execute. Pls help me in reducing the cost.
    -KC

    It depends on what kind of code it generates at each stage. The first step would be collect stats for all the tables used and check the SQL generated using EXPLAIN PLAN. See which sub-query or inline view creates the most cost.
    Generate SQL at various stages and see if you can achieve the same with a different operator.
    The other option would be passing HINTS to the tables selected.
    - K

  • While running the query how much time it will taken, I want to see the time

    Hi Folks
    I would like to know ... While running the query how much time it will be taken, I want to see the time? in WEBI XI R2.....
    Plz let me know  the answer.......

    Hi Ravi,
    The time a report runs is estimated based on the last time it was run. So you need to run the report once before you can see how long it will take. Also it depends on several factors... the database server could cache some queries so running it a second time immediately after the first time could be quicker. And there is the chance of changing filters to bring back different sets of data.
    You could also schedule a report and then check the scheduled instance's status properties and view how long a report actually ran.
    Good luck

  • Stopping a Query taking more time to execute in runtime in Oracle Forms.

    Hi,
    In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
    We have tried three approach.
    1. set max fetch record in form and block level.
    2. set max fetch time in form and block level.
    in above two method does not provide the appropiate solution for us.
    3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
    It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
    But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
    Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
    This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
    Thanks and Regards,
    Suraj
    Edited by: user10673131 on Jun 25, 2009 4:55 AM

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • Select Query Takes more time

    Hi All,
    I have cloned KSB1 tcode to custom one as required by business.
    Below query takes more time than excepted.
    Here V_DB_TABLE = COVP.
    Values in Where clause are as follows
    OBNJR in ( KSBB010000001224  BT  KSBB012157221571)
    GJAHR in blank
    VERSN in '000'
    WRTTP in '04' and '11'
    all others are blank
    VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
    SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT      
                        FROM (V_DB_TABLE)                             
                        WHERE LEDNR = '00'                            
                        AND   OBJNR IN LR_OBJNR                       
                        AND   GJAHR IN GR_GJAHR                       
                        AND   VERSN IN GR_VERSN                       
                        AND   WRTTP IN GR_WRTTP                       
                        AND   KSTAR IN LR_KSTAR                       
                        AND   PERIO IN GR_PERIO                       
                        AND   BUDAT IN GR_BUDAT                       
                        AND   PAROB IN GR_PAROB                       
                        AND   (VT_VAR_COND).    
    Checked in table for this condition it has only 92 entries.
    But when i execute program takes long time as 3 Hrs.
    Could any one help me on this

    >1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
    > 2.Avoid using corresponding addition.create a type and reference it.
    > If the select is going for dump beacause of storage limitations ,then use Cursors.
    you got three large NOs .... all three recommendations are wrong!
    The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
    Select options:
    Did you ever try to trace the SE16?  The generic statement has for every field an in-condition!
    Without the information what was actually filled, nobody can say something there
    are at least 2**n  combinations possible!
    Use ST05 for SE16 and check actual statement plus explain!

  • Count (*)  for select stmt take more time than  execute a that sql stmt

    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...

    797525 wrote:
    HI
    count (*) for select stmt take more time than execute a that sql stmt
    executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql  command for faster execute .
    but if i tried to find out total number of rows in that query it takes more time ..
    almost 2.30 hrs still running to find count(col)
    please help me to get count of row faster.
    thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
    As already mentined please read teh FAQ to post tuning questions.

  • One query taking different time to execute on different environments

    I am working on Oracle 10g. We have setup of two different environments - Development and Alpha.
    I have written a query which gets some records from a table. This table contains around 1,000,000 records on both the environments.
    This query takes 5 seconds to execute on Development environment to get 200 records but the same query takes around 50 seconds to execute on Alpha environment and to retrieve same number of records.
    Data and indexes on the table is same on both environments. There are no joins in the query.
    Please let me know what are the all possible reasons for this?
    Edited by: 956610 on Sep 3, 2012 2:37 AM

    Below is the trace on the two environments ---
    -----------------------Development ------------------------------
    CPU used by this session     1741
    CPU used when call started     1741
    Cached Commit SCN referenced     15634
    DB time     1752
    Effective IO time     7236
    Number of read IOs issued     173
    SQL*Net roundtrips to/from client     14
    buffer is not pinned count     90474
    buffer is pinned count     264554
    bytes received via SQL*Net from client     4507
    bytes sent via SQL*Net to client     28859
    calls to get snapshot scn: kcmgss     6
    calls to kcmgcs     13
    cell physical IO interconnect bytes     165330944
    cleanout - number of ktugct calls     5273
    cleanouts only - consistent read gets     5273
    commit txn count during cleanout     5273
    consistent gets     202533
    consistent gets - examination     101456
    consistent gets direct     19686
    consistent gets from cache     182847
    consistent gets from cache (fastpath)     81013
    enqueue releases     3
    enqueue requests     3
    execute count     6
    file io wait time     1582
    immediate (CR) block cleanout applications     5273
    index fetch by key     36608
    index scans kdiixs1     36582
    no buffer to keep pinned count     8
    no work - consistent read gets     95791
    non-idle wait count     42
    non-idle wait time     2
    opened cursors cumulative     6
    parse count (hard)     1
    parse count (total)     6
    parse time cpu     1
    parse time elapsed     2
    physical read IO requests     181
    physical read bytes     163299328
    physical read total IO requests     181
    physical read total bytes     163299328
    physical read total multi block requests     162
    physical reads     19934
    physical reads direct     19934
    physical reads direct temporary tablespace     248
    physical write IO requests     8
    physical write bytes     2031616
    physical write total IO requests     8
    physical write total bytes     2031616
    physical write total multi block requests     8
    physical writes     248
    physical writes direct     248
    physical writes direct temporary tablespace     248
    physical writes non checkpoint     248
    recursive calls     31
    recursive cpu usage     1
    rows fetched via callback     23018
    session cursor cache hits     4
    session logical reads     202533
    session uga memory max     65488
    sorts (memory)     3
    sorts (rows)     19516
    sql area evicted     2
    table fetch by rowid     140921
    table scan blocks gotten     19686
    table scan rows gotten     2012896
    table scans (direct read)     2
    table scans (long tables)     2
    user I/O wait time     2
    user calls     16
    workarea executions - onepass     4
    workarea executions - optimal     7
    workarea memory allocated     17
    ------------------------------------------------------ For Alpha ------------------------------------------------------------------
    CCursor + sql area evicted     1
    CPU used by this session     5763
    CPU used when call started     5775
    Cached Commit SCN referenced     9264
    Commit SCN cached     1
    DB time     6999
    Effective IO time     4262103
    Number of read IOs issued     2155
    OS All other sleep time     10397
    OS Chars read and written     340383180
    OS Involuntary context switches     18766
    OS Other system trap CPU time     27
    OS Output blocks     12445
    OS Process stack size     24576
    OS System call CPU time     223
    OS System calls     20542
    OS User level CPU time     5526
    OS User lock wait sleep time     86045
    OS Voluntary context switches     15739
    OS Wait-cpu (latency) time     273
    SQL*Net roundtrips to/from client     14
    buffer is not pinned count     2111
    buffer is pinned count     334
    bytes received via SQL*Net from client     4486
    bytes sent via SQL*Net to client     28989
    calls to get snapshot scn: kcmgss     510
    calls to kcmgas     4
    calls to kcmgcs     119
    cell physical IO interconnect bytes     340041728
    cleanout - number of ktugct calls     1
    cleanouts only - consistent read gets     1
    cluster key scan block gets     179
    cluster key scans     168
    commit txn count during cleanout     1
    consistent gets     41298
    consistent gets - examination     722
    consistent gets direct     30509
    consistent gets from cache     10789
    consistent gets from cache (fastpath)     9038
    cursor authentications     2
    db block gets     7
    db block gets from cache     7
    dirty buffers inspected     1
    enqueue releases     58
    enqueue requests     58
    execute count     510
    file io wait time     6841235
    free buffer inspected     8772
    free buffer requested     8499
    hot buffers moved to head of LRU     27
    immediate (CR) block cleanout applications     1
    index fast full scans (full)     1
    index fetch by key     196
    index scans kdiixs1     331
    no work - consistent read gets     40450
    non-idle wait count     1524
    non-idle wait time     1208
    opened cursors cumulative     511
    parse count (hard)     39
    parse count (total)     44
    parse time cpu     78
    parse time elapsed     343
    physical read IO requests     3293
    physical read bytes     329277440
    physical read total IO requests     3293
    physical read total bytes     329277440
    physical read total multi block requests     1951
    physical reads     40195
    physical reads cache     8498
    physical reads cache prefetch     7467
    physical reads direct     31697
    physical reads direct temporary tablespace     1188
    physical write IO requests     126
    physical write bytes     10764288
    physical write total IO requests     126
    physical write total bytes     10764288
    physical writes     1314
    physical writes direct     1314
    physical writes direct temporary tablespace     1314
    physical writes non checkpoint     1314
    prefetched blocks aged out before use     183
    recursive calls     1329
    recursive cpu usage     76
    rows fetched via callback     7
    session cursor cache count     8
    session cursor cache hits     491
    session logical reads     41305
    session pga memory max     851968
    session uga memory     -660696
    session uga memory max     3315160
    shared hash latch upgrades - no wait     14
    sorts (disk)     1
    sorts (memory)     177
    sorts (rows)     21371
    sql area evicted     10
    table fetch by rowid     613
    table scan blocks gotten     30859
    table scan rows gotten     3738599
    table scans (direct read)     4
    table scans (long tables)     8
    table scans (short tables)     3
    user I/O wait time     1208
    user calls     16
    workarea executions - onepass     7
    workarea executions - optimal     113
    workarea memory allocated     -617

Maybe you are looking for