consistent gets

前段时间在测试高级压缩在IO方面性能的时候发现一个疑问，先看看当时的场景

SQL> select table_name,num_rows,blocks from user_tab_statistics where table_name in('COMTAB'
,'NOCOMTAB');
TABLE_NAME           NUM_ROWS     BLOCKS
------------------------------ ---------- ----------
COMTAB                  71991    342
NOCOMTAB                71992   1051

这是两个表最新的统计信息，数据完全一样(差那一条是建表先后顺序造成的)，comtab是启用高级压缩的，nocomtab没有压缩，下面看看两个表的全表扫描情况

SQL> set autotrace trace
SQL> select * from comtab;71991 rows selected.Execution Plan
----------------------------------------------------------
Plan hash value: 1463407995----------------------------------------------------------------------------
| Id  | Operation     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 71991 |  6819K|    95   (2)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| COMTAB | 71991 |  6819K|    95   (2)| 00:00:02 |
----------------------------------------------------------------------------Statistics
----------------------------------------------------------1  recursive calls0  db block gets5109  consistent gets0  physical reads0  redo size3720394  bytes sent via SQL*Net to client53313  bytes received via SQL*Net from client4801  SQL*Net roundtrips to/from client0  sorts (memory)0  sorts (disk)71991  rows processedSQL> select * from nocomtab;71992 rows selected.Execution Plan
----------------------------------------------------------
Plan hash value: 754113270------------------------------------------------------------------------------
| Id  | Operation     | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 71992 |  6819K|   287   (1)| 00:00:04 |
|   1 |  TABLE ACCESS FULL| NOCOMTAB | 71992 |  6819K|   287   (1)| 00:00:04 |
------------------------------------------------------------------------------Statistics
----------------------------------------------------------1  recursive calls0  db block gets5768  consistent gets0  physical reads0  redo size8254868  bytes sent via SQL*Net to client53313  bytes received via SQL*Net from client4801  SQL*Net roundtrips to/from client0  sorts (memory)0  sorts (disk)71992  rows processed

刚开始我认为两个表在数据块数量相差如此大的情况下，consistent gets的数量应该也有相当大的差距，但是现在看来，差距是有，却不是那么明显，很多疑问也出来了

1，consistent gets到底是次数还是块数？

2，consistent gets是怎么计算的？

3，三百多数据块为什么产生五千多的一致性读？

4，两个表的数据块比例达到了1/3，一致性读的比例却接近1/1？

块数or次数

以前我只关心consistent gets前面的数值，至于数值后面的单位是什么，根本没去管，现在这么个情况不管不行了，在我个人看来，我更倾向于consistent gets是一致性读次数，而不是块数，就拿这个例子来说，全部数据才300多个数据块，oracle扫描300多个数据块不至于递归调用5000多数据块吧，所以我认为是这5000多是一致性读次数，后面会有实验证明

consistent gets计算

在查询操作中，oracle按照执行计划去读取数据块，数据块只能存在两个地方，内存和磁盘，对应的也就是逻辑读和物理读，consistent gets就是数据库在内存中为了获取指定的数据产生的一致性读次数，而不是块数，同一个数据块可以读多次而不是获取多次，一致性读概念这里就不解释了，在全表扫描中，理想情况下consistent gets应该和表的总数据块数差不多或者接近，下面做个测试

创建一个表，插入一条数据

SQL> create table test01 as select * from dba_objects where rownum=1;Table created.SQL> begin2  dbms_stats.gather_table_stats(3  ownname => user,4  tabname => 'test01');5  end;6  /PL/SQL procedure successfully completed.

test01占用4个数据块

SQL> select table_name,num_rows,blocks from user_tab_statistics where table_name='TEST01';TABLE_NAME            NUM_ROWS     BLOCKS
------------------------------ ---------- ----------
TEST01                  1      4

执行全表扫描

SQL> set autotrace trace
SQL> select * from test01;Execution Plan
----------------------------------------------------------
Plan hash value: 262542483----------------------------------------------------------------------------
| Id  | Operation     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    |     1 |    73 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| TEST01 |     1 |    73 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------Statistics
----------------------------------------------------------1  recursive calls0  db block gets3  consistent gets0  physical reads0  redo size1608  bytes sent via SQL*Net to client524  bytes received via SQL*Net from client2  SQL*Net roundtrips to/from client0  sorts (memory)0  sorts (disk)1  rows processed

4个数据块，3个consistent gets，这才是我们想要的效果，那之前300多个数据块5000多次一致性读是怎么回事呢，后来查阅资料发现，oracle从数据库读取数据行发送给sqlplus客户端的时候有个参数设置，这个参数就是arraysize，用来控制每次读取数据的行数，在sqlplus里面默认是15

