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

 

笔者在《一次数据文件镜像丢失引起的故障解决》（http://blog.itpub.net/17203031/viewspace-2126579/）中，使用了强制关闭数据库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

 

 

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

 

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

转载于:http://blog.itpub.net/17203031/viewspace-2126665/