Question on physical reads

Is RMAN I/Os accounted in physical reads stat?
I mean, do the blocks read from disk by RMAN to backup the database get accounted in physical reads statistic?
One of our databases has a value for physical read total IO requests higher than physical reads so I guess the physical reads missing are RMAN's.
Thanks in advance

Statistics have not the same unit so you cannot compare them directly:
>
physical read total IO requests
Number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities. The difference between this value and "physical read total multi block requests" gives the total number of single block read requests.
>
and
>
physical reads     
Total number of data blocks read from disk. This value can be greater than the value of "physical reads direct" plus "physical reads cache" as reads into process private buffers also included in this statistic.
>
You should compare physical read total IO requests with:
>
physical read IO requests
Number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of "physical read total IO requests" statistic.
>
Edited by: P. Forstmann on 9 avr. 2013 12:57

Similar Messages

  • Corruption Parameters Increase High Physical Read for one query

    Hi Oracle Experts,
    Here is what I am currently facing in my non-prod environment:
    We are testing out corruption parameters in non-prod environment and doing a perf test for them and we found that one SELECT query has seen significant decreases in performance; What I mean by that is after adding corruption parameters query is executing 40 sec compare to 18 sec and less. Also, this query is widely use by user in Prod environment, so performance degradation will create serious impact on their work.
    I have generated AWR Diff for baseline and perf test following are parameter we have set for corruption test:
    db_block_checking (Baseline) LOW (Perftest) MEDIUM
    db_block_checksum (Baseline) TRUE (Perftest) FULL
    Load Profile from AWR Diff are below:
    Load Profile
    1st Per Sec 2nd Per Sec %Diff 1st Per Txn 2nd Per Txn %Diff
    Redo size: 758,356.06 752,760.94 -0.74 67,161.76 66,631.71 -0.79
    Logical reads: 104,637.62 108,677.76 3.86 9,266.95 9,619.77 3.81
    Block changes: 1,578.11 1,560.15 -1.14 139.76 139.76 0.00
    Physical reads:          103.78 544.41 424.58 9.19 48.19 424.37
    Physical writes: 108.94 107.13 -1.66 9.65 9.48 -1.76
    User calls: 3,477.02 3,497.26 0.58 307.93 309.57 0.53
    Parses: 948.36 949.61 0.13 83.99 84.06 0.08
    Hard parses: 0.79 0.54 -31.65 0.07 0.05 -28.57
    Sorts: 121.48 120.32 -0.95 10.76 10.65 -1.02
    Logons: 0.36 0.27 -25.00 0.03 0.02 -33.33
    Executes: 1,575.55 1,591.40 1.01 139.53 140.87 0.96
    Transactions: 11.29 11.30 0.09
    If we gather stats for tables involved in the query than it performs well in fact with in 5 Sec, but I believe in prod we can't gather state very often.
    Questions:
    1) How to remedy this situation and have query perform well along with corruption parameters?
    2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.
    3) Any reference to Doc will be highly appreciated.

    1) How to remedy this situation and have query perform well along with corruption parameters?Use faster CPU. Checksum is a thing that needs to be computed.
    2) Does corruption parameters have impact on SELECT query too, I believe it will have impact on INSERT and UPDATE.According to docs corruption parameters do not have impact on SELECT queries.
    However, I believe, checksum has to be recomputed after delayed block cleanout that may be done by SELECT query after big update. ( http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/ )
    3) Any reference to Doc will be highly appreciated.
    Why is it difficult for you to find the docs yourself?

  • Reducing Physical Reads

    Hi
    My oracle version is 10.2.0.4
    Is there any way to reduce the physical reads apart from tuning the query and index creation.
    Can I have my whole table arranged in blocks sequentially one after the other so that my search becomes simple.
    Is there any option for that like Coallesce /deallocate unused space/ Compact.

    littleboy wrote:
    Is there any way to reduce the physical reads apart from tuning the query and index creation.Incorrectly phrased. By reducing PIO (physical I/O) you can imply that you want to increase LIO (logical I/O) as this is faster and will thus increase performance.
    That is not tuning. That is hacking of a terrible kind.
    In fact, a high percentage LIO is indicative of an application design problem.
    The correctly phrased question is "<i>how to reduce I/O</i>?" - as less I/O means less work. And less work does not equate to only less PIOs. It means less I/O (of all kinds). Period.
    Can I have my whole table arranged in blocks sequentially one after the other so that my search becomes simple.
    Is there any option for that like Coallesce /deallocate unused space/ Compact.From the questions you have asked the past few days, I get the feeling that you are looking for magical silver bullet solutions to performance. A knob to turn somewhere in Oracle, a switch to throw to enable some special behaviour.
    That is, and never was, performance tuning. Performance starts with the design of the system. It continues with the architecture used and implemented. And remains with every single line of code written.
    You do not pop Oracle's hood and rummage around in the engine, muck about with the fuel injectors, in order to get it to go faster. You design the application to use Oracle correctly. You implemented Oracle correctly. That is where performance start. Not with popping the hood.
    Messing with space management to make Oracle go faster? Messing with undocumented parameters? Changing process priorities? Supersizing this and that? That is a <b><font color="red">FAIL</font></b> as far as the correct software engineering approach to performance goes.

  • SGA size is 1 GB  free but oracle starts physical read/write,why ?

    Dear Friends ,
    In my production server I observe that it takes the the data from the HDD where my SGA is still 1 GB free .
    As far I know , In oracle , when the allocated SGA size is filled up then it reads the data from the HDD which is called "physical read/write " . I am using oracle 10g database . In performance tab(From Oracle 10g OEM) , when I see that oracle starts to read the physical data , at that moment I run the following query :
    select sum(bytes)/1024/1024 " SGA size used in MB"
    from v$sgastat
    where name!='free memory';
    and I found that still 1 GB memory are still free in the SGA .
    In this moment , I want to know , is it possible to start the physical read / write while the SGA size are still free ?
    Edited by: shipon_97 on Mar 24, 2009 10:45 AM

    shipon_97,
    Your understanding is wrong. From your previous posts it appears you never read the concepts manual.
    Begging on my knees PLEASE READ IT and stop asking doc questions.
    Sybrand Bakker
    Senior Oracle DBA

  • What causes BUFFER GETS and PHYSICAL READS in INSERT operation to be high?

    Hi All,
    Am performing a huge number of INSERTs to a newly installed Oracle XE 10.2.0.1.0 on Windows. There is no SELECT statement running, but just INSERTs one after the other of 550,000 in count. When I monitor the SESSION I/O from Home > Administration > Database Monitor > Sessions, I see the following stats:
    BUFFER GETS = 1,550,560
    CONSISTENT GETS = 512,036
    PHYSICAL READS = 3,834
    BLOCK CHANGES = 1,034,232
    The presence of 2 stats confuses. Though the operation is just INSERT in database for this session, why should there be BUFFER GETS of this magnitude and why should there by PHYSICAL READS. Aren't these parameters for read operations? The BLOCK CHANGES value is clear as there are huge writes and the writes change these many blocks. Can any kind soul explain me what causes there parameters to show high value?
    The total columns in the display table are as follows (from the link mentioned above)
    1. Status
    2. SID
    3. Database Users
    4. Command
    5. Time
    6. Block Gets
    7. Consistent Gets
    8. Physical Reads
    9. Block Changes
    10. Consistent Changes
    What does CONSISTENT GETS and CONSISTENT CHANGES mean in a typical INSERT operation? And does someone know which all tables are involved in getting these values?
    Thank,
    ...

    Flake wrote:
    Hans, gracias.
    The table just have 2 columns, both of which are varchar2 (500). No constraints, no indexes, neither foreign key references are in place. The total size of RAM in system is 1GB, and yes, there are other GUI's going on like Firefox browser, notepad and command terminals.
    But, what does these other applications have to do with Oracle BUFFER GETS, PHYSICAL READS etc.? Awaiting your reply.Total RAM is 1GB. If you let XE decide how much RAM is to be allocated to buffers, on startup that needs to be shared with any/all other applications. Let's say that leaves us with, say 400M for the SGA + PGA.
    PGA is used for internal stuff, such as sorting, which is also used in determing the layout of secondary facets such as indexes and uniqueness. Total PGA usage varies in size based on the number of connections and required operations.
    And then there's the SGA. That needs to cover the space requirement for the data dictionary, any/all stored procedures and SQL statements being run, user security and so on. As well as the buffer blocks which represent the tablespace of the database. Since it is rare that the entire tablespace will fit into memory, stuff needs to be swapped in and out.
    So - put too much space pressure on the poor operating system before starting the database, and the SGA may be squeezed. Put that space pressure on the system and you may enbd up with swapping or paging.
    This is one of the reasons Oracle professionals will argue for dedicated machines to handle Oracle software.

  • Consistent gets and physical reads

    Hi all,
    I am tuning a DM SQL query, by comparing execution plans with STAR TRANSFORMATION enabled or disabled. I got the following results:
    STAR TRANSFORMATION ON
    74889 consistent gets
    254365 physical reads
    STAR TRANSFORMATION OFF
    1945892 consistent gets
    168028 physical reads
    I thought a physical read would be counted as a logical read as well, because the data block would be read from disk (1 physical IO), placed in the buffer cache and then read from there (1 more logical IO or consistent get).
    So, one physical IO does not cause a logical IO?
    Thanks!
    Edited by: user10634835 on 12-Jul-2011 08:40

    But shouldn't consistent gets be >= physical reads (Since, as per my understanding, 1 PIO causes at least 1 LIO)? In this case it is not.
    74889 consistent gets
    254365 physical readsJust clarifying for my knowledge.
    regards

  • Query on data dictionary results in large number of physical reads

    I don't understand why I am getting 80,000 physicals for this query. I am not looking for help re-writing this. I just don't understand why I would hit the disk at all.
    My understanding had been that v$views where sql structures that pointed to x$tables. These x$tables are sql structures.
    underneath, the x$tables were linked lists stored in memory. This is why when you bounce the database, all the data, gets reset. Since it is not saved to disk.
    I am doing a simple insert/select off of v$open_cursor that is resulting in 80,000+ physical reads. I am posting the tkprof. It is all from v$open_cursor.
    mysid_table has 6 records. It is 1 mb in size
    if I index mysid_table.sid the query reduces to 20,000 physical reads. (but all the physical reads are on v$session_event)
    the sequence number I am passing returns 2 SIDs
    insert into my_save_table
    select *
    from v$session_event
    where sid in (select sid
      from my_sid_table
    where id = vseq);
    vrowcount := sql%rowcount;
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.01          0          0          0           0
    Execute      1     31.70      47.57      88570         22          0           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2     31.71      47.58      88570         22          0           1
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 22 
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      latch: row cache objects                        1        0.00          0.00
      log file sync                                   1        0.00          0.00
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        0.00          0.00
    ********************************************************************************

    It seems like there is some missing information.
    You have a wait for a log file sync, but no commit.
    Your table my_sid_table is 1 MB for only 6 records?
    Does the target table you are inserting into (my_save_table) have indexes on it?

  • High no. of physical reads of a query in statspack report

    we have a Oracle database 9.2.0.6 on solaris box....
    SQL ordered by Reads for DB: ic  Instance: ic12  Snaps: 19 -20
    -> End Disk Reads Threshold:      1000
                                                         CPU      Elapsd
    Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
          1,103,253           77       14,328.0   53.1  1641.98  11428.17 3825541888
    Module: w3wp.exe
    select  MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX, trim
    ((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as M
    EMNAME, decode(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')
    AS ACA_FCA, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
    MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_Pexplain plan
    SQL> explain plan for select  MRH_MRN,DECODE(MRH_SEX,'M','MALE','FEMALE') AS SEX
    , trim((mrh_sur_name||' '||mrh_first_name||' '||mrh_middle_name)) as MEMNAME, de
    code(nvl(mrh_fellow_status_yn,'333'),'Y','FCA','ACA')AS ACA_FCA, DECODE(MRH_RESI
    _STATUS,'I',MRH_PROF_ADDR_LINE_1,'A',
      2  MRH_RES_ADDR_LINE_1) AS L_ADD1, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADDR_LI
    NE_2,'A',MRH_RES_ADDR_LINE_2) AS L_ADD2, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ADD
    R_LINE_3,'A',MRH_RES_ADDR_LINE_3) ASL_ADD3, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_
    ADDR_LINE_4,'A',
      3  MRH_RES_ADDR_LINE_4) AS L_ADD4, DECODE(MRH_RESI_STATUS,'I',a.city_name,'A',
    C.CITY_NAME) AS L_CITY, DECODE(MRH_RESI_STATUS,'I',MRH_PROF_ZIP_POSTAL_CODE,'A',
    MRH_RES_ZIP_POSTAL_CODE) AS L_PIN, DECODE(MRH_RESI_STATUS,'I',b.cou_name,'A',D.C
    OU_NAME) as L_Country,
      4  DECODE(MRH_RESI_STATUS,'I','NOT APPLICABLE',MRH_PROF_ADDR_LINE_1)AS R_ADD1,
    DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_2)AS R_ADD2, DECODE(MRH_RESI_
    STATUS,'I',' ',MRH_PROF_ADDR_LINE_3)
      5  AS R_ADD3, DECODE(MRH_RESI_STATUS,'I',' ',MRH_PROF_ADDR_LINE_4)AS R_ADD4, D
    ECODE(MRH_RESI_STATUS,'I',' ','A',A.CITY_NAME) AS R_CITY, DECODE(MRH_RESI_STATUS
    ,'I',' ','A',MRH_PROF_ZIP_POSTAL_CODE) AS R_PIN, DECODE(MRH_RESI_STATUS,'I',' ',
    'A',B.COU_NAME) as
      6  R_Country, decode(nvl(mrh_mem_sub_status,'555'),'26','EXPIRED','') as sub_s
    tatus, decode(nvl(mrh_mem_status,'777'),'1','ACTIVE','2','REMOVED') as mem_statu
    s,mrh_resi_status, DECODE(MRH_COP_STATUS,'1',DECODE(MRH_COP_TYPE ,'13','FULLTIME
    -COP','1',
      7  'FULLTIME-COP', '12','PARTTIME-COP','2','PARTTIME-COP'),'NOT HOLDING COP')
    AS COP_STATUS, TO_CHAR(MRH_ENROL_DT,'RRRR') AS ASSO_YR,TO_CHAR(MRH_FELLOW_DT,'RR
    RR') AS FELLOW_YR from om_mem_reg_head,om_city A,
      8  om_country B,om_city C,om_country D  where  mrh_doc_status=5  and mrh_prof_
    city_code=A.City_code(+) and mrh_prof_cou_code=B.cou_code(+)  and mrh_res_city_c
    ode=C.City_code(+) and mrh_res_cou_code=D.cou_code(+) and trim((mrh_sur_name||'
    '||mrh_first_name||
      9  ''||mrh_middle_name)) like upper('%%')  ORDER BY trim((mrh_sur_name||' '||m
    rh_first_name||' '||mrh_middle_name))
    10  ;
    Explained.
    SQL> select * from table(dbms_xplan.displaY());
    PLAN_TABLE_OUTPUT
    | Id  | Operation              |  Name            | Rows  | Bytes |TempSpc| Cost
      |
    |   0 | SELECT STATEMENT       |                  |  2870 |   762K|       |  202
    PLAN_TABLE_OUTPUT
    8 |
    |   1 |  SORT ORDER BY         |                  |  2870 |   762K|  1592K|  202
    8 |
    |   2 |   NESTED LOOPS OUTER   |                  |  2870 |   762K|       |  190
    2 |
    |   3 |    NESTED LOOPS OUTER  |                  |  2870 |   714K|       |  190
    2 |
    PLAN_TABLE_OUTPUT
    |   4 |     HASH JOIN OUTER    |                  |  2870 |   667K|       |  190
    2 |
    |   5 |      HASH JOIN OUTER   |                  |  2870 |   616K|       |  189
    2 |
    |   6 |       TABLE ACCESS FULL| OM_MEM_REG_HEAD  |  2870 |   566K|       |  188
    2 |
    |   7 |       TABLE ACCESS FULL| OM_COUNTRY       |   677 | 12186 |       |
    4 |
    PLAN_TABLE_OUTPUT
    |   8 |      TABLE ACCESS FULL | OM_COUNTRY       |   677 | 12186 |       |
    4 |
    |   9 |     INDEX UNIQUE SCAN  | CITY_CODE_PK     |     1 |    17 |       |
      |
    |  10 |    INDEX UNIQUE SCAN   | CITY_CODE_PK     |     1 |    17 |       |
      |
    PLAN_TABLE_OUTPUT
    Note: cpu costing is off, PLAN_TABLE' is old version
    18 rows selected.
    SQL>Please suggest me whjat cab done to overcome the same
    Edited by: user00726 on Feb 3, 2009 5:03 AM

    SQL> show arraysize
    arraysize 15
    SQL>should i set SDU parameter in tnsnames and listener.ora
    for more info related to the same...pls do visit the below thread:
    n/w perfromance related problem                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Query tuning-how to reduce physical reads-help me

    1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%' order by Invoice asc
    SQL> /
    33 rows selected.
    Elapsed: 00:00:00.34
    Execution Plan
    Plan hash value: 352896138
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 16 | 6304 | 341 (3)| 00:00:05 |
    | 1 | SORT ORDER BY | | 16 | 6304 | 341 (3)| 00:00:05 |
    | 2 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 48 | 2 (0)| 00:00:01
    | 3 | NESTED LOOPS | | 16 | 6304 | 340 (3)| 00:00:05 |
    | 4 | NESTED LOOPS | | 16 | 5536 | 316 (3)| 00:00:04 |
    |* 5 | HASH JOIN OUTER | | 16 | 5168 | 308 (3)| 00:00:04 |
    |* 6 | HASH JOIN | | 16 | 4992 | 302 (3)| 00:00:04 |
    |* 7 | HASH JOIN | | 16 | 4752 | 298 (3)| 00:00:04 |
    | 8 | NESTED LOOPS | | 17 | 4828 | 44 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 17 | 3451 | 35 (0)| 00:00:01 |
    | 10 | NESTED LOOPS OUTER | | 1 | 91 | 2 (0)| 00:00:01 |
    | 11 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 74 | 1 (0)| 00:00:01 |
    |* 12 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
    | 13 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 29495 | 1 (0)| 00:00:01 |
    |* 14 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
    |* 15 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 17 | 1904 | 33 (0)| 00:00:01 |
    |* 16 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
    | 17 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 81 | 1 (0)| 00:00:01 |
    |* 18 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
    | 19 | VIEW | | 35844 | 455K| 254 (3)| 00:00:04 |
    | 20 | HASH GROUP BY | | 35844 | 455K| 254 (3)| 00:00:04 |
    | 21 | TABLE ACCESS FULL | CONTACT | 56100 | 712K| 250 (1)| 00:00:03 |
    | 22 | VIEW | index$_join$_009 | 7 | 105 | 3 (0)| 00:00:01 |
    |* 23 | HASH JOIN | | | | | |
    | 24 | INDEX FAST FULL SCAN | IDX_PAYMENTTERMSID | 7 | 105 | 1 (0)| 00:00:01
    | 25 | INDEX FAST FULL SCAN | PK_PAYMENTTERMS | 7 | 105 | 1 (0)| 00:00:01
    | 26 | VIEW | index$_join$_011 | 1428 | 15708 | 6 (0)| 00:00:01 |
    |* 27 | HASH JOIN | | | | | |
    | 28 | INDEX FAST FULL SCAN | PK_EMPLOYEE | 1428 | 15708 | 3 (0)| 00:00:01 |
    | 29 | INDEX FAST FULL SCAN | IDX_EMPLOYEEEMPLOYEEID | 1428 | 15708 | 3 (0)| 00:00:01
    | 30 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 23 | 1 (0)| 00:00:
    |* 31 | INDEX UNIQUE SCAN | PK_CONTACT | 1 | | 1 (0)| 00:00:01 |
    |* 32 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
    12 - access("B"."SITEIID"=300964)
    14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
    16 - access("A"."SITEIID"=300964)
    18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    23 - access(ROWID=ROWID)
    27 - access(ROWID=ROWID)
    31 - access("F"."CONTACTIID"="G"."CONTACTIID")
    32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    Statistics
    107 recursive calls
    0 db block gets
    2819 consistent gets
    0 physical reads
    0 redo size
    6586 bytes sent via SQL*Net to client
    356 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    33 rows processed
    SQL> ed
    Wrote file afiedt.buf
    1* select * from masterbillingInvoiceview Where SiteIID =300964 and InvoiceID like '%%%' order by Invoice asc
    SQL> /
    33 rows selected.
    Elapsed: 00:06:15.23
    Execution Plan
    Plan hash value: 1828716447
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 964 | 295 (3)| 00:00:04 |
    |* 1 | FILTER | | | | | |
    | 2 | SORT GROUP BY | | 2 | 964 | 295 (3)| 00:00:04 |
    | 3 | MERGE JOIN CARTESIAN | | 72315 | 33M| 291 (1)| 00:00:04 |
    | 4 | TABLE ACCESS BY INDEX ROWID | ADDRESS | 1 | 52 | 2 (0)| 00:00:01 |
    | 5 | NESTED LOOPS | | 1 | 447 | 41 (0)| 00:00:01 |
    | 6 | NESTED LOOPS | | 1 | 395 | 40 (0)| 00:00:01 |
    | 7 | NESTED LOOPS | | 1 | 382 | 38 (0)| 00:00:01 |
    | 8 | NESTED LOOPS OUTER | | 1 | 289 | 37 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 1 | 266 | 36 (0)| 00:00:01 |
    | 10 | NESTED LOOPS | | 1 | 239 | 35 (0)| 00:00:01 |
    | 11 | NESTED LOOPS OUTER | | 1 | 115 | 2 (0)| 00:00:01 |
    | 12 | TABLE ACCESS BY INDEX ROWID| SITEMASTER | 1 | 86 | 1 (0)| 00:00:01 |
    |* 13 | INDEX UNIQUE SCAN | PK_SITEMASTER | 1 | | 1 (0)| 00:00:01 |
    | 14 | TABLE ACCESS BY INDEX ROWID| INVGROUPS | 1735 | 50315 | 1 (0)| 00:00:01 |
    |* 15 | INDEX UNIQUE SCAN | PK_INVGROUPS | 1 | | 1 (0)| 00:00:01 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | INVOICEHEAD | 1 | 124 | 33 (0)| 00:00:01 |
    |* 17 | INDEX RANGE SCAN | IDX_INVOICEHEADSITEIID | 271 | | 1 (0)| 00:00:01 |
    | 18 | TABLE ACCESS BY INDEX ROWID | PAYMENTTERMS | 1 | 27 | 1 (0)| 00:00:01 |
    |* 19 | INDEX UNIQUE SCAN | PK_PAYMENTTERMS | 1 | | 1 (0)| 00:00:01 |
    | 20 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 1 | 23 | 1 (0)| 00:00:01 |
    |* 21 | INDEX UNIQUE SCAN | PK_EMPLOYEE | 1 | | 1 (0)| 00:00:01 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1 | 93 | 1 (0)| 00:00:01 |
    |* 23 | INDEX UNIQUE SCAN | PK_CUSTOMER | 1 | | 1 (0)| 00:00:01 |
    | 24 | TABLE ACCESS BY INDEX ROWID | CONTACT | 1 | 13 | 2 (0)| 00:00:01 |
    |* 25 | INDEX RANGE SCAN | IDX_CONTACTCUSTOMERIID | 2 | | 1 (0)| 00:00:01 |
    |* 26 | INDEX RANGE SCAN | PK_ADDRESS | 1 | | 1 (0)| 00:00:01 |
    | 27 | BUFFER SORT | | 56100 | 1917K| 294 (3)| 00:00:04 |
    | 28 | TABLE ACCESS FULL | CONTACT | 56100 | 1917K| 250 (1)| 00:00:03 |
    Predicate Information (identified by operation id):
    1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
    13 - access("B"."SITEIID"=300964)
    15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
    17 - access("A"."SITEIID"=300964)
    19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
    filter("CUSTOMERIID" IS NOT NULL)
    26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    Statistics
    1952 recursive calls
    78 db block gets
    4649 consistent gets
    236151 physical reads
    0 redo size
    6586 bytes sent via SQL*Net to client
    356 bytes received via SQL*Net from client
    4 SQL*Net roundtrips to/from client
    1 sorts (memory)
    1 sorts (disk)
    33 rows processed
    this is the execution plan of my one query with a small difference, bt there is large diffference in physical reads..
    can anyone help me out of this
    thanks
    aju

    Hi,
    Can you please format your explain plan using
    { code } --without space
    Explain plan
    { code } -- without any space
    What is your DB version?
    There are differences in access and filter criteria...
    -- FRIST QUERY
    5 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    6 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    7 - access("D"."CUSTOMERIID"="F"."CUSTOMERIID")
    12 - access("B"."SITEIID"=300964)
    14 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    15 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%')
    16 - access("A"."SITEIID"=300964)
    18 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    23 - access(ROWID=ROWID)
    27 - access(ROWID=ROWID)
    31 - access("F"."CONTACTIID"="G"."CONTACTIID")
    32 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))
    ------SECOND QUERY
    1 - filter("G"."CONTACTIID"=MAX("CONTACTIID"))
    13 - access("B"."SITEIID"=300964)
    15 - access("B"."PARENTIID"="I"."GROUPIID"(+))
    16 - filter("A"."TYPE"=4 AND "A"."INVOICEID" LIKE '%%%')
    17 - access("A"."SITEIID"=300964)
    19 - access("A"."TERMSIID"="H"."PAYMENTTERMSIID")
    21 - access("A"."CREATEDBY"="J"."EMPIID"(+))
    23 - access("A"."BILLINGCUSTOMERIID"="D"."CUSTOMERIID")
    25 - access("D"."CUSTOMERIID"="CUSTOMERIID")
    filter("CUSTOMERIID" IS NOT NULL)
    26 - access("E"."ADDRESSIID"=NVL("D"."BILLINGADDRESSIID","D"."ADDRESSIID"))-Avinash

  • Oracle 9i Performance Issue High Physical Reads

    Dear All,
    I have Oracle 9i Release 9.2.0.5.0 database under HP Unix, I have run the query and got following output. Can any body just have a look and advise what to do in the following situation? We have performance issues.
    Many thanks in advance
    Buffer Pool Advisory for DB: DBPR Instance: DBPR End Snap: 902
    -> Only rows with estimated physical reads >0 are displayed
    Size for Size Buffers for Est Physical Estimated
    P Estimate (M) Factr Estimate Read Factor Physical Reads
    D 416 .1 51,610 4.27 1,185,670,652
    D 832 .2 103,220 2.97 825,437,374
    D 1,248 .3 154,830 2.03 563,139,985
    D 1,664 .4 206,440 1.49 412,550,232
    D 2,080 .5 258,050 1.32 366,745,510
    D 2,496 .6 309,660 1.23 340,820,773
    D 2,912 .7 361,270 1.14 317,544,771
    D 3,328 .8 412,880 1.09 301,680,173
    D 3,744 .9 464,490 1.04 288,191,418
    D 4,096 1.0 508,160 1.00 276,929,627

    Hi,
    Actually you didnt give the exact problem statement.
    Seems to be your database is I/O bound. Ok, do the following one by one:
    1. Identify the FTS queries and try to create the optimal indexes (depending on the disk reads factor!!) on the problem queries.
    2. To reduce the 276M physical reads, you need to allocate more memory to db_cache_size. try 8GB (initially) and then depending on the buffer advisery you can increase further if you have more memory on the box.
    3. as a Next step , configure KEEP and RECYCLE cache to get the benefits of reduced I/O by multiple pools. Allocate objects to the KEEP/RECYCLE pools.
    Thanks,

  • Hint or parameter to force physical read

    I am using  Oracle 11.2.0.3. I have a query which took 45 minute the first time and it take 4 minutes in subsequent run  in QC environment. In both the cases it uses same plan. If I try the query again in few days , first time it takes considerable amount of time.Most of the wait is in range index scan - 'db file parallel read'
    Same query runs within 2 minutes in lower environment with different plan. I have used  hint to make the plan same in QC environment. Now query runs as expected but I suspect it might slow down if the data is not cached. I do not have access to  alter system flush buffer cache privilege.
    Is there any  hint or parameter I can use force physical read?
    Which view will tell me if a table is still cached in memory?

    spur230 wrote:
    <snip>
    Which view will tell me if a table is still cached in memory?
    v$bh will tell you what blocks of an object are cached:
    orcla> select file#,block#,status from v$bh where objd=(select data_object_id
      2  from dba_objects where owner='SCOTT' and objecT_name='DEPT');
    no rows selected
    orcla> select * from scott.dept;
        DEPTNO DNAME          LOC
            10 ACCOUNTING     NEW YORK
            20 RESEARCH       DALLAS
            30 SALES          CHICAGO
            40 OPERATIONS     BOSTON
    orcla> select file#,block#,status from v$bh where objd=(select data_object_id
      2  from dba_objects where owner='SCOTT' and objecT_name='DEPT');
         FILE#     BLOCK# STATUS
             4        131 xcur
             4        134 xcur
             4        132 xcur
             4        135 xcur
             4        130 xcur
             4        133 xcur
    6 rows selected.
    orcla>
    but you do need to be aware of the status. There may be several versions of a block cached.

  • Physical reads

    I 'm running the same query against two databases on two different servers, and not seeing the expected results.
    Query runs in 6 seconds on server A, and 32 seconds on server B. The database on B is a copy of the database on A, same blocksize, same db_file_multiblock_read_count.
    Query is:
    SELECT
    IMS_BO_PMAN08.REF_ID,( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
    decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
    decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure')
    FROM
    IMS_BO_PMAN08,
    IMS_BO_PMAN08_TRAN
    WHERE
    ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID )
    AND ( IMS_BO_PMAN08.VERSION_ID IN (select version_id from ims_bo_version where version_id = 1 ) )
    AND ( IMS_BO_PMAN08.INV_REGION_CODE > 2 )
    and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') ='Actual'
    GROUP BY
    IMS_BO_PMAN08.REF_ID,decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
    decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC Expenditure','V','ACQ Expenditure');
    I am seeing the same execution plan when running the query against either database, with the same cost in each case. However, the physical reads on server B is ten times that of on server A
    Server A
    =====
    293851 rows selected.
    Elapsed: 00:00:06.58
    Execution Plan
    0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50270 Card=27811 Bytes=973385)
    1 0 SORT (GROUP BY) (Cost=50270 Card=27811 Bytes=973385)
    2 1 HASH JOIN (Cost=50088 Card=27811 Bytes=973385)
    3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17990 Card=26243 Bytes=446131)
    4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26243)
    5 2 NESTED LOOPS (Cost=32049 Card=107258 Bytes=1930644)
    6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
    7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32048 Card=107258 Bytes=1716128)
    Statistics
    0 recursive calls
    13 db block gets
    288529 consistent gets
    *18,218 physical reads*
    0 redo size
    17924295 bytes sent via SQL*Net to client
    2174914 bytes received via SQL*Net from client
    19592 SQL*Net roundtrips to/from client
    0 sorts (memory)
    1 sorts (disk)
    293851 rows processed
    Server B
    =====
    292677 rows selected.
    Elapsed: 00:00:32.66
    Execution Plan
    0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=50255 Card=27805 Bytes=973175)
    1 0 SORT (GROUP BY) (Cost=50255 Card=27805 Bytes=973175)
    2 1 HASH JOIN (Cost=50073 Card=27805 Bytes=973175)
    3 2 TABLE ACCESS (BY INDEX ROWID) OF 'IMS_BO_PMAN08' (Cost=17984 Card=26237 Bytes=446029)
    4 3 INDEX (RANGE SCAN) OF 'IMS_BO_PMAN08_IX1' (UNIQUE) (Cost=105 Card=26237)
    5 2 NESTED LOOPS (Cost=32040 Card=107230 Bytes=1930140)
    6 5 INDEX (UNIQUE SCAN) OF 'IMS_BO_VERSION_IX1' (UNIQUE)
    7 5 TABLE ACCESS (FULL) OF 'IMS_BO_PMAN08_TRAN' (Cost=32039 Card=107230 Bytes=1715680)
    Statistics
    0 recursive calls
    357 db block gets
    250918 consistent gets
    *188,332 physical reads*
    0 redo size
    17853447 bytes sent via SQL*Net to client
    2166145 bytes received via SQL*Net from client
    19513 SQL*Net roundtrips to/from client
    0 sorts (memory)
    1 sorts (disk)
    292677 rows processed
    8.1.6.3 on solaris 8
    Can anyone tell me where the excessive physical i/o's (and presumably associated runtime) is coming from? Any pointers much appreciated.
    Pete
    Edited by: user12248598 on 17-Mar-2010 09:01

    sort_area_size, sort_area_retained_size & hash_area_size are the same size for both instances, as are all NLS settings.
    Tables are not specified NOCACHE, and there are no additional buffer pools.
    Running with sql_trace enabled for both queries highlighed some very interesting results:
    For the slow query, this is the tkprof output, unfortunately waits=yes is not available in 8.1.6
    TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:54:18 2010
    (c) Copyright 1999 Oracle Corporation.  All rights reserved.
    Trace file: imsroc_ora_10166.trc
    Sort options: default
    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 events '10046 trace name context forever, level 8'
    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 goal: FIRST_ROWS
    Parsing user id: 5
    BEGIN DBMS_APPLICATION_INFO.SET_MODULE(:1,NULL); END;
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.01       0.01          0          0          0           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.01       0.01          0          0          0           1
    Misses in library cache during parse: 1
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5
    SELECT
      IMS_BO_PMAN08.REF_ID,
       ( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
         decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
    ','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
    tions','F','FC Expenditure','V','ACQ Expenditure')
    FROM
      bo_ims.IMS_BO_PMAN08,
      bo_ims.IMS_BO_PMAN08_TRAN
    WHERE  ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID  )
      AND  ( IMS_BO_PMAN08.VERSION_ID IN (select  version_id from bo_ims.ims_bo_version where version_id =
    1 ) )
        AND  ( IMS_BO_PMAN08.INV_REGION_CODE > 2  )
        and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
    GROUP BY
      IMS_BO_PMAN08.REF_ID,
        decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup
    ','S','SOS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Comple
    tions','F','FC Expenditure','V','ACQ Expenditure')
    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    16278     15.36      36.39     215625     251560        361      244156
    total    16280     15.36      36.39     215625     251560        361      244156
    Misses in library cache during parse: 0
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.00       0.00          0          0          0           0
    Execute      3      0.01       0.01          0          0          0           1
    Fetch    16278     15.36      36.39     215625     251560        361      244156
    total    16283     15.37      36.40     215625     251560        361      244157
    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
        3  user  SQL statements in session.
        0  internal SQL statements in session.
        3  SQL statements in session.
    Trace file: imsroc_ora_10166.trc
    Trace file compatibility: 8.00.04
    Sort options: default
           2  sessions in tracefile.
           5  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           3  SQL statements in trace file.
           3  unique SQL statements in trace file.
       75998  lines in trace file.And this is the tkprof formatted output for the faster running query:
    TKPROF: Release 8.1.6.3.0 - Production on Tue Mar 23 14:56:28 2010
    (c) Copyright 1999 Oracle Corporation.  All rights reserved.
    Trace file: imslive_ora_7489.trc
    Sort options: default
    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 events '10046 trace name context forever, level 8'
    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 goal: FIRST_ROWS
    Parsing user id: 5
    SELECT
      IMS_BO_PMAN08.REF_ID,
       ( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
         decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_00,:SYS_B_01,:SYS_B_02,:SYS_B_03),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_04,:SYS_B_05,:SYS_B_06,:SYS_B_07,:SYS_B_08,:SYS_B_09,:SYS_B_10,:
    SYS_B_11,:SYS_B_12,:SYS_B_13,:SYS_B_14,:SYS_B_15,:SYS_B_16,:SYS_B_17,:SYS_B_18,:SYS_B_19,:SYS_B_20,:SYS_B_21,:
    SYS_B_22,:SYS_B_23)
    FROM
      BO_IMS.IMS_BO_PMAN08,
      BO_IMS.IMS_BO_PMAN08_TRAN
    WHERE  ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID  )
      AND  ( IMS_BO_PMAN08.VERSION_ID IN (select  version_id from bo_ims.ims_bo_version where version_id = :SYS_B_
    24 ) )
        AND  ( IMS_BO_PMAN08.INV_REGION_CODE > :SYS_B_25  )
        and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_26,:SYS_B_27,:SYS_B_28,:SYS_B_29) = :SYS_B_30
    GROUP BY
      IMS_BO_PMAN08.REF_ID,
        decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,:SYS_B_31,:SYS_B_32,:SYS_B_33,:SYS_B_34),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,:SYS_B_35,:SYS_B_36,:SYS_B_37,:SYS_B_38,:SYS_B_39,:SYS_B_40,:SYS_B_41,:
    SYS_B_42,:SYS_B_43,:SYS_B_44,:SYS_B_45,:SYS_B_46,:SYS_B_47,:SYS_B_48,:SYS_B_49,:SYS_B_50,:SYS_B_51,:SYS_B_52,:
    SYS_B_53,:SYS_B_54)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch    20042      0.00       0.00      20064     295221         13      300608
    total    20045      0.00       0.00      20064     295221         13      300608
    Misses in library cache during parse: 1
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5
    Rows     Row Source Operation
    300608  SORT GROUP BY
    300628   NESTED LOOPS
      55647    NESTED LOOPS
          2     INDEX UNIQUE SCAN (object id 151050)
      55647     TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08
      55649      INDEX RANGE SCAN (object id 185149)
    300628    TABLE ACCESS BY INDEX ROWID IMS_BO_PMAN08_TRAN
    356274     INDEX RANGE SCAN (object id 157241)
    DELETE FROM PLAN_TABLE
    WHERE
    STATEMENT_ID=:1
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          3          5         12           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          3          5         12           0
    Misses in library cache during parse: 1
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5
    Rows     Row Source Operation
          1  DELETE PLAN_TABLE
          1   TABLE ACCESS FULL PLAN_TABLE
    EXPLAIN PLAN SET STATEMENT_ID='PLUS18028884' FOR SELECT
      IMS_BO_PMAN08.REF_ID,
       ( sum(IMS_BO_PMAN08_TRAN.MONTH_13_APR) ) + ( sum(IMS_BO_PMAN08_TRAN.MONTH_14_MAY) ) ,
         decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
    OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
    xpenditure','V','ACQ Expenditure')
    FROM
      BO_IMS.IMS_BO_PMAN08,
      BO_IMS.IMS_BO_PMAN08_TRAN
    WHERE  ( IMS_BO_PMAN08.PROG_MAN_ID=IMS_BO_PMAN08_TRAN.PROG_MAN_ID  )
      AND  ( IMS_BO_PMAN08.VERSION_ID IN (select  version_id from bo_ims.ims_bo_version where version_id = 1 ) )
        AND  ( IMS_BO_PMAN08.INV_REGION_CODE > 2  )
        and decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast') = 'Actual'
    GROUP BY
      IMS_BO_PMAN08.REF_ID,
        decode(IMS_BO_PMAN08_TRAN.TRANS_SUB_TYPE,'A','Actual','F','Forecast'),
      decode(IMS_BO_PMAN08_TRAN.TRANS_TYPE,'E','Expenditure','U','Unit completions','A','Allocation Takeup','S','S
    OS units','T','SOS Expenditure','G','Grant Claim Units','H','Larger Homes','C','FC Unit Completions','F','FC E
    xpenditure','V','ACQ Expenditure')
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      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        1      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 1
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5
    insert into plan_table (statement_id, timestamp, operation, options,
      object_node, object_owner, object_name, object_instance, object_type,
      search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
       bytes, other_tag, partition_start, partition_stop, partition_id,
      distribution )
    values
    (:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
      :20,:21,:22)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      7      0.00       0.00          1          3          9           7
    Fetch        0      0.00       0.00          0          0          0           0
    total        8      0.00       0.00          1          3          9           7
    Misses in library cache during parse: 1
    Optimizer goal: FIRST_ROWS
    Parsing user id: 5     (recursive depth: 1)
    select o.name, u.name
    from
    sys.obj$ o, sys.user$ u where obj# = :1and owner# = user#
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      2      0.00       0.00          0          0          0           0
    Fetch        2      0.00       0.00          3         12          0           2
    total        5      0.00       0.00          3         12          0           2
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: SYS   (recursive depth: 1)
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        3      0.00       0.00          0          0          0           0
    Execute      4      0.00       0.00          3          5         12           0
    Fetch    20042      0.00       0.00      20064     295221         13      300608
    total    20049      0.00       0.00      20067     295226         25      300608
    Misses in library cache during parse: 3
    Misses in library cache during execute: 1
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.00       0.00          0          0          0           0
    Execute      9      0.00       0.00          1          3          9           7
    Fetch        2      0.00       0.00          3         12          0           2
    total       13      0.00       0.00          4         15          9           9
    Misses in library cache during parse: 2
        5  user  SQL statements in session.
        1  internal SQL statements in session.
        6  SQL statements in session.
    Trace file: imslive_ora_7489.trc
    Trace file compatibility: 8.00.04
    Sort options: default
           3  sessions in tracefile.
           8  user  SQL statements in trace file.
           1  internal SQL statements in trace file.
           6  SQL statements in trace file.
           6  unique SQL statements in trace file.
       77410  lines in trace file.The sql statement as run did not make use of bind variables, so the ones in the tkprof output for the longer running statement made me immediately think of cursor sharing, and right there in the init.ora for the faster running database was CURSOR_SHARING=FORCE.
    I'm not familiar with the history of the databases, nor the specific reasoning for enabling cursor sharing (bind variable usage seems prevalent in all custom code) so I've replicated the setting on the slower database, resulting in a similar tkprof output to the faster server, with a runtime of 7 seconds for 2nd and subsequent runs.
    My immediate issue is now solved, thanks to all who contributed, and apologies for not spotting the obvious earlier.
    Regards, Pete

  • No of physical reads of buffers from disk on PROD and Clone has huge differ

    Please help !
    I am having a problem interpreting a tkprof report.
    I am executing the same statement below in PROD and Clone of PROD.
    What I do not understand why the tkprof report shows huge difference in disk reads for same executions from PROD and Clone of PROD. I.e. first execution disk reads = 757187 , second = 6.
    I expected to see Similar disk reads in the second execution also.The data it fetches is same in both the Instances.
    Statment
    SELECT NVL(SUM(RG_OTH.DEBIT),0),NVL(SUM(RG_OTH.CREDIT),0)
    FROM
    JA_IN_PLA PLA,JAI_RG_OTHERS RG_OTH,HR_ALL_ORGANIZATION_UNITS HOU,
    HR_LOCATIONS LOC,JA_IN_HR_ORGANIZATION_UNITS HR_ORG WHERE 1 = 1 AND
    PLA.ORGANIZATION_ID = :b1 AND TRUNC(PLA.CREATION_DATE) >= :b2 AND
    TRUNC(PLA.CREATION_DATE) <= :b3 AND HOU.ORGANIZATION_ID =
    PLA.ORGANIZATION_ID AND LOC.LOCATION_ID = PLA.LOCATION_ID AND
    HR_ORG.ORGANIZATION_ID = PLA.ORGANIZATION_ID AND HR_ORG.LOCATION_ID =
    PLA.LOCATION_ID AND TRANSACTION_ID = 19 AND INVENTORY_ITEM_ID != 0 AND
    NVL(ROUNDING_ID,1) != -1 AND RG_OTH.SOURCE_REGISTER_ID = PLA.REGISTER_ID
    AND RG_OTH.SOURCE_REGISTER = 'PLA' AND RG_OTH.TAX_TYPE IN (
    'EXCISE_EDUCATION_CESS' )
    Tkproff from PROD.
    call count cpu elapsed disk query current rows
    Parse 1 0.01 0.01 0 0 0 0
    Execute 1 0.04 0.03 0 0 0 0
    Fetch 1 973.41 1724.95 757187 789442 0 1
    total 3 973.46 1725.01 757187 789442 0 1
    Tkproff from CLONE of PROD.
    call count cpu elapsed disk query current rows
    Parse 1 0.06 0.05 1 789 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 0.73 0.72 6 30594 0 1
    total 3 0.79 0.78 7 31383 0 1

    wins wrote:
    SELECT NVL(SUM(RG_OTH.DEBIT),0),NVL(SUM(RG_OTH.CREDIT),0)  
    FROM
    JA_IN_PLA PLA,JAI_RG_OTHERS RG_OTH,HR_ALL_ORGANIZATION_UNITS HOU,
    HR_LOCATIONS LOC,JA_IN_HR_ORGANIZATION_UNITS HR_ORG  WHERE 1 = 1  AND
    PLA.ORGANIZATION_ID = :b1  AND TRUNC(PLA.CREATION_DATE) >= :b2  AND
    TRUNC(PLA.CREATION_DATE) <= :b3  AND HOU.ORGANIZATION_ID =
    PLA.ORGANIZATION_ID  AND LOC.LOCATION_ID = PLA.LOCATION_ID  AND
    HR_ORG.ORGANIZATION_ID = PLA.ORGANIZATION_ID  AND HR_ORG.LOCATION_ID =
    PLA.LOCATION_ID  AND TRANSACTION_ID = 19  AND INVENTORY_ITEM_ID != 0  AND
    NVL(ROUNDING_ID,1) != -1  AND RG_OTH.SOURCE_REGISTER_ID = PLA.REGISTER_ID 
    AND RG_OTH.SOURCE_REGISTER = 'PLA'  AND RG_OTH.TAX_TYPE IN (
    'EXCISE_EDUCATION_CESS'  )
    Tkproff from PROD.
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.01          0          0          0           0
    Execute      1      0.04       0.03          0          0          0           0
    Fetch        1    973.41    1724.95     757187     789442          0           1
    total        3    973.46    1725.01     757187     789442          0           1
    Tkproff from CLONE of PROD.
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.06       0.05          1        789          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.73       0.72          6      30594          0           1
    total        3      0.79       0.78          7      31383          0           1
    As others have pointed out, this looks like a change in execution plan. At a guess, the PROD database is doing a tablescan somewhere (physical reads is approximately equal to logical reads is a pointer).
    There are many reasons why this could happen, continuing with the guesswork - we note that the statement was re-optimised (hard parsed) in the clone, but used an existing cursor in production (logical I/O = 0 in prod, 789 in clone). So the plan you got in the clone was the one that Oracle thought best for the inputs you had supplied. The plan in prod could have been produced as the response to a completely different set of input; since you have two bind variables applied to a range based predicated and one bind variable with equality it's possible that you have a histogram that makes a difference on the equality column, alternatively the range of dates used to generate the original plan was very different from the range used in the test.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Author: <b><em>Oracle Core</em></b>

  • Logical reads VS physical reads

    hello all,
    What is the difference between logical reads and physical read ??? I do get the part of logical read (from buffer) and physical read(from disk). And also do know physical reads are bad, but is it true in oracle world..logical reads are bad ??? if so why ??? Could you please explain which on to look for. As i am going thru AWR report and i see segemts by logical/physical read.

    The first and foremost difference is that physcial reads are done from the hard disk. And this is always going tobe slwoer than the memory. That's why its said that the physcial ios must be removed. Logical ios are good as they are done from the memory.The theory that logical are also not good is because the logical ios require the access given by latches. So with lots of the gets for the latches put them in to contention and latch contention would make the access to the logical io slower.So its better to do this in less IO even they are logical too.
    Lots of logical IOs probably mean that you are accessing unnecessary data which may be not required.
    HTH
    Aman....

  • High user input output (I/O) and physical reads

    Hi guys
    Recently we have noticed that our database performance degraded significantly. as we looked around in grid control we noticed that the user IO and Physical reads are really high which cause the database to be laggy.
    at first we thought it was memory problem, so we added 2gb to sga. we have set sga to be automatic and it's been like this for the past 2 years.
    how do i trouble shoot this problem. i haven't found any troubleshooting guide for it yet.
    please instruct me on how to solve it
    database: 10.2.0.4 sparc
    regards
    Sina

    Top 5 Timed events
    db file sequential read          23,582          679          29          46.3     User I/O
    CPU time                                        626                    42.7     
    db file scattered read     3,089     70     23     4.8     User I/O
    db file parallel write     3,478     28     8     1.9     System I/O
    log file parallel write     4,201     24     6     1.7     System I/O
    SGA Memory Summary
    SGA regions     Begin Size (Bytes)     End Size (Bytes) (if different)
    Database Buffers     2,768,240,640     2,835,349,504
    Fixed Size     2,050,240     
    Redo Buffers     14,721,024     
    Variable Size     3,657,439,040     3,590,330,176
    Process Memory Summary
         Category     Alloc (MB)     Used (MB)     Avg Alloc (MB)     Std Dev Alloc (MB)     Max Alloc (MB)     Hist Max Alloc (MB)     Num Proc     Num Alloc
    B     Other     569.22     0     2.62     3.14     22     24     217     217
         Freeable     101.63     0.00     0.77     0.45     3          132     132
         SQL     91.51     45.35     0.44     0.76     4     78     209     192
         PL/SQL     12.50     5.57     0.06     0.07     0     4     217     217
         JAVA     5.40     5.38     1.08     0.09     1     2     5     5
    E     Other     603.20          3.03     3.62     22     24     199     199
         SQL     115.21     64.78     0.60     1.67     21     78     191     182
         Freeable     112.31     0.00     0.83     0.43     3          135     135
         PL/SQL     13.89     5.94     0.07     0.12     1     4     199     199
         JAVA     8.93     8.89     1.12     0.23     2     2     
    for some reason i can't paste a table into this post but if you want i can email you above tables

Maybe you are looking for