块清除

一般的清除是COMMIT清除，当需要修改（DML）的块大于BUFFER CACHE的10%的时候就会出现

延迟块清除，在一般的OLTP系统不会出现这样的情况。以为修改的数据量巨大，执行COMMIT的时候

只会修改ITL FLAG信息(ITL FLAG信息是U，一般的COMMIT清除是C，在没有提交的时候是没有记录的就是-----）和SCN，而对于在行上LB信息就不会清除（这叫FAST COMMIT，也是为什么COMMIT及时在数据量

很大的情况下依然很快的原因），只有依靠下次的延迟的块清除，

延迟的块清除不但会导致SELECT语句生成REDO，而且会把原本干净的已经写入磁盘的

数据块，重新读入BUFFER CACHE，然后完成延迟块清除后重新写入磁盘，这就导致了

大量的不必要的物理写，清除其实就是清理块的头信息的ITL信息，ITL信息能够记录哪行被修改，

同时ITL.XID 能够对应事物信息，同时也能找到UNDO HEADER，

ITL.UBA能够找到UNDO块的信息

在行中的lb（lock BTTE）记录了ITL信息，也就是在ITL对应哪一行

Block header dump:  0x024014ed

Object id on Block? Y

seg/obj: 0x2e61  csc: 0x00.ec539  itc: 1  flg: - typ: 1 - DATA

fsl: 0  fnx: 0x0 ver: 0x01

Itl    Xid                       Uba                     Flag  Lck      Scn/Fsc         

0x01   xid:  0x0005.000.00000805 uba: 0x00c02619.0304.01  ---- 1        fsc 0x0000.00000000

tab 0, row 0, @0x7aa 

tl: 14 fb: --H-FL-- lb: 0x1 cc: 4 

col  0: [ 2]  c1 02 

col  1: [ 4]  52 4f 57 31 

时间： 2024-09-23 23:39:01

块清除的相关文章

[20170428]延迟块清除测试.txt

[20170428]延迟块清除测试.txt --//做一个延迟块清除测试,前面的测试太乱了,思路非常不清楚. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ------------------------------------------------------------------

[20170420]关于延迟块清除2.txt

[20170420]关于延迟块清除2.txt --昨天做延迟块清除测试时,有一个问题我自己一直没搞明白,就是把表空间设置为只读的情况下,当访问块时, --由于没法更新对应块,不知道为什么每次重启数据库,正常undo的事务槽不可能这么块覆盖,为什么ora_rowscn --总是变化,而且取的是control scn,要认真探究一下问题在那里. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BA

[20170420]关于延迟块清除3.txt

[20170420]关于延迟块清除3.txt --昨天做延迟块清除测试时,有一个问题我自己一直没搞明白,就是把表空间设置为只读的情况下,当访问块时, --由于没法更新对应块,不知道为什么每次重启数据库,正常undo的事务槽不可能这么块覆盖,为什么ora_rowscn --总是变化,而且取的是control scn,要认真探究一下问题在那里. --上午测试没有测试出来,链接http://blog.itpub.net/267265/viewspace-2137714/ => [20170420]关于

[20150409]只读表空间与延迟块清除.txt

[20150409]只读表空间与延迟块清除.txt --昨天测试只读表空间的数据库恢复问题,突然想到一种情况,如果只读表空间存在延迟块清除情况,这样在下次访问是会更新块的信息吗? --自己还是做1个测试: 1.首先在测试前,说明1点,设置表空间只读,仅仅阻止dml操作,并不能阻止ddl操作,ddl操作的是数据字典. SCOTT@test> @ &r/ver1 PORT_STRING                    VERSION        BANNER --------------

ORA-01555 快照太旧、Undo表空间、一致性读、延时块清除

  ORA-01555 快照太旧.Undo表空间.一致性读.延时块清除 回滚与撤销 回滚与撤销: 为了保证数据库中多个用户间的读一致性和能够回退事务,Oracle必须拥有一种机制,能够为变更的数据构造一种前镜像(before image)数据(保存修改之前的旧值),以保证那够回滚或撤销对数据库所作的修改,同时为数据恢复以及一致性读服务. 这就是回滚(或撤销).在之前的日志中已经提到Redo,我们说Redo是用来保证在故障时事务可以被恢复,那么Undo则是用来保证事务可以被回滚或者撤销. 什么是回

ORACLE空间管理实验（八）数据块格式分析--DUMP结合BBED

使用DUMP 数据块格式结合BBED进行查看. ####################实验准备步骤: BYS@ bys3>create table test6(aa int,bb varchar2(10)); Table created. BYS@ bys3>insert into test6 values(89,'bys'); 1 row created. BYS@ bys3>insert into test6 values(69,'hello'); 1 row created. B

Oracle恢复内部原理：块修复

块修复是最简单的恢复,在数据库正常操作过程中由系统自动做的,用户几乎感觉不到. 7.1  块修复初始化和操作 前台进程在修改一个缓冲区的时候调用重做程序在该缓冲区上应用改变向量时因为前台进程僵死或者触发一个错误而导致缓冲区的状态不一致,块修复就是用来修复这种缓冲区的状态.修复的过程包括:(i)从磁盘上读取该块:(ii)用当前线程的重做日志重新构建该缓冲区的一致版本:(iii)将修复的块写回磁盘.如果块修复第一次失败了,会再尝试第二次,然后将该块标识为逻辑损坏(将该块的序号置为0),然后触发一个块

【体系结构】Oracle数据块详解

Oracle数据块详解 操作系统块是操作系统读写的最小操作单元,也是操作系统文件的属性之一.当创建一个Oracle数据库时,选择一个基于操作系统块的整数倍大小作为Oracle数据库块的大小.Oracle数据库读写操作则是以Oracle块为最小单位,而非操作系统块. 数据库块也称逻辑块或Oracle块,它对应磁盘上一个或多个物理块,它的大小由初始化参数DB_BLOCK_SIZE决定,可以定义数据块为2K.4K.8K.16K.32K甚至更大,默认Oracle块大小是8K.若一旦设置了Oracle数据

常识之外：全表扫描为何产生大量 db file sequential read 单块读？

原创 2016-07-05 熊军 Oracle   编辑手记:在理解Oracle技术细节时,我们不仅应该读懂概念,还要能够通过测试验证细节,理解那些『功夫在诗外』的部分,例如全表扫描和单块读. 开发人员在进行新系统上线前的数据校验测试时,发现一条手工执行的 SQL 执行了超过1小时还没有返回结果.SQL 很简单: 下面是这条 SQL 的真实的执行计划: 很显然,在这个表上建 billing_nbr 和 start_date 的复合索引,这条 SQL 就能很快执行完(实际上最后也建了索引).但是这