使用BBED修改文件头解决数据库Open验证问题

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

笔者在《一次 Oracle 数据文件镜像丢失引起的故障解决》（http://www.linuxidc.com/Linux/2016-10/136212.htm）中，使用了强制关闭数据库 Open 过程中完整性验证来开启数据库。除此之外，还可以使用数据文件头修改的方法，“骗过”Oracle 启动机制。

本篇就通过 BBED 来模拟错误和进行修复。注意：BBED 是 Oracle 研究的利器，但是同样也可能是“塌天大祸”的起始。所以，如果没有 100% 把握，绝对不要轻易在投产环境上应用。作为技术人员，创新精神是可贵的，但是谨慎认真是更需要的一种职业素养。

1、环境说明

笔者使用 Oracle 11gR2 进行测试，具体版本为 11.2.0.4。

SQL> select * from v$version;

BANNER

——————————————————————————–

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production

PL/SQL Release 11.2.0.4.0 – Production

CORE    11.2.0.4.0    Production

TNS for Linux: Version 11.2.0.4.0 – Production

NLSRTL Version 11.2.0.4.0 – Production

当前数据文件列表如下：

SQL> select file#, checkpoint_change#, checkpoint_time, name from v$datafile;

    FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME NAME

———- —————— ————— ——————————————————————————–

        1            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf

        2            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_sysaux_bw773xpr_.dbf

        3            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_undotbs1_bw773xqo_.dbf

        4            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_users_bw773xrv_.dbf

        5            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_TESTdev_bw8xbqrz_.dbf

        6            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_inttestt_bw8xdnkt_.dbf

        7            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

7 rows selected

2、故障模拟

笔者的思路是：在数据库正常运行过程中，抽取数据文件 7。Datafile 7 对应的是一个过去时间的 SCN 编号和文件头。之后，通过一系列的 Online Redo Log 切换、手工检查点操作，最后直接 shutdown immediate 关闭服务器动作，推动数据库所有数据文件 SCN 编号前进。

关闭之后，使用过去版本的数据文件 7 来替换文件。启动数据库进入 open 状态之后，如果当前 online redo log 已经乜有接续的文件（被覆盖 + 非归档），系统报错。

当前文件目录，拷贝留存一个旧版本的 datafile 7。

[oracle@TESTlife datafile]$ ls -l

total 6482252

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:05 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:05 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–. 1 oracle oinstall    5251072 Oct 18 22:05 o1_mf_users_bw773xrv_.dbf

（篇幅原因，有省略……）

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf o1_mf_epssite_by19vtnh_.dbf_bk

[oracle@TESTlife datafile]$ ls -l

total 8452440

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:05 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:12 o1_mf_epssite_by19vtnh_.dbf_bk

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:05 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–  1 oracle oinstall 1283465216 Oct 18 22:05 o1_mf_TESTdev_bw8xbqrz_.dbf

-rw-r—–. 1 oracle oinstall  597696512 Oct 18 22:10 o1_mf_sysaux_bw773xpr_.dbf

多次切换日志，进行检查点操作。

SQL> alter system switch logfile;

System altered

（篇幅原因，有省略……）

SQL> alter system checkpoint;

System altered

SQL> alter system switch logfile;

System altered

SQL> select group#, status, FIRST_CHANGE# from v$log;

    GROUP# STATUS          FIRST_CHANGE#

———- —————- ————-

        1 CURRENT                1714475

        2 INACTIVE              1714464

        3 INACTIVE              1714467

关闭数据库，强行使用旧版本文件替换。

[oracle@TESTlife datafile]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 18 22:14:53 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn / as sysdba

Connected.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf o1_mf_epssite_by19vtnh_.dbf_bk_f

[oracle@TESTlife datafile]$ ls -l

total 10422628

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:15 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:12 o1_mf_epssite_by19vtnh_.dbf_bk

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:20 o1_mf_epssite_by19vtnh_.dbf_bk_f

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:15 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–  1 oracle oinstall 1283465216 Oct 18 22:15 

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf_bk o1_mf_epssite_by19vtnh_.dbf

启动数据库，在 open 过程中报错。

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 3540881408 bytes

Fixed Size                  2258320 bytes

Variable Size            855640688 bytes

Database Buffers        2667577344 bytes

Redo Buffers              15405056 bytes

Database mounted.

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7:

‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf’

使用 redo log 进行修复，失败。

SQL> recover datafile 7

ORA-00279: change 1713752 generated at 10/18/2016 22:00:25 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2016_10_18/o1_mf_1_60_%u_.a

rc

ORA-00280: change 1713752 for thread 1 is in sequence #60

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log

‘/u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2016_10_18/o1_mf_1_60_%u_.

arc’

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

故障出现，尝试进行修复。

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2016-10/136569p2.htm

