当用户发出提交(commit)之后，oracle是需要写出redo来保证故障时数据可以被恢复，oracle并不需要在提交时就写出变更的数据块。由于在事务需要修改数据时，必须分配ITL事务槽，必须锁定行，必须分配回滚段事务槽和回滚表空间来记录要修改的数据的前镜像。当事务提交时，oracle需要将回滚段上的事务表信息标记为非活动，以便空间可以被重用那么还有ITL事务信息和锁定信息需要清除,以记录提交。

由于oracle在数据块上存储了ITL和锁定等事务信息，所以oracle必须在事务提交之后清除这些事务数据，这就是块清除。块清除主要清除的数据有行级锁、ITL信息(包括提交标志、scn等)。

如果提交时修改过的数据块仍然在buffer cache中，那么oracle可以清除ITL信息，这种清除叫做快速块清除(fast block cleanout)，快速块清除还有一个限制，当修改的块数量超过buffer cache的10%，则对超出的部分不再进行快速块清除。

如果提交事务时，修改过的数据块已经被写回到数据文件上(或大量修改超出10%的部分)，再次读出该数据块进行修改，显然成本过于高昂，对于这种情况，oracle选择延迟块清除(delayed block cleanout)，等到下一次访问该block时再来清除ITL锁定信息，这就是延迟块清除。oracle通过延迟块清除来提高数据库的性能，加快提交操作。

快速提交是最普遍的情况。来看一下延迟块清除的处理：

SYS@ prod>update scott.emp set sal=1999 where empno=7369;

1 row updated.

SYS@ prod>update scott.emp set sal=1998 where empno=7499;

1 row updated.

SYS@ prod>update scott.emp set sal=1997 where empno=7521;

1 row updated.
更新完成之后,强制刷新buffer cache,将buffer cache中的数据都写出到数据文件:
SYS@ prod>alter system flush buffer_cache;

System altered.

查询事务及回滚段用户与转储
SYS@ prod>select xidusn,xidslot,ubafil,ubablk from v$transaction;

XIDUSN XIDSLOT UBAFIL UBABLK
---------- ---------- ---------- ----------
6 30 3 8028

SYS@ prod>select * from v$rollname where usn=6;

USN NAME
---------- ------------------------------
6 _SYSSMU6_2897970769$

此时再提交事务;
SYS@ prod> commit;

Commit complete.

由于此时更新过的数据已经写出到数据文件,oracle将执行延迟块清除,将此时的数据块和回滚段转储出来:
SYS@ prod>select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from scott.emp;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
4 149

SYS@ prod> alter system dump datafile 4 block 149;

System altered.

SYS@ prod> alter system dump undo header '_SYSSMU1_592353410$';

System altered.

SYS@ prod> alter system dump datafile 3 block 8028;

System altered.

SYS@ prod>oradebug setmypid
Statement processed.
SYS@ prod>oradebug tracefile_name
/u01/diag/rdbms/prod/prod/trace/prod_ora_3775.trc

查看跟踪文件信息,看数据块上的信息,ITL事务信息仍然存在:
其中scn表示提交commit scn,fsc表示快速提交scn
Block dump from disk:
buffer tsn: 4 rdba: 0x01000095 (4/149)
scn: 0x0000.0013bc2d seq: 0x01 flg: 0x04 tail: 0xbc2d0601
frmt: 0x02 chkval: 0x931a type: 0x06=trans data

Block header dump: 0x01000095
Object id on Block? Y
seg/obj: 0x123d7 csc: 0x00.13bbc9 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1000090 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0007.00a.0000030f 0x00c000e3.00d3.2c C--- 0 scn 0x0000.0013baa2
0x02 0x0006.01e.00000398 0x00c01f5c.0173.07 ---- 3 fsc 0x0000.00000000

xid=0x0006.01e.00000398的事务lck=3

