编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友们。
相关阅读推荐:
新书连载:Oracle数据库的跟踪和分析方法
新书连载: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目录中获得。但是要注意的是,此时如果关闭数据库,则此句柄会消失,那么除了扫描磁盘进行文件恢复之外就没有其他方法了,因此在数据库出现问题的时候,如果不确认情况的复杂程度,千万不要随便关闭数据库。重启数据库往往是没有意义的,甚至是致命的。
有任何疑问欢迎加入云和恩墨大讲堂跟专家面对面交流。
加入"云和恩墨大讲堂"微信群,参与讨论学习
搜索 盖国强(Eygle) :eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。