toppic
当前位置: 首页> 科幻小说小说> ASM的备份解析与恢复

ASM的备份解析与恢复

2018-06-19 22:49:15

编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友们。


相关阅读推荐:

新书连载:Oracle数据库的跟踪和分析方法

新书连载:Oracle数据库的初始化与跟踪学习方法

新书连载:深入剖析dump block对数据库的影响


一、如何验证ASM的块头备份块的位置

大家都知道,在Oracle10.2.0.5之前,ASM磁盘的头块并没有自己的备份,因此一旦头块损坏,如果没有以前kfedread备份出来的信息,也就没有办法使用kfed merge来作头块恢复,特别是如果一个磁盘组中所有的磁盘头块都出现问题(比如被人为地创建了PV),恢复ASM磁盘头块的操作就会非常麻烦。


但是从Oracle 10.2.0.5之后,ASM磁盘的头块会自动备份在另外一个块中,这实际上是Oracle 11g出现的功能,不过经过测试,在Oracle 10.2.0.5版本中,这个备份也是存在的。正是因为存在这个备份,所以Oracle10.2.0.5之后的kfed程序才有了新的repair命令,该命令将备份块直接覆盖到磁盘头块,完成修复工作。


在Oracle10.2.0.4中,如果尝试执行kfed repair,则会报错说命令行参数不正确,此报错说明并不存在repair命令。

$ kfed repair

KFED-00101: LRM error [102] while parsing command line arguments


但是在Oracle10.2.0.5中,执行kfed repair,则会说无法打开文件,而这正说明repair命令是存在的,报错是因为还需要明确指定要修复哪块磁盘。

$ kfed repair

KFED-00303: unable to open file ''

 

那么这个备份块具体存在哪里呢?

在学习Oracle技术的过程中,好奇心是驱使我们进步的强大动力,设问、思考、解答,这是获得自我提升的根本。养成动手的习惯,通过动手找出真相,这是成长的必经之路。


在Solaris下的测试,我们使用truss来进行跟踪。

$ truss -o tracedisk2.out kfed repair/asmdisks/vdisk2

 

在trace文件中,找到下面这段,可以明确地看到kfed程序从第510个块中读出4096字节,然后再写回到第0个块中。


同样如果是在Linux下用裸设备作为ASM磁盘,并且用strace进行repair命令的跟踪,也可以得到类似结果。


那么通过kfed命令再来验证一下这两个块是否都标志为头块。验证结果表示块类型都为DISKHEAD。

那么下一个疑问是,在11gR2以后,ASM磁盘组的AU Size可以指定不同的大小,是不是不同的AU Size下的磁盘头块备份都是在第510个块呢?还是用truss来跟踪一下,这里的vdisk3属于一个AU Size=8M的磁盘组,此时repair命令需要明确指定aus,否则会报KFED-00320错误。

truss -o tracedisk3.out kfed repair/asmdisks/vdisk3 aus=8388608


在trace文件中,可以发现已经不是读第510个块,而是改为读第4094个块。


用kfed验证第4094个块,确实标志为DISKHEAD。

$ kfed read /asmdisks/vdisk3 blkn=4094 | grepKFBTYP

kfbh.type:            1 ; 0x002: KFBTYP_DISKHEAD


那么也就是AU 1M的磁盘组头块备份在第510个块上,而AU 8M的磁盘组头块备份在第4094个块上,备份块的存储位置有规律吗?有的,始终保存在第2个AU的倒数第2个块上。下面来验证这个观点。


对于默认的磁盘组,AUSize=1M,每个AU中可以存储256个块,块号为0~255。第1个AU存储256个块,第2个AU最后1个块号为255,倒数第2个块号是254,也就是整体的第510个块(从第1个AU的第1个块往后算起)。


对于AU Size=8M的磁盘组,每个AU可以存储2048个块,块号为0~2047。第1个AU存储2048个块,第2个AU最后1个块号为2047,倒数第2个块号是2046,也就是整体的第4094个块(从第1个AU的第1个块往后算起)。

对于其他AU Size磁盘组的验证,看到文章的朋友有兴趣可以自己做一下。

结论:

从Oracle 10.2.0.5开始,ASM磁盘已经开始自动将头块进行备份,备份块的位置在第2个AU的倒数第2个块上(对于默认1M的AU来说,是第510个块),如果头块损坏,可以用kfed repair命令来修复。


二、如何利用文件句柄恢复误删除的文件

动手、动手,还是动手,看到有兴趣的案例、方法,就坐言起行,通过实践将这些知识变成自己的知识储备。


这一次是客户的数据库意外被删除了整个目录中的数据文件,操作系统级别的删除,然而幸运的是这个数据库没有崩溃。仍然处于open状态的时候,客户就发现了问题,并求助到我们,最终完整地恢复了所有数据文件。


在Linux下大致重新演示一下恢复的过程,恢复的步骤与数据库版本没有太大关系,但是会因操作系统的不同有所改变。


(1)在数据库open的时候,直接删除users表空间中的数据文件。


(2)尝试在users表空间中创建表,开始报错。


在警告日志中,同样也可以看到类似信息。


(3)检查dbwr的进程PID。

$ ps -ef|grep dbw0|grep -v grep

oracle   2879     1  0 21:38 ?        00:00:00 ora_dbw0_orcl

 

(4)dbwr会打开所有数据文件的句柄。在proc目录中可以查到,目录名是进程PID,fd表示文件描述符。


注意其中“/datafile/o1_mf_users_555wrj4o_.dbf(deleted)”字样,表示该文件已经被删除,如果是Solaris操作系统,ls命令不会有如此清晰地显示,为了在Solaris系统中确认哪个句柄对应哪个文件,则需要使用lsof程序。


(5)直接cp该句柄文件名回原位置。

cp 19 /datafile/o1_mf_users_555wrj4o_.dbf

 

(6)进行数据文件recover。

SQL> alter database datafile 4 offline;

Database altered.

SQL> recover datafile 4;

Media recovery complete.

SQL> alter database datafile 4 online; 

Database altered.

 

完成数据文件恢复。


恢复的原理是:

在Linux操作系统中,如果文件从操作系统级别被rm掉,之前打开该文件的进程仍然持有相应的文件句柄,所指向的文件仍然可以读写,并且该文件的文件描述符可以从/proc目录中获得。但是要注意的是,此时如果关闭数据库,则此句柄会消失,那么除了扫描磁盘进行文件恢复之外就没有其他方法了,因此在数据库出现问题的时候,如果不确认情况的复杂程度,千万不要随便关闭数据库。重启数据库往往是没有意义的,甚至是致命的。

有任何疑问欢迎加入云和恩墨大讲堂跟专家面对面交流。

加入"云和恩墨大讲堂"微信群,参与讨论学习

搜索 盖国强(Eygle)微信号:eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


关注公众号,获得后续精彩分享


友情链接