在上篇中，我们进行了环境准备。下面就可以进行问题修复动作。

    3、故障修复

总体修复的思路是：使用 BBED，将文件头的 SCN 等关键信息修改到与控制文件 control file 相匹配即可。

当前，控制文件各个文件 SCN 相同，而数据文件上 SCN 不同。

– 控制文件上信息

SQL> select file#, CHECKPOINT_CHANGE# from v$datafile;

    FILE# CHECKPOINT_CHANGE#

———- ——————

        1            1714543

        2            1714543

        3            1714543

        4            1714543

        5            1714543

        6            1714543

        7            1714543

7 rows selected

SQL> select CHECKPOINT_CHANGE# from v$database;

CHECKPOINT_CHANGE#

——————

          1714543

– 数据文件头信息

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

    FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

———- ——- —– ——————

        1 NO      NO              1714543

        2 NO      NO              1714543

        3 NO      NO              1714543

        4 NO      NO              1714543

        5 NO      NO              1714543

        6 NO      NO              1714543

        7 YES    YES              1713752

7 rows selected

一种最简单的策略，是将 File 7 对应的 SCN 修改为其他文件相同。首先，我们可以先使用 BBED 看一下那些正确文件的内容是什么。

[Oracle@TESTlife datafile]$ bbed 

Password: 

BBED: Release 2.0.0.0.0 – Limited Production on Tue Oct 18 22:33:26 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************

BBED> set filename ‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf’ –一号文件

        FILENAME        /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf

BBED> set block 1

        BLOCK#          1

BBED> map

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

 Block: 1                                    Dba:0x00000000

————————————————————

 Data File Header

 struct kcvfh, 860 bytes                    @0       

 ub4 tailchk                                @8188   

针对这个案例，我们通常需要关注四个偏移量 offset 点，分别为 484、492、140 和 148。

BBED> p kcvfh

struct kcvfh, 860 bytes                    @0       

  struct kcvfhbfh, 20 bytes                @0       

      ub1 type_kcbh                        @0        0x0b

（篇幅原因，有省略……）

  ub2 kcvfhbth                            @136      0x0000

  ub2 kcvfhsta                            @138      0x2000 (NONE)

  struct kcvfhckp, 36 bytes                @484     

      struct kcvcpscn, 8 bytes              @484     

        ub4 kscnbas                        @484      0x001a296f        –SCN：1714543 与文件一致

        ub2 kscnwrp                        @488      0x0000

      ub4 kcvcptim                          @492      0x372b7d00        – 最后一次 Check Point Time

      ub2 kcvcpthr                          @496      0x0001

      union u, 12 bytes                    @500     

        struct kcvcprba, 12 bytes          @500     

            ub4 kcrbaseq                    @500      0x00000043

            ub4 kcrbabno                    @504      0x0000005b

            ub2 kcrbabof                    @508      0x0010

      ub1 kcvcpetb[0]                      @512      0x02

      ub1 kcvcpetb[1]                      @513      0x00

      ub1 kcvcpetb[2]                      @514      0x00

      ub1 kcvcpetb[3]                      @515      0x00

      ub1 kcvcpetb[4]                      @516      0x00

      ub1 kcvcpetb[5]                      @517      0x00

      ub1 kcvcpetb[6]                      @518      0x00

      ub1 kcvcpetb[7]                      @519      0x00

  ub4 kcvfhcpc                            @140      0x000000c8        –Check Point Count

  ub4 kcvfhrts                            @144      0x372b5d94         

  ub4 kcvfhccc                            @148      0x000000c7        – 比检查点计数少 1

  struct kcvfhbcp, 36 bytes                @152     

      struct kcvcpscn, 8 bytes              @152     

        ub4 kscnbas                        @152      0x00000000

        ub2 kscnwrp                        @156      0x0000

      ub4 kcvcptim                          @160      0x00000000

（篇幅原因，有省略……）

其中，位于 484 和 488 偏移量的是数据文件对应的 SCN 编号。在 Oracle 内部，SCN 是使用 wrap*4*1024*1024*1024+base 来进行标示的。通常我们看到的数据库 wrap 都是 0。位于 492 偏移量的是最后一次检查点对应的时间信息。位于 140 和 148 偏移量的是检查点次数。这些信息都是会由于时间推动和检查点动作引起变化，我们严格情况下，需要保证文件头块的信息和控制文件信息一致。

另外一点，由于 Linux 是 Little 字节系统，要关注写入时候的格式问题。最简单的方式是 dump 一下偏移量，看看是怎么保存的。

BBED> set offset 484

        OFFSET          484

（0x001a296f）

BBED> dump   

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

 Block: 1                Offsets:  484 to  995          Dba:0x00000000

————————————————————————

 6f291a00 00000000 007d2b37 01000000 43000000 5b000000 10009e33 02000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

BBED> set offset 492

        OFFSET          492

