【案例讨论】灾难与拯救 数据安全精彩案例大讨论！欢迎大家踊跃参与！

本期活动特邀几位社区版主， oracle 数据库专家与大家共同交流探讨：
eygle—中国地区Oracle ACE总监，也是中国地区首位Oracle ACE，云和恩墨创始人,ITPUB论坛超级版主
secooler—Oracle ACE,国际航空运输协会（IATA）任高级数据架构师,OCM联盟（ www.ocmu.org）创始人、ITPUB Oracle专题深入讨论版版主
yxyup—现任职知名网络招聘公司系统运维负责人,曾在多家培训中心进行Oracle教学,为企业单位提供了高质量的技术培训,ITPUB Oracle数据库管理版版主
kelsoncong—现任Oracle Fusion HCM Release Team运维成员，多年数据库运维和开发经验,ITPUB Oracle数据库管理版版主

讨论话题：

1.保护业务数据有哪些方法？

2.威胁到数据安全的因素有哪些？

3.通过以下这份案例，给您带来哪些警示？

本期活动精彩案例分享：
【数据安全】
一次惊心动魄的ASM磁盘头损坏故障处理过程带来的深思
  数据通常比喻为企业的血液和生命，数据安全一直是大家非常重视的话题。
  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.……

注：特别感谢secooler版主为大家提供的精彩案例！！欢迎大家踊跃讨论

我的回复：

1.保护业务数据有哪些方法？
我首先从硬手段上讲
（1）常规的冷备份，如果允许shutdown的话，可以使用最原始的冷备份
（2）物理备份恢复工具RMAN，热备份
（3）逻辑备份恢复工具EXPDP，数据泵
（4）Data Guard 主备库模式，即专用备份节点
（5）Golden Gate 高级复制软件
（6）Exadata 软硬件一体机备份
（7）启用专用冗余服务器，把数据备份到多个地方，当某一份数据出现故障时我们还有其他备份可用
我在从软手段上讲
（1）全方位的数据监控：一个好的监控软件可以让你事半功倍，举例 我们公司在运维数据库中就采用了quest 公司spotlight监控软件，它可以提前预示一些警告，把灾难抹杀在摇篮里
（2）对高风险操作，需要安全测试和评估，例如 RM 操作是危险的，在不确定的情况下，可以先重命名测试，没有问题后在删除
（3）制定高规范权限和登陆制度，对不同级别的人员只给予够用的权限或者临时权限，监控登陆记录，对不符合要求的人员给予登陆拒绝
（4）制定审计策略，可以审计 delete  truncate drop 等危险操作，例如 谁  哪张表  什么时候  做了哪些动作  可以追溯到源头，认定责任  评估事态
（5）备份介质有效性验证，对备份介质的有效性经常验证，并保证在恢复时是可信的，可依靠的
（6）高可用架构设计，例如现在流行的 大规模分布式存储集群架构，采用这种架构我们可以有效的避免单点故障，从而有效的保护我们的数据
2.威胁到数据安全的因素有哪些？
常见因素
（1）病毒发作
（2）黑客入侵
（3）存储设备损坏
（4）信息盗取
（5）说白了最主要的还是人的因素，由于人为盲目操作导致的数据丢失 例  我前几天就帮助同事恢复了数据文件丢失问题，他在不了解.dbf文件情况下 使用了 rm -rf *.dbf
非常见因素
（1）不可抗力自然灾害
（2）电源故障
（3）机箱风扇故障，案例 我们公司的新疆项目由于机箱风扇停止，温度升高导致主机当机，数据丢失
（4）bug问题，也威胁着数据安全，例如 oracle-00600错误  在上面的“ASM磁盘头损坏案例”中表现的淋漓尽致
3.通过以下这份案例，给您带来哪些警示？
（1）给我第一个警示：千万不能在生产库上尝试没有把握的恢复，保留现场定位问题很重要
（2）给我第二个警示：做了备份也不能高枕无忧，完全放心下来，需要定期做备份有效性验证，保证我们的备份是实时可用有效的
（3）给我第三个警示：crosscheck  归档文件，使其完整有效，也成我们高度重视内容之一
（4）给我第四个警示：高可用HA架构，是保证业务续航能力首要平台
（5）给我第五个警示：定期进行灾备演练，增强容灾意识
leonarding
2012.8.3
天津&早

 

 

 

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

转载于:http://blog.itpub.net/26686207/viewspace-739709/