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

笔者在《一次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 ProductionPL/SQL Release 11.2.0.4.0 - ProductionCORE 11.2.0.4.0 ProductionTNS for Linux: Version 11.2.0.4.0 - ProductionNLSRTL 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_.dbf7 rows selected2、故障模拟笔者的思路是：在数据库正常运行过程中，抽取数据文件7。Datafile 7对应的是一个过去时间的SCN编号和文件头。之后，通过一系列的Online Redo Log切换、手工检查点操作，最后直接shutdown immediate关闭服务器动作，推动数据库所有数据文件SCN编号前进。关闭之后，使用过去版本的数据文件7来替换文件。启动数据库进入open状态之后，如果当前online redo log已经乜有接续的文件（被覆盖+非归档），系统报错。当前文件目录，拷贝留存一个旧版本的datafile 7。[oracle@TESTlife datafile]$ ls -ltotal 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 -ltotal 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 alteredSQL> alter system switch logfile;System alteredSQL> 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 /nologSQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 18 22:14:53 2016Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected.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 -ltotal 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 sysdbaConnected to an idle instance.SQL> startupORACLE instance started.Total System Global Area 3540881408 bytesFixed Size 2258320 bytesVariable Size 855640688 bytesDatabase Buffers 2667577344 bytesRedo Buffers 15405056 bytesDatabase mounted.ORA-01113: file 7 needs media recoveryORA-01110: data file 7:"/u01/app/oracle/oradata/TESTDB/datafile/o1_mf_epssite_by19vtnh_.dbf"使用redo log进行修复，失败。SQL> recover datafile 7ORA-00279: change 1713752 generated at 10/18/2016 22:00:25 needed for thread 1ORA-00289: suggestion :/u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2016_10_18/o1_mf_1_60_%u_.arcORA-00280: change 1713752 for thread 1 is in sequence #60Specify 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 statusLinux-x86_64 Error: 2: No such file or directoryAdditional information: 3故障出现，尝试进行修复。更多详情见请继续阅读下一页的精彩内容： http://www.linuxidc.com/Linux/2016-10/136569p2.htm

使用NID修改DBID和DBNAME实验MongoDB 3.0.2与wiredTiger存储引擎安装测试相关资讯 BBED

Oracle BBED 修改数据内容（08月22日）
通过BBED修复ORA-01190错误（11/16/2015 10:51:13）

Oracle 11g 编译使用BBED （03月08日）
Oracle实验：用BBED恢复误删记录的（06/14/2012 17:21:36）

本文评论查看全部评论（0）