构造一致性读,
ORACLE需要做的工作:
1)克隆这个块到另一个buffer,克隆的块跟之前的current块在一个HASH CHAIN上。我们后面的四个步骤,就是发生在新克隆的块上的。
2)如果这个块上存在 延迟块清除或者快速块清除,那么对它进行块清除的动作。
3)对于块上所有未提交的事务进行块级别的回滚,注意这里并不是回滚整个事务,而是只针对事务里修改了这个块的操作进行回滚。
4)检查ITL槽位里,COMMIT SCN有没有大于查询时刻SCN(snapshot SCN)的条目,如果有的话,对这个条目涉及到的事务进行块级别的回滚(类似步骤3)。
5)如果回滚后,ITL槽位里依然有大于查询时刻SCN的条目,重复步骤四。
1)克隆这个块到另一个buffer,克隆的块跟之前的current块在一个HASH CHAIN上。我们后面的四个步骤,就是发生在新克隆的块上的。
2)如果这个块上存在 延迟块清除或者快速块清除,那么对它进行块清除的动作。
3)对于块上所有未提交的事务进行块级别的回滚,注意这里并不是回滚整个事务,而是只针对事务里修改了这个块的操作进行回滚。
4)检查ITL槽位里,COMMIT SCN有没有大于查询时刻SCN(snapshot SCN)的条目,如果有的话,对这个条目涉及到的事务进行块级别的回滚(类似步骤3)。
5)如果回滚后,ITL槽位里依然有大于查询时刻SCN的条目,重复步骤四。
有几点需要说明:
1)构造一致性读发生在克隆块上,不产生日志。但是在步骤2上,虽然科隆块不产生日志,但是current block由于也需要做块清除,所以会产生日志。
2)步骤四可能会发生多次。如果查询耗时较长,在读取到某个块前,N个事务已经对它做了修改提交,那么这个块就要发生N次步骤4的操作。
3)构造出来的一致性读的块一般由于TCH数很小很容易被LUR算法抛弃重用。
4)一致性读取回滚的只是这个块,假如一个事务修改了1000个块,产生了1000个undo record,但是只有1个undo recored是这个块产生的,那么oracle能够根据ITL槽位里记录的UBA快速的识别到这个undo record,而其他的999条,不会读取。
1)构造一致性读发生在克隆块上,不产生日志。但是在步骤2上,虽然科隆块不产生日志,但是current block由于也需要做块清除,所以会产生日志。
2)步骤四可能会发生多次。如果查询耗时较长,在读取到某个块前,N个事务已经对它做了修改提交,那么这个块就要发生N次步骤4的操作。
3)构造出来的一致性读的块一般由于TCH数很小很容易被LUR算法抛弃重用。
4)一致性读取回滚的只是这个块,假如一个事务修改了1000个块,产生了1000个undo record,但是只有1个undo recored是这个块产生的,那么oracle能够根据ITL槽位里记录的UBA快速的识别到这个undo record,而其他的999条,不会读取。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27210518/viewspace-738192/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/27210518/viewspace-738192/