ORA-00600 [kmgs_parameter_update_timeout_1], [27072] ORA-27072 解决方法

ORA-27072: 文件 I/O 错误

Linux-x86_64 Error: 9: Bad file descriptor

Additional information: 4

Additional information: 4

Additional information: -1

Incident details in:/g01/app/oracle/diag/rdbms/gumd/gumd/incident/incdir_76981/gumd_mmon_21407_i76981.trc

Mon Jul 30 22:01:02 2012

Trace dumping is performingid=[cdmp_20120730220102]

Mon Jul 30 22:01:04 2012

Errors in file/g01/app/oracle/diag/rdbms/gumd/gumd/trace/gumd_dbw0_3375.trc  (incident=76937):

ORA-27072: 文件 I/O 错误

Linux-x86_64 Error: 9: Bad file descriptor

Additional information: 4

Additional information: 4

Additional information: -1

Incident details in:/g01/app/oracle/diag/rdbms/gumd/gumd/incident/incdir_76937/gumd_dbw0_3375_i76937.trc

Errors in file /g01/app/oracle/diag/rdbms/gumd/gumd/trace/gumd_dbw0_3375.trc:

ORA-27072: 文件 I/O 错误

Linux-x86_64 Error: 9: Bad file descriptor

Additional information: 4

Additional information: 4

Additional information: -1

DBW0 (ospid: 3375): terminating theinstance due to error 471

Instance terminated by DBW0, pid = 3375

二．解决方法

2.1 错误原因：

Starting with10g, the MMON background process manages all memory resize activity by modifyingthe related parameters. The parameter update activity is triggered by atimeout.

If the updatecannot be performed, several error conditions are checked to see if that couldbe the cause.

If we cannotmatch the current condition to the list of known exceptions, we raise theassert kmgs_parameter_update_timeout_1

In such a case,we need to look at the first argument returned with the ORA-600.
This will give you the error number of the triggering condition.

In the presentcase, the key error is the ORA-27091 "unable to queue I/O"
In other words, we raise such an error when a "read/write/readv/writevsystem call returned error".

Finally, here,we found out that the problem was actually due to the spfile having root asowner

导致ORA-00600: [kmgs_parameter_update_timeout_1]的原因可能有如下：

（1）    ORACLE_HOME 磁盘空间不足

（2）    包含SPFILE的文件系统损坏，导致Oracle 不能访问SPFILE.

（3）    SPFILE文件所在的用户和组，或者权限不正确。

2.2 解决方法：

（1）如果是权限问题，那么修改SPFILE 文件到oracle 用户，dba组就ok了。

（2）大部分ORA-600 [kmgs_parameter_update_timeout_1]的错误都可以尝试重建SPFILE来解决。

步骤如下：

--根据当前SPFILE创建pfile：

SQL> createpfile='<replace_by_full_path>\init.ora' from spfile;

--检查新的PFILE 文件

--关闭数据库并用新的PFILE 启动：

SQL> shutdown immediate
SQL> startup pfile=''<replace_by_full_path_of_newly_created_pfile>';

--创建新的SPFILE:

SQL> create spfile from pfile;

--关闭数据库，用新的SPFILE启动：

SQL> shutdown immediate
SQL> startup

参考：

-------------------------------------------------------------------------------------------------------

版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!

QQ:492913789

Email:ahdba@qq.com

Blog:  http://www.cndba.cn/dave

Weibo: http://weibo.com/tianlesoftware

Twitter: http://twitter.com/tianlesoftware

Facebook: http://www.facebook.com/tianlesoftware

Linkedin: http://cn.linkedin.com/in/tianlesoftware

-------加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请----

DBA1 群：62697716(满);   DBA2 群：62697977(满)  DBA3 群：62697850(满)  

DBA 超级群：63306533(满);  DBA4 群：83829929   DBA5群： 142216823

DBA6 群：158654907    DBA7 群：172855474   DBA总群：104207940