教学文章
Technology Exchange
热门课程
400电话

免费咨询热线
400-090-9964

教学文章

陈老师博客【 fuzzy backup (非正常状态备份)】

时间:2016-03-01 来源:

某次在客户那里进行recover database的时候,告警日志提示:WARNING! Recovering data file 1 from a fuzzy backup. It might be an online backup taken without entering the begin backup command.

根据提示,意思是备份的时候是热备,可能在备份的之前没有使用begin backup命令,这是什么意思呢,要理解这个问题,我们得慢慢跟大家唠唠。

首先,我们谈谈表空间的备份,如果是热备,需要在备份之前把某个表空间变成begin backup状态,为什么要执行这个命令呢:1,系统会发一个局部检查点,更新该表空间下的所有数据文件头的检查点号;2,把所有属于该表空间的数据文件 头给锁住,目的是防止在备份过程中数据文件头的检查点号被修改,以后recovery的时候就从刚才发生的检查点号开始;3,在备份过程中,如果涉及到 该表空间的数据块被改变,oracle会把整个块的镜像写入redolog中,而不仅仅是日志条目,这样子会产生比较多的日志,这一步就跟上面的 fuzzy backup问题有着紧密的联系,oracle为什么要把数据块的镜像写入到日志中呢,原因是预防块不一致,什么叫块不一致?简单的说就是数据库是打开的 状态,事务还会不断的修改数据块,而在这个时候又开始做备份,用的是操作系统的cp,那么这两者之间没有一个机制去协调,容易造成备份的时候cp的块不一 致,下面我们举个例子来说明:比如操作系统的块是1k,而我们的数据库块是8k,由8个操作系统块组成,那么在备份这个oracle数据块的时候它的 scn号是1000,使用操作系统命令cp去copy这个8k的块,由于操作系统是按照1k的尺寸去copy的,那么它就按照这个尺寸去copy,当它 copy完前面的4个1k的块时,假如这个时候数据块被一个新的事务修改了,oracle的数据块的scn就变成了1001了,那么操作系统在copy后 面4个1k块时,块的scn是1001,跟前面的4个块的scn 1000就不一致了,所以以后把备份的数据块恢复出来的时候,数据块的状态一半是scn 1000的状态,一半是scn 1001的状态,这就是块的不一致现象。有的人就说了,如果是这样的话,如果我把oracle的数据块变成是1k的尺寸,跟操作系统的块尺寸一样,是不是 就没有这个问题了,其实还是有这个问题,只不过我用不同块的尺寸做例子大家能够理解的简单一点,因为在操作系统cp的时候跟数据库之间是没有什么机制进行 协调的,说白了就是你改你的,我拷我的,所以块不一致现象都会随机性出现,解决这个问题的办法就是,在备份时修改了某个块,那么oracle把这个块的镜 像copy到redo log中,就解决了这个问题。上面的理论理解起来有些困难,但是你一旦理解了,对Oracle的备份就理解的比较深了。为什么rman在备份的时候不需要 把数据库变成begin backup状态呢,原因是rman是oracle的自己的产品,它在备份的时候会有一个协调的机制,可能会隐式的发一个begin backup,而不需要DBA手动的执行begin backup。


Oracle在对数据库进行recovery的时候就会判断该数据文件在备份前是不是把表空间或者数据库变成begin backup状态,如果不是,就会出现上面提到的问题,那么以后在recovery的时候,会报错,告知某个块不一致,恢复就会失败。

这个问题我之前遇到的比较多,因为我原来在DSG(迪思杰)公司呆过一段时间,他们有个备份产品很有特点,叫做非归档支持热备,很多人听了都觉得新 鲜,DBA都知道非归档数据库是不能做热备的,原因是需要的redolog会被覆盖,以后无法做recovery,但是DSG的产品里面有个很重要的特点 就是由DSG来做归档,说白了很简单,就是Oracle不归档,DSG来归档,其实就是把切换过的日志给复制到另外一个地方,这样子就可以在非归档的模式 下做热备了,但是oracle数据库在非归档的模式下是无法执行begin backup命令的,所以我们把备份的数据文件restore出来以后,在做recovery的时候告警日志都会出现上面问题:Recovering data file 1 from a fuzzy backup,有的的客户就担心这样子的恢复能不能用,实际上,如果recovery的过程中没有出现块不一致问题而导致recovery无法继续,数据 库恢复成功完全是可以使用的。DSG前期的版本经常出现这个问题,后来把这个bug修改了,他们在备份过程中记录哪些块发生改变,然后备份结束后检查这些 发生改变的数据块,看跟刚才备份的数据块是否不一致,如果不一致,则再备份一次,这样子就解决了块不一致的问题,同时又能支持非归档模式的热备,大家听了 是不是神乎其神?还有他们有一款复制软件,效率比goldengate还高,也比较有特色,如果有遇到,可以试试其效率,这里免费的给他们做个广告。

曾经沧海难为水 除却巫山不是云,见的人多了,遇到的事儿多了,你就慢慢成熟了。大家一定要记得在热备的时候要把表空间或者数据库变成begin backup状态,备份结束后要变成end backup,要不然会产生很多而外的日志。

版权所有@北京神脑资讯技术有限公司(CUUG,中国UNIX用户协会) Copyright ALL Rights Reserved 京ICP备11008061号-1

CUUG旗下网站:www.cuug.com.cn www.cuug.com oracle.cuug.com bbs.cuug.com www.cuug.net

电话:010-59426307 010-59426319 邮政编码:100089

地址:北京市海淀区北清路164号28-38号院