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

Similar Messages

  • 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

  • Unable to reduce  Physical Reads

    Hi
    Problem:
    Need to reduce the Physical reads in Oracle 8.1.7
    Information:
    Optimizer_mode= Choose
    Statistics will not be gathered.
    Intially the cache hit ratio is 18%. At this point when we checked the SQL Statement
    SELECT a32,
    F_DOCNUMBER,NVL(a109,'BIWS') AS WorkFlow,
    a147 AS Service_Subsidary,
    a89 AS StaffInd,
    a88 AS SubsidiaryInd
    FROM doctaba
    WHERE a94 = 'CCOC_CARDS_CCA_060824_6'
    AND a40 IN ('3','4','5')
    0 recursive calls
    81 db block gets
    5020 consistent gets
    3909 physical reads
    0 redo size
    401 bytes sent via SQL*Net to client
    311 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed.
    Once we increase the Buffer Cache Hit Ratio to 90% We got the following
    0 recursive calls
    81 db block gets
    3717 consistent gets
    3576 physical reads
    0 redo size
    401 bytes sent via SQL*Net to client
    311 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed.
    But can you please advice how to reduce the Physical Reads further.
    Note: Table DOCTABA is a Snapshot that is present in Other Database.
    Please advice!!
    Cheers
    Ramkannan.A

    Buffer hit cache ratios are totally meaningless as was proven many years ago by Connor's brilliant little utility that allows you to dial in any ratio you want.
    The reason your are getting FTEs is because your totally antiquated version of the product, never supported during the current century, is that it thinks FTEs cost less than using any indexes that may (or may not) exist. You've not established in your email that there are any indexes or posted DDL or provided much of anything else that would be helpful.
    I would think moving from the Jurassic to 10.2.0.4, or above, would be your first priority.

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

  • How do I fix Reader XI compatability issues with Windows 7 Home Premium?

    Compatability issues are keeping me from being able to open pdf files using Acrobat Reader XI.  I have Windows 7 Home Premium and am using Webroot Security.  It is telling me to try unprotected mode, but I would like to be able to use protected mode.  Any way to fix this?

    M Ben wrote:
    all of my option under file and edit are darked out.
    All menu options in Reader DC are very faint compared to earlier Reader versions or other programs.  You should still be able to click Preferences on the Edit menu:

  • Physical read & logical read

    Hi
    What is ment by Physical-Read and Logical-Read in oracle?Can anybody explain me clearly.
    Aqueel.

    Physical read, reading from the disk and logical reads mean reading it from the memory.
    When a session(query) required information (data blocks), it will first look into the buffer cache (SGA), if it find the required data block, it will read it from the memory, i.e. logical reads, but, if it doesn't find required data block in the memory, then it read from the disk(datafile), physical read.
    Generally, people motive to reduce physical read and read as much as possible from the memory, I was also int he same wrong impression until I came across a good paper by tuning expert Cary Milsap, 'why we should focus on LIO instead of PIO'. also, search http://asktom.oracle.com 'logical reads', there are good discussion on this point.
    Jaffar

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

  • I am just starting out in graphic design and I wanted to know how to get more involved with either adobe and or graphic design? I am really very interested in working with adobe and graphic design more and becoming more involved with both!!

    I am just starting out in graphic design and I wanted to know how to get more involved with either adobe and or graphic design? I am really very interested in working with adobe and graphic design more and becoming more involved with both!!

    I have now recently downloaded 10.0.2 which is confusing in itself, as, as far as I can ascertain that is actually version 11, but I'm not even sure about that.
    Version 10.0.2 is the newest version and the successor to GarageBand '11 (version 6.0.5).
    The '11 is referring to the iLife '11 suit of multimedia application - the older GarageBand was a part of this bundle.
    Have a look at Edgar's graphical enhanced manuals, the explain very detailed how things work and why. You can buy them as iBooks from the iBook store or directly from the page:
    http://DingDingMusic.com/Manuals/

  • How to reduce a PDF file size under Adobe Acrobat Reader DC. The size is now 23MB; I need it to be less than 4MB. thanks

    how to reduce a PDF file size under Adobe Acrobat Reader DC. The size is now 23MB; I need it to be less than 4MB. thanks

    I've found in Pdf's many time when you go to Optimize a PDF and look at the font list there are often up to a 1/2dozen copies of a given font, say Helvetica, then that many Helvetica Bold, or Arial or Ariel Italic
    What I do ie remove from list all but one copy of each different font. often dramatically reduces the size. also something lese is Flattening images will in some cases reduce a file size. I have run into a case where it actually made a PDF Larger.

  • Consistent gets/physical reads issue

    Dear all,
    There are not any of DML on table tb_hxl_user.
    First Select:
    SQL> select count(1) from tb_hxl_user;
      COUNT(1)                                                                     
    286435658                                                                     
    Elapsed: 00:04:03.67                                                       
    Statistics
            357  recursive calls                                                   
              0  db block gets                                                     
        2106478  consistent gets                                                   
        2106316  physical reads                                                    
              0  redo size                                                         
            422  bytes sent via SQL*Net to client                                  
            416  bytes received via SQL*Net from client                            
              2  SQL*Net roundtrips to/from client                                 
              6  sorts (memory)                                                    
              0  sorts (disk)                                                      
              1  rows processed                                                     Second Select:
    SQL> select count(1) from tb_hxl_user;
      COUNT(1)                                                                     
    286435658                                                                     
    Elapsed: 00:03:02.29
    Statistics
              0  recursive calls                                                   
              0  db block gets                                                     
        2106395  consistent gets                                                   
        2106273  physical reads                                                    
              0  redo size                                                         
            422  bytes sent via SQL*Net to client                                  
            416  bytes received via SQL*Net from client                            
              2  SQL*Net roundtrips to/from client                                 
              0  sorts (memory)                                                    
              0  sorts (disk)                                                      
              1  rows processed                                                     After the first,I know that all the blocks have been flushed to SGA,
    but the second select,it generated many " 2106395 consistent gets" and " 2106273 physical reads" also,
    why?

    What exactly is consistent gets read below link:
    http://jonathanlewis.wordpress.com/2009/06/12/consistent-gets-2/
    Which is similar to docs clearity and authenticity.
    What exactly is physical read read below link:
    http://download.oracle.com/docs/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_instance_throughput_physreads_ps.html
    Regards
    Girish Sharma

  • Version count in statspack report-How to reduce this

    I generate stats report every week for 24 Hr time period and analyze all top20 queries interms of buffer gets,physical reads and executions.I could tune the queries with the help of you.Recently my Boss asked me to look in to top version count queries and reduce the number of versions.
    I have 4-5 queries which are running 300,000 times and has version count of 35.How can I reduce this number.please suggest me how to approach it.
    Your help will be appreciated.Thanks in advance.
    Thanks
    Anand

    Version count 35 out of 300000 doesn't look like a problem to me. Are you having performance issue on your system at all?
    <br>
    <br>
    1. Are the subject queries using Bind variables ?<br>
    2. What's the setting of CURSOR_SHARING?<br>
    should have CURSOR_SHARING=FORCE<br>
    3. check if Bug 3406977 apply to your case <br>

  • How to reduce the fetch time of this sql?

    Here is the SQL, three-table join and joining conditions are:
    ms_ets_cntrl.ims_cntrt_oid=ims_alctn.ims_alctn_oid
    ims_alctn.ims_trde_oid=ims_trde.ims_trde_oid
    SELECT 'MCH' Type, ims_ets_cntrl.STTS tp_stts, count(*) Count  FROM ims_ets_cntrl  where ims_ets_cntrl.ims_cntrt_oid in
    (select ims_alctn.ims_alctn_oid  FROM ims_alctn, ( select ims_trde.ims_trde_oid from ims_trde
    where ( IMS_TRDE.IMS_TRDE_RCPT_DTTM  >= TO_DATE('10/29/2009 00:00', 'MM/DD/YYYY HH24:MI') AND IMS_TRDE.IMS_TRDE_RCPT_DTTM <= (TO_DATE('11/5/2009 23:59', 'MM/DD/YYYY HH24:MI')) )
    AND (IMS_TRDE.GRS_TRX_TYPE IN ('INJECTION','WITHDRAWAL','PAYMENT') OR IMS_TRDE.SSC_INVST_TYPE = 'FC' AND  1=1  and IMS_TRDE.SERVICE_TYPE='FS' )) TRDE
    where IMS_ALCTN.IMS_TRDE_OID=TRDE.IMS_TRDE_OID) and ims_ets_cntrl.outbnd_dest = 'ETD' group by ims_ets_cntrl.STTSOptimizer and related parameter info:
    SQL> show parameter optimizer
    NAME                                 TYPE        VALUE
    optimizer_dynamic_sampling           integer     1
    optimizer_features_enable            string      9.2.0
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_max_permutations           integer     2000
    optimizer_mode                       string      CHOOSE
    SQL>select pname, pval1, pval2 from sys.aux_stats$ where sname='SYSSTATS_INFO';
    DSTART          11-16-2009 10:23
    DSTOP          11-16-2009 10:23
    FLAGS     1     
    STATUS          NOWORKLOADHere is autotrace output:
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE
       1    0   SORT (GROUP BY)
       2    1     VIEW
       3    2       SORT (UNIQUE)
       4    3         TABLE ACCESS (BY INDEX ROWID) OF 'IMS_ETS_CNTRL'
       5    4           NESTED LOOPS
       6    5             NESTED LOOPS
       7    6               TABLE ACCESS (BY INDEX ROWID) OF 'IMS_TRDE'
       8    7                 INDEX (RANGE SCAN) OF 'IMS_TRDE_INDX4' (NON- UNIQUE)
       9    6               TABLE ACCESS (BY INDEX ROWID) OF 'IMS_ALCTN'
      10    9                 INDEX (RANGE SCAN) OF 'IMS_ALCTN_INDX1' (NON  -UNIQUE)
      11    5             INDEX (RANGE SCAN) OF 'IMS_ETS_CNTRL_INDX1' (NON  -UNIQUE)
    Statistics
              0  recursive calls
              0  db block gets
         244608  consistent gets
          58856  physical reads
              0  redo size
            497  bytes sent via SQL*Net to client
            499  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              2  sorts (memory)
              0  sorts (disk)
              1  rows processedHere is TKPROF output:
    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        2      4.85     129.72      53863     244608          0           1
    total        4      4.85     129.72      53863     244608          0           1
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 63 
    Rows     Row Source Operation
          1  SORT GROUP BY
      12972   VIEW 
      12972    SORT UNIQUE
      12972     TABLE ACCESS BY INDEX ROWID IMS_ETS_CNTRL
      46236      NESTED LOOPS 
      19134       NESTED LOOPS 
      19744        TABLE ACCESS BY INDEX ROWID IMS_TRDE
    176922         INDEX RANGE SCAN IMS_TRDE_INDX4 (object id 34099)
      19134        TABLE ACCESS BY INDEX ROWID IMS_ALCTN
      19134         INDEX RANGE SCAN IMS_ALCTN_INDX1 (object id 34094)
      27101       INDEX RANGE SCAN IMS_ETS_CNTRL_INDX1 (object id 34101)
    ********************************************************************************Explain plan output:
    PLAN_TABLE_OUTPUT
    | Id  | Operation                         |  Name                | Rows  | Bytes | Cost  |
    |   0 | SELECT STATEMENT                  |                      |       |       |       |
    |   1 |  SORT GROUP BY                    |                      |       |       |       |
    |   2 |   VIEW                            |                      |       |       |       |
    |   3 |    SORT UNIQUE                    |                      |       |       |       |
    |*  4 |     TABLE ACCESS BY INDEX ROWID   | IMS_ETS_CNTRL        |       |       |       |
    |   5 |      NESTED LOOPS                 |                      |       |       |       |
    |   6 |       NESTED LOOPS                |                      |       |       |       |
    |*  7 |        TABLE ACCESS BY INDEX ROWID| IMS_TRDE             |       |       |       |
    |*  8 |         INDEX RANGE SCAN          | IMS_TRDE_INDX4       |       |       |       |
    |   9 |        TABLE ACCESS BY INDEX ROWID| IMS_ALCTN            |       |       |       |
    |* 10 |         INDEX RANGE SCAN          | IMS_ALCTN_INDX1      |       |       |       |
    |* 11 |       INDEX RANGE SCAN            | IMS_ETS_CNTRL_INDX1  |       |       |       |
    Predicate Information (identified by operation id):
       4 - filter("IMS_ETS_CNTRL"."OUTBND_DEST"='ETD')
       7 - filter("IMS_TRDE"."GRS_TRX_TYPE"='INJECTION' OR "IMS_TRDE"."GRS_TRX_TYPE"='WITHD
                  RAWAL' OR "IMS_TRDE"."GRS_TRX_TYPE"='PAYMENT' OR "IMS_TRDE"."SSC_INVST_TY
                  PE"='FC' AND "IMS_TRDE"."SERVICE_TYPE"='FS')
       8 - access("IMS_TRDE"."IMS_TRDE_RCPT_DTTM">=TO_DATE('2009-10-29 00:00:00', 'yyyy-mm-
                  dd hh24:mi:ss') AND "IMS_TRDE"."IMS_TRDE_RCPT_DTTM"<=TO_DATE('2009-11-05
                  23:59:00', 'yyyy-mm-dd hh24:mi:ss')
      10 - access("IMS_ALCTN"."IMS_TRDE_OID"="IMS_TRDE"."IMS_TRDE_OID")
      11 - access("IMS_ETS_CNTRL"."IMS_CNTRT_OID"="IMS_ALCTN"."IMS_ALCTN_OID")
    Note: rule based optimizationCould you please help tune this sql?
    How can I reduce the elapsed time? How can I reduce query read?
    If there is any other info that you need, please let me know!
    thank you very much!

    What exactly is this logic meant to do?
    AND    (ims_trde.grs_trx_type IN ('INJECTION', 'WITHDRAWAL', 'PAYMENT')
            OR ims_trde.ssc_invst_type = 'FC'
            AND ims_trde.service_type = 'FS')is that really:
    AND    (ims_trde.grs_trx_type IN ('INJECTION', 'WITHDRAWAL', 'PAYMENT')
            OR ims_trde.ssc_invst_type = 'FC')
    AND    ims_trde.service_type = 'FS'or is it maybe:
    AND   (ims_trde.grs_trx_type IN ('INJECTION', 'WITHDRAWAL', 'PAYMENT')
           OR (ims_trde.ssc_invst_type = 'FC'
               AND ims_trde.service_type = 'FS'))?

  • 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

  • How to reduce max buffer/cache size?

    Hi,
    every time I copy a file which is bigger or similiar in size to my total RAM (4gb) I notice very low responsibility from firefox (which is totally unresponsive, can't switch tabs or scroll for 30-60s). Of course my free memory is very low (something like 50-100mb) and I notice some swap usage. AFAIK linux caches everthing that is being copied, but in case of such big files it seems unnecessary.
    Is there a way to reduce max buffer size?
    I know that buffering is good in general, but I get a feeling that firefox is giving up ram and he has to read everything again from disk which slows him down. I always have many tabs open, so often it has around 30% of memory.
    I searched many times on how to reduce buffer sizes, but I've always found only articles with "buffering is always good and never an issue" attitude.
    I would be very happy to hear any suggestrions,
    cheers,
    kajman

    This seems a popular problem, going back years. The default Linux setup is bad for responsiveness, it seems.
    Here's the summary of what I do:
    Firstly, install a BFS-patched kernel, for a better kernel scheduler, and also so that the ionice and schedtool commands will work. Bonus points for switching to BFQ while you're at it - or stick with CFQ, which also supports ionice.
    In /etc/fstab, use commit=60 rather than default of 5 seconds, and also noatime, e.g.:
    UUID=73d55f23-fb9d-4a36-bb25-blahblah / ext4 defaults,noatime,nobarrier,commit=60 1 1
    In /etc/sysctl.conf
    # From http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
    vm.swappiness=0
    # https://lwn.net/Articles/572921/
    vm.dirty_background_bytes=16777216
    vm.dirty_bytes=50331648
    In ~/.bashrc - see post, e.g.:
    alias verynice="ionice -c3 nice -n 15"
    In /etc/security/limits.d/ - see post. Read CK's excellent blog article, for info.
    In your cp command, add the word verynice to the start, to stop the large batch copy from having the same priority as your UI.
    Compile sqlite without fsync, to make e.g. firefox smoother.
    Potentially use threadirqs to prioritize the interrupt-handling.
    Edit: Updated vm.swappiness from 0 to 10, from CK's blog.
    Edit2: Also see patch and e.g. nr_requests in thread.
    Edit3: Using nice instead of schedtool - not sure whether schedtool can hog the CPU.
    Edit4: Added threadirqs.
    Edit5: Tweaked sysctl.conf settings.
    Edit6: Added nobarrier option to mount, and sqlite's fsync.
    Edit7: Removed swap comment - I do use a swapfile, these days, mainly because firefox needs so much virtual RAM to compile.
    Last edited by brebs (2014-03-10 09:51:34)

  • How to Reduce Clusetering Factor on Table?

    I am seeing a very high clustering factor on an SDO geometry table in our 10g RAC DB on our Linux boxes. This slow performance is repeateable on othe r Linux as well as Solaris DBs for the same table. Inserts go in at a rate of 44 milliseconds per insert and we only have about 27000 rows in the table. After viewing a VERY slow insert of about 600 records into this same table, I saw the clustering factor in OEM. The clustering factor is nearly identical to the # rows in the table indicating that useability of the index is fairly low now. I have referenced Metalink Tech Note 223117.1 and, while it affirms what I've seen, I am still trying to determine how to reduce the Clustering Factor. The excerpt on how to do this is below:
    "The only method to affect the clustering factor is to sort and then store the rows in the table in the same order as in they appear in the index. Exporting rows and putting them back in the same order that they appeared originally will have no affect. Remember that ordering the rows to suit one index may have detrimental effects on the choice of other indexes."
    Sounds great, but how does one actually go about storing the rows in the table in the same order as they appear in the index?
    We have tried placing our commits after the last insert as well as after every insert and the results are fairly neglible. We also have a column of type SDE.ST_GEOMETRY in the table and are wondering if this might also be an issue. Thanks in advance for any help.
    Matt Sauter

    Joel is right that the clustering factor is going to have absolutely no effect on the speed of inserts. The clustering factor is merely one, purely statistical, factor the optimiser makes use of to determine how to perform a SELECT statement (i.e., do I bother to use this index or not for row retrieval). It's got nothing to do with the efficiency of inserts.
    If I were you, I'd be looking at factors such as excessive disk I/O taking place for other reasons, inadequate buffer cache and/or enqueue and locking issues instead.
    If you're committing after every insert, for example, then redo will have to be flushed (a commit is about the only foreground wait event -i.e., one that you get to experience in real time- that Oracle has, so a commit after every insert's really not a smart idea). If your redo logs are stored on, say, the worst-performing disk you could buy that's also doing duty as a fileserver's main hard disk, then LGWR will be twiddling its thumbs a lot! You say you've tested this, and that's fine... I'm just saying, it's one theoretical possibility in these sorts of situations. You still want to make sure you're not suffering any log writer-related waits, all the same.
    Similarly, if you're performing huge reads on a (perhaps completely separate) table that is causing the buffer cache to be wiped every second or so, then getting access to your table so your inserts can take place could be problematic. Check if you've got any database writer waits, for example: they are usally a good sign of general I/O bottlenecks.
    Finally, you're on a RAC... so if the blocks of the table you're writing to are in memory over on another instance, and they have to be shipped to your instance, you could have high enqueue waits whilst that shipment is taking place. Maybe your interconnect is not up to the job? Maybe it's faulty, even, with significant packet loss along the way? Even worse if someone's decided to switch off cache fusion transfer for the datafiles invoved (for then block shipment happens by writing them to disk in one instance and reading from disk in the other). RAC adds a whole new level of complexity to things, so good luck tracking that lot down!!
    Also, maybe you're using Freelists and Freelist groups rather than ASSM, so perhaps you're fighting for access to the freelist with whatever else is happening on your database at the time...
    You get the idea: this could be a result of activity taking place on the server for reasons completely unconnected with your insert. It could be a feature of Spatial (with which not many people will be familiar, so good luck if so!) It could be a result of the way your RAC is configured. It could be any number of things... but I'd be willing to bet quite a bit that it's got sod-all to do with the clustering factor!
    You'll need to monitor the insert using a tool like Insider or Toad so you can see if waits and so on happen, more or less in real time -or start using the built-in tools like Statspack or AWR to analyze your workload after it's completed- to work out what your best fix is likely to be.

Maybe you are looking for

  • How to get Photostream from 'business' iPhone to 'family' iCloud-account

    Has anyone found a solution for this yet ? There must be numerous pleople having this same problem : I have a (in my opinon rather standard) setup in which I have a private iCloud-account on my 'business devices' (iPhone, iPad, MacBook Pro) and I hav

  • Import Statement Error

    Does anyone know what is wrong with these import statement? import Reduction; import Mapper; import ApplyObj; import ApplyObjUnary; import java.lang.String; public class Driver{ public static Driver me = new Driver(); public static void main(String[]

  • Install HRCS 9.0 R5 with Linux Issue: upgrade HRCS 9.0 PT8.52 to PT8.53

    Folks, Hello. I have been installing HCM and Campus Solution 9.0 with PeopleTools8.53. Server machine is Oracle Linux 5.10 and client machine is Windows XP.  My internet architecture is WebLogic11g/Tuxedo11g/OracleDatabase 11gR1. Peopletools 8.53 run

  • Regarding PDF conversion

    hi all, Am doing GR form(Script) for japan.....some of the things are hard coded in japan....but when i will convert into PDF using the program RSTXPDFT4 ......some garbage characters r showing instead of japanese chars.... and I used font JPMINCHO..

  • How can I get stats on my iweb blog site?

    How can I get blog stats on my iweb blog site?