假事务之名,深入研究UNDO与REDO

郭耀龙 2015-11-20 09:39:50
 
“有道无术,术尚可求;有术无道,止于术”。今天让我们一起来看看DBA+社群联合发起人郭耀龙大师如何布道。
 
 
 
 
 

专家简介

 
 


郭耀龙

DBA+社群联合发起人

 

超过5年Oracle数据库经验,服务于大型制造业、银行、政府、电信、电力等行业,曾主导某大型制造业的16核心系统从10g向11g平稳演进,擅长Oracle数据库架构规划、性能调整、故障诊断、SQL优化,熟悉Oracle RAC及MAA架构,对大型IT系统的Oracle数据库运维有较丰富的经验。

 

 

 

本文主要讲述关于undo、redo的一些内容。由于undo、redo内容非常多,短时间内难以讲诉清楚,故若水三千,我们只取一瓢,我将从Oracle事务切入,分析undo、redo在事务中的作用。

 

分享一句出自《道德经》里的话,我做了一个曲解,即:“道”理解为原理;“术”理解为实践、操作,就是说如果我们懂得了事物的原理,那么实践性的东西我们是可以培养和训练的,但是如果我们只懂得表面的操作,而不懂原理,那我们就只能停留在事物的表层,如果遇到新的情况,就难以应对。我认为做DBA也是一样,要能够理解Oracle的原理,才能处理一些深层次的问题,而不是在google无结果后就缴械投降。本篇文章的主要内容就是布道。

 

目录
 

 

1、Undo在事务中的作用

  • 解析undo段头结构

  • 解析undo块、undo chain结构

2、Redo在事务中的作用

  • 解析redo结构、undo受redo保护的实质、CV对数据块的作用

  • 理解快速提交机制、delete实质

 


 

最近连续遇到3个由于ORA-600错误导致数据库无法启动的情况,其中两个都是由于异常关机后导致无法启动,这种错误大部分情况是与redo、undo相关,但是怎样来定位问题,怎样解决?这就需要了解Oracle redo、undo的原理,定位问题的方向一般都是解读alert日志、trace日志、或者在mount阶段使用一些跟踪事件,比如10013、10015、10046等进行辅助分析。

 

当然还有最主要的一招,查MOS,MOS上有专门针对600错误的搜索入口,在这里根据错误代码的第一个参数进行匹配查找:

 

 

但如果这里匹配不上,或者MOS上给出的解决办法无效,就还是得回到使用trace日志等分析定位问题,但是这里的trace的解读可能会是拦路虎,怎样去解读trace不是今晚的主题,不做深入,当然不同的trace解读的方法也不尽相同,但是我自己有个体验,就是对Oracle的一些原理和数据结构理解越透彻,就越能读懂trace文件,我们只需要读懂其中的一些关键点,其余可以进行猜测,就足以解决问题,就像英语的阅读理解,只需要读懂1/3的内容,就能解答2/3的问题。这里扯的有点远了,我们回到今晚主题,希望通过今晚的分享能够让大家对undo、redo在Oracle事务中的作用有一定了解,并通过对undo、redo的部分结构的解析,让大家深入Oracle内部,在后续处理相关问题时能够有所帮助。

 

首先,先说下我对事务的理解。Oracle数据库根本上是一个程序,跟其他的应用系统程序无差别,应用系统的程序如果没有业务,那程序代码就无意义,Oracle如果没有事务运行,那Oracle代码也就无意义,所以,事务对于Oracle就像业务对于应用系统一样,是Oracle的灵魂,从这个意义上看,Oracle实例可以看做是用一段代码在维护很多事务运行,事务是oracle实例运行的核心任务,事务产生的数据就是db(控制文件、system文件等可看作内部事务产生)。个人理解,仅供参考。

 

下面描述一下oracle事务的一个简单过程

 

