对于实际的业务系统,通常有一些热点的表,insert和delete的量非常大,这个时候就会发现一些查询语句的逻辑读比较偏高,
这时可能就是oracle在构建一致性块的进行的consistent
read。
下面做一个测试看下:
第一步准备数据:
create tabletest(
col1varchar2(12)
col2numberextvarchar2(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 (selectt.name,
pre.valueaspre,
suf.valueassuf,
(suf.value- pre.value) asdifffromprefix_stats pre, v$sesstat suf, v$statname twhere pre.sid =suf.sidand pre.STATISTIC# =suf.STATISTIC#and pre.STATISTIC# =t.STATISTIC#) tmpwhere tmp.diff > 0
order by tmp.diff descName PRE SUF DIFF---------------------------------------------------------------------- ---------- ---------- ----------
session pga memory max 957208 1153816 196608session pga memory957208 1153816 196608bytes sent via SQL*Net to client 6692 37013 30321redo size0 8256 8256session logical reads52 1508 1456consistent getsfrom cache 52 1508 1456consistent gets52 1508 1456bytes received via SQL*Net from client 4385 5639 1254consistent gets- examination 21 1253 1232data blocks consistent reads- undo records applied 0 920 920consistent changes0 920 920bufferis not pinned count 17 222 205
table fetch by rowid 6 206 200bufferis pinned count 0 197 197CR blocks created0 160 160callsto kcmgas 0 160 160db block changes0 120 120redo entries0 120 120cleanout- number of ktugct calls 0 120 120cleanoutsand rollbacks - consistent read gets 0 120 120immediate (CR) block cleanout applications0 120 120nowork - consistent read gets 19 83 64heap block compress0 51 51rollbacksonly - consistent read gets 0 40 40shared hash latch upgrades- no wait 0 5 5
user calls 28 33 5
execute count 21 23 2DB time0 2 2parsecount (total) 22 24 2sessioncursor cache count 16 17 1CPU usedwhen call started 0 1 1recursive calls92 93 1parsecount (hard) 0 1 1sessioncursor cache hits 4 5 1CPU usedby 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的大小。使用块中的记录数变少,减少构建一致性读的问题。
未完待续。。。
原文:http://www.cnblogs.com/xpchild/p/3694987.html