激动人心的ASM磁盘磁头损坏故障排除过程带来的想法

通常将数据与企业的生命和生命进行比较，数据安全一直是每个人都非常重视的话题。

Oracle提供了多种体系结构方法，以防止数据丢失并构建高度可用的环境。例如，为了防止在Oracle实例级别发生单点故障，提供了RAC技术（Real Application Clusters）。 RAC使用“共享一切”体系结构允许多个主机实例在存储上共享一组数据，从而避免了由于单个实例的故障而导致不可用； RAC技术仅在实例级别提供高可用性解决方案。为了防止在存储级别出现单点故障，Oracle还提出了Data Guard（Data Guard）技术，无论是逻辑Data Guard还是物理Data Guard都从存储级别解决了单点故障，也是灾难恢复技术的最佳选择。 Oracle基于RAC和Data Guard技术，进一步引入了MAA架构，即主站点为RAC架构，备用站点也为RAC架构。主站点和备用站点之间的数据通过使用重做的Data Guard技术进行传输，以确保备用站点。与主站点的实时或准实时数据一致性。

此：全国

数据量：8T

主机类型：IBM 570

版本：10.2.0.4.0

ASM版本：10.2.0.4.0

体系结构：两节点RAC体系结构；存储使用ASM技术，并且不备份ASM磁盘头；未部署Data Guard灾难恢复站点；归档模式，RMAN用于完整和增量备份。

[问题]：

将数据文件手动添加到表空间时，ASM磁盘头已损坏，并且以下信息记录在ASM警报日志中：

2012年6月9日星期六：01：45：51

警告：缓存从磁盘39中读取损坏的块gn = 1 dsk = 39 blk = 18

注意：已损坏的块已转储到跟踪文件

错误：缓存无法从磁盘：39读取dsk = 39 blk = 18

ORA-15196：无效的ASM块标头[kfc.c：8033] [check_kfbh] [2147483687] [18] [2154781313！= 2634714205]

转储到跟踪文件/ home / oracle / admin / + ASM / bdump / + asm1_arb0_602136.trc的系统状态

注意：高速缓存从磁盘39组1脱机启动

警告：使磁盘39.3734428818（BDC_DATA_0039)的掩码为0x3）脱机

注意：PST更新：grp = 1，dsk = 39，模式= 0x6

[困难的数据恢复过程]：

第一次尝试：直接还原ASM磁盘头数据

尝试使用Oracle KFED（内核文件编辑器）工具来修改ASM磁盘头。如果此方法可以顺利还原ASM磁盘头，则将是一个完美的结局。但是，情况与预期相反。此时，ASM磁盘头已损坏。对于一般类型的损坏（在故障原因中进行了分析），无法使用KFED完成恢复。第一场噩梦出乎意料。

第二次尝试：使用RMAN进行数据恢复

由于RMAN每天都会备份，因此在正常情况下RMAN可用于数据恢复。因此，请尝试在设备上进行数据恢复（提醒：切勿在生产环境中尝试恢复，重要的是保持现场！），长时间的17小时恢复后，难以想象8T数据的复制和恢复时间。再次。在尝试还原期间，我突然发现RAC第二个节点上的归档日志不完整。仅保留了半个月前的存档日志。这是不可原谅的，这意味着使用RMAN工具最多只能还原15天前的数据，而最后半个月中的数据将消失。这是由“无人值守”引起的典型灾难。

第三次尝试：尽力恢复数据

由于丢失了第二个RAC节点的存档日志，因此可以在15天之前恢复数据，但是不要放弃希望并尽一切努力来恢复数据。再试一次以使用RMAN将数据还原到15天之前。正如小说中经常看到的那样，此时，噩梦再次进入这个可怜的！即使将数据还原到15天之前，也发现该仍然无法正常打开。尝试各种方法，启用隐藏参数和其他方法均无效。使用各种方法强制打开后，警报日志中经常出现ORA-00600错误。即使在逻辑导出数据的过程中，也经常引发ORA-00600错误。最后，备份媒体无效，无法完美还原。

第四种最终处理方法：使用工具直接提取ASM磁盘组中的数据

当客户差点崩溃时，他最终选择了直接数据提取方法进行恢复。直接提取ASM磁盘组中的数据以构建数据文件的完整图片。数据提取和恢复时间很长，超过10个小时。经过漫长的等待，经过验证，数据已完美还原，客户没有丢失任何重要数据！

[失败原因]：

推测此故障是由底层磁盘映射的混乱引起的。例如，主机重新启动后，磁盘号发生变化，这导致Oracle认为ASM磁盘组中的某个磁盘是有表决权的磁盘，然后错误地写入了心跳信息，从而覆盖了原始位置的ASM元数据ALT被删除。 ，因此，如果需要更改上述ALT的重新平衡操作，则在ASM中会发生上述故障。这种故障无法通过简单的KFED工具恢复。

[数据安全失败摘要]：

这种情况下的故障本身并不可怕。可怕的是，过程中的各种危险令人深思。我们经常提到DBA的职业道德，例如“备份比一切都重要”和“准备就绪”。我认为最好的解释应该再加上一点：在可靠的体系结构的前提下，定期验证备份介质和DRP演练在灾难恢复环境中的有效性！

鉴于此失败的原因和后果，给出以下建议：

1.提供了一种高可用性解决方案；建议使用Data Guard技术进行远程灾难恢复；

2.必须定期验证RMAN物理备份和逻辑备份介质的备份介质的有效性；

3.“人为”因素，建立严格的备份和恢复检查机制，并对备份和灾难恢复环境进行日常检查；

4.早期的架构设计非常重要；

5.……

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/dianqi/article-325407-1.html