前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ASM的备份解析与恢复

ASM的备份解析与恢复

作者头像
数据和云
发布2018-03-07 14:06:48
8590
发布2018-03-07 14:06:48
举报
文章被收录于专栏:数据和云

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

一、如何验证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目录中获得。但是要注意的是,此时如果关闭数据库,则此句柄会消失,那么除了扫描磁盘进行文件恢复之外就没有其他方法了,因此在数据库出现问题的时候,如果不确认情况的复杂程度,千万不要随便关闭数据库。重启数据库往往是没有意义的,甚至是致命的。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-03-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 数据和云 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档