（0x372b7d00）

BBED> dump

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

 Block: 1                Offsets:  492 to 1003          Dba:0x00000000

————————————————————————

 007d2b37 01000000 43000000 5b000000 10009e33 02000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 0d000d00 0d000100 

BBED> set offset 140

        OFFSET          140

（0x000000c8）

BBED> dump

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

 Block: 1                Offsets:  140 to  651          Dba:0x00000000

————————————————————————

 c8000000 945d2b37 c7000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

BBED> set offset 144

        OFFSET          144

（0x000000c7)

BBED> dump

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf (0)

 Block: 1                Offsets:  144 to  655          Dba:0x00000000

————————————————————————

 945d2b37 c7000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

实施修改文件块动作：

BBED> set filename ‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf’

        FILENAME        /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

BBED> set block 1

        BLOCK#          1

BBED> set mode edit

        MODE            Edit

修改对应文件块的位数。

BBED> m /x 6f291a00 offset 484

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf (0)

 Block: 1                Offsets:  484 to  995          Dba:0x00000000

————————————————————————

 6f291a00 00000000 79792b37 01005e7d 3c000000 02000000 10000000 02000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

BBED> m /x 007d2b37 offset 492

 File: /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf (0)

 Block: 1                Offsets:  492 to 1003          Dba:0x00000000

————————————————————————

 007d2b37 01005e7d 3c000000 02000000 10000000 02000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

注意：Oracle 数据块中使用冗余校验功能，修改数据块之后，要使用 sum apply 重新计算校验位。

BBED> sum apply

Check value for File 0, Block 1:

current = 0xc606, required = 0xc606

BBED> verify

DBVERIFY – Verification starting

FILE = /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

BLOCK = 1

DBVERIFY – Verification complete

Total Blocks Examined        : 1

Total Blocks Processed (Data) : 0

Total Blocks Failing  (Data) : 0

Total Blocks Processed (Index): 0

Total Blocks Failing  (Index): 0

Total Blocks Empty            : 0

Total Blocks Marked Corrupt  : 0

Total Blocks Influx          : 0

Message 531 not found;  product=RDBMS; facility=BBED

此时在 mount 状态的数据库中看一下，可以发现文件 SCN 已经发生变化。

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

    FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

———- ——- —– ——————

        1 NO      NO              1714543

        2 NO      NO              1714543

        3 NO      NO              1714543

        4 NO      NO              1714543

        5 NO      NO              1714543

        6 NO      NO              1714543

        7 YES    YES              1714543

7 rows selected

启动数据库，尝试 open。

[oracle@TESTlife datafile]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 18 23:02:18 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn / as sysdba

Connected.

SQL> select open_mode from v$database;

OPEN_MODE

——————–

MOUNTED

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7:

‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf’

使用 recover 命令进行还原，此时需要的 online redo log 就可以支持了。

SQL> recover datafile 7;

Media recovery complete.

SQL> alter database open;

Database altered

启动过程的 alert log 信息：

Tue Oct 18 23:02:35 2016

alter database open

Errors in file /u01/app/oracle/diag/rdbms/TESTdb/TESTdb/trace/TESTdb_ora_16545.trc:

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7: ‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf’

ORA-1113 signalled during: alter database open…

Tue Oct 18 23:02:49 2016

ALTER DATABASE RECOVER  datafile 7 

Media Recovery Start

Serial Media Recovery started

WARNING! Recovering data file 7 from a fuzzy backup. It might be an online

backup taken without entering the begin backup command.

Media Recovery Complete (TESTdb)

Completed: ALTER DATABASE RECOVER  datafile 7 

alter database open

Oracle 在 recover 的时候发现有一些问题，但是还是让通过了。此时，数据整体正常。

SQL> select file#, recover, fuzzy, CHECKPOINT_CHANGE# from v$datafile_header;

    FILE# RECOVER FUZZY CHECKPOINT_CHANGE#

———- ——- —– ——————

（篇幅原因，有省略……）

        5 NO      YES              1714546

        6 NO      YES              1714546

        7 NO      YES              1714546

7 rows selected

4、结论

Oracle 启动 Open 是一个极其复杂的过程。单独通过 open 过程，我们就可以学习到很多的知识和技能。在解决故障的时候，应用多种途径，找到最适当的策略，是我们需要掌握的工作手段。

更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-10/136569.htm

笔者在《一次 Oracle 数据文件镜像丢失引起的故障解决》（http://www.linuxidc.com/Linux/2016-10/136212.htm）中，使用了强制关闭数据库 Open 过程中完整性验证来开启数据库。除此之外，还可以使用数据文件头修改的方法，“骗过”Oracle 启动机制。

