ORA-01148:cannot refresh file size for datafile ***
ORA-01148: cannot refresh file size for datafile *
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的一个合作商,是否有这种魄力,推动客户去做数据库升级呢?而同时,这会又是一个新的项目基点。 哪怕没有此种问题,我们是否有向客户提供打补丁的建议?以提高客户满意度?
Created: 2019-06-22 Sat 11:47
===================
天行健,君子以自强不息
地势坤,君子以厚德载物
===================