一、事务和事务槽是两个概念 :事务就是一些信息的集合,事务槽则是存放事务的地方。
一个事务在undo表空间上会有一个相关的undo chain。
二、DMLddl操作就是所谓的写(即会修改数据文件上数据块的内容),DQL操作(select)即所谓的读。
三、
dump出来的undo块上的内容里会出现属于三种对象的op:
1、
* Layer: 11 (Row) opc: 1 rci 0x00
2、
KTB Redo
op: 0x04 ver: 0x01(即KTB的op类型)
3、KDO Op code: 21 row dependencies Disabled(即KDO的op类型)
总结:同一个op的值,得看op是属于谁的,不同的对象,同一个op值有不同的意义。
四、
数据(表或索引)块的数据层由一条条数据行(即表上的一行)组成,类似地,undo块的数据层由一条条undo记录组成,redo块的数据层由一条条redo记录组成。
块的块头格式里有个类型字节,用于区分块的不同用途,如undo block,undo header block等。若类型字节等于6,表示事务型的块,则还有一个参数用于区分是表还是索引。具体见《DBA思想的天空》数据块结构一章。
数据(表或索引)块的块头有一个SCN,表示数据块上最近一次有一条数据行被更新后而提交的时间(注意更新的时间和提交的时间可以是不一样的,更新后可以隔个长时间再提交的),数据块还有一处SCN在事务槽上的scn/fsc字段上。
一个表段中的各个数据块的块头中的SCN(即最近一次块内有数据行更新的时间)是可以不一样的。因为例如表上只更新一行,而该行在块A上,不在块B上,则只有块A的块头里的SCN变了,块B的没有变化还是。
五、
一个undo记录大致分为三部分:
第一部分
*-----------------------------
* Rec #0x2a slt: 0x08 objn: 24636(0x0000603c) objd: 24636 tblspc: 6(0x00000006)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000Ext idx: 0
flg2: 0
*-----------------------------
uba: 0x00c0008d.00de.29 ctl max scn: 0x0000.00400a3b prv tx scn: 0x0000.00400a45
txn start scn: scn: 0x0000.004015b5 logon user: 59
prev brb: 12583049 prev bcl: 0
第二部分
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: L itl: xid: 0x0003.00e.000002e4 uba: 0x00c00407.0122.08
flg: C--- lkc: 0 scn: 0x0000.003f86e4
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x020000ce hdba: 0x020000ca
注释:KDO层包含着KTB层
第三部分(记录被修改前的值)
itli: 1 ispac: 0 maxfr: 4858
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0
ncol: 2 nnew: 1 size: -6
col 1: [ 7] 58 49 41 4f 4b 55 4e
-- col 1: [ 7] 58 49 41 4f 4b 55 4e
六、理解一个DML操作涉及到的undo的相关过程,参考盖国强。深入解析oracle。8.9回滚机制的深入研究 。
七、
为了select时能始终一致性读(即select所获得的数据都是在select开始执行时前提交的数据,而构造了CR块,这样就产生了多个版本的数据块,一个是当前数据块,一个是由当前数据块回滚到select开始执行前的数据内容所得的CR块))
一致性读机制就是为不同会话下,一个会话有DML操作且未提交,之后,另一个会话来了个select操作(DQL操作),此时select操作所读的数据块是根据一致性读机制而构造出的CR块。若同一个会话下,有DML操作且未提交,之后,来了个select操作(DQL操作),这是不用一致性读机制的。不同会话下,一个会话有DML操作且提交,之后,另一个会话来了个select操作(DQL操作),这也是不用一致性读机制的。
因为要使select操作能一致性读,所以产生了多版本这个概念,即同一个dba的数据块有不同内容的多个版本。
因为要能控制并发操作,所以产生了锁机制的概念。
一个DML操作针对的只能是表上的一行(非多行),所以在undo记录中如类似下面的内容:
col 1: [ 3] c2 02 33
col 2: [ 1] 80
col 3: [ 3] c2 02 0d
col 4: [ 7] 78 71 03 17 15 10 06
就是指表上一行里被修改的各列(字段)
八、在任一时刻,一数据块上的事务槽们的flag字段只有提交和未提交两者状态(即flag字段里关于提交方面的只有这两个字段),无论一个事务槽已经被覆盖了多少次,此时就只有这两个状态,强调下。(这句话没意义对自己理解)
九、select操作时 服务进程扫描于表(即段,段上的各个块)是不会对其进行加锁的?所以所扫描的块上所有事务槽中,若已经扫描过的槽变了,该怎么办?
十、对《利用行SCN实现表变化跟踪》的说明:默认时,数据块的数据行格式上是不存在行SCN这个位置的,所以手动开启行SCN功能后,是对之后产生的数据块上的数据行格式产生影响,即有存在行SCN这个位置。而至于在手动开启行SCN功能前的数据块还是不受影响,没有存在行SCN这个位置。