一则有存储导致的数据库大量坏块的事故
一则有存储导致的数据库大量坏块的事故oracle version ：oracle 10403 RAC 两节点os：hp—ux存储：hp自己的1.alert.log中发现大量坏块，我先将报错的信息记录下来，准备用dbv 去检测相应的数据文件。2.将dbv检测的结果记录下来，但是发现多次检测的结果不一致，坏块不稳定，一直在变，这时推测可能是oracle 数据库的bug 或者 主机os的bug ，也有可能是存储的故障3.后来主机，存储工程师检测后都没有没有发现问题，将问题再次推到oracle 的身上，于是，继续检查oracle 的alert 日志，集群日志，主机的日志，也没有发现很明确的问题指向。4.开始尝试使用rman blockrecover 快介质恢复去恢复损坏的数据块，使用 backup validate database； blockrecover corruption list； 修复数据块，但是再次校验时 v$database_block_corruption 查到的坏块数和dbv检测的结果不一样 ，这个很是奇怪。补充一点 dbv 只能检测 数据文件，控制文件5.后来尝试用nbu全库恢复，来恢复数据库，多次尝试，每次结果都一样，都存在大量坏块。但是尝试恢复到另外的一套环境，没有出现任何报错信息。由此断定备份是没有问题的6.后来建议主机，存储工程师升级os ，或者升级存储微码。 终于在硬件层面出现明显报错，直指存储，最后确定是存储的一个控制器有问题。在拿掉那个坏的控制器后，再次nbu恢复，一切正常，不在出现坏块。这个案子在处理过程中，个方面都没有明确证据来证明是对方的错，主机，存储方面咬定不是他们的问题，但是数据库方面也没有任何信息指向，整个case 在处理是相当被动dba作为问题处理的一把手，应该hold住场面，一步一步去验证各种可能的因素，先把跟数据库相关的测试验证都做完，再去‘ 逼迫’ 主机，存储按你的推测i去验证结果，用事实说话，最后问题是处理好了，客户非常满意，应为这个问题已经折腾他们好几次了，今天终于把元凶个找到了，当然存储工程师很郁闷了。
