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

Similar Messages

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

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

  • Buffer gets and logical reads

    Hello !
    Does the counter of event buffer gets include the logical reads ?
    Does the mertic buffer gets include the event of reading from undo buffer ?
    Thanks and regards,
    Pavel
    Edited by: Pavel on Jun 27, 2012 3:08 AM
    Edited by: Pavel on Jun 27, 2012 3:35 AM
    Edited by: Pavel on Jun 27, 2012 4:13 AM

    Hi,
    buffer gets = number of times a block was requested from buffer cache. A buffer get always request in a logical read. Depending on whether or not a copy of the block is available in the buffer cache, a logical read may or may not involve a physical read. So "buffer gets" and "logical reads" are basically synonyms and are often used interchangeably.
    Oracle doesn't have a special "undo buffer". Undo blocks are stored in rollback segments in UNDO tablespace, and are managed in the same way data blocks are (they're even protected by redo). If a consistent get requires reading from UNDO tablespace, then statistics counters will show that, i.e. there will be one more consistent get in your autotrace.
    For more information and some examples, see a thread at askTom:
    http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:549546900346542976
    Best regards,
    Nikolay

  • Consistent gets and db block gets

    Hi...
    I wanted to know the difference between consistent gets and db block gets in v$sess_io.I have read that consistent gets is the blocks in consistent mode..so here what does consistent mode means????
    Thanks in Advance,
    Anand

    Here's the complete text of the answer I originally wrote nearly 5 years ago on the Oracle-L mailing list:
    A 'db block get' is a current mode get. That is, it's the most up-to-date copy of the data in that block, as it is right now, or currently. There can only be one current copy of a block in the buffer cache at any time. Db block gets generally are used when DML changes data in the database. In that case, row-level locks are implicitly taken on the updated rows. There is also at least one well-known case where a select statement does a db block get, and does not take a lock. That is, when it does a full table scan or fast full index scan, Oracle will read the segment header in current mode (multiple times, the number varies based on Oracle version).
    A 'consistent get' is when Oracle gets the data in a block which is consistent with a given point in time, or SCN. The consistent get is at the heart of Oracle's read consistency mechanism. When blocks are fetched in order to satisfy a query result set, they are fetched in consistent mode. If no block in the buffer cache is consistent to the correct point in time, Oracle will (attempt to) reconstruct that block using the information in the rollback segments. If it fails to do so, that's when a query errors out with the much dreaded, much feared, and much misunderstood ORA-1555 "snapshot too old".
    As to latching, and how it relates, well, consider that the block buffers are in the SGA, which is shared memory. To avoid corruption, latches are used to serialize access to many linked lists and data structures that point to the buffers as well as the buffers themselves. It is safe to say that each consistent get introduces serialization to the system, and by tuning SQL to use more efficient access paths, you can get the same answer to the same query but do less consistent gets. This not only consumes less CPU, it also can significantly reduce latching which reduces serialization and makes your system more scalable.
    Well, that turned out longer than I planned. If you're still reading, I hope it helped!
    Hope that helps,
    -Mark
    PS The original question asked about latching as well, which explains the reason for the third paragraph.
    Edited by: mbobak on Sep 2, 2008 11:07 PM

  • Consistent gets and buffer gets

    Hi,
    what is the difference between Consistent gets and buffer gets ?
    Many thanks before.

    plz the documentation is your friend. You can search from tahiti.oracle.com or 10.2 (or your version) docu library.

  • 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

  • Most buffer gets and disk reads on table "CRMD_BRELVONAI"

    hello friends,
    we have to much buffer gets and disk reads on this table. se11 says:
    2 indexes on this table:
    first:
    OBJKEY_A -
    Index CRMD_BRELVONAI~1 exist on DB ORACLE
    second:
    OBJKEY_B-
    Index not exist on DB ORACLE
    Has anbody created the second index and good experience? OSS has no information.
    thanks,
    christoph

    Ho Christioph,
    If you double click on secondary index OBJECT_B you will get to index screen. Note that secondary index OBJECT_B as been set to <b>No database index</b>.
    For your information, here is a copy of the related documentation.
    Create the index in the database (selection)
    Whether an index improves or worsens performance often depends on the database system. You can therefore set whether an index defined in the ABAP Dictionary should be created in the database.
    This makes it easier to install a platform-specific customer system.
    You can set this option as follows:
    <b>Index in all database systems:</b> The index is always created in the database.
    <b>In selected database systems:</b> The index is created depending on the database system used. In this option, you must specify the databases in which the indexes are to be created. You can do this either on an inclusive (list of systems on which it should be created) or an exclusinve (list of systems on which it should not be created) basis. In either case, you can list up to four different database systems.
    <b>No database index:</b> The index is not created in the database. If you set this option for an index that already exists in the database, it is deleted when you activate the table in the ABAP Dictionary.
    Note: Unique indexes have an extra function, and must therefore always be created in the database. The database system prevents entries or index fields being duplicated. Since programs may rely on this database function, you cannot delete unique indexes from the database.
    Hopping this answer your question.
    Sincerely,
    Alain Gauthier

  • Difference between "Physical Read Total IO Requests Per Sec" and "Physical Read IO Requests Per Sec"

    What is the difference between "Physical Read Total IO Requests Per Sec" and "Physical Read IO Requests Per Sec" metrics in dba_hist_sysmetric_summary?

    From docs (Reference, Statistics Descriptions)   :
    physical read IO requests : Number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of "physical read total IO requests" statistic.
    physical read total IO requests : Number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities.

  • High Consistent Gets and memory settings

    What is actually high consistent gets?
    I get High Consistent Gets for certain sessions. Following are some of my parameter settings.
    db_16k_cache_size = 0
    db_2k_cache_size = 0
    db_32k_cache_size = 0
    db_4k_cache_size = 0
    db_8k_cache_size = 0
    db_block_size = 8192
    sga_max_size = 7632M
    sga_target = 7632M
    shared_pool_reserved_size = 119957094
    shared_pool_size = 48M
    pga_aggregate_target = 1500M
    Will setting AMM by configuring following parameter help Oracle to manage the memory in terms of workload and reduce CONSISTENT GETS?
    Or do I need to manually configure parameter such as "db_8k_cache_size".?
    memory_max_target = my SGA+PGA: 9.5G
    memory_target = my SGA+PGA: 9.5G
    sga_target = 0
    pga_agreegate_target =0
    Regards, Lily

    Lily wrote:
    What is actually high consistent gets?These are the logical IO's . If the logical IOs are high, it may mean that you have selected a lot of data which is now supposed to be given back to you. The high Logical IOs is not something that you should try to minimize using a high amount of memory since its already cached data. That sort of workaround works or would work if the physical IOs are high. If the session is doing more logical IO's check the query and the selectivity of the data and see if you can limit it further.
    I get High Consistent Gets for certain sessions. Following are some of my parameter settings.
    db_16k_cache_size = 0
    db_2k_cache_size = 0
    db_32k_cache_size = 0
    db_4k_cache_size = 0
    db_8k_cache_size = 0
    db_block_size = 8192
    sga_max_size = 7632M
    sga_target = 7632M
    shared_pool_reserved_size = 119957094
    shared_pool_size = 48M
    pga_aggregate_target = 1500M
    Will setting AMM by configuring following parameter help Oracle to manage the memory in terms of workload and reduce CONSISTENT GETS?
    Or do I need to manually configure parameter such as "db_8k_cache_size".?
    memory_max_target = my SGA+PGA: 9.5G
    memory_target = my SGA+PGA: 9.5G
    sga_target = 0
    pga_agreegate_target =0
    As I said, instance tuning is not something that you should aim for .
    Aman....

  • 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

  • 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

  • Query 1 shows less consistent gets but more cost than Query 2..

    Hi ,
    SQL> select dname from scott.dept where deptno not in (select deptno from scott.emp)
    Ðñüãñáììá åêôÝëåóçò
    Plan hash value: 3547749009
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |    1 |    22 | 4 (0)| 00:00:01 |
    |*  1 |  FILTER            |      |       |       |            |          |
    |   2 |   TABLE ACCESS FULL| DEPT |     4 |    88 | 2 (0)| 00:00:01 |
    |*  3 |   TABLE ACCESS FULL| EMP  |    11 |   143 |  2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "SCOTT"."EMP" "EMP"
                  WHERE LNNVL("DEPTNO"<>:B1)))
       3 - filter(LNNVL("DEPTNO"<>:B1))
    Note
       - dynamic sampling used for this statement
    ÓôáôéóôéêÜ
              0  recursive calls
              0  db block gets
             15 consistent gets
              0  physical reads
              0  redo size
            416  bytes sent via SQL*Net to client
            384  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL>
    SQL> select dname from scott.dept,scott.emp where dept.deptno=emp.deptno(+)
      2    and emp.rowid is null;
    Ðñüãñáììá åêôÝëåóçò
    Plan hash value: 2146709594
    | Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |      |   12 |   564 | 5 (20)| 00:00:01 |
    |*  1 |  FILTER             |      |       |       |            |          |
    |*  2 |   HASH JOIN OUTER   |      |    12 |   564 | 5 (20)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL| DEPT |     4 |    88 | 2 (0)| 00:00:01 |
    |   4 |    TABLE ACCESS FULL| EMP  |    12 |   300 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("EMP".ROWID IS NULL)
       2 - access("DEPT"."DEPTNO"="EMP"."DEPTNO"(+))
    Note
       - dynamic sampling used for this statement
    ÓôáôéóôéêÜ
              0  recursive calls
              0  db block gets
              6 consistent gets
              0  physical reads
              0  redo size
            416  bytes sent via SQL*Net to client
            384  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processedI have two questions:
    1) which one is preferable.... the first which is less costy to the system or the second which causes less consistent gets to the system and so is considered to be more scalable..????
    2)Whereas the number of rows returned by both queries is 1.. why the is difference in the underlined values in the two queries (values 1 and 12 respectively)?
    I use Oracle10g v.2
    Thanks.. a lot
    Sim

    The less logical I/O's the better.
    So always do it like your query 2 (btw. your title is the wrong way)
    Your example is probably flawed. If I try it in SQL*Plus I get correct results:
    SQL> get t
      1* select dname from dept where deptno not in (select deptno from emp)
    SQL> /
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=3 Bytes=39)
       1    0   FILTER
       2    1     TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=2 Card=4 Bytes=52)
       3    1     TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=2 Card=1 Bytes=3)
    Statistics
              0  recursive calls
              0  db block gets
             15  consistent gets
              0  physical reads
              0  redo size
            537  bytes sent via SQL*Net to client
            660  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> get tt
      1  select dname from dept,emp where dept.deptno=emp.deptno(+)
      2* and emp.rowid is null
    SQL> /
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=14 Bytes=322)
       1    0   FILTER
       2    1     HASH JOIN (OUTER) (Cost=5 Card=14 Bytes=322)
       3    2       TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=2 Card=4 Bytes=52)
       4    2       TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=2 Card=14 Bytes=140)
    Statistics
              0  recursive calls
              0  db block gets
              6  consistent gets
              0  physical reads
              0  redo size
            537  bytes sent via SQL*Net to client
            660  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> I'm wondering for instance why you have there 11 rows in emp for query 1 (should be only 1 row) and why you have only 12 rows in query 2 (should be 14 rows)

  • Reduce Logical IO [db block gets/consistent gets]

    Hi,
    Still I'm unsure about the Logical IO (db block gets + consistent gets).
    I want to reduce 'consistent gets' for this query
    SQL> set autotrace traceonly
    SQL> select * from cm_per_phone_vw;
    905 rows selected.
    Execution Plan
    Plan hash value: 524433310
    | Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |              |   868 | 38192 |     8   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY NOSORT        |              |   868 | 38192 |     8   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| CI_PER_PHONE |  1238 | 54472 |     8   (0)| 00:00:01 |
    |   3 |    INDEX FULL SCAN           | CM172C0      |  1238 |       |     1   (0)| 00:00:01 |
    Statistics
              8  recursive calls
              0  db block gets
            922  consistent gets
              4  physical reads
              0  redo size
          39151  bytes sent via SQL*Net to client
           1045  bytes received via SQL*Net from client
             62  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
            905  rows processedFollowing is the view it's accessing
    CREATE OR REPLACE VIEW CM_PER_PHONE_VW
    AS
    SELECT
      per_id
      , MAX(DECODE(TRIM(phone_type_cd), 'MOB', phone)) AS MOB
      , MAX(DECODE(TRIM(phone_type_cd), 'HOME', phone)) AS HOME
      , MAX(DECODE(TRIM(phone_type_cd), 'BUSN', TRIM(phone) || ' ' || TRIM(extension))) AS BUSN
      , MAX(DECODE(TRIM(phone_type_cd), 'FAX', phone)) AS FAX
      , MAX(DECODE(TRIM(phone_type_cd), 'INT', phone)) AS INT
    FROM
      ci_per_phone
    GROUP BY
      per_idI have following indexes on table ci_per_phone
    INDEX_NAME                     COLUMN_NAME                    COLUMN_POSITION
    XM172P0                        PER_ID                                       1
    XM172P0                        SEQ_NUM                                      2
    XM172S1                        PHONE                                        1
    CM172C0                        PER_ID                                       1I tried creating indexes on PER_ID and PHONE_TYPE_CD but the consistent gets reduces to 920 instead of 922.
    Just for curiosity, how can I reduce this?
    secondly, is there any explanation on 'OPERATION' break of the plan, e.g. TABLE ACCESS BY INDEX ROWID ?
    Please advice.
    Luckys.

    Further I'm having problem with another query which is a view
    CREATE OR REPLACE VIEW CM_PER_CHAR_VW
    AS
    SELECT
    /*+ full (a) */
      a.acct_id
      , MAX(DECODE(a.char_type_cd, 'ACCTYPE', a.char_val)) acct_type
      , MAX(DECODE(a.char_type_cd, 'PRVBLCYC', a.adhoc_char_val)) prev_bill_cyc
    FROM
      ci_acct_char a
    WHERE
      a.effdt =
        (SELECT
          MAX(a1.effdt)
        FROM
          ci_acct_char a1
        WHERE a1.acct_id = a.acct_id
        AND a1.char_type_cd = a.char_type_cd)
    GROUP BY
      a.acct_idI'm not able to reduce the consistent gets and even the filter appears.
    I've analyzed the table as well as the index on the table.
    cisadm@CCBDEV> select * from cm_acct_char_vw;
    2649 rows selected.
    Execution Plan
    Plan hash value: 132362271
    | Id  | Operation              | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT       |              |    27 |  4536 |    14   (8)| 00:00:01 |
    |   1 |  HASH GROUP BY         |              |    27 |  4536 |    14   (8)| 00:00:01 |
    |   2 |   VIEW                 |              |    27 |  4536 |    14   (8)| 00:00:01 |
    |*  3 |    FILTER              |              |       |       |            |          |
    |   4 |     HASH GROUP BY      |              |    27 |  2916 |    14   (8)| 00:00:01 |
    |   5 |      NESTED LOOPS      |              |  2686 |   283K|    13   (0)| 00:00:01 |
    |   6 |       TABLE ACCESS FULL| CI_ACCT_CHAR |  2686 |   157K|    12   (0)| 00:00:01 |
    |*  7 |       INDEX RANGE SCAN | XM064P0      |     1 |    48 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("A"."EFFDT"=MAX("A1"."EFFDT"))
       7 - access("A1"."ACCT_ID"="A"."ACCT_ID" AND
                  "A1"."CHAR_TYPE_CD"="A"."CHAR_TYPE_CD")
    Statistics
              0  recursive calls
              0  db block gets
           2754  consistent gets
              0  physical reads
              0  redo size
          76517  bytes sent via SQL*Net to client
           2321  bytes received via SQL*Net from client
            178  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
           2649  rows processedhere's the tkprof
    select *
    from
    cm_acct_char_vw
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch      178      0.07       0.05          0       2754          0        2649
    total      181      0.07       0.05          0       2754          0        2649
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 63  (CISADM)
    Rows     Execution Plan
          0  SELECT STATEMENT   MODE: CHOOSE
          0   HASH (GROUP BY)
          0    VIEW
          0     FILTER
          0      HASH (GROUP BY)
          0       NESTED LOOPS
          0        TABLE ACCESS   MODE: ANALYZED (FULL) OF 'CI_ACCT_CHAR'
                       (TABLE)
          0        INDEX   MODE: ANALYZED (RANGE SCAN) OF 'XM064P0'
                       (INDEX (UNIQUE))
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                     179        0.00          0.00
      SQL*Net message from client                   179        0.00          0.08
    ********************************************************************************I've an similar query for another table, where there are 1110 rows, but in the explain, no filter appears in the predicate
    Predicate Information (identified by operation id):
       2 - access("P"."EFFDT"="VW_COL_1" AND "PER_ID"="P"."PER_ID" AND
                  "CHAR_TYPE_CD"="P"."CHAR_TYPE_CD")Both the queries have somewhat similar views.
    I've got 2 questions,
    Is there a way I can reduce the consistent gets( I've tried with/without HINTS),
    secondly whats the predicate access shows as 'VW_COL_1'
    please advice.

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

Maybe you are looking for