首页 > 代码库 > Oracle core05_事务和一致性

Oracle core05_事务和一致性

事务和一致性

oracle的redo和undo机制保证了数据库的ACID特性,以及高性能和可恢复特性。

redo的数据是记录着数据块变更的顺序的正向数据流,

  1. commit时,保证redo同步持久化,保证高性能。
  2. 恢复的时候,顺序的应用日志。

redo的机制相对比较简单。

 

undo记录着数据块的前映像。

  1. 保证事务的特性,数据只有在commit后才可见。
  2. 提供读一致性,保证读写互不阻塞。

一方面,在undo segment header中transaction table中记录着事务,并在undo的record中维护着link list,实现事务的回滚。

另一方面,在数据块中intereted transaction list中保存着本事务对数据块的前映像的最新UBA,并在undo recored中
维护着link list,用于构建数据块的一致性读。


在正常的业务处理中,rollback属于比较少的情况,所以,oracle也特别优化了机制,commit的时间会非常的快,而rollback
因为要根据linked list顺序应用undo record,要比commit慢的多。

undo的机制相对比较复杂,这里就从两个不同的立足点去讨论

  1. 事务
  2. 表或者索引的数据块

 

1,事务

undo segment header包括了一般的数据块的通用结构,还包括了特殊的结构,
比如transaction table, extent retention table。
在8k大小的数据块中,每个undo segment header中的transaction table是有限的。比如下面的片段:

TRN TBL::

index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x00f9 0x0011 0x0000.000e3357 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326654543
0x01 9 0x00 0x00f9 0x0000 0x0000.000e3297 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326654005
0x02 9 0x00 0x00f9 0x0006 0x0000.000e2fe0 0x008002bd 0x0000.000.00000000 0x00000001 0x00000000 1326652743
0x03 9 0x00 0x00f9 0x0008 0x0000.000e3153 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326653343
0x04 9 0x00 0x00f9 0x002d 0x0000.000e30f3 0x008002bd 0x0000.000.00000000 0x00000001 0x00000000 1326653343
0x05 9 0x00 0x00f9 0x000c 0x0000.000e312a 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326653343
.......

 

当事务为inactive状态,并且slot被重用的情况下,wrap#会向上递增。

这里有一点要注意:在oracle内容,持久化到文件的变更,db的restart都不会重置,而对于内存中的记录,比如动态性能视图,会被清除重置。


下面记录下事务的开始和结束进行的action:

1,begin transaction
2,写undo数据块变更的redo日志到redo buffer
3,变更undo数据块,包括,选择undo segment,transaction table entry,递增wrap#,更新state为10,即active。
4,commit 事务
5,写undo变更的redo
6,更新state为9,写入当前的scn到scn column中
7,同步等待lgwr写入完成

这里仅仅记录了在事务中,undo变化的过程。

 

注:在commit的时候,产生的所谓“redo commit record”,其实是undo segment header数据块变更的redo record。

 

在对事务的标示时,使用的是transaction id,这里唯一标识了一个事务,例如:0x0009.002.00002013
其包括:undo segment, entry,wrap#三部分。

所以,以事务为单位,在transaction table中可以看到以下信息:

1,事务(transaction id)的物理地址
2,事务的状态
3,事务提交的scn号
4,事务的最新的undo记录的地址
5,事务的undo记录量

查询这些信息不需要dump块,这里有一个视图x$ktuxe,但这个视图会扫描所有的undo segment header块。

select
indx,
ktuxesta,
ktuxecfl,
ktuxesqn wrap#,
ktuxescnw scnW,
ktuxescnb scnB,
ktuxerdbf dba_file,
ktuxerdbb dba_block,
ktuxesiz nub
from
x$ktuxe
where
ktuxeusn = 9
and ktuxeslt <= 5

 

注意:在oracle的官方文档中有一句“transactions don’t share undo blocks”,这里的意思是,这个事务own这个undo块,但如果这个事务是inactive的时候,

如果还有空闲空间,可是会被其它事务所使用。当undo要被清除的时候,oracle开辟一个块大小的buffer,然后format,而并非是从文件中读取块的内容。

2,表或者索引的数据块


下面看一下构建一致性块的过程
主要存在以下两种情况:

1,当事务未commit状态的时候,使用undo信息构建一致性块内容。
2,当块中事务commit的scn比当前query的scn大,使用undo 信息构建一致性内容。

这其中存在延迟块清除的情况:即当commit的时候,为了加快commit的时间,当事务更新的块较多的时候,仅仅更新了undo segment header中的transaction table中记录的事务的状态,当后面query到这个块的时候,进行块清除,即更改itl中事务的状态。

所以构建的主要过程:

1,在buffer中克隆这个块,下面的步骤都将应用在这个块上。
2,对这个块上所以commit的事务,进行块清除。
3,回滚没有提交的事务,应用undo record。
4,当commit的事务的scn大于query的scn时,就应用undo record。
5,重复第四步。


3,commit scn

fast commit:当事务commit的时候,仅仅修改transaction table的undo segment header这一个块,而跟修改的数据块的数量没有关系,修改这个块的redo vector就是所谓的commit record。
在oracle的演化过程中,oralce改变了fast commit,session memory中保存着(最多10% buffer cache)更改的块的list,当commit的时候,就会访问这些块,进行块清除。主要包括:

1,清理lock bytes
2,设置fsc/scn为commit的scn
3,设置commit的flag为C----
这个过程称为commit cleanout。

注:在这个过程中,仅仅更改transaction table slot中产生了redo日志,oracle优化了commit cleanout的过程。
其中,块的revisit并没有计入logical read,redo日志。

总结:


即:在事务的整个过程中,有两个重要的结构
1,itl
itl记录着事务的id,即txid,undo记录的地址UBA和commit scn,如果commit scn不可用,那么可以根据txid来确定undo segment header中的transaction table
slot中的信息,确定事务的状态,如果要构建一致性块,就根据UBA的地址找到undo record的链,回滚一致性的块内容。


2,transaction table
slot中记录着transaction的状态,最后更新的块的undo地址和commit scn,slot是有限的,当被重用的时候,会递增wrap#,wrap#数值是组成txid的一部分。
当事务回滚的时候,根据UBA地址,然后再undo record中有pointer指向想一个UBA,以此来回滚整个事务。
当slot被重用的时候,前一个事务的commit scn,uba地址会记录在下一个新事物的第一个undo record中,这样,就可以构建一致性的transaction table。

当事务根据UBA的链表查找的时候,发现当前undo record的seq#数值与当前不对,就会报出“ORA-01555”错误,说明undo块已经被重用。