数据块的锁定信息仍然存在:
block_row_dump:
tab 0, row 0, @0x1c88
tl: 39 fb: --H-FL-- lb: 0x2 cc: 8
col 0: [ 3] c2 4a 46
col 1: [ 5] 53 4d 49 54 48
col 2: [ 5] 43 4c 45 52 4b
col 3: [ 3] c2 50 03
col 4: [ 7] 77 b4 0c 11 01 01 01
col 5: [ 3] c2 14 64
col 6: *NULL*
col 7: [ 2] c1 15
tab 0, row 1, @0x1caf
tl: 44 fb: --H-FL-- lb: 0x2 cc: 8
col 0: [ 3] c2 4b 64
col 1: [ 5] 41 4c 4c 45 4e
col 2: [ 8] 53 41 4c 45 53 4d 41 4e
col 3: [ 3] c2 4d 63
col 4: [ 7] 77 b5 02 14 01 01 01
col 5: [ 3] c2 14 63
col 6: [ 2] c2 04
col 7: [ 2] c1 1f
tab 0, row 2, @0x1e00
tl: 43 fb: --H-FL-- lb: 0x2 cc: 8
col 0: [ 3] c2 4c 16
col 1: [ 4] 57 41 52 44
col 2: [ 8] 53 41 4c 45 53 4d 41 4e
col 3: [ 3] c2 4d 63
col 4: [ 7] 77 b5 02 16 01 01 01
col 5: [ 3] c2 14 62
col 6: [ 2] c2 06
col 7: [ 2] c1 1f

再来看回滚段的信息:
********************************************************************************
Undo Segment: _SYSSMU6_2897970769$ (6)
********************************************************************************

Version: 0x01
FREE BLOCK POOL::
uba: 0x00c01f5c.0173.07 ext: 0xd spc: 0x1cfc
uba: 0x00000000.0173.02 ext: 0xd spc: 0x1f06
uba: 0x00c01f59.0173.23 ext: 0xd spc: 0xc58
uba: 0x00000000.0095.01 ext: 0x10 spc: 0x1ed0
uba: 0x00000000.0095.01 ext: 0x10 spc: 0x1ed0
TRN TBL::

index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x1e 9 0x00 0x0398 0xffff 0x0000.0013bc55 0x00c01f5c 0x0000.000.00000000 0x00000001 0x00000000 1559115495

undo块
********************************************************************************
UNDO BLK:
xid: 0x0006.014.00000399 seq: 0x173 cnt: 0x1e irb: 0x1e icl: 0x0 flg: 0x0000

Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1f8c 0x02 0x1f18 0x03 0x1ebc 0x04 0x1e68 0x05 0x1dcc
0x06 0x1d74 0x07 0x1d1c 0x08 0x1c94 0x09 0x1c30 0x0a 0x1bdc
0x0b 0x1b70 0x0c 0x1aec 0x0d 0x1a7c 0x0e 0x19fc 0x0f 0x1974
0x10 0x18e8 0x11 0x1880 0x12 0x1798 0x13 0x1730 0x14 0x16d8
0x15 0x1650 0x16 0x15d4 0x17 0x156c 0x18 0x14e4 0x19 0x144c
0x1a 0x13e4 0x1b 0x1308 0x1c 0x1220 0x1d 0x11b8 0x1e 0x1160

事务提交,事务表已经释放。如果此时查询scott.emp表,数据库将产生延迟块清除:

SYS@ prod>set autotrace on
SYS@ prod>select * from scott.emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- ------------------- ---------- ---------- ----------
7369 SMITH CLERK 7902 1980-12-17 00:00:00 1999 20
7499 ALLEN SALESMAN 7698 1981-02-20 00:00:00 1998 300 30
7521 WARD SALESMAN 7698 1981-02-22 00:00:00 1997 500 30
7566 JONES MANAGER 7839 1981-04-02 00:00:00 2975 20
7654 MARTIN SALESMAN 7698 1981-09-28 00:00:00 1250 1400 30
7698 BLAKE MANAGER 7839 1981-05-01 00:00:00 2850 30
7782 CLARK MANAGER 7839 1981-06-09 00:00:00 2450 10
7839 KING PRESIDENT 1981-11-17 00:00:00 5000 10
7844 TURNER SALESMAN 7698 1981-09-08 00:00:00 1500 0 30
7900 JAMES CLERK 7698 1981-12-03 00:00:00 950 30
7902 FORD ANALYST 7566 1981-12-03 00:00:00 3000 20
7934 MILLER CLERK 7782 1982-01-23 00:00:00 1300 10

