对于实际的业务系统，通常有一些热点的表，insert和delete的量非常大，这个时候就会发现一些查询语句的逻辑读比较偏高，
这时可能就是oracle在构建一致性块的进行的consistent
read。
下面做一个测试看下：
第一步准备数据：
create table test(
col1 varchar2(12)
col2 number
ext varchar2(4000)
);
create index test_ind on test(user_id, col2);
create sequence seq_test cache 200;
这样这样的表，我们假设有频繁的插入和删除操作，那么下面来测试一下select的逻辑读的情况。
开启两个session:
1，创建表保存snapshot
在session1：
create table prefix_stats tablespace IW_ACCOUNT_LOG_01 as select * from v$sesstat where sid=&1;
2，在session2查询
select * from (select * from test t where col1 = ‘xpchild001‘ order by trans_log_id) where rownum <= 200;
3，在session1监控session2的统计信息
select *
from (select t.name,
pre.value as pre,
suf.value as suf,
(suf.value - pre.value) as diff
from prefix_stats pre, v$sesstat suf, v$statname t
where pre.sid = suf.sid
and pre.STATISTIC# = suf.STATISTIC#
and pre.STATISTIC# = t.STATISTIC#) tmp
where tmp.diff > 0
order by tmp.diff descName PRE SUF DIFF
---------------------------------------------------------------------- ---------- ---------- ----------
session pga memory max 957208 1153816 196608
session pga memory 957208 1153816 196608
bytes sent via SQL*Net to client 6692 37013 30321
redo size 0 8256 8256
session logical reads 52 1508 1456
consistent gets from cache 52 1508 1456
consistent gets 52 1508 1456
bytes received via SQL*Net from client 4385 5639 1254
consistent gets - examination 21 1253 1232
data blocks consistent reads - undo records applied 0 920 920
consistent changes 0 920 920
buffer is not pinned count 17 222 205
table fetch by rowid 6 206 200
buffer is pinned count 0 197 197
CR blocks created 0 160 160
calls to kcmgas 0 160 160
db block changes 0 120 120
redo entries 0 120 120
cleanout - number of ktugct calls 0 120 120
cleanouts and rollbacks - consistent read gets 0 120 120
immediate (CR) block cleanout applications 0 120 120
no work - consistent read gets 19 83 64
heap block compress 0 51 51
rollbacks only - consistent read gets 0 40 40
shared hash latch upgrades - no wait 0 5 5
user calls 28 33 5
execute count 21 23 2
DB time 0 2 2
parse count (total) 22 24 2
session cursor cache count 16 17 1
CPU used when call started 0 1 1
recursive calls 92 93 1
parse count (hard) 0 1 1
session cursor cache hits 4 5 1
CPU used by this session 0 1 1
这一次的查询，返回记录200条。table fetch by rowid=200;
1，逻辑读session logical reads=consistent gets（一致读)+db block
gets(当前读);
这个sql只有一致性读session logical reads=consistent gets=1456
2，构建一致性读应用回滚记录统计：data blocks consistent reads(undo records
applied)：920
等价于consistent changes。
3，需要回滚或者块清除产生的一致性读（这里边没有回滚，只可能有块清除）cleanouts and rollbacks - consistent read
gets：120
跟db block changes=120一致，这里进行了块清楚，从而改变了db block。
4，构建一致性读clone的块数：CR blocks created=160
5，块清除产生的redo：redo size 8256
验证了开始的猜测：大量的构建一致性读。
对于这样的热点表，通常有几种手动去调整，但核心都是要分散热点，减少争用。
- hash表，分散热点
- 调整pctfree，增加pctfred的大小。使用块中的记录数变少，减少构建一致性读的问题。
未完待续。。。