有关延迟块儿清除、快照过旧、读一致的总结

有关延迟块儿清除、快照过旧、读一致的总结,希望把这三个知识点串联一起做个总结,没有巨细无遗的写完每个地方,欢迎大家一起讨论,如果有前辈指出错误的地方更是不胜感激。

Blockcleanout 并不是指把脏块儿写入磁盘,只是单纯的指把DB buffer中一个块从 dirty 变为 clean,表明这个块里面的数据是干净的、最新的,本质上是更新 block header 中的一个标志位——ITL(Interested Transaction List)和block
SCN。



什么是delayed block cleanout?

每当事务commit 时,事务修改过的块儿就会被 cleanout,不过Clean out有2种方式:fast commit cleanout和delayed blockcleanout。

1.fastcommit cleanout 算是真正意义上的 cleanout,当做fast commit cleanout时,Oracle将事务commit
时的系统scn作为commitSCN,马上更新block上 ITL 、block scn 和 undo segment header的Transaction table的slot(槽)上的 scn,三者是一致的。

2.delayedblock cleanout 是将 cleanout 操作延后了,由于某些原因只是用commit SCN更新了undo segment header 的 Transaction table 上的slot scn,而并未做block上的更新,等待下次使用此block的时候,再用undo
segment header 的 Transaction table 上的slot scn(与之前事务的commit SCN相同)去更新 block scn 和 ITL。(当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时需要在读入后完成块清除)



为什么要执行delayed block cleanout呢?

这是出于性能考虑的,我们首先来看哪些块会做delayed block cleanout

前提:Oracle有一个modifiedblock list 结构(checkpoint queue机制?),用来记录每个transaction更改过的block,每个transaction可以在这个list上面记录大约10%buffercache这多的modified
block。

事务commit 时:

  • 更改过的block低于10%,则oracle可以根据modified
    block list定位到那些块并做fast commit cleanout。
  • 更改过的block超过10%,则超出部分就做delayed
    block cleanout。
  • 未commit前,由于事务耗时太长已经被写至磁盘的块做delayed block cleanout。

这里就可以看出,不立即cleanout 的原因有二,但本质都是不能立刻在DB buffer中找到对应的块儿,前者是超出10%,没有在list中记录,后者是已经写入磁盘,如果再重新读回DB buffer再修改,IO太多,都影响性能。



和快照过旧是什么关系?

前提:别的会话用过这个块儿(clean),或者正在占用这个块儿(dirty),都会在块儿上记录ITL(itl、xid、flag、uda、scn\fsc)。

1.当发出一条select语句时,ORACLE会记录下这个时刻SCN,然后在buffer cache中查找需要的BLOCK,或者从磁盘上读。

2.首先要查看最近一个修改这个块的事务的flag,如果需要cleanout 就马上执行。如果执行成功或者不需要执行就接着比较ITLSCN和select SCN,如果ITL SCN > select SCN,证明块儿的版本是比要select的新,要执行读一致找旧版本。

3.ORACLE就会根据ITL中的uba找到UNDO信息获得该block的前镜像,然后在buffercache 中构造出CR块,此时ORALCE也会检查构造出来的CR块儿中ITL记录的SCN,如果SCN还大于select时刻的SCN,那么一直重复构造前镜像,直到找到需要的块儿,这样ORACLE就实现了多版本。但如果在构造前镜像的过程中所需的UNDO信息被覆盖了,就会报快照过旧的错误。所以简单来说,是利用递推方式去找到和自己select同一SCN的那个块儿的版本,如果找不到就是快照过旧。

而对于延迟清除的块儿,尽管对应的事务已经commit,但自己本身还是dirty状态。之前commit的时候只是更新undo segment header的Transaction table的slot(槽)上的 scn,而块儿自己的itl 和 block scn却没有更新。当再次访问到这个块儿的时候,肯定要完成剩余的工作,即上面第二步说的马上cleanout——更新这个块儿的itl scn
和 blockscn。之前说过,如果clean执行成功就接着比较ITL SCN和selectSCN来决定是否需要要执行读一致。但如果因为undo被覆盖,就获得不了commit SCN,连cleanout也不能执行,也就比较不了大小了。报错还是快照过旧。

时间: 2024-08-28 18:14:33

有关延迟块儿清除、快照过旧、读一致的总结的相关文章

Oracle ORA-01555 快照过旧 说明

oracle高级知识(1) ORA-01555 快照过旧,是数据库中很常见的一个错误,比如当我们的事务需要使用undo来构建CR块的时候,而此时对应的undo 已经不存在了, 这个时候就会报ORA-01555的错误. 有关CR 块,参考我的Blog: CR (consistent read) blocks create 说明 http://blog.csdn.net/xujinyang/article/details/6823237 老熊Blog上的一个链接: http://www.laoxio