12 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 12 | 468 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 12 | 468 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
9 consistent gets
6 physical reads
116 redo size
1382 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
12 rows processed

SYS@ prod>select * from scott.emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- ------------------- ---------- ---------- ----------
7369 SMITH CLERK 7902 1980-12-17 00:00:00 1999 20
7499 ALLEN SALESMAN 7698 1981-02-20 00:00:00 1998 300 30
7521 WARD SALESMAN 7698 1981-02-22 00:00:00 1997 500 30
7566 JONES MANAGER 7839 1981-04-02 00:00:00 2975 20
7654 MARTIN SALESMAN 7698 1981-09-28 00:00:00 1250 1400 30
7698 BLAKE MANAGER 7839 1981-05-01 00:00:00 2850 30
7782 CLARK MANAGER 7839 1981-06-09 00:00:00 2450 10
7839 KING PRESIDENT 1981-11-17 00:00:00 5000 10
7844 TURNER SALESMAN 7698 1981-09-08 00:00:00 1500 0 30
7900 JAMES CLERK 7698 1981-12-03 00:00:00 950 30
7902 FORD ANALYST 7566 1981-12-03 00:00:00 3000 20
7934 MILLER CLERK 7782 1982-01-23 00:00:00 1300 10

12 rows selected.

Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 12 | 468 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| EMP | 12 | 468 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
1382 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
12 rows processed

注意,在此查询是产生了物理读取和redo,这个redo就是因为延迟块清除导致的,再次查询则不会
产生redo了。

再次转储一下该数据块和回滚段:

SSYS@ prod> alter system dump datafile 4 block 149;

System altered.

SYS@ prod> alter system dump undo header '_SYSSMU1_592353410$';

System altered.

SYS@ prod> alter system dump datafile 3 block 8028;

System altered.

SYS@ prod>oradebug setmypid
Statement processed.
SYS@ prod>oradebug tracefile_name
/u01/diag/rdbms/prod/prod/trace/prod_ora_3775.trc

查看跟踪文件,看到此时ITL事务信息已经清除,但是注意,这里的xid和uba信息仍然存在:
Block header dump: 0x01000095
Object id on Block? Y
seg/obj: 0x123d7 csc: 0x00.13bfab itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1000090 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0007.00a.0000030f 0x00c000e3.00d3.2c C--- 0 scn 0x0000.0013baa2
0x02 0x0006.01e.00000398 0x00c01f5c.0173.07 C--- 0 scn 0x0000.0013bc55

数据块块的锁定位也已经清除了:
block_row_dump:
tab 0, row 0, @0x1c88
tl: 39 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4a 46
col 1: [ 5] 53 4d 49 54 48
col 2: [ 5] 43 4c 45 52 4b
col 3: [ 3] c2 50 03
col 4: [ 7] 77 b4 0c 11 01 01 01
col 5: [ 3] c2 14 64
col 6: *NULL*
col 7: [ 2] c1 15
tab 0, row 1, @0x1caf
tl: 44 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4b 64
col 1: [ 5] 41 4c 4c 45 4e
col 2: [ 8] 53 41 4c 45 53 4d 41 4e
col 3: [ 3] c2 4d 63
col 4: [ 7] 77 b5 02 14 01 01 01
col 5: [ 3] c2 14 63
col 6: [ 2] c2 04
col 7: [ 2] c1 1f
tab 0, row 2, @0x1e00
tl: 43 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4c 16
col 1: [ 4] 57 41 52 44
col 2: [ 8] 53 41 4c 45 53 4d 41 4e
col 3: [ 3] c2 4d 63
col 4: [ 7] 77 b5 02 16 01 01 01
col 5: [ 3] c2 14 62
col 6: [ 2] c2 06
col 7: [ 2] c1 1f