1、在事务开始前,会申请redo资源、undo资源; redo的申请主要是要获取记录redo的内存资源,会涉及到redo allocation latch等资源的申请, undo资源申请是要获取到一个undo段用来存储undo数据(IMU机制会稍有不同);

 

2、在undo段头的事务表中申请一个槽位,记录事务信息,这些相关信息也会以xid等形式写入到数据块的事务槽中;

 

3、undo段头的事务表指向可用的undo块,undo块用于存储具体的undo信息;

 

4、事务开始,进行增、删、改、查等操作,redo记录相关信息、undo也记录相关信息,在事务涉及到的行头还会设置行锁标记;

 

5、事务提交或回滚,结束事务。修改undo段头事务表信息,尽可能的修改相关数据块的事务槽信息、行锁信息,将相关事务信息写入redo log文件。

 

上面只是粗略的一个描述,其中涉及到很多概念,比如undo段头、unod块、事务槽、行锁标记、redo记录等,这些东西具体长什么样?是怎样工作的呢?这里让我想起了一句话:爱情就像鬼一样,谁都听过,但谁也没见过。下面我们就通过实验来解析上面提到的这些概念,看一看是否真的有爱情。

 

 
1
 
 
Undo在事务中的作用
 

 

1.1 解析undo段头结构

 

 

上面的实验修改了表中的两条记录,且这两条记录是存放在不同的块中先dump被修改的两个数据块进行观察

 

 

另外一个数据块

 

 

前面提到的事务槽和行锁标记都出现了,我们看到爱情了!!!

 

事务槽中涉及到几个重要的结构,下面进行下解释:

 

xid=Undo.Segment.Number+Transaction.Table.Slot.Number+Wrap

 

uba = Address of the last undo block used + Sequence + Last Entry in UNDO record map

 

这两个重要结构简单的理解就是,xid指向了事务使用的undo段号、事务表中的槽位号、以及槽位被覆盖的次数;uba指向事务使用的最后一个undo块、seq值、以及最后一条undo记录。

 

事务槽中还有一个flag段,这个段有不同的取值,代表事务的不同状态,可以通过修改这个标志实现手工提交事务,常见的取值有以下几种:

 

----    事务是活动的,或者在块清除前提交事务

C---    事务已经提交并且清除了行锁定

--U-    快速提交

 

再回到前面的两个块的dump数据可以发现,两个数据块的事务槽中都有一个未提交的事务,都是使用了第二个事务槽,两个块的xid完全相同,即两个块使用的是同一个undo段中的同一个事务表槽位,uba的前两部分也完全相同,即使用的是同一个undo块,第三部分不一样,说明两个块的前镜像使用了两个条undo record进行记录。

 

从xid信息可以知道,事务使用的是第6号回滚段,下面dump 6号undo段头进行观察:

 

 

 

上图就是undo段头中的事务表,又看到爱情了!!!

 

下面对其中的几个重要列进行解释:

 

index:表示slot 编号

 

state:表示状态,9 表示事务inactive,10表示active.

 

Uel:跟提交列表有关

 

Dba:表示该事务对应的undo block dba地址

 

1.2 解析undo块、undo chain结构

 

根据前面两个块的xid(0x0006.01f.000001a5)可知,事务使用的是1f号槽位,从前面事务表的图中可以看出,该槽位的state列为10,即事务未提交,其对应的undo block的地址为c03fba。

 

将该dba地址进行转换:

 

 

使用的undo块是3号文件的16314号块,下面dump该块进行观察:

 

 

这里有两个重要结构,irb指向事务的最后一条undo记录,即回滚的起点,icl指向事务的第一条undo记录,即回滚的终点。

 

从前面数据块dump的uba(0x00c03fba.0072.15、0x00c03fba.0072.14)的第三部分可知,事务对应的undo记录为14、15,观察这两条记录:

 

 

 

这里需要注意三点:

 

  • redo记录中的rci指向的是事务的前一条undo记录;

  • 前镜像的内容中只记录了被修改列内容;

  • undo块中存在着一条链表,这个链表见下图:

 

 

