Consistant gets query

Hi all,
I have a query about consistant gets. When we see statistics or the output when autotrace is on, we see a value "consistant gets".
According to docs, its the number of blocks read in "consistant read" mode. I am confused here.
Say, a query began to run. The process looked through the database buffers for data, for a SCN number. Lets say, the result of my query was in 1000 blocks. Out of which 500 were taken by rolling back some data, as it was mofified by another process while my query was executing.
Now, should we say Buffer Gets=500 and Consistant gets=500
OR
all 1000 blocks were consistant gets.
If I am getting too many consistant gets, what should I do ? increase DB_BLOCK_BUFFERS ( DB_CACHE_SIZE in 9i ) ? or what ?
Please explain.
Regards

For any SELECT query, all reads will be done as consistent gets. A consistent get means that Oracle is reading the blocks (whether out of cache or from disk) at a particular point in time. It may or may not need to look into rollback segments to so this. In a query, the read is consistent as at the time your query started
A block get is a read of the current value of a block. Typically, when Oracle reads the data dictionary (not you querying, but Oracle reading it as recursive sql) it reads the current values. Also, when you do an update, Oracle will use consistent gets to find the candidate rows, then a block get just before updating.
In your example, all 1000 blocks would be consistent gets, although there may be a few block gets as well, particularly if Oracle needed to do physical reads.
If you are getting too many consistent gets (actually logical I/O's) then you need to re-write the query to be more efficient. Although, the question of what is "too many" is often very difficult to answer.
HTH
John

Similar Messages

Consistent gets are reduced by 50% but the query taking more elapsed time.

Hi All,
While tuning a application my consistent gets are reduced by 50% but the query is still taking the same time.
In a Warehouse env data is coming from With clause that is having some 40000 rows .Then these 40K rows are joined to a table that is having 2 Billion records having indexes on primary key and date column(bitmap)indexes .
It is using Hash Joining method.

Try forcing a hash join, if possible:
http://dba-oracle.com/tips_oracle_hash_joins.htm
Can you post the plans?
http://www.dba-oracle.com/plsql/t_plsql_plans.htm

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)

Consistent gets are reduced by 50% but the query is still taking the same t

Hi ,
I am tuning a query in DWH env using a WITH clause .Doing that my consistent gets are reduced by 50% but the elapsed time in increased.
In that one 40000 rows are coming from WITH clause and joined with a table having 250000000 rows joined through Hash join.
can anybody help me out in this issue.
Thanx
Nitin

