ITPub博客

【数据安全】一次惊心动魄的ASM磁盘头损坏故障处理过程带来的深思

原创 Linux操作系统 作者:secooler 时间:2012-08-03 01:10:06 2 删除 编辑
  数据通常比喻为企业的血液和生命,数据安全一直是大家非常重视的话题。

  Oracle数据库,为了防止数据丢失以及构建高可用环境给出了多种架构方式。例如,为了防止Oracle实例级别的单点故障提供了RAC技术(Real Application Clusters,真正的应用集群),RAC以Share Everything的架构方式使多个主机实例可以共享一套存储上的数据,从而避免了由于个别实例出现故障导致数据库不可用;RAC技术仅仅给出了实例层 面的高可用解决方案,为了防止存储层面的单点故障,Oracle又提出了Data Guard(数据卫士)技术,无论是逻辑Data Guard还是物理Data Guard都从存储层面解决了单点故障,同时也是灾备技术的最佳选择。基于RAC和Data Guard技术,Oracle进一步又推出了MAA架构方式,即主站点是RAC架构方式,备用站点也是RAC架构方式,主备站点之间通过Data Guard技术使用redo传输变化的数据,确保备站点与主站点之间达到实时或者准实时的数据一致。

  除此之外,Oracle还提供了各种备份恢复工具,比如物理备份恢复工具RMAN、逻辑备份恢复工具EXP/IMP EXPDP/IMPDP。基于这些工具便可以定制一套有效的备份恢复策略,以便防止数据丢失。

  以上技术手段都是确保数据不丢失的必要条件,绝非充分条件!这些技术固然重要,但是与之相比,更加重要的是“人”的因素。再优秀的技术,如果没有人来定期 做健康检查并排查潜在问题的话,这些都是“浮云”。这里给大家分享一个最近刚刚为客户处理完的一个Case。起到警示的作用。

【数据库环境描述】:
数据库类型:    某政府核心生产系统
影响范围:      全国性
数据量:        8T
主机类型:      IBM 570
数据库版本:    10.2.0.4.0
ASM版本:       10.2.0.4.0
数据库架构方式:两节点RAC架构方式;存储使用ASM技术,并且ASM磁盘头没有备份;未部署Data Guard灾备站点;归档模式,使用RMAN做全库及增量备份。

【故障现象】:
  在手工为表空间添加数据文件的时候,触发ASM磁盘头损坏,ASM的alert日志中记录了如下信息:
Sat Jun  9 01:45:51 2012
WARNING: cache read a corrupted block gn=1 dsk=39 blk=18 from disk 39
NOTE: a corrupted block was dumped to the trace file
ERROR: cache failed to read dsk=39 blk=18 from disk(s): 39
ORA-15196: invalid ASM block header [kfc.c:8033] [check_kfbh] [2147483687] [18] [2154781313 != 2634714205]
System State dumped to trace file /home/oracle/admin/+ASM/bdump/+asm1_arb0_602136.trc
NOTE: cache initiating offline of disk 39  group 1
WARNING: offlining disk 39.3734428818 (BDC_DATA_0039) with mask 0x3
NOTE: PST update: grp = 1, dsk = 39, mode = 0x6

【艰难的数据恢复过程】:
  第一次尝试:直接恢复ASM磁盘头数据
  尝试使用Oracle KFED(Kernel Files Editor)工具修改ASM磁盘头,如果这种方式能够顺利的恢复ASM磁盘头的话,将是一种完美的结局,然而事与愿违,此时的ASM磁盘头损坏非一般类 型的损坏(故障原因中给出分析),使用KFED无法完成恢复。第一次梦魇不期而遇。

  第二次尝试:使用RMAN进行数据恢复
  既然每天都做RMAN的备份,正常情况下便可以使用RMAN进行数据恢复。因此,找来设备上尝试数据恢复(提醒:千万不要在生产环境上尝试恢复,保留现场 很重要!),8T的数据拷贝以及恢复时间都是不可想象的,经过漫长的17小时的恢复,梦魇再一次来袭,在尝试恢复的过程中突然发现,RAC的第二节点上的 归档日志不完整,仅剩半个月之前的归档日志,这是不可饶恕的,这也就意味着,使用RMAN工具最多只能恢复到15天前的数据,最近半个月的数据将荡然无 存。这便是典型的“无人值守”导致的灾难。

  第三次尝试:尽最大努力挽回数据
  由于RAC第二节点归档日志的丢失导致最多可以恢复到15天前的数据,但也不要放弃希望,尽一切努力进行数据恢复。再次尝试使用RMAN恢复数据到15天 前。正如小说中常见的情景,此时,梦魇又一次降临到这套可怜的数据库!即便恢复到了15天前的数据,发现数据库依然无法正常open。尝试各种手段,启用 隐含参数等方法,亦不奏效。使用各种手段强制open数据库后alert日志中频现ORA-00600错误,即使在逻辑导出数据的过程中,都在频繁的抛出 ORA-00600错误。最终以备份介质无效无法完美恢复而终止。

  第四次终极处理方法:使用工具直接抽取ASM磁盘组中的数据
  在客户几近崩溃的时候,最终选择了直接数据抽取方法进行恢复,直接抽取ASM磁盘组中的数据,构造出数据文件的全貌,又是一个10多小时的漫长数据抽取恢复时间。经过漫长的等待之后,经验证,数据完美恢复完毕,没有让客户丢失任何一条重要数据!

【故障原因】:
  此次故障推测是由于底层磁盘的映射混乱导致的,比如主机重启后导致disk number变化,导致Oracle认为ASM磁盘组的某块盘是voting disk,进而错误的写入了心跳信息,覆盖了原来位置上的ASM元数据ALT,这样一旦有大规模的reblance操作需要改上述ALT时,ASM便出现 了上述故障。这种故障是无法通过简单的KFED工具进行恢复的。

【数据安全故障总结】:
  这个Case中的故障本身并不可怕,可怕的是这个过程中出现的各种险情,发人深思。我们经常提到“备份重于一切”、“有备无患”等DBA职业操守。我认为最佳的诠释应该再加一条:在可信的架构方式下,定期对备份介质进行有效性验证,及灾备环境DRP演练的前提下!

  针对此次故障的前因后果,给出以下建议:
  1.给出高可用解决方案;建议使用Data Guard技术做远程灾备;
  2.RMAN物理备份以及逻辑备份介质,要定期做备份介质有效性验证;
  3.“人”的因素,制定严格的备份恢复检查机制,对备份以及灾备环境进行日常检查;
  4.前期的架构设计很重要;
  5.……

关于此案例,欢迎访问itpub论坛参与讨论: 
http://www.itpub.net/thread-1701553-1-1.html

Good luck.

secooler
12.08.03

-- The End --

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/519536/viewspace-739705/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE 总监,OCM联盟(ocmu.org)创始人,恩墨学院(enmoedu.com)创始人,ITPUB Oracle专题深入讨论版版主,资深Oracle数据库专家,北京大学理学硕士,获Oracle OCM 10g 11g认证,ACOUG核心成员,DATAGURU专家团成员,Blogger。Good luck.

注册时间:2008-03-16

  • 博文量
    797
  • 访问量
    7866744