话说前几天的一次现场服务:
一个重要客户现场使用了四年多Oracle集群（RAC）忽然宕机了，导致PVSS无法归档，历史数据无法查询。
现场情况是这样的：
PVSS冗余服务器使用了双节点的Oracle RAC，而RAC 使用了RAID5的共享磁盘阵列存储。按理说这样的设计是SCADA系统中较为全面的容错配置：应用服务器冗余，数据库实例冗余，磁盘阵列冗余。
但为什么这个堪称“豪华”的冗余配置还会出现宕机现象呢？
经了解，获悉：在RAC宕机前，磁盘阵列已经有一块磁盘故障，RAID5降级运行，现场巡检人员发现后立即报告，但现场由于没有额外的备用的更换硬盘，只好打报告申请购买新的硬盘。可是没想到，在几天后共享磁盘阵列上又有一块磁盘故障，而这时已申请的硬盘还没到货。
磁盘阵列一下坏了两块硬盘，RAID5的功能失效，Oracle集群彻底无法工作。
后来找到当地的数据恢复公司，进行硬盘级数据恢复，但经尝试后，数据还是无法完全恢复成功。
至此，只好重做Oracle集群。
由于没有作数据备份，这次故障导致PVSS的历史归档、重要的生产历史数据全部丢失，而系统恢复的时间、人力成本也较高。
可以说这次故障损失较为惨重，但如果能未雨绸缪，提前做好备品备件以及数据备份的工作，即便遇到意外情况的发生，还是能将损失降到最低，甚至不会影响正常生产。
现在国内很多项目的设计和实施中，都已经对系统停机时间提出了很高的要求，除了冗余数据库和服务器，使用更高级别的冗余部件，如：磁盘阵列使用更高容错力的RAID50,专业的容错服务器等以外，生产系统中的各个部分也都使用了冗余，冗余控制器、冗余/环网络等等。
这些冗余系统能够很好的避免单点故障带来的影响，虽然有的系统能承受多点故障，但故障后，系统的降级运行会大大降低系统的可用性，如果不能及时的将系统恢复至最佳运行状态，冗余设计在接下来的运行中可能是形同虚设，更本无法让您高枕无忧。
所以冗余思想在系统设计过程中固然很重要，但如果要使冗余系统能否真正起到大幅降低停机时间的作用，后期的系统的维护和备件管理及流程也必须跟上。
亡羊补牢，为时不晚。这个故障也为我们再一次敲响了警钟，让我们再次审视一下我们生产现场的容错/冗余手段是否依然有效，巡检和备件管理等工作是否切实到位。
“高枕无忧”的冗余