NitinMishra wrote:
Hi ,
I am tuning a query in DWH env using a WITH clause .Doing that my consistent gets are reduced by 50% but the elapsed time in increased.Unusual! Normally time goes, down when system resources do - but not always as you are seeing :(. Last time I saw something like this the reads had gone down but the CPU usage had gone up. You can get CPU usage from V$SQL.
Can you post the query, the execution plan, and statistics - both before and after the tuning?

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

Trying to understand consistent gets

1. We were very surprised to observe that the consistent gets for a query (shown below) changed (from 120K to 18K) when the only modification was adding a comment to it. How can this happen?
2. Furthermore, the plans for the two queries were identical. How can consistent gets differ if the plan is the same?
3. Is consistent gets the best metric for comparing the performance of two versions of a query, or is there a better one? (In the past we've tried to use execution timing for comparison, but the timing of a single query can vary greatly between runs.)
select
       count(*) from (
SELECT source_id, project_id,
       max_score,
       fields_matched
FROM (SELECT source_id, project_id, MAX(scoring) as max_score,
             apidb.tab_to_string(set(CAST(COLLECT(table_name) AS apidb.varchartab)), ', ') fields_matched,
             max(index_name) keep (dense_rank first order by scoring desc, source_id, table_name) as index_name,
             max(oracle_rowid) keep (dense_rank first order by scoring desc, source_id, table_name) as oracle_rowid
      FROM ( SELECT SCORE(1) * (select nvl(max(weight), 1) from apidb.TableWeight where table_name = 'Blastp')
                       as scoring,
                    'apidb.blastp_text_ix' as index_name, b.rowid as oracle_rowid, b.source_id, b.project_id,
                    external_database_name as table_name
              FROM apidb.Blastp b
              WHERE CONTAINS(b.description, 'protein', 1) > 0
                AND 'Blastp' IN ('Product', 'Notes', 'Comments', 'InterPro', 'EcNumber', 'GoTerms', 'Phenotype', 'Notes', 'and the rest')
                AND 'gene' = 'gene'
                AND b.pvalue_exp < -30
                AND b.query_organism IN ('Plasmodium falciparum', 'Plasmodium vivax', 'Plasmodium yoelii', 'Plasmodium berghei', 'Plasmodium chabaudi', 'Plasmodium knowlesi')
            UNION
              SELECT
                     SCORE(1)* nvl(tw.weight, 1)
                       as scoring,
                     'apidb.gene_text_ix' as index_name, gt.rowid as oracle_rowid, gt.source_id, gt.project_id, gt.field_name as table_name
              FROM apidb.GeneDetail gt, apidb.TableWeight tw, apidb.GeneAttributes ga
              WHERE CONTAINS(content, 'protein', 1) > 0
                AND gt.field_name IN ('Product', 'Notes', 'Comments', 'InterPro', 'EcNumber', 'GoTerms', 'Phenotype')
                AND 'gene' = 'gene'
                AND gt.field_name = tw.table_name(+)
                AND gt.source_id = ga.source_id
                AND ga.species IN ('Plasmodium falciparum', 'Plasmodium vivax', 'Plasmodium yoelii', 'Plasmodium berghei', 'Plasmodium chabaudi', 'Plasmodium knowlesi')
            UNION
              SELECT SCORE(1) * nvl(tw.weight, 1)
                       as scoring,
                    'apidb.isolate_text_ix' as index_name, wit.rowid as oracle_rowid, wit.source_id, wit.project_id, wit.field_name as table_name
              FROM apidb.IsolateDetail wit, apidb.TableWeight tw
              WHERE CONTAINS(content, 'protein', 1) > 0
                AND wit.field_name in ('fred')
                AND 'gene' = 'isolate'
                AND wit.field_name = tw.table_name(+)
      GROUP BY source_id, project_id
      ORDER BY max_score desc, source_id
);

1. We were very surprised to observe that the consistent gets for a query (shown below) changed (from 120K to 18K) when the only modification was adding a comment to it. How can this happen?Adding a comment and getting a different anything makes no sense, but you already know this. Did you toggle the comment on and off to see any changes in performance?
2. Furthermore, the plans for the two queries were identical. How can consistent gets differ if the plan is the same?Clearly something odd happened. Possibilities include
* wrong execution plan reported in one case (unlikely, but possible)
* system resource availability was different at different times
3. Is consistent gets the best metric for comparing the performance of two versions of a queryI use consistent gets, but also look at disk reads (not useful after data has been cached), CPU, and overall execution time. On rare occasions queries can be CPU-bound
Edited by: riedelme on Mar 3, 2010 1:06 PM

Consistent gets examination

" You have 3,847.1 consistent gets examination per second. "Consistent gets - examination" is different than regular consistent gets. It is used to read undo blocks for consistent read purposes, but also for the first part of an index read and hash cluster I/O. To reduce logical I/O, you may consider moving your indexes to a large blocksize tablespace. Because index splitting and spawning are controlled at the block level, a larger blocksize will result in a flatter index tree structure.
Can you explain the above and help me understand it?
What is index split and spawning? why does it happen and what is the fix?
Which indexes are affected? Is there a query to find out? What is an optimal block size to use for these affected index table spaces?

I'd strongly suggest you start reading the Oracle DBA manual to get a bit more basics behind you before you get into the advanced tuning stuff. It's at http://docs.oracle.com

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.

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.

Consistent gets are reduced but elapsed time is increased.

Hi All,
While tuning a application my consistent gets are reduced by 50% but the query is still taking the same time.
In a Warehouse env data is coming from With clause that is having some 40000 rows .Then these 40K rows are joined to a table that is having 2 Billion records having indexes on primary key and date column(bitmap)indexes .

This forum is for issues with the SQL Developer tool. You'd get more response in the General Database forum.
Have fun,
K.

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

What's "consistent gets - examination"?

http://www.dba-oracle.com/m_consistent_gets.htm
says it is a special consistent gets which only need one latch instead of 2 latches(for normal consistent gets). Could you anyone put more information on this? Under what condition which this stats happens? such as access the root block of the index?

user646745,
Thanks for supplying your test case to demonstrate your point.
My original comment was:
Blocks from a suitably defined single table hash cluster make another case because (if there have been no hash collisions) the location of the correct row-pointer is implied by the hash-key value requested.
You also need a unique index on the hash key (which won't be used for the access, even though it exists) and have to query with equality on the hash key.
I modified your test case to demonstrate this - running on 9.2.0.8:
SQL> set echo on
SQL> @temp
SQL> drop table t_hashed;
Table dropped.
SQL> drop cluster hash_cluster;
Cluster dropped.
SQL>
SQL> create cluster hash_cluster
2 ( hash_key number(10) )
3 hashkeys 100
4 size 60
5 single table
6 hash is HASH_KEY;
Cluster created.
SQL>
SQL> create table t_hashed
2 cluster hash_cluster(a)
3 as
4 select cast( rownum as number(10) ) a from all_objects where rownum <= 100;
Table created.
SQL>
SQL> create unique index t_pk on t_hashed(a);
Index created.
SQL> alter table t_hashed add constraint t_pk primary key (a);
Table altered.
SQL>
SQL> execute dbms_stats.gather_schema_stats('test_user', cascade=>true);
PL/SQL procedure successfully completed.
SQL>
SQL> select name,value from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like 'consistent%';
NAME                                                                  VALUE
consistent gets                                                        7393
consistent changes                                                       24
consistent gets - examination                                           611
3 rows selected.
SQL>
SQL> declare
2           a int;
3 begin
4           for i in 1 .. 10000 loop
5                select a into a from t_hashed where a = 1 + mod(i,100);
6           end loop;
7 end;
8 /
PL/SQL procedure successfully completed.
SQL>
SQL> select name,value from v$mystat a , v$statname b where a.STATISTIC#=b.STATISTIC# and b.NAME like 'consistent%';
NAME                                                                  VALUE
consistent gets                                                       17417
consistent changes                                                       24
consistent gets - examination                                         10620
3 rows selected.
SQL>
SQL>
SQL> ed temp.lst
SQL> spool offThe "examination" seems to be about doing a minimal amount of work while holding the latch - so reading every row from the block doesn't count.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking.

Consistant gets query

Similar Messages

Maybe you are looking for