No physical reads, plenty of consistant gets

Hi All,
Oracle v11.2 on Linux.
Please have a look at the query I ran and the output. The SQL_ID is of a SELECT command.
What does this situation represents, where there are zero physical reads and plenty of consistant gets ?
For consistant gets, we do read undo information (correct ??), if that undo is read from disk, will that be a "physical read"? i.e. if we read disks for consistant gets, will that be counted under physical reads or not ?
How can I describe the exact data retrival of the command here? Is it the case of "everything it needs is found in the buffer cache" ?
select a.sid, a.value , B.NAME ,  s.sql_id
from v$sesstat a, v$statname b, v$session s
where A.STATISTIC# = B.STATISTIC#
and b.name in ( 'redo size','physical read bytes','physical reads cache','consistent gets' )
and a.sid = s.sid
and a.sid=1018
order by a.sid;
       SID      VALUE NAME                                                             SQL_ID
      1018    7281396 consistent gets                                                  434u36htuz0s9
      1018          0 physical reads cache                                             434u36htuz0s9
      1018          0 physical read bytes                                              434u36htuz0s9
      1018       4448 redo size                                                        434u36htuz0s9
4 rows selected.Thanks in advance.

>
There are no physical reads, so weather its doing consistant-gets or not, can I say, all data required for the SELECT was in buffer cache ?
>
The data for those system views is cached in memory so Oracle does not read the disk (except at startup) to gather the information.
Some static information, like dictionary objects, is stored stored on disk in the system tablespace but this data is read when the database is mounted and stored in memory structures.
Other dynamic information, like session info, is only stored in memory structures (similar to C arrays) and Oracle can query these as if they were tables.
So no, the data was not in the buffer cache. It was already in system memory.

