ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-600(kmgs_parameter_update_timeout_1)错误

ORA-600(kmgs_parameter_update_timeout_1)错误

原创 Linux操作系统 作者:yangtingkun 时间:2009-09-26 23:56:38 0 删除 编辑

检查一个RAC环境的alert文件,在实例启动过程中,发现了这个错误。

 

 

错误信息为:

Sat Sep 26 20:26:39 2009
ALTER DATABASE   MOUNT
Sat Sep 26 20:26:44 2009
Setting recovery target incarnation to 2
Sat Sep 26 20:26:44 2009
Successful mount of redo thread 1, with mount id 2135712636
Sat Sep 26 20:26:44 2009
Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)
Completed: ALTER DATABASE   MOUNT
Sat Sep 26 20:26:44 2009
ALTER DATABASE OPEN
Sat Sep 26 20:26:44 2009
This instance was first to open
Sat Sep 26 20:26:47 2009
System State dumped to trace file /oracle/product/admin/pmias/bdump/pmias1_mmon_12447.trc
Sat Sep 26 20:26:49 2009
Errors in file /oracle/product/admin/pmias/bdump/pmias1_mmon_12447.trc:
ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [1565], [], [], [], [], [], []
ORA-01565: error in identifying file '/dev/vgpms01/rlvol22'
ORA-15059: invalid device type for ASM disk
Additional information: 255
Sat Sep 26 20:26:50 2009
Trace dumping is performing id=[cdmp_20090926202650]
Sat Sep 26 20:26:57 2009
Picked broadcast on commit scheme to generate SCNs
Sat Sep 26 20:26:57 2009
Thread 1 opened at log sequence 506
  Current log# 1 seq# 506 mem# 0: /dev/vgpms01/rlvol10
Successful open of redo thread 1
Sat Sep 26 20:26:57 2009
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Sep 26 20:26:57 2009
SMON: enabling cache recovery
Sat Sep 26 20:26:57 2009
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Sat Sep 26 20:26:58 2009
Successfully onlined Undo Tablespace 1.
Sat Sep 26 20:26:58 2009
SMON: enabling tx recovery
Sat Sep 26 20:26:58 2009
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=28, OS id=14687
Sat Sep 26 20:26:59 2009
Completed: ALTER DATABASE OPEN

显然这个错误的出现并没有影响数据库实例的打开。

检查对应的trace详细信息:

/oracle/product/admin/pmias/bdump/pmias1_mmon_12447.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/db1
System name: HP-UX
Node name: pmsdb1
Release: B.11.31
Version: U
Machine: ia64
Instance name: pmias1
Redo thread mounted by this instance: 1
Oracle process number: 28
Unix process pid: 12447, image: oracle@pmsdb1 (MMON)

*** 2009-09-26 20:26:47.877
*** SERVICE NAME:() 2009-09-26 20:26:47.876
*** SESSION ID:(512.1) 2009-09-26 20:26:47.876
Warning: MMON hit err 1565 while doing parameter updates.
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
ksedst()+64          call     00000000ffffffff     000000000 ? 000000001 ?
$cold_kmgs_paramete  call     00000000ffffffff     000000000 ?
r_update_timeout()+                                C000000000000A1A ?
2112                                               40000000042157B0 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksbabs()+1312        call     00000000ffffffff     60000000000BFAC0 ?
                                                   9FFFFFFFFFFFC490 ?
                                                   9FFFFFFFFFFFBF10 ?
                                                   60000000000B31D8 ?
                                                   C000000000000B1E ?
                                                   4000000002C9DE50 ?
                                                   00000F3DF ?
                                                   9FFFFFFFFFFFBF20 ?
kebm_mmon_main()+11  call     00000000ffffffff     60000000000BFE30 ?
36                                                 60000000000B31D8 ?
                                                   C000000000000D20 ?
                                                   4000000002670040 ?
                                                   00000F11B ?
                                                   60000000000BFCD0 ?
ksbrdp()+3552        call     00000000ffffffff     C000000040028D40 ?
                                                   9FFFFFFFFFFFC7A0 ?
                                                   60000000000B31D8 ?
                                                   9FFFFFFFFFFFD2B0 ?
                                                   C000000000000F24 ?
                                                   4000000003B172E0 ?
opirip()+1216        call     00000000ffffffff     9FFFFFFFFFFFD2C0 ?
                                                   60000000000B31D8 ?
                                                   9FFFFFFFFFFFDE00 ?
                                                   C000000000000CA0 ?
                                                   4000000003AC6EC0 ?
                                                   0000058DB ?
                                                   60000000000BFAC0 ?
opidrv()+1568        call     00000000ffffffff     9FFFFFFFFFFFEBE0 ?
                                                   000000004 ?
                                                   9FFFFFFFFFFFF200 ?
                                                   9FFFFFFFFFFFDE10 ?
                                                   60000000000B31D8 ?
                                                   C000000000000F24 ?
sou2o()+240          call     00000000ffffffff     000000032 ?
                                                   60000000000BFAC0 ?
                                                   9FFFFFFFFFFFF200 ?
opimai_real()+512    call     00000000ffffffff     9FFFFFFFFFFFF220 ?
                                                   000000032 ? 000000004 ?
                                                   9FFFFFFFFFFFF200 ?
main()+368           call     00000000ffffffff     000000003 ? 000000000 ?
main_opd_entry()+80  call     00000000ffffffff     000000003 ?
                                                   9FFFFFFFFFFFF6D0 ?
                                                   60000000000B31D8 ?
                                                   C000000000000004 ?
 

查询了METALINK,发现是Oraclebug在文档Doc ID:  5399699.8中对这个错误进行了描述。这个错误影响10.2.0.310.2.0.4版本,在10.2.0.511.1.0.6中解决了这个错误。

问题是MMON进程在尝试更新SPFILE中的内存参数时,由于长时间没有办法更新参数,导致的超时,引发的这个错误。

不过当前和文档中描述的不同之处在于,当前使用的是裸设备,而不是ASM

这个bug对系统影响不大,不打补丁也没有什么影响。

 

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

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10404617