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