玉面飞龙的BLOG

有些情况下，一致读consistent gets 会导致Index Scan的性能下降很多。尤其在OLTP的数据库环境中，如果应用设计的不科学，会导致走Index Scan的SQL语句的buffer gets成倍的增长。

测试如下,

Session 1 运行
SQL> create table t as select * from dba_objects;
Table created.
SQL> create index tidx on t(owner,object_name);
Index created.
SQL> select count(*) from t;
COUNT(*)
———-
9674

Session 2 作Index Range Scan，consistent gets正常

SQL> set autotrace on
SQL> select count(*) from t where owner=’SYS’ and object_name>’F';
COUNT(*)
———-
3030
Execution Plan
———————————————————-
0      SELECT STATEMENT Optimizer=RULE
1    0   SORT (AGGREGATE)
2    1     INDEX (RANGE SCAN) OF ‘TIDX’ (NON-UNIQUE)
Statistics
———————————————————-
0  recursive calls
0  db block gets
21  consistent gets
5  physical reads
188  redo size

Session 1 再做些批量的数据更新，但并不提交

SQL> insert into t select * from t ;
9674 rows created.
SQL> /
19348 rows created.

Session 2 再次查询，因为一致读的原因导致consistet gets异常猛增

SQL> set autotrace on
SQL> select count(*) from t where owner=’SYS’ and object_name>’F';
COUNT(*)
———-
3030
Statistics
—————————————–
0  recursive calls
0  db block gets
746  consistent gets
0  physical reads

Session 1 提交事务

SQL> commit;
Commit complete.

Session 2 再次查询,consistent gets恢复正常

SQL> /
COUNT(*)
———-
12120
Statistics
———————————————————-
0  recursive calls
0  db block gets
66  consistent gets
0  physical reads

当consistent gets异常增加的时候，从v$mystat中可以看到‘data blocks consistent reads - undo records applied’增加很多.它的解释是”Number of undo records applied to data blocks that have been rolled back for consistent read purposes”.

在应用并行Session较多的情况下，如果应用既需要批量更新数据，又需要根据索引查询该表，则发生过多undo records applied的可能性越大。

解决的方法就是，分隔开批量更新和OLTP查询，或者批量更新快速提交。