这就是undo chain的一部分,与事务的混滚操作有关,undo块的irb指向事务undo record的最后一条记录 ,该记录中的rci指向前一个undo record记录,以此类推,最后一个undo record的ric为空,表示事务的起点,也是回滚的终点。

 

下图是完整的undo chain:

 

 

这里大家可以扩展思考一下,oracle的save point是如何实现的,是不是会与undo chain有关?如果修改rci值是不是可以实现回滚部分事务?

 

下面我们来看一个网上流传比较广的一个图:

 

 

从前面我们的实验可以看出,这个图是有歧义的,undo镜像不是块级别的,所以不是一个数据块对应一个undo块,undo镜像其实是列级别的,只有被更改的列才会被记录。

 

Undo在事务中的工作方式我们就先分析到这。

 

 
2
 
 
Redo在事务中的作用
 

 

2.1 解析redo结构、undo受redo保护的实质、CV对数据块的作用

 

下面来看一看redo是如何工作的:

 

 

接下来dump 405号块进行观察(这里只选取表数据部分)

 

 

使用BBED观察DBA+这列的行头信息

 

 

下面删除其中的两条数据(这两条数据是位于不同的块中)

 

 

Dump上面两个scn之间的redo进行观察

 

 

 

 

下面对redo dump进行分析:

 

1、 redo log是以CHANGE VECTOR为最小单位构成的,就是上面的CHANGE #n部分;

 

2、 一个REDO RECORD包含多个CV(CHANGE VECTOR);

 

3、 OP表示操作类型,不同的值表示不同的操作类型;

 

4、 redo中包含了前镜像,这就是redo保护undo的实质;

 

5、 上面的操作涉及两个块,但是只有一条redo record,所以redo record是可以包含多个块的,但是一个CV只能针对一个块,CV是一个数据块块版本演进的结果,CV只能向前推进数据块的版本,不能后退,对于回滚操作,会由于undo的应用而生成新的CV,这个CV依然是推进数据块版本,要使数据块版本回退的唯一方法是介质恢复。

 

2.2 理解快速提价机制、delete实质

 

下面再次dump 405号块(包含DBA+的数据块)

 

 

注意,这里nrow显示还有两行数据,但是删除行的数据没有在dump中显示;行锁标记也未释放,但是事务已经提交了,这就是Oracle的快速提交、和延迟块清除机制,只是保证修改undo段头事务表信息,块头和行头信息不一定进行修改。

 

那么delete到底发生了什么?下面用bbed进行观察:

 

 

发现被删除的数据依然在块中,只是行头标记被修改,这就是delete的实质。所以在数据被覆盖之前是可以通过修改行头标记恢复被delete的数据的。

 

还记得我们开始的那句话吗?爱情就像鬼一样,谁都听过,但谁也没见过。通过上面的实验,我们应该看到了一些东西。真爱还是有的!

 

时间,教会了我们很多东西。有些我们曾经认为根本没有的,后来发现,它确确实实存在着,而有些我们深信不疑的,后来却明白,根本就没有。比如,爱情…

 

小编精心为大家挑选了近日最受欢迎的几篇热文,回复001看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复002,看《灾备故障上了红头文件,容灾技术到底哪家强?》;

回复003,看吕海波的《去不去O,谁说了算?》;

回复004,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复005,看付新《达梦专家解读:国产数据库也疯狂》。

 

 

关于DBA+社群

DBA+社群,是一个以连接全中国DBA为使命的公益性组织,致力于成为DBA界的UBER,充分利用DBA的业余时间,为广大DBA搭建一个学习交流、价值实现、人脉搭建、跨界合作的平台。目前,DBA+社群已于北上广深等全国15大城市成立DBA+城市群,100+业界专家成为联合发起人,6000+跨界DBA加入队伍,每周4次线上技术分享活动同步直播。

扫码关注

DBAplus社群

超越DBA圈子,连接的不仅仅是DBA

活动预告