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

ORA-01148: cannot refresh file size for datafile *

Table of Contents

• 1. 版本信息
• 2. 错误信息
• 3. 收集错误信息
• 4. 故障恢复
• 5. 问题总结
• 6. 建议
• 7. 高屋建瓴

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