BBED跳过归档恢复

      我们知道恢复的时候需要归档日志，假如我恢复的数据库需要10个归档日志，当恢复到5个的时候发现归档日志丢了，那么这种情况只能进行不完全恢复了，也就是说5号归档日志以后的数据都丢失了，但是其他的归档日志还是完好的，这样看来是不是有点“可惜了”，其实我们可以通过bbed跳过5号归档进行恢复，下面是实验步骤：

 

1.建立测试表，切换日志产生归档。

ZXY@zxy>create table test ( id number);

Table created.

ZXY@zxy>insert into test values (1);

1 row created.

ZXY@zxy>commit;

这里插入了6条数据
ZXY@zxy>select * from test;

        ID
----------
         1
         2
         3
         4
         5
         6
切换日志产生归档，每插入一条数据切换一次

SYS@zxy>alter system switch logfile;

System altered.

2.查看归档日志：

[oracle@zxy 2013_06_25]$ ll
-rw-r----- 1 oracle oinstall   888320 Jun 25 21:01 o1_mf_1_15_8wm54y3q_.arc
-rw-r----- 1 oracle oinstall    12800 Jun 25 21:01 o1_mf_1_16_8wm562c7_.arc
-rw-r----- 1 oracle oinstall     8192 Jun 25 21:02 o1_mf_1_17_8wm56jf3_.arc
-rw-r----- 1 oracle oinstall     2048 Jun 25 21:02 o1_mf_1_18_8wm5701y_.arc
-rw-r----- 1 oracle oinstall     9216 Jun 25 21:02 o1_mf_1_19_8wm57h27_.arc
-rw-r----- 1 oracle oinstall     6144 Jun 25 21:02 o1_mf_1_20_8wm57y2h_.arc

3.关闭数据库破坏数据文件和归档日志文件：

[oracle@zxy zxy]$ rm tbs_zxy_01.dbf
[oracle@zxy 2013_06_25]$ rm o1_mf_1_17_8wm56jf3_.arc

4.启动数据库报错：

SYS@zxy>startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  2020224 bytes
Variable Size             121638016 bytes
Database Buffers          159383552 bytes
Redo Buffers                2170880 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 10 - see DBWR trace file
ORA-01110: data file 10: '/u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf'

5.用rman转储datafile 10：

RMAN> restore datafile 10;

Starting restore at 25-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK

creating datafile fno=10 name=/u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf
restore not done; all files readonly, offline, or already restored
Finished restore at 25-JUN-13

6.恢复datafile 10：

SYS@zxy>recover datafile 10;
ORA-00279: change 2155502 generated at 06/25/2013 21:01:54 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ZXY/archivelog/2013_06_25/o1_mf_1_17_%u_.arc
ORA-00280: change 2155502 for thread 1 is in sequence #17

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/ZXY/archivelog/2013_06_25/o1_mf_1_17_8wm56j
f3_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

可以看到oracle找不到17号归档日志了。这种情况下常规的恢复只能做不完全恢复了，恢复到16号归档日志。

 

7.下面我们通过bbed跳过17归档日志应用17号以后的归档日志进行恢复：

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484    
   struct kcvcpscn, 8 bytes                 @484    
      ub4 kscnbas                           @484      0x0020e3ee
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x30d1e242
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500    
      struct kcvcprba, 12 bytes             @500    
         ub4 kcrbaseq                       @500      0x00000011--需要的归档日志序号（转化为10进制为17正好是我们缺少的归档日志）
         ub4 kcrbabno                       @504      0x00000002
         ub2 kcrbabof                       @508      0x0000
   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

BBED> set offset 500
        OFFSET          500

BBED> d count 32
 File: /u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf (10)
 Block: 1                Offsets:  500 to  531           Dba:0x02800001
------------------------------------------------------------------------
 11000000 02000000 00000000 02000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

BBED> modify /x 12
 File: /u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf (10)
 Block: 1                Offsets:  500 to  531           Dba:0x02800001
------------------------------------------------------------------------
 12000000 02000000 00000000 02000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

 

8.查看归档日志的SCN号：

SYS@zxy>select thread#,sequence#,first_change#,next_change# from v$archived_log ;

   THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
         1         10       2095473      2127817
         1         11       2127817      2155154
         1         12       2155154      2155256
         1         13       2155256      2155288
         1         14       2155288      2155299
         1         15       2155299      2155478
         1         16       2155478      2155502
         1         17       2155502      2155508

         1         18       2155508      2155516
         1         19       2155516      2155533
         1         20       2155533      2155542

     我们为了跳过17号归档日志，所以需要修改16号日志的 NEXT_CHANGE#为18号日志的FIRST_CHANGE#，即为2155508

 9.查看现在数据文件头中的这个号：

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484    
   struct kcvcpscn, 8 bytes                 @484    
      ub4 kscnbas                           @484      0x0020e3ee--转化为10进制为2155502即为17号日志的FIRST_CHANGE#
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x30d1e242
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500    
      struct kcvcprba, 12 bytes             @500    
         ub4 kcrbaseq                       @500      0x00000012
         ub4 kcrbabno                       @504      0x00000002
         ub2 kcrbabof                       @508      0x0000
   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

10.下面更改这个scn号为2155508（对应的16进制为20E3F4）：

BBED> set offset 484
        OFFSET          484

BBED> d count 32
 File: /u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf (10)
 Block: 1                Offsets:  484 to  515           Dba:0x02800001
------------------------------------------------------------------------
 eee32000 00000000 42e2d130 01000000 12000000 02000000 00000000 02000000

 <32 bytes per line>

注意dump出来的SCN号和我们上面看到存储顺序不一样，dump出来的存储顺序为倒叙。

BBED> d
 File: /u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf (10)
 Block: 1                Offsets:  484 to  515           Dba:0x02800001
------------------------------------------------------------------------
 eee32000 00000000 42e2d130 01000000 12000000 02000000 00000000 02000000

 <32 bytes per line>

BBED> modify /x F4E320
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/app/oracle/oradata/zxy/tbs_zxy_01.dbf (10)
 Block: 1                Offsets:  484 to  515           Dba:0x02800001
------------------------------------------------------------------------
 f4e32000 00000000 42e2d130 01000000 12000000 02000000 00000000 02000000

 <32 bytes per line>

BBED> sum apply
Check value for File 10, Block 1:
current = 0x289b, required = 0x289b

11.在此尝试恢复：

SYS@zxy>recover datafile 10;
ORA-00279: change 2155508 generated at 06/25/2013 21:01:54 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ZXY/archivelog/2013_06_25/o1_mf_1_18_%u_.arc
ORA-00280: change 2155508 for thread 1 is in sequence #18

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
Log applied.
Media recovery complete.

恢复成功了。

12.查询test表中的数据：

ZXY@zxy>select * from test;

        ID
----------
         1
         2
         4
         5
         6

发现少了"3"这条数据，也就是17号归档日志对应的数据改变。