遇到ORA-600 [kmgs_parameter_update_timeout_1] [1565]的错误

今天上午，在一套Windows 2003 64位的双节点10.2.0.5.0的64位RAC数据库上，遇到一则600的错误，ORA-00600: 内部错误代码, 参数: [kmgs_parameter_update_timeout_1], [1565], [], [], [], [], [], []。从(节点1的)alert日志里获取的具体错误信息如下：

Wed Jul 25 10:49:39  2012
Unexpected communication failure with ASM instance:
 error 21561 (ORA-21561: 生成 OID 失败
)
NOTE: ASMB process state dumped to trace file c:\oracle\product\10.2.0\admin\zhfr8db\bdump\zhfr8db1_mmon_4624.trc
System State dumped to trace file c:\oracle\product\10.2.0\admin\zhfr8db\bdump\zhfr8db1_mmon_4624.trc
Wed Jul 25 10:55:02  2012
Errors in file c:\oracle\product\10.2.0\admin\zhfr8db\bdump\zhfr8db1_mmon_4624.trc:
ORA-00600: 内部错误代码, 参数: [kmgs_parameter_update_timeout_1], [1565], [], [], [], [], [], []
ORA-01565: 标识文件 '+DATA/zhfr8db/spfilezhfr8db.ora' 时出错
ORA-17503: ksfdopn: 2 未能打开文件 +DATA/zhfr8db/spfilezhfr8db.ora
ORA-21561: 生成 OID 失败

Wed Jul 25 10:55:03  2012
Trace dumping is performing id=[cdmp_20120725105503]
Wed Jul 25 10:56:06  2012
Restarting dead background process MMON
MMON started with pid=33, OS id=6756

当时的表现情况是，客户端无法通过应用系统访问数据库，客户端通过tnsping service_name的返回结果也是，有时通，返回10毫秒，而有时挂死了。

登录到其中的一个节点服务器(节点1)上，执行lsnrctl status，查看监听状态也挂死，而到另外一个节点(节点2)上，执行lsnrctl status一切正常。并且，分别在两个节点上，通过SQL*PLUS连接数据库均正常，执行crs_stat -t返回的结果也都正常。

接下来，分别在两个节点上作了一个AWR报告，分析了AWR发现并没有发现数据库的异常现象。

从告警日志里看到跟SPFILE相关的错误，于是在SQL*PLUS里尝试create pfile from spfile,以及使用RMAN工具backup spfile时，都报错了，当时匆忙，具体错误号没有记录下来。

没辙了，就到节点1上，尝试通过srvctl stop database -d db_unique_name关闭数据库时，挂死了，丝毫没有反应；通过SQL*PLUS在节点1上，尝试shutdown immediate来手工关闭实例，也未果。

当时，从网络上找到老杨以及惜分飞的文章，不过，貌似都和我遇到的这个情况不太类似。

然后，在没有更好的办法的前提下，直接重启节点1的Windows服务器，毕竟当时应用已经不可用了，再者是RAC架构，最起码还留着一个实例。重启之后，数据库一切正常了。

最后，从MetaLink上找到这样的一篇文章：ORA-600 [kmgs_parameter_update_timeout_1], [1565] While Accessing Spfile Managed By ASM [ID 553915.1]该文档描述，该错误影响到10.2及以上版本的数据库，原因是：

This is due to unpublished bug 5399699 where ORA-600 [kmgs_parameter_update_timeout_1] or similar errors can occur in MMON when ASM is being used.

In 10g MMON manages all memory re-size activity by modifying related parameters. If MMON is not running DBW0 will handle this task. The parameter update activity is triggered by a timeout. Basically this error indicates that the MMON process is not able to write to the SPFILE to store some settings required for dynamic SGA parameter adjustments.

也就是说：这个错误是oracle还未发布的一个bug,bug号是5399699。这个错误是说在10g的数据库里，MMON进程动态的管理内存，MMON（Memory Monitor）是10g数据库的新进程。从10g开始，数据库支持自动调整SGA内存，当需要调整（动态增大或减小）的时候，MMON进程会自动完成，MMON会把这个改变的信息，写入到SPFILE里。

结合最开始的alert日志文件的内容，是由于当时MMON进程无法把这个信息写入到SPFILE里导致的，导致后来MMON后台进程僵死了，在Wed Jul 25 10:56:06 2012的时候，MMON进程又被重启了。然后数据库一直处于“假死”的状态。

Oracle Metalink上这篇文章给的解决方案：

Solution

1. Upgrade to the 10.2.0.4.4 PSU Patch:9352164 or higher where this bug is fixed.

2. Check if Patch:5399699 is available for your RDBMS release and platform.

3. Use one of the following workarounds:

Relocate the spfile either to some other diskgroup on which the archive logs are not being managed.
Move the spfile to the file system

显然，第1个与当前环境下的数据库版本不一致；而第2个方案中，又没有查到Windows 2003 X64平台下的补丁；第3个方案，我当前是RAC的库，如果把SPFILE迁移到文件系统上的话，又不太合适，除非给每个实例单独配置PFILE。

最后，这个问题，对于我这个Oracle菜鸟而言，依然头痛，没有更好的解决方案，如果大家有遇到过类似的案例的话，请不吝赐教！