跳过归档日志的完全非常规恢复(四)

跳过归档日志的完全非常规恢复(一) http://blog.chinaunix.net/uid-22948773-id-3294762.html
跳过归档日志的完全非常规恢复(二) http://blog.chinaunix.net/uid-22948773-id-3294763.html
跳过归档日志的完全非常规恢复(三) http://blog.chinaunix.net/uid-22948773-id-3294767.html
跳过归档日志的完全非常规恢复(四) http://blog.chinaunix.net/uid-22948773-id-3294770.html
跳过归档日志的完全非常规恢复(五) http://blog.chinaunix.net/uid-22948773-id-3294773.html

我们采用diff命令来查看2个文件的不同之处：

 

 

[oracle@db2server ~]$ diff recover_sequence7.txt recover_sequence8.txt
13c13
< ub2 chkval_kcbh @16 0xc785
---

> ub2 chkval_kcbh @16 0xc404
27c27
< ub4 kccfhcsq @40 0x00000325
---

> ub4 kccfhcsq @40 0x00000327
83c83
< ub4 kscnbas @484 0x000cf775
---

> ub4 kscnbas @484 0x000cf786
85c85
< ub4 kcvcptim @492 0x2f171759
---

> ub4 kcvcptim @492 0x2f171773
89c89
< ub4 kcrbaseq @500 0x00000008
---

> ub4 kcrbaseq @500 0x00000009
101c101
< ub4 kcvfhrts @144 0x2f171995
---

> ub4 kcvfhrts @144 0x2f171ace
[oracle@db2server ~]$

 

我们发现ORACLE一共改了6个地方：

偏移量16为块的校验值ub2 chkval_kcbh 原来为0xc785 后来为0xc404 

偏移量40为control sequence ub4 kccfhcsq  原先为0x00000325 后来为0x00000327

偏移量484为 ub4 kscnbas     --SCN of last change to the datafile.

偏移量492为 ub4 kcvcptim    --Time of the last change to the datafile

偏移量500为 ub4 kcrbaseq    --RECOVER需要的下一个日志序列号

偏移量144，我也不知道是干啥的

重点修改的内容为偏移量484，偏移量492，偏移量500，chkval_kcbh 最后通过bbed sum apply来得到，其他2个地方不修改问题也不大。

那么这3个地方要修改为啥呢？

偏移量484需要修改为需要归档日志文件的NEXT_CHANGE#。

如下：

日志序列号7的NEXT_CHANGE#为：

 

 

SQL> select to_number('cf775','xxxxxxxx') from dual;

TO_NUMBER('CF775','XXXXXXXX')
-----------------------------

                       849781

日志序列号8的NEXT_CHANGE#为：

SQL> select to_number('cf786','xxxxxxxx') from dual;

TO_NUMBER('CF786','XXXXXXXX')
-----------------------------

                       849798

 

日志序列号9的NEXT_CHANGE# 可以通过如下方式查到，就是849810，转为16进制就是0000cf792。

 

 

SQL> select SEQUENCE#,FIRST_CHANGE#,FIRST_TIME ,NEXT_CHANGE#,NEXT_TIME from v$archived_log order by 1;

 SEQUENCE# FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ------------- ------------------- ------------ -------------------

         6 848360 2012-07-31 00:03:06 849604 2012-07-31 00:08:36
         7 849604 2012-07-31 00:08:36 849781 2012-07-31 00:14:17
         8 849781 2012-07-31 00:14:17 849798 2012-07-31 00:14:43
         9 849798 2012-07-31 00:14:43 849810 2012-07-31 00:14:58
        10 849810 2012-07-31 00:14:58 849819 2012-07-31 00:15:10
        11 849819 2012-07-31 00:15:10 849834 2012-07-31 00:15:37

6 rows selected.

 

偏移量492需要修改为需要归档日志文件的NEXT_TIME#。

但是这里存放的不是时间值，而是从1988年1月1日起到现在所经历的秒数。

看看前面的这2个值

<       ub4 kcvcptim                          @492      0x2f171759

---

>       ub4 kcvcptim                          @492      0x2f171773

 

 

 

SQL> select to_number('2f171759','xxxxxxxx') from dual;

TO_NUMBER('2F171759','XXXXXXXX')
--------------------------------

                       790042457

SQL> select to_number('2f171773','xxxxxxxx') from dual;

TO_NUMBER('2F171773','XXXXXXXX')
--------------------------------

                       790042483

SQL> select 790042483-790042457 from dual;

790042483-790042457
-------------------


             26

 

         

从下面的查询我们也可以看到7和8的NEXT_TIME就是差了26秒，8和9之间差了15秒。

 

 

SQL> select SEQUENCE#,NEXT_TIME from v$archived_log order by 1;

 SEQUENCE# NEXT_TIME
---------- -------------------

         6 2012-07-31 00:08:36
         7 2012-07-31 00:14:17
         8 2012-07-31 00:14:43
         9 2012-07-31 00:14:58
        10 2012-07-31 00:15:10
        11 2012-07-31 00:15:37

6 rows selected.

 

因此这里存放的值修改为0x2f171773+15=790042483+15=790042498=0x2f171782

偏移量500更简单了修改为10就行了。

 

有了上面的知识我们回到RECOVER窗口：


SQL> recover datafile 6;
ORA-00279: change 849630 generated at 07/31/2012 00:09:16 needed for thread 1
ORA-00289: suggestion : /archivelog/1_7_789791289.dbf
ORA-00280: change 849630 for thread 1 is in sequence #7


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/archivelog/1_7_789791289.dbf
ORA-00279: change 849781 generated at 07/31/2012 00:14:17 needed for thread 1
ORA-00289: suggestion : /archivelog/1_8_789791289.dbf
ORA-00280: change 849781 for thread 1 is in sequence #8


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/archivelog/1_8_789791289.dbf
ORA-00279: change 849798 generated at 07/31/2012 00:14:43 needed for thread 1
ORA-00289: suggestion : /archivelog/1_9_789791289.dbf
ORA-00280: change 849798 for thread 1 is in sequence #9


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/archivelog/1_9_789791289.dbf
ORA-00308: cannot open archived log '/archivelog/1_9_789791289.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3


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


我们在应用日志文件/archivelog/1_9_789791289.dbf的时候报错了，这也是意料之中的。