提交之后的undo信息
当提交事务之后,回滚段事务表标记该事务为非活动,继续再来看一下回滚段数据块的信息,
看到这里的irb指向了0x3d，此前的事务已经不可回滚

********************************************************************************
UNDO BLK:
xid: 0x0006.004.00000399 seq: 0x173 cnt: 0x3d irb: 0x3d icl: 0x0 flg: 0x0000

看一下偏移量列表也已经新增了一条信息0x3d 0x01c8

Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1f8c 0x02 0x1f18 0x03 0x1ebc 0x04 0x1e68 0x05 0x1dcc
0x06 0x1d74 0x07 0x1d1c 0x08 0x1c94 0x09 0x1c30 0x0a 0x1bdc
0x0b 0x1b70 0x0c 0x1aec 0x0d 0x1a7c 0x0e 0x19fc 0x0f 0x1974
0x10 0x18e8 0x11 0x1880 0x12 0x1798 0x13 0x1730 0x14 0x16d8
0x15 0x1650 0x16 0x15d4 0x17 0x156c 0x18 0x14e4 0x19 0x144c
0x1a 0x13e4 0x1b 0x1308 0x1c 0x1220 0x1d 0x11b8 0x1e 0x1160
0x1f 0x10b0 0x20 0x1000 0x21 0x0f94 0x22 0x0f24 0x23 0x0eb8
0x24 0x0e4c 0x25 0x0d9c 0x26 0x0cec 0x27 0x0c80 0x28 0x0c14
0x29 0x0ba8 0x2a 0x0b3c 0x2b 0x0a8c 0x2c 0x0a20 0x2d 0x09b4
0x2e 0x0904 0x2f 0x087c 0x30 0x0820 0x31 0x0770 0x32 0x06c0
0x33 0x0610 0x34 0x05a4 0x35 0x0538 0x36 0x04cc 0x37 0x0460
0x38 0x03f4 0x39 0x0388 0x3a 0x031c 0x3b 0x02b0 0x3c 0x0234
0x3d 0x01c8

再看前镜像的信息,仍然存在。

虽然这个事务已经提交了,不可以回滚了,但是在覆盖之前,这个前镜像信息仍然存在,通过某些手段,还是可以获得这个信息的.比如回闪查询

Oracle Block Cleanouts 块清除的更多相关文章

  1. oracle(八)块清除

    (1)  快速块清除(fast block cleanout), 当事务修改的数据库全部保存在buffer cache并且修改数据块的数据量没有超过cache buffer 的10%,快速清除事务信息 ...

  2. oracle延迟块清除

    oracle在执行一些DML操作时,会在block上有活动事务的标志,如果一个事务commit后,由于某些block在commit之前已经写回datafile, 或者事务影响到的block数过多,则c ...

  3. oracle --(一)数据块（data Block）

    基本关系:数据库---表空间---数据段---分区---数据块 数据块(data Block)一.数据块Block是Oracle存储数据信息的最小单位.这里说的是Oracle环境下的最小单位.Orac ...

  4. 对Oracle数据库坏块的理解

    1.物理坏块和逻辑坏块 在数据库中有一个概念叫做数据块的一致性,Oracle的数据块的一致性包括了两个层次:物理一致性和逻辑一致性,如果一个数据块在这两个层次上存在不一致性,那就对应到了我们今天要要说 ...

  5. 使用BBED模拟Oracle数据库坏块

    BBED(OracleBlockBrowerandEDitor Tool),用来直接查看和修改数据文件数据的一个工具,是Oracle一款内部工具,可以直接修改Oracle数据文件块的内容,在一些极端恢 ...

  6. undo丢失恢复异常恢复，运维DBA反映Oracle数据库无法启动报错ORA-01157 ORA-01110，分析原因为Oracle数据库坏块导致

    本文转自 惜纷飞 大师. 模拟基表事务未提交数据库crash,undo丢失恢复异常恢复,运维DBA反映Oracle数据库无法启动报错ORA-01157 ORA-01110,分析原因为Oracle数据库 ...

  7. tablespace(表空间) / segment（断） / extent（盘区）/ block（块）/datafile(文件)之间的关系

    tablespace(表空间) / segment(断) / extent(盘区)/ block(块)之间的关系   tablespace : 一个数据库划分为一个或多个表逻辑单位,即表空间,每个表空 ...

  8. Oracle block 格式

    Oracle block 格式 信息参考:  http://www.ixora.com.au/ 特别感谢 overtime 大哥对我的无私的帮助和对我一直鼓励支持我的网友这些资料是没得到oracle ...

  9. 13 oracle数据库坏块-逻辑坏块（模拟/修复）

    13 oracle数据库坏块-逻辑坏块 逻辑数据坏块的场景1)oracle bug也可能导致逻辑坏块的产生. 特别是parallel dml. 例如:Bug 5621677 Logical corru ...

