同样一条SQL ,有的时候 buffer get 会暴增?! Oracle-L 中有人提了一个这样的问题：

I have a batch process that executes individual transactions, normally
a transaccion e.g. a simple select would take 8-10 buffer gets but in
the batch processing it takes 45 buffer gets.

Zhu Chao (Chao_ping,这家伙现在一篇文章都不写，只能从邮件列表里看到他的踪迹) 给了一个解释：

the job is processing some very hot blocks. So it always need to reverse back and find the CR block from buffer, so it will generate some more buffer gets for that execution.

如果是因为Hot Block 的原因,那么主要的症状应该是 Wait. 如果这个 SQL 在运行的时候数据已经发生了变化,那么为了维持一致性不可避免的会生成回滚,所以这个解释更为准确一些:

If a query does a consistent get on a block that has been changed since that query began or that had uncommitted changes at the time that that query began, then it is necessary to rollback those changes for read consistency. The consistent changes statistics counts the number changes rolled back. However, most consistent gets do not require any such rollback, and so it is normal for the number of consistent gets to be much greater than the number of consistent changes. This is reflected in the no work – consistent read gets statistic

我们不妨来做个例子.假定我们现在有两个Session,首先在第一个窗口做如下操作

继续阅读 →