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磁盘组的验证，看到文章的朋友有兴趣可以自己做一下。

结论：

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

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

这一次是客户的数据库意外被删除了整个目录中的数据文件，操作系统级别的删除，然而幸运的是这个数据库没有崩溃。仍然处于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.

完成数据文件恢复。

恢复的原理是：

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