一次Oracle数据文件镜像丢失引起的故障解决

193次阅读

共计 6356 个字符，预计需要花费 16 分钟才能阅读完成。

对 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 有比较大的差异，其他文件没有差异。

检索两个 SCN 号：1490874094 对应的时间是 2016/9/21 9:49，而 1490736502 对应的时间是 2016/9/20 9:00。显然是文件在关闭 shutdown immediate 之后，由于一些原因被替换为 24 小时之前的文件。

和朋友确认，的确是有可能备份厂商为了能够启动数据库，似乎使用过头一天的镜像来部分还原数据文件，而且是整个 F 盘。

了解了原有，就起码有一个基本出发点。下面就是如何进行数据处理，具体来说有三种方法可以考虑：

ü 如果需要紧急的启动数据库，在非归档模式下，可以将 F 盘对应的表空间和数据文件 offline drop 剔除数据库。但是这样，就永远不能将文件数据追回了；

ü 对应 F 盘上的数据都是数据表空间文件，而不是系统表空间，而且在一天中乜有对应的更新，所以可以通过 bbed 类型手工修改文件头 SCN 编号，让所有文件 SCN 号统一。这样就可以避免 open 过程错误，但是需要人为修改若干个文件头，技术风险存在；

ü 第三种是让 Oracle 启动 open 过程放弃验证 SCN 一致性，强行打开系统。这样的问题是，后续也可能出现其他报错问题。

经过讨论，决定使用第三种方法进行操作。

3、操作处理

Oracle 放弃一致性检查的参数是_ALLOW_RESETLOGS_CORRUPTION，将其添加在 pfile 中，使用这个 pfile 启动数据库。

注意：放弃验证之后，依然会有 open resetlog 方式启动数据库，刷新全体 SCN 对象的情况。之后，open 状态依然存在问题。

SQL> alter database open;

alter database open

*

第 1 行出现错误:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00604: error occurred at recursive SQL level 1

ORA-01555: snapshot too old: rollback segment number 6 with name

“_SYSSMU6_1439239625$” too small

进程 ID: 2596

会话 ID: 96 序列号: 1

在 alert log 中，报错如下：

Thu Oct 06 10:04:19 2016

SMON: enabling cache recovery

ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.58dbbfec):

select ctime, mtime, stime from obj$ where obj# = :1

Errors in file d:\app\administrator\diag\rdbms\DGT\DGT\trace\DGT_ora_7856.trc:

ORA-00704: 引导程序进程失败

ORA-00604: 递归 SQL 级别 1 出现错误

ORA-01555: 快照过旧: 回退段号 6 (名称为 “_SYSSMU6_1439239625$”) 过小

Errors in file d:\app\administrator\diag\rdbms\DGT\DGT\trace\DGT_ora_7856.trc:

ORA-00704: 引导程序进程失败

ORA-00604: 递归 SQL 级别 1 出现错误

ORA-01555: 快照过旧: 回退段号 6 (名称为 “_SYSSMU6_1439239625$”) 过小

Error 704 happened during db open, shutting down database

USER (ospid: 7856): terminating the instance due to error 704

Instance terminated by USER, pid = 7856

ORA-1092 signalled during: alter database open…

opiodr aborting process unknown ospid (7856) as a result of ORA-1092

Thu Oct 06 10:04:21 2016

ORA-1092 : opitsk aborting process

Oracle 启动 open 阶段要进行两个 recovery，分别为 Media Recovery 和 Cache Recovery。Media Recovery 主要是基于 online redo log 进行日志的前滚操作，Cache Recovery 则是依赖从 bootstrap$ 等系列数据字典对象创建重构，将数据库启动的操作过程。

当前报错主要是在执行 SQL：4krwuz0ctqxdt 的时候，要求 SCN 为 0x0000.58dbbfec 的数据镜像。这个 SCN 时间对应为：1490796524，而检索时候希望使用 MVCC 特性，就出现了 undo 段不支持的情况了。

那么，这个时间点是什么？

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 1490776516 1490776516

D:\APP\ADMINISTRATOR\ORADATA\DGT\SYSAUX01.DBF 1490776516 1490776516

SQL> select resetlogs_change#, CHECKPOINT_CHANGE# from v$database;

RESETLOGS_CHANGE# CHECKPOINT_CHANGE#