防止Oracle实例级别的单点故障给出了多种架构方式

Oracle提供了多种体系结构方法，以防止数据丢失并构建高度可用的环境。例如，为了防止在Oracle实例级别发生单点故障，提供了RAC技术（

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

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数据复制和恢复时间如何，梦night已到再次。在恢复过程中，我突然发现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.……

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