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