ASM的备份解析与恢复

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

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-03-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏蛋未明的专栏

十个免费的 Web 压力测试工具(转)

1363
来自专栏全栈

Maven管理多模块应用

1531
来自专栏Java学习123

web服务器和应用服务器的区别?

2716
来自专栏七夜安全博客

Scrapy爬取美女图片第三集 代理ip(下)

1735
来自专栏Vamei实验室

Linux进程关系

作者:Vamei 出处:http://www.cnblogs.com/vamei 欢迎转载,也请保留这段声明。谢谢! Linux的进程相互之间有一定的关系。比如...

1795
来自专栏数据之美

玩转 Linux 之:由 Nginx log rotation 聊聊 mv 的妙用

1、Nginx 下如何正确的做日志切分 今天发现有个 Nginx 日志 rotation 出来大小是 0,很奇怪,按公司的业务场景来说,这是不可能的。 瞅了...

21910
来自专栏数据和云

深入内核:从Oracle ASM自动备份头块到ASMFD

张乐奕 云和恩墨副总经理 Oracle ACE 总监 ITPUB Oracle数据库管理版版主、Oracle高可用版版主、ACOUG联合创始人 在 Oracle...

2758
来自专栏熊二哥

JMeter快速入门

今天的年会已过,仍然是空手而归,不过俺坚信能让生活稳定永远都是努力。由于隔壁组负责年会的抢红包项目,因而趁此机会把通过工具模拟高并发的知识补了补,通过和身边大师...

2205
来自专栏北京马哥教育

十个免费的 Web 压力测试工具

本文列举了是十个免费工具,可以用来进行Web的负载/压力测试的。这样你就可以知道你的服务器以及你的WEB应用能够扛得住多少的并发量,以及网站性能。 0. Gr...

5686
来自专栏张戈的专栏

gh-ost:在线DDL修改MySQL表结构工具

在之前,我分享过一次 pt-online-schema-change 在线 DDL 的工具实践记录,在实际使用过程中,发现部门的很多老系统大量使用了触发器,从而...

5157

扫码关注云+社区