SQL> show arraysize
arraysize 15

现在来计算一下前面那个5109个consistent gets怎么来的

数据行：71991

数据块：342

arraysize：15

总读取次数：71991/15 = 4800

总读取次数：4800 + 342 = 5142

这个数值已经很接近consistent gets了，而且全表扫描时表的数据块不会被全部读进内存，这样计算出来的值跟一致性读的值就更吻合了

现在改变arrarysize这个参数，看看consistent gets会有什么变化

SQL> set arraysize 100
SQL> select * from comtab;71991 rows selected.Execution Plan
----------------------------------------------------------
Plan hash value: 1463407995----------------------------------------------------------------------------
| Id  | Operation     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 71991 |  6819K|    95   (2)| 00:00:02 |
|   1 |  TABLE ACCESS FULL| COMTAB | 71991 |  6819K|    95   (2)| 00:00:02 |
----------------------------------------------------------------------------Statistics
----------------------------------------------------------0  recursive calls0  db block gets1047  consistent gets0  physical reads0  redo size2973754  bytes sent via SQL*Net to client8432  bytes received via SQL*Net from client721  SQL*Net roundtrips to/from client0  sorts (memory)0  sorts (disk)71991  rows processed

计算：71991/100=720 ， 720 + 342 = 1062
增加arraysize大小，可以显著减少逻辑读次数，网络开销也有减少，同时也能看出，由于arraysize只有15，前面那两个5000多逻辑读的场景，大部分逻辑读是在不停的扫描同一个数据块获取数据，arraysize只在sqlplus客户端中用，其他地方使用fetch size，该参数大小设置影响客户端和服务器内存的占用，应根据实际环境配置，总之不是越大越好。

至此，疑问也基本上理清了

1，consistent gets是次数，认为是块数也行，不过可能会包含同一个块的重复计数

2，这个数据库没有对这个表做DML操作，所以consistent gets没有包括undo块

3，5000多逻辑读有4800个是由于arraysize参数设置引起的

4，还是arraysize问题，如果设置成5000，比例就差不多了

consistent gets相关推荐

一致性 hash 算法（ consistent hashing ）
原文地址:http://blog.csdn.net/sparkliang/article/details/5279393 consistent hashing 算法早在 1997 年就在论文 Cons ...
一致性哈希(Consistent Hashing)
在大型web应用中,缓存可算是当今的一个标准开发配置了.在大规模的缓存应用中,应运而生了分布式缓存系统.分布式缓存系统的基本原理,大家也有所耳闻.key-value如何均匀的分散到集群中?说到此,最常 ...
关于consistent hash的思考及改进方案
这里默认读者已经知道了一致性hash算法的原理. 1. 为什么在某台机器宕机之后consistent hash算法能够避免所有或者大部分key重新hash? 首先需要弄清的是,如果某一台机器宕机之后, ...
聊聊jump consistent hash
序本文主要简介一下jump Consistent hash. jump consistent hash jump consistent hash是一致性哈希的一种实现,论文见A Fast, Mini ...
An eventually consistent data model for Erlang (and Riak)
CAP理论指出:一个分布式系统不可能同时满足一致性(Consistency).可用性(Availibility)和分区容忍性(Partition Tolerance)这三个需求,最多只能同时满足其中的 ...
【异常】 Ensure that config phoenix.schema.isNamespaceMappingEnabled is consistent on client and server.
[异常] Ensure that config phoenix.schema.isNamespaceMappingEnabled is consistent on client and server. ...
一致性hash算法 - consistent hashing
参考: http://yacare.iteye.com/blog/1973022 1. 情景分析前一篇博文分析了HashMap源码,HashMap在许多场景中作为存储数据的不二选择. 但是否使用 ...
consistent gets在Oracle使用特例
Oracle数据库中,consistent gets在判断一段SQL的性能时非常有用,通常来讲比较两段SQL的性能好坏不是看谁的执行时间短,而是看谁的consistent gets小.不过这也不是绝对 ...
转载：一致性 hash 算法（ consistent hashing ）
转载:http://blog.csdn.net/sparkliang/article/details/5279393 ...
主从mysql replication 集群的sharding memcache集群使用consistent hash
sharding 实现跨越DB的分区与扩展功能 consistent hash 一致哈希实现memcache的扩展 http://cache.baidu.com/c?m=9f65cb4a8c8507e ...

consistent gets

consistent gets相关推荐

最新文章

热门文章