ORA-01148:cannot refresh file size for datafile ***

 

<style></style>

ORA-01148: cannot refresh file size for datafile *

Table of Contents

1 版本信息

  • 操作系统版本:
-bash-3.00$ uname -a
SunOS boss-db1 5.10 Generic_138888-06 sun4u sparc SUNW,SPARC-Enterprise
  • 数据库版本:
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

2 错误信息

ORA-01110: data file 254: '+DATA2/so_35.dbf'
ORA-00376: file 254 cannot be read at this time

3 收集错误信息

  • 查找数据库trace信息
-bash-3.00$ cd $ORACLE_BASE/admin/boss/bdump
-bash-3.00$ grep -i so_35 ./*
./boss1_dbw0_25404.trc:ORA-01110: data file 254: '+DATA2/so_35.dbf'
./boss1_dbw0_25404.trc:file 254: +DATA2/so_35.dbf
./boss1_diag_25354.trc:     fname=+DATA2/so_35.dbf
  • 确认文件的最后修改时间与问题出现时间一致
-bash-3.00$ ls -la boss1_dbw0_25404.trc
-rw-rw----   1 oracle   oinstall  442294 Apr 14 15:25 boss1_dbw0_25404.trc
  • 查看trace提供的信息
........(省略)
{***} 2017-04-14 15:20:05.747
ORA-01148: cannot refresh file size for datafile 254
ORA-01110: data file 254: '+DATA2/so_35.dbf'
ORA-09817: Write to audit file failed.
SVR4 Error: 28: No space left on device                     =========================> 审计文件所在路径为$ORACLE_BASE/admin/$ORACLE_SID/adump, 空间充足
Automatic datafile offline due to media error on            =========================> 数据文件被offline
file 254: +DATA2/so_35.dbf
........(省略)

4 故障恢复

  • 查看文件状态
SQL> COL FILE_NAME FOR A40
SQL> SELECT FILE_NAME,STATUS,BYTES FROM DBA_DATA_FILES WHERE FILE_ID=254;

FILE_NAME                                STATUS         BYTES
---------------------------------------- --------- ----------
+DATA2/so_35.dbf                         AVAILABLE                   =======================================> 文件大小为空!

SQL> COL NAME FOR A17
SQL> SELECT FILE#,STATUS,ERROR,RECOVER,FUZZY,BYTES,NAME FROM V$DATAFILE_HEADER WHERE FILE#=254;

     FILE# STATUS  ERROR                          REC FUZ      BYTES NAME
---------- ------- ------------------------------ --- --- ---------- -----------------
       254 OFFLINE                                 NO  YES 1.8765E+10 +DATA2/so_35.dbf                   ====> status=offline 与trace文件中处理结果一致。
这里我们可以看到文件本身的状态是available,但是文件头已经是offline状态,与trace 文件内容一致。
  • 尝试恢复数据文件
SQL> ALTER DATABASE RECOVER DATAFILE 254;

Database altered.
  • online 数据文件
SQL> ALTER DATABASE DATAFILE 254 ONLINE;

Database altered.

SQL> SELECT FILE_NAME,STATUS,BYTES FROM DBA_DATA_FILES WHERE FILE_ID=254;

FILE_NAME                                STATUS         BYTES
---------------------------------------- --------- ----------
+DATA2/so_35.dbf                         AVAILABLE 1.8765E+10       ===========================================> 文件大小已正常刷新!

NOTES
数据库最好是在归档状态,如果问题处理不及时,redo 文件被覆盖而又没有开启归档,这种处理方式不会奏效的.

5 问题总结

从现象上来看,是由于物理磁盘空间不足引起的。此问题,目前发现的,只有10G,SUNOS 操作系统中会出现。
 经确认,此问题,属于BUG(Bug 9357097),在数据库版本11.2.0.2 之后得以解决。

6 建议

由于此BUG Oracle官方未提供任何补丁及规避方案。因此,将数据库最低升级至11.2.0.4 版本,以避免Oracle 10G 中诸多BUG.

7 高屋建瓴

数据库,是一个超级复杂的程序,里面的各种逻辑关系,让人想起来就头皮发麻。在一个复杂到要一个人花数年时间去研究其中的逻辑的程序中,肯定会存在各种各样的问题,包括尚未完善的甚至是缺失的功能。
Oracle官方在这一点上也做的不错,就是在推广应用、维护的过程中,收集问题,处理问题,优化逻辑,收集BUG,弥补过失。尽力使自己的产品功能完善,减少问题,并尽力跟随世界发展的趋势.
毕竟这样一个庞大的数据库想要做体系架构的变动实在是难。
新的版本数据,解决了旧版本中各种的BUG,新添加了很多的增强的功能,一方面使数据库性能得以提升,同时,更加便于维护管理。
那么我们的客户使用对方的产品,我们作为Oracle的一个合作商,是否有这种魄力,推动客户去做数据库升级呢?而同时,这会又是一个新的项目基点。
哪怕没有此种问题,我们是否有向客户提供打补丁的建议?以提高客户满意度?

Author: AsiaInfo Techenology(China) Co. Ltd. 部门: PMO 工程师:李海波

Created: 2019-06-22 Sat 11:47

Validate

上一篇:C#Winform学习笔记


下一篇:WinForm 关闭登陆窗体,打开主窗体的实现