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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

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?

  • Finding sql query in statspack report

    Hi;
    I have 11.5.10.2 and db version is 9iR2.. i took one statspack report and i should find one sql query... But admin is kill session and i cant see complite query under SQL ordered by Gets for DB...
    so the question is can i find this query whihc is kiiled by admin?
    thanks

    Hi,
    Its bad news to cant find this sql.. If normaly it istn killed by admin, i could find it from stats$sql_summary or v$sql_text??It is possible.
    Note: 153507.1 - Oracle Applications and StatsPack
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=153507.1
    And one other question... If i suspect from one sql is eating my cpu or my server resource, how i can find this sql? Under which title i can find in statspack reportRefer to:
    Note: 232443.1 - How to Identify Resource Intensive SQL for Tuning
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=232443.1
    Regards,
    Hussein

  • Physical reads, writes and logical reads,writes

    hi there,
    is there any way to find the physical reads and writes, logical reads and writes
    other than statspack report?

    It depends which version of Oracle are you using.
    If you are using 10g, you can get very comprehensive information from the dictionary views.
    If you are on <=9i, then, use, v$sysstat and look for 'physical reads', 'logical reads'.
    The values dervied from v$sysstat are cummulative values. i.e. values counted since the instance started.
    Jaffar

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

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

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

  • 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

  • Parrallel query and physical reads

    Hi I have ran a query in uing OPQ degree 12 several time, but in subsiquent runs, im still seeing physical reads, should the data not be cached after the first run..
    ie, run 4 is shown below:
    Statistics
             33  recursive calls                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
              0  db block gets                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
           4866  consistent gets                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
           3146  physical reads                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
              0  redo size                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
        7373850  bytes sent via SQL*Net to client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
         293742  bytes received via SQL*Net from client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
          26668  SQL*Net roundtrips to/from client                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
              2  sorts (memory)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
              0  sorts (disk)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
         400002  rows processed  

    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1027523970333
    parallel query may use direct io, it may not use direct io.
    parallel query may use the buffer cache, it may bypass it.
    And in the next followup.
    Tom, in what conditions parallel query would entirely bypass buffer cache? Thanks.
    Followup June 15, 2005 - 10am Central time zone:
    when it does direct IO to read the blocks.
    "

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

  • Logical read Vs Physical Reads

    Hi,
    I want to know How should we balance the logical reads and physical reads on database.
    I generaly assume logical reads is always better but what if too many session accessing the same
    objects it will cause latch contention.
    If it is physical read then it will take more time to read from disk than reading from SGA.
    If I look at statspack report I check the
    Logical reads: 59,846.54 840.03
    Physical reads: 1,095.91 15.38
    Is there any standards for logical reads on database. If there is latch contentions can we go for the
    decreasing the SGA to avoid the contentions so that there will balance between the physical reads
    and logical reads.

    amitbansode wrote:
    I want to know How should we balance the logical reads and physical reads on database.There is no balance as it implies some kind of "+perfect ratio+" for logical I/O vs. physical I/O.
    A high percentage of physical I/O can be perfectly acceptable and normal and correct for a specific database (e.g. think of a system collecting telemetry data where 90% or more of all I/O is writing new telemetry into the database and the remaining 10% is querying the data, with old data being aged out from the database using partition drops which is negligible I/O).
    A high percentage of logical I/O can be indicative of a serious application design problem - where 80GB of database data is read and read again and again and again.. resulting in over a TB of logical I/O. (actually saw this in production database some years ago)
    So there is no balance (e.g. not true that physical I/O = BAD and logical I/O = GOOD). No perfect cache hit ratio figure that tells you that the database is doing the right amounts of logical and physical I/O.
    And I want to emphasise what Mark said - tuning requires you to identify the performance problem first, before trying to solve it.
    It is very dangerous to take one metric, like the I/O cache hit ratio, and attempt to tune that. It alone is meaningless. Just like memory utilisation alone is useless and CPU utilisation alone is useless. It does not by any means point to an actual performance problem. E.g. 100% CPU utilisation can mean hardware has insufficient horses, instead of performance issues related with application design, database setting or kernel configuration.
    I often repeat the following mantra here on OTN - a fundamental concept IMO for software engineering:
    A solution is only as good as the problem definition.
    Identify the problem first - correctly and comprehensively. And then solve it.

  • How to reduce physical reads - very interesting issue

    HI,
    Every week i generate a statspack report which will give me top20 buffer gets queries and top 20 physical reads query.When i start reducing physical reads by placing the heavy accessed table in buffer i will get the same query in top 20 higher buffer gets list in the next week.If i want to reduce buffer gets i have to remove the heavy accessed table from buffer which will cause higer physical reads.How can i solve this problem.I am trying to tune query as much as possible.
    Your help is appreciated..
    Thanks and Regards
    Anand

    I think that you are labouring under a misapprehension. Buffer gets and physical reads are basically the same thing. In order to satisfy your query, Oracle needsto read X number of blocks to find all of the data. Admittedly, it is generally faster to read those blocks from memory (buffer gets) than from disk (physical reads), but the blocks have to be read (this is called logical I/O). The only way to reduce I/O is to re-write the query to be more efficient. This may or may not be possible.
    As Kamal said, if the query is fast enough, then you are done. If it is too slow, then you need to look at ways of reducing I/O. It is unlikely that any database parameters will have a significant impact on the I/O. You need to look at the statisitics on the table and the actual sql statement.
    John

  • 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

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

Maybe you are looking for

  • Want to move iPhoto data to other disk

    I have iPhoto running and its data stored in ~/Pictures per normal. I want to MOVE the iPhoto pics dirs to another drive - how do I point to the new location? Also - I still want iPhoto to import files dragged to Library into the new drive's location

  • Converting java.lang.String to a XML Node

    Hi, how do you convert a straight forward string like .. "<nodename>this is the node value</nodename>" to a org.w3c.dom.Node....?? This way it would be easier to use appendNode() to add temporary nodes & build up a document.

  • ORA-00937:not a single-group group function|ORA-06512:at"schema.procedure n

    ORA-00937:not a single-group group function|ORA-06512:at"schema.procedure name)? The details of this procedure are the emp table is used in the emp1 which is shown in line 19 1 DECLARE 2 cur_emp sys_refcursor; 3 TYPE t_tab IS TABLE OF emp%ROWTYPE; 4

  • Best Practices for SES

    Are there any: 1) Best Practices documents 2) Project methodology 3) Project evaluation techniques/pointers documents for SES? Apologies if this has been posted before. Please point me to any such post I might have missed. Thanks in advance.

  • UCMON - Currency translation problem

    Hi I'm new to use UCMON tcode, here I need to debug Currency Translation for Consolidatin Area 'SH' Version '100' Group Currency 'GBP', Period '1/2010'. In context menu of Currency translation if i give Test it is giving dump. The dump says that "GET