ITPub博客

首页 > 数据库 > Oracle > 幸运还是不幸,又遭遇ORA-00600 [kfgFinalize_2],导致业务宕机20分钟

幸运还是不幸,又遭遇ORA-00600 [kfgFinalize_2],导致业务宕机20分钟

原创 Oracle 作者:zhang41082 时间:2019-06-11 18:33:07 0 删除 编辑
为生产系统扩容,准备把两台rac的机器的内存全部从8G升级到16G,凌晨3点开始实施,方案如下:首先应用全部切换到节点1,然后停节点2,加内存,然后节点2起来,不幸发生,节点2的ASM实例启不来,本来实例是自动启动的,手工去启动也启不来,磁盘不能被MOUNT,报错如下:
Errors in file /u01/app/oracle/admin/+ASM/udump/+asm2_ora_11560.trc:
ORA-00600: internal error code, arguments: [kfgFinalize_2], [], [], [], [], [], [], [][@more@]

打开trace文件,错误如下:
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kfgFinalize_2], [], [], [], [], [], [], []
Current SQL statement for this session:
ALTER DISKGROUP ALL MOUNT
后面就是一堆天书的二进制码,看来是磁盘组mount的时候出现问题。难道是加内存出现了问题,内存拔掉,问题依旧。网上搜索了半天,发现是oracle的一个bug。
解决的办法有三个:
1、升级到10.2.0.3
2、打一个patch上去
3、把活着的那个节点的PMON进行kill掉,然后重新启动活着的节点的实例,使得强制对数据库进行恢复

评估一下,方案1动作太大,而且这个版本没有测试使用过。方案2的readme文件里明确写着这个patch可能会造成数据丢失,要在oracle support的支持下做,俺们没有support,看来方案三比较可行,可问题是现在至少有一个节点活着,如果强行kill pmon进程后,节点1也起不来了,那就全玩完了,只有准备好切dataguard的方案先了。后来在oracle的论坛上看见说不用kill pmon的,只要把两个节点都宕下来,然后启动就ok。这个方案最安全,到现在无论哪种方案都是要停业务的,估计最少要影响20分钟业务,向上级汇报,得到批准。
把节点1也宕下来,干脆把内存也插上去。很多资料说这个bug下至少有一个节点能正常mount上来的,既然节点2不能mount上来,那干脆先起节点2,能成功mount了再起节点1。节点2启动后,mount正常,启动节点1,看见SUCCESS: diskgroup DATA was mounted提示出来了,放心了。

数据库全部起来后,业务恢复正常,内存也成功的从8G升级到了16G

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25016/viewspace-984622/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2002-10-11

  • 博文量
    105
  • 访问量
    80968