ORA-27069: attempt to do I/O beyond the range of the file

2011.06.01香港系统出现如下信息（多亏自己10分钟有一次日志监控哦）：

ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [27091], [], [], [], [], [], []
ORA-27091: unable to queue I/O
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1
Wed Jun  1 12:06:21 2011
Restarting dead background process MMON
MMON started with pid=57, OS id=533394

网上查到的资料：

ORA-600 [Kmgs_parameter_update_timeout_1], [27091], [] [ID 1286640.1]

--------------------------------------------------------------------------------
 
  修改时间 09-MAR-2011     类型 PROBLEM     状态 MODERATED  

In this Document
  Symptoms
  Cause
  Solution
  References

 

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

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

 

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.2 - Release: 10.2 to 11.2
Information in this document applies to any platform.

Symptoms
Alert log shows multiple occurrences of the following errors:

ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [27091], [], [], [], [], [], []
ORA-27091: unable to queue I/O
ORA-27072: File I/O error
SVR4 Error: 9: Bad file number
Additional information: 4
Additional information: 4
Additional information: -1

Cause
Starting with 10g, the MMON background process manages all memory resize activity by modifying the related parameters.
The parameter update activity is triggered by a timeout.
If the update cannot be performed, several error conditions are checked to see if that could be the cause.
If we cannot match the current condition to the list of known exceptions, we raise the assert 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 present case, 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/writev system call returned error".

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

Solution
In the present case, changing the owner of the spfile to oracle and group to dba solved the issue.

In numerous cases of ORA-600 [kmgs_parameter_update_timeout_1], recreation of the SPfile helps to solve the issue.

Thus, we recommend to:

Create a PFILE from your current SPFILE:
SQL> create pfile='\init.ora' from spfile;
- Review the newly-created PFILE with a Text-Editor

- Shutdown and Restart the Database with this newly-created PFILE:
SQL> shutdown immediate
SQL> startup pfile=''';

- Create a new SPFILE
SQL> create spfile from pfile;

- Shutdown and Re-start the database with the new SPFILE
SQL> shutdown immediate
SQL> startup

References
NOTE:356537.1 - ORA-600 [kmgs_parameter_update_timeout_1] Pending parameter timeout

 

大概是说mmon是内存自动分配的进程，调用该进程进行自动内存分配时，会写入spfile，但是由于spfile的异常，导致校验时发现问题，认为无法写入。所以出现了以上的错误。
而正对香港的问题，检查spfile，大小居然变为了0，但是操作系统没有报任何错，存储也没有任何错。spfile为空所以才出现了这样的问题。试图创建pfile，也报相同的错误。
看来只有从备份恢复的方法了。

 

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

转载于:http://blog.itpub.net/288166/viewspace-705062/