您好,欢迎光临! 请 |

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

作者: | 分类:Experience, Oracle, RAC | Tag:, , | 评论:0 
字号:T|T

           今天上午,在一套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.

OR

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

OR

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菜鸟而言,依然头痛,没有更好的解决方案,如果大家有遇到过类似的案例的话,请不吝赐教! 

 

顶一下
(0)
100%
踩一下
(0)
100%

发表评论

插入图片

NOTICE1:请申请gravatar头像,没有头像的评论可能不会被回复|头像相关帮助!