随机推荐

  1. Html表格和表头文字不换行

    [本文出自天外归云的博客园] 希望表头中的文字和表格中的文字不换行,只需要在th和td标签加上: nowrap="nowrap"

  2. java中为什么notify()可能会导致死锁，而notifyAll()则不会

    简单的说,notify()只唤醒一个正在等待的线程,当该线程执行完以后施放该对象的锁,而没有再次执行notify()方法,则其它正在等待的线程 则一直处于等待状态,不会被唤醒而进入该对象的锁的竞争池, ...

  3. 模态窗口showModalDialog的浏览器兼容解决方案【改】

    将代码中原来的 window.showModalDialog 全部替换成: showModalDialogN 然后增加方法: function showModalDialogN(uri, args, ...

  4. Linux（CentOS）安装JDK1.8

    1.JDK的RPM包安装方式: https://www.cnblogs.com/hunttown/p/5450463.html 2.JDK的tar包安装方式: 首先,从SUN公司网站下载最新的JDK ...

  5. （转载）基于比较的少样本(one/few-shoting)分类

    基于比较的方法 先通过CNN得到目标特征,然后与参考目标的特征进行比较. 不同在于比较的方法不同而已. 基本概念 数据集Omniglot:50种alphabets(文字或者文明); alphabet中 ...

  6. python2 手动安装更新pip

    现在对于python2版本,直接修改python.exe名字为python2.exe,命令python2 -m pip install --upgrade pip --force-reinstall可 ...

  7. ASP.NET LinqDataSource数据绑定后，遇到[MissingMethodException: 没有为该对象定义无参数的构造函数。]问题。

    问题出现的情形:LinqDataSource数据绑定到DetailsView或GridView均出错,错误如下: “/”应用程序中的服务器错误. 没有为该对象定义无参数的构造函数. 说明: 执行当前 ...

  8. C++内存管理4-Windows编程中的堆管理（转）

    1 引言 在大多数Windows应用程序设计中,都几乎不可避免的要对内存进行操作和管理.在进行大尺寸内存的动态分配时尤其显的重要.本文即主要对内存管理中的堆管理技术进行论述. 堆(Heap)实际是位于 ...

  9. idea修改maven项目名

    1.修改pom.xml中相关 <artifactId>seal-hn</artifactId><name>seal-hn</name><descr ...

  10. Zabbix 3.0 配置企业微信报警(注册---测试)

    一.申请企业微信 1.登录企业微信官网,点击企业注册 二.配置企业微信 1.邀请管理员使用企业微信,如果有多个人直接添加新成员 2.管理员收到邀请,下载手机版企业微信,使用微信号登陆即可 3.创建应用 ...