对DBA而言，世间最悲催的事情不外于由于软硬件故障（硬件居多）引起的数据丢失，同时发现没有备份，恢复无门。但是，笔者并不认为“归档模式+若干备份”是避免出现问题的法宝。“狡兔三窟”，事先多留退路可能是成熟DBA应有的职业素养。关键时刻，一个几天前的Dump文件、几个月前的配置表和系统特性往往是拯救DBA职业生命的关键。
数据文件丢失、损坏这样的错误，随着管理人员水平的提升和技术保障，已经很少在行业中听到的。相对于软件故障，基础环境硬件故障和人为操作故障，常常是我们面对故障的直接因素。在这样的背景下，规范的操作、对系统数据的熟悉程度和稳妥的处置是我们避免问题进一步恶化，最大限度挽回损失的重要措施。
本篇主要介绍笔者遇到的文件丢失故障。
1、问题说明
一个负责管理数据库的朋友来找笔者，说负责的一个数据库在启动时候报错，文件找不到。具体日志如下：
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Errors in file d:\app\administrator\diag\rdbms\DGT\DGT\trace\DGT_ora_2028.trc:
ORA-01113:文件28需要介质恢复
ORA-01110: 数据文件 28: 'F:\XXX\XXXX01.DBF'
ORA-1113 signalled during: alter database open...
Wed Sep 21 13:20:57 2016
Checker run found 51 new persistent data failures
环境是虚拟机，朋友同时也是虚拟平台管理员，平时对硬盘故障监控的比较勤。数据库是11gR2，具体版本为11.2.0.1 For Windows版本。远程登录操作系统，对应的各个盘符都存在，而且正常访问。
出现问题的F盘文件，也可以从资源管理器中找到。
遇到这种情况，作为分析人员，不是简单去重复重启服务器，这样通常会让问题更加恶化。这个时候，DBA首要工作是“手离开键盘，通知可以帮助你的领导和同事”！大家一起坐下来，通过分析来确认问题源头。
注意：分析的过程中，不能单方面听取管理员和用户的陈述，因为在高压力的情况下，管理员可能会将重要的操作、现象加以回避。所以，alert log、操作系统日志和应用服务器日志都是可以忠实反映问题的资料来源。下面是通过多方面验证得到的故障分析：
ü 问题源头是虚拟化平台备份软件故障，在对服务器进行备份失败的时候，生成的瞬时镜像是不能自动删除，长期留待系统中占据空间；
ü 出现故障的服务器恰恰是本次软件故障受影响的服务器之一，数据量超过1T；
ü 故障数据库在关闭修理之前，朋友曾经shutdown immediate关机，当时操作正常，没有报错；
ü 该服务器在启动过程中，独立的各个盘符分别对应了不同的磁盘组，备份软件厂商曾经进行过处理；
ü 该数据库中数据输入数据仓库类型系统，目前数据已经加载完毕，近几个月都是进行只读操作；
ü 数据库处在非归档情况下，无备份；
2、问题分析
正常情况下，无备份、非归档情况下的Oracle系统，一旦发生文件损坏、数据丢失的情况，都属于是大事故。很多时候，能修复都是依赖一些特定条件和好运气。针对这个案例，笔者认为一个基本出发点就是之前的“成功关闭”。
Oracle关闭系统有若干种模式，如shutdown abort、normal、immediate和transactional。每种关闭模式都对应不同的行为，shutdown immediate操作是可以保证各个文件文件头SCN和控制文件control file中SCN一致。在这个问题中，也可以在alert log中找到对应的过程记录。
那么，为什么在重新启动服务器和Oracle之后，出现了丢失文件的现象。曾经一致的SCN出现了什么问题。
这个时候，一种比较方便的是观察视图v$datafile和v$datafile_header两个对象。v$datafile是在控制文件中记录的各个文件的SCN和对应信息，而v$datafile_header是各个数据文件对应的文件头信息。通过对比，视图发现一些端倪。
SQL> select a.name,a.checkpoint_change# start_SCN,
2 b.checkpoint_change# last_SCN
3 from v$datafile_header a, v$datafile b
4 where a.file#=b.file#;
NAME START_SCN LAST_SCN
-------------------------------------------------------------------------------- ---------- ----------
D:\APP\ADMINISTRATOR\ORADATA\DGT\SYSTEM01.DBF 1490874094 1490874094
（篇幅原因，有省略……）
E:\DATAFILE\DATA1G17.DBF 1490874094 1490874094
E:\DATAFILE\DATA1G18.DBF 1490874094 1490874094
F:\XXX\XXXX01.DBF 1490736502 1490874094
F:\XXX\XXXX02.DBF 1490736502 1490874094
F:\XXX\XXXX03.DBF 1490736502 1490874094
F:\XXX\XXXX04.DBF 1490736502 1490874094
（篇幅原因，有省略……）
F:\FINISH\FINISH23.DBF 1490736502 1490874094
E:\DATAFILE\DATA1G21.DBF 1490874094 1490874094
82 rows selected
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
1490874094
注意：这个数据库对应的文件数量是比较多的，为82个。出现问题的是F盘所有文件的文件头SCN和控制文件SCN有比较大的差异，其他文件没有差异。