天道酬勤

上周四中午刚放下订餐电话，手机响起鸟，客户的一套AIX 5.2 ML04  +  Oracle 10.2.0.3.0 (+Dataguard)的系统挂了，业务中断。收拾东西下楼打车赶往客户机房，大致半小时后到达客户机房登录系统检查发现系统报：“ORA-00600: internal error code, arguments: [2103], [1], [0], [1], [900]”错误。[2103]的错误与controlfile有关，[900]是等待的超时时间S。进一步检查发现，问题是出现在每天晚上0点都有crontab调度的系统备份任务：0点将系统置为热备模式—>连接FTP服务器—>CP需要备份的所有件—>最后将系统退出热备模式。metalink [ID 567891.1]说：系统处在热备份模式下，在日志发生切换时获取控制文件队列信息时发生了超时，这个等待时间默认是15分钟（900s）。虽然这里有一个Bug 6018274，但我的习惯是只有在做完了尽可能的尝试之后再认为是bug。

继续检查发现，系统一直在进行kill动作：“Killing enqueue blocker (pid=827572) on resource CF-00000000-00000000”，但遗憾的是这个动作失败了，尝试手工kill，失败。而且此时在系统中只要一发起与log相关的动作系统就挂起，无赖之下想重启oracle(这个想法很邪恶啊，如果待会儿起不来，how?),FT……正常关闭失败（意料中的），abort关机失败，回到OS中kill -9失败。万般无赖之下，只能重启OS，没想到的是AIX重启到一般的时候挂起，此时已经13：30了，还没有吃饭（12点客户叫俺一起去吃饭看到她那表情俺也有点不好意思。）不管了，先搞定系统再说吧。由于这套系统是P690上的一个分区，只要在HMC上使用“Hard Reset”选项了，鼠标移到此分区上检查了又检查了，俺视力5.2的说，但就怕这时看错了的话，后果，你知道的。在这前后几分钟，真有心跳加速的感觉，就怕待会儿库打不开啊。10分钟之后，my god，库顺利的打开了，哎呀，肚子不饿了，起应用一切顺利，先让别人开工吧。

造成ORA-00600 [2103]错误的原因有下：

1) 控制文件存放在I/O非常慢的存储系统上。

2) 频繁的日志切换，或日志文件过小或日志文件组数目过少。

3) 同时使用了异步I/O或多个数据写进程。

4) Oracle软件内部Bug。

5) OS/硬件问题。

讯问过客户工程师，确实在前一天18：30的时候进行数据整理，发生过非常频繁的日志切换，高峰时1分钟达5次日志切换，但在其后一天是正常的，由于环境复杂，暂时先做如下测试：（以影响业务程度最小化且实施难易程度依次列出）

1. 增大日志组成员大小，同时增加日志组数目。

2. 由于业务的特殊性，商讨能否修改备份策略来避开热备份。

3. 根据官方建议打补丁：Patch 5923866，在失效的情况下，将系统升级到10.2.0.4.0之上（最新分布为10.2.0.5.0）

4. 将操作系统从AIX 5.2 ML04升级到AIX 5.2 ML05（Oracle在[ID 406191.1]中建议）

BTW：在我重启完系统后问客户，此套系统应该有Dataguard的吧，答案是肯定的。到这里，可能大家会说为什么不在出问题的时候将系统切换到备机上。其实切换系统更多决定因素不仅仅只在技术层面的。

-The End-