本篇就通过 BBED 来模拟错误和进行修复。注意：BBED 是 Oracle 研究的利器，但是同样也可能是“塌天大祸”的起始。所以，如果没有 100% 把握，绝对不要轻易在投产环境上应用。作为技术人员，创新精神是可贵的，但是谨慎认真是更需要的一种职业素养。

1、环境说明

笔者使用 Oracle 11gR2 进行测试，具体版本为 11.2.0.4。

SQL> select * from v$version;

BANNER

——————————————————————————–

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit Production

PL/SQL Release 11.2.0.4.0 – Production

CORE    11.2.0.4.0    Production

TNS for Linux: Version 11.2.0.4.0 – Production

NLSRTL Version 11.2.0.4.0 – Production

当前数据文件列表如下：

SQL> select file#, checkpoint_change#, checkpoint_time, name from v$datafile;

    FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME NAME

———- —————— ————— ——————————————————————————–

        1            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_system_bw773xok_.dbf

        2            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_sysaux_bw773xpr_.dbf

        3            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_undotbs1_bw773xqo_.dbf

        4            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_users_bw773xrv_.dbf

        5            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_TESTdev_bw8xbqrz_.dbf

        6            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_inttestt_bw8xdnkt_.dbf

        7            1713752 2016/10/18 22:0 /u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf

7 rows selected

2、故障模拟

笔者的思路是：在数据库正常运行过程中，抽取数据文件 7。Datafile 7 对应的是一个过去时间的 SCN 编号和文件头。之后，通过一系列的 Online Redo Log 切换、手工检查点操作，最后直接 shutdown immediate 关闭服务器动作，推动数据库所有数据文件 SCN 编号前进。

关闭之后，使用过去版本的数据文件 7 来替换文件。启动数据库进入 open 状态之后，如果当前 online redo log 已经乜有接续的文件（被覆盖 + 非归档），系统报错。

当前文件目录，拷贝留存一个旧版本的 datafile 7。

[oracle@TESTlife datafile]$ ls -l

total 6482252

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:05 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:05 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–. 1 oracle oinstall    5251072 Oct 18 22:05 o1_mf_users_bw773xrv_.dbf

（篇幅原因，有省略……）

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf o1_mf_epssite_by19vtnh_.dbf_bk

[oracle@TESTlife datafile]$ ls -l

total 8452440

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:05 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:12 o1_mf_epssite_by19vtnh_.dbf_bk

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:05 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–  1 oracle oinstall 1283465216 Oct 18 22:05 o1_mf_TESTdev_bw8xbqrz_.dbf

-rw-r—–. 1 oracle oinstall  597696512 Oct 18 22:10 o1_mf_sysaux_bw773xpr_.dbf

多次切换日志，进行检查点操作。

SQL> alter system switch logfile;

System altered

（篇幅原因，有省略……）

SQL> alter system checkpoint;

System altered

SQL> alter system switch logfile;

System altered

SQL> select group#, status, FIRST_CHANGE# from v$log;

    GROUP# STATUS          FIRST_CHANGE#

———- —————- ————-

        1 CURRENT                1714475

        2 INACTIVE              1714464

        3 INACTIVE              1714467

关闭数据库，强行使用旧版本文件替换。

[oracle@TESTlife datafile]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 18 22:14:53 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn / as sysdba

Connected.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf o1_mf_epssite_by19vtnh_.dbf_bk_f

[oracle@TESTlife datafile]$ ls -l

total 10422628

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:15 o1_mf_epssite_by19vtnh_.dbf

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:12 o1_mf_epssite_by19vtnh_.dbf_bk

-rw-r—–  1 oracle oinstall 2017468416 Oct 18 22:20 o1_mf_epssite_by19vtnh_.dbf_bk_f

-rw-r—–  1 oracle oinstall 1702895616 Oct 18 22:15 o1_mf_inttestt_bw8xdnkt_.dbf

-rw-r—–  1 oracle oinstall 1283465216 Oct 18 22:15 

[oracle@TESTlife datafile]$ cp o1_mf_epssite_by19vtnh_.dbf_bk o1_mf_epssite_by19vtnh_.dbf

启动数据库，在 open 过程中报错。

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 3540881408 bytes

Fixed Size                  2258320 bytes

Variable Size            855640688 bytes

Database Buffers        2667577344 bytes

Redo Buffers              15405056 bytes

Database mounted.

ORA-01113: file 7 needs media recovery

ORA-01110: data file 7:

‘/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf’

使用 redo log 进行修复，失败。

SQL> recover datafile 7

ORA-00279: change 1713752 generated at 10/18/2016 22:00:25 needed for thread 1

ORA-00289: suggestion :

/u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2016_10_18/o1_mf_1_60_%u_.a

rc

ORA-00280: change 1713752 for thread 1 is in sequence #60

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log

‘/u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2016_10_18/o1_mf_1_60_%u_.

arc’

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

故障出现，尝试进行修复。

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2016-10/136569p2.htm