Similar Messages

  • 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

  • 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

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

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

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

  • Query 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)

  • 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

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

  • Physical reads and autotrace

    Hii all
    In http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:880343948514 tom gives an example table
    has a 320 block and the query "select * from table"
    autotrace output shows physical reads=46 the statics physical reads= number of block read from disk but table has 320 block how this could be ?
    Best regards..

    As Oracle has a buffer cache, Oracle will place blocks in buffer cache as soon as it needs it.
    When it needs those records subsequently, there will be a consistent get only.
    Logical I/O is predictable. Physical I/O depends on the size of the cache.
    There will never be a 1 on 1 relationship between size of a table and physical reads or you must disable the buffer cache.
    Clarifications about Asktom articles are also best asked at Asktom.
    Sybrand Bakker
    Senior Oracle DBA
    Experts: those who did read documentation.

  • Consistent Gets statistic

    I would like to get a better understanding of what exactly this statistic means. Oracle documentation states:
    Consistent Gets is the number of times a consistent read was requested for a block.
    Is the data included in Consistent Gets coming from a Rollback Segment of from a DB Cache?
    In the datawarehousing environment with very heavy reporting and ETL running at the same time, when Consistent Gets statistic is 5 times higher than Physical Reads, is that a reason for concern?

    In the datawarehousing environment with very heavy reporting and ETL running at the same time, when Consistent Gets statistic is 5 times higher than Physical Reads, is that a reason for concern? <<It doesn't sound relevant -- if your reporting is using parallel query then it is bypassing the buffer cache, hence a logical i/o against the table being parallel-scanned is going to be a physical i/o also. So, much would depend on how much use you are making of parallel query.
    The parallel query LIO/PIO effect is easy to demonstrate by querying a chunk of data twice with a noparallel hint and twice with a parallel hint, and having autotrace turned on. you'll see the PIO's drop down on the second execution of the noparallel query, but on the parallel query they'll remain pretty much the same on the second execution.

  • Consistent gets

    Hi,
    Working on 12c. Run the following query two times to check the consistent gets
    First time it is 242 and second time it is 15.
    SQL> set autotrace traceonly
    SQL> select * from employees;
    107 rows selected.
    Execution Plan
    Plan hash value: 1445457117
    | Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |           |   107 |  6634 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| EMPLOYEES |   107 |  6634 |     3   (0)| 00:00:01 |
    Statistics
            125  recursive calls
              0  db block gets
            247  consistent gets
             11  physical reads
              0  redo size
          10499  bytes sent via SQL*Net to client
            621  bytes received via SQL*Net from client
              9  SQL*Net roundtrips to/from client
              6  sorts (memory)
              0  sorts (disk)
            107  rows processed
    SQL>/
    Execution Plan
    Plan hash value: 1445457117
    | Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |           |   107 |  6634 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| EMPLOYEES |   107 |  6634 |     3   (0)| 00:00:01 |
    Statistics
              0  recursive calls
              0  db block gets
             15  consistent gets
              0  physical reads
              0  redo size
          10499  bytes sent via SQL*Net to client
            621  bytes received via SQL*Net from client
              9  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
            107  rows processed
    FYI..
    From dba_tables, block=5 , empty blocks 3 and arraysize =15
    Can you please help me to know that how consistent gets is being calculated?
    Thanks,

    >Can you please help me to know that how consistent gets is being calculated?
    why does it matter?
    how will you act differently after you have the answer/

  • Consistent Gets Doubt

    Hello,
    Consistent Gets

    Aman.... wrote:
    Well, as I said before, there is an overhead that would be always there, ALWAYS, when you would be reading the data from the table and this would be there with per execution! What does this mean that whenever you would read the data of the query, oracle would read the extent map of the table and for this , would incur additional ios and then will start fetching the data of the table. This overhead is going to be there when you have the data or won't have the data in the table. See the below demo and tell me what you have understood, forget your demo for a moment,I understood the point that there will ALWAYS be overhead but I am trying to find out how much of the total work is overhead.
    Not sure what you are trying to show with your demo. It is similar to my test case except with more data spread over multiple blocks (which I want to avoid)
    So here is your demo, executed on my environment
    SQL> select * from v$version ;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE     10.2.0.1.0     Production
    TNS for Linux: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    SQL> drop table t_new purge ;
    Table dropped.
    SQL> create table t_new(a number) ;
    Table created.
    SQL> exec dbms_stats.gather_table_stats(user, 'T_NEW') ;
    SQL> exec hr.show_space('T_NEW','HR') ;
    Unformatted Blocks .....................            0
    FS1 Blocks (0-25)  .....................            0
    FS2 Blocks (25-50) .....................            0
    FS3 Blocks (50-75) .....................            0
    FS4 Blocks (75-100).....................            0
    Full Blocks        .....................            0
    Total Blocks............................            8
    Total Bytes.............................       65,536
    Total MBytes............................            0
    Unused Blocks...........................            5
    Unused Bytes............................       40,960
    Last Used Ext FileId....................            6
    Last Used Ext BlockId...................          169
    Last Used Block.........................            3
    PL/SQL procedure successfully completed.
    SQL> set autotrace traceonly statistics
    SQL> select * from t_new ;
    no rows selected
    Statistics
              1  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            270  bytes sent via SQL*Net to client
            374  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> /
    no rows selected
    Statistics
              0  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            270  bytes sent via SQL*Net to client
            374  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> select count(*) from t_new ;
    Statistics
              1  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            410  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> /
    Statistics
              0  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            410  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> set autotrace off
    SQL> begin
      2  for i in 1..1000 loop
      3    insert into t_new values (i);
      4  end loop;
      5  end;
      6  /
    PL/SQL procedure successfully completed.
    SQL> commit ;
    Commit complete.
    SQL> exec dbms_stats.gather_table_stats(user, 'T_NEW') ;
    PL/SQL procedure successfully completed.
    SQL> exec hr.show_space('T_NEW','HR') ;
    Unformatted Blocks .....................            0
    FS1 Blocks (0-25)  .....................            0
    FS2 Blocks (25-50) .....................            0
    FS3 Blocks (50-75) .....................            0
    FS4 Blocks (75-100).....................            4
    Full Blocks        .....................            1
    Total Blocks............................            8
    Total Bytes.............................       65,536
    Total MBytes............................            0
    Unused Blocks...........................            0
    Unused Bytes............................            0
    Last Used Ext FileId....................            6
    Last Used Ext BlockId...................          169
    Last Used Block.........................            8
    PL/SQL procedure successfully completed.
    SQL> show arrays
    arraysize 100
    SQL> set autotrace traceonly statistics
    SQL> select * from t_new ;
    1000 rows selected.
    Statistics
              0  recursive calls
              0  db block gets
             17  consistent gets
              0  physical reads
              0  redo size
          10495  bytes sent via SQL*Net to client
            484  bytes received via SQL*Net from client
             11  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
           1000  rows processed
    SQL> select count(*) from t_new ;
    Statistics
              0  recursive calls
              0  db block gets
              7  consistent gets
              0  physical reads
              0  redo size
            411  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    SQL> set autotrace off
    SQL> select blocks,empty_blocks from user_tables where table_name = 'T_NEW' ;
        BLOCKS EMPTY_BLOCKS
             5            0
    SQL> select count(distinct dbms_rowid.rowid_block_number(rowid)) from t_new ;
    COUNT(DISTINCTDBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID))
                                                      2

  • Define - consistent_gets, db_block_gets, physical reads

    Hi
    Can anybody explain the components we use for
    Buffer Hit Ratio consistent_gets, db_block_gets,
    physical reads ? They all measured in terms of blocks
    or no of counts of reads/fetches ?
    Still I am not clear with consistent_gets and db_block_gets
    I have read some articles of good authors.
    They say db_block_gets consists of physical/logical
    gets. If they represent different units of measurements
    how can we arrive at Hit ratio ?
    S.D.RAVICHANDRAN
    Verizon.

    Hi
    I browsed ora-faq site and got the below answer :
    Consistent get = The blocks which is bound to change
    dynamically due to updations and in order to retain
    its previous image it has to visit undo segment and
    maintain its originallity. It involves CPU. That's why
    sometimes LIO is costly and engages CPU.
    db_block_get = No above change happens.
    This is my simple understanding. You can add if
    you deem fit.
    Ravichandran
    Verizon.

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

Maybe you are looking for

  • How can i take the music off my ipod touch/iphone 3gs and put it on my itunes account without deleting the music

    I have a Ipod touch and a Iphone 3gs with music that i want to put on my Iphone 4s. How can i put music from each one onto my itunes without itunes trying to delete it?????

  • Stms configuration

    HI all,                I am trying to import the data from dev server but i got the error message " Transport control program tp ended with error code 0212"  Errors: could not access file as supposed (see SLOG for more info) i think its becase of the

  • Multiple screens

    I have a main screen with 2 panels, one is Static and will be used for Buttons, ComboBox�s etc.. I want the other panel to be able to load in different frames so that I don�t have to load up a new screen each time. (Eg Wingows Media Player, static pa

  • How to customize mode_show_about in a custom portlet?

    I have created a custom PL/SQL portlet. I have set the has_help flag to true and have created a page under the p_portlet_record.exec_mode = wwpro_api_provider.MODE_SHOW_HELP. When you click on the help link from the portlet header, the page that you

  • Unable to Install Adobe Flash Player

    I am having a diificult time trying to install Adobe Flash Player. I am running a Windows Vista Operating Sys. Once the download begins, it acts as if it is ready to download..and then a message pops up and says Error: Unable to load GUI..I have no i