oracle 11g rac ORA-01555 快照过旧报错处理

ORA-01555 快照过旧,是数据库中很常见的一个错误,比如当我们的事务需要使用undo来构建CR块的时候, 而此时对应的undo 已经不存在了, 这个时候就会报ORA-01555的错误. 环境是Oracle 11g RAC 由于客户执行一个比较复杂的SQL,使用PLSQL运行了88分钟后出现报错,这是一个要查看报表的SQL. 临时的处理方法如下: 以下为虚拟机模拟操作,建议数据库安装的时候这个参数一定要提前调整优化一下,不要使用默认值. [[email protected] ~]# su -

深入解析direct path read (转)

文章转自:http://www.itpub.net/thread-1815281-1-1.html 传统读取数据的方式是服务器进程通过读取磁盘,然后把数据加载到共享内存中,这样后面的进程就可以通过共享内存访问这些数据,不用再通过缓慢的磁盘读取来完成.direct path read读取数据块方式,是指服务器进程直接读取数据文件,不经过buffer cache,这种方式读取的数据块会加载到服务器进程的PGA内中当中,不会进入buffer cache中.11G之前的direct path read主

nolock的替代方案-提交读快照隔离[行版本控制]

with(nolock)并意味着没有锁,实际上在查询一张表时,还是有锁,会对对象增加架构锁, 防止表会修改,会对数据库增加共享锁.若使用drop index,则要等到架构锁释放. sql server2005提供了快照隔离和读取已提交快照这两种新的不加锁.无阻塞的事务隔离级别,可使用 快照:每次从数据进行修改时,会在teampdb上存储上一版本 好处: select不要求锁,会大大降低整个库的锁负载量 nolock会读取到未提交事务时修改的数据,而读快照读取的是修改之前的数据,故nolock易读

转:nolock的替代方案-提交读快照隔离[行版本控制]

with(nolock)并意味着没有锁,实际上在查询一张表时,还是有锁,会对对象增加架构锁, 防止表会修改,会对数据库增加共享锁.若使用drop index,则要等到架构锁释放. sql server2005提供了快照隔离和读取已提交快照这两种新的不加锁.无阻塞的事务隔离级别,可使用 快照:每次从数据进行修改时,会在teampdb上存储上一版本 好处: select不要求锁,会大大降低整个库的锁负载量 nolock会读取到未提交事务时修改的数据,而读快照读取的是修改之前的数据,故nolock易读

由读一致性分析undo

下面通过undo的一致性读分析undo: [[email protected] ~]$ lsb_release -a LSB Version:    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: EnterpriseEnterpriseServer Description:    Enterprise Linux Enterprise Linux Server releas

MVCC SQLSERVER的快照隔离级别

MVCC SQLSERVER的快照隔离级别 MVCC 产品简介编辑 Multi-Version Concurrency Control 多版本并发控制 大多数的MySQL事务型存储引擎,如InnoDB,Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和另外一种用来增加并发性的被称为“多版本并发控制(MVCC)”的机制来一起使用.MVCC不只使用在MySQL中,Oracle.PostgreSQL,以及其他一些数据库系统也同样使用它. 你可将MVCC看成行级别锁的一种妥协,它在许多

[译]MySQL不加锁实现一致性读的机制分析

原文直通车:Consistent Nonlocking Reads   MySQL的一致性读的机制是是这样实现的:InnoDB引擎为一个事务Tx提供一个在时间T1的版本快照(T1就是在本 事务中首次执行查询语句的时间点).事务Tx中可以查询到时间点T1之前提交的数据,时间点T1之后提交的数据在 Tx中是看不到的.唯一的例外Ex是在事务Tx中可以看到在本事务中提交的数据(即便是在T1时间点还没有提交的数据).   先建一个表,边理论边实践,具体看下MySQL是如何工作的. mysql> creat

UNDO三大作用与一致性读机制浅析

UNDO三大作用1.一致性读(consistent read)2.事务回滚(Rollback Transaction)3.实例恢复(Instance Recovery) 一致性读当会话发出一条SQL查询,将当前时间的SCN号记录下来,当进程扫描到表T的数据块,再与该块头部的ITL槽(事务槽)的SCN号比较,如果发现该块SCN号较小,则该块没有被更新过所以可用:如果该块SCN号较大,则该块被更新过,要借助UNDO块了,该块的ITL槽会记录了对应的UNDO块的地址,就取出对应的UNDO块,如果发现该