ITPub博客

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

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

原创 Oracle 作者:realkid4 时间:2016-10-17 15:12:07 2 删除 编辑

 

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 abortnormalimmediatetransactional。每种关闭模式都对应不同的行为,shutdown immediate操作是可以保证各个文件文件头SCN和控制文件control fileSCN一致。在这个问题中,也可以在alert log中找到对应的过程记录。

 

那么,为什么在重新启动服务器和Oracle之后,出现了丢失文件的现象。曾经一致的SCN出现了什么问题。

 

这个时候,一种比较方便的是观察视图v$datafilev$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-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-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-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 RecoveryCache RecoveryMedia Recovery主要是基于online redo log进行日志的前滚操作,Cache Recovery则是依赖从bootstrap$等系列数据字典对象创建重构,将数据库启动的操作过程。

 

当前报错主要是在执行SQL4krwuz0ctqxdt的时候,要求SCN0x0000.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#

----------------- ------------------

       1490736503         1490776516

 

 

由于原来的SCN比较高,现在检索一个过去的SCN时间点是不存在的。解决的方法是强制的推动SCN到一个适当地时间点。

 

 

 

SQL> conn / as sysdba

已连接。

SQL> select open_mode from v$database;

 

OPEN_MODE

--------------------

MOUNTED

 

 

SQL> alter session set events '10015 trace name adjust_scn level 10';

 

会话已更改。

 

SQL> select CHECKPOINT_CHANGE# from v$database;

 

CHECKPOINT_CHANGE#

------------------

        1490796521

 

SQL>

 

SQL> alter session set events '10015 trace name adjust_scn level 10';

 

会话已更改。

 

SQL> select CHECKPOINT_CHANGE# from v$database;

 

CHECKPOINT_CHANGE#

------------------

        1490796521

 

SQL> alter session set events '10015 trace name adjust_scn level 10';

 

会话已更改。

 

SQL> select CHECKPOINT_CHANGE# from v$database;

 

CHECKPOINT_CHANGE#

------------------

        1490796521

 

SQL> alter database open;

 

数据库已更改。

 

SQL> select CHECKPOINT_CHANGE# from v$database;

 

CHECKPOINT_CHANGE#

------------------

        1490816526

 

 

注意:当前数据库版本为11.2.0.1,通过10015方法推动SCN编号前进的策略是可以的。之后的11.2.0.211.2.0.3之后,这种方法就被Oracle禁用了,只能使用oradebug来改写内存进行修改了。

 

推动Oracle SCN编号之后,Oracle可以正常启动开启,问题消失。

 

4、结论

 

Oracle故障是我们经常遇到的问题,每一种故障的处理方法都有所不同。处理的过程,是建立在我们大量的分析思考基础上,从数据安全留存的角度出发进行的最优决策。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/17203031/viewspace-2126579/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
求道~

注册时间:2010-11-30

  • 博文量
    545
  • 访问量
    7808868