数据库恢复起点判定(使用旧控制文件)

   下面是本人做的信息截自我做的一次恢复演练，我使用了旧的控制文件来恢复数据库，通过下面的信息我们可以知道当使用旧的控制文件进行数据库恢复时，oracle是如果确定恢复的起始scn，从而确定起始日志的sequence 

1.相关信息描述：

  本次恢复演练我restore了2015/3/31号的控制文件备份片，数据文件restore自4月份的数据库全被。

2. recover database

执行recover database using backup controlfile;命令查看恢复数据库所需的归档日志

SQL> recover database using backup controlfile;

SQL> recover database using backup controlfile;
ORA-00279: change 306942332414 generated at 03/31/2015 08:44:34 needed for thread 1
ORA-00289: suggestion : /archlog/recovertest1/recovertest1_99642_843846456.arc
ORA-00280: change 306942332414 for thread 1 is in sequence #99642


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

##从上面的信息中我们可以看出，恢复开始的scn为306942332414，该scn包含在实例1的第99642个归档日志中

3.查看log_history信息

select thread#,sequence#,FIRST_CHANGE#,FIRST_TIME,NEXT_CHANGE# from v$log_history where SEQUENCE#<102009 order by 3         
         1      99636  306,935,483,939 2015-03-31 08:06:26  306,939,873,746
         1      99637  306,939,873,746 2015-03-31 08:35:04  306,939,892,543
         1      99638  306,939,892,543 2015-03-31 08:35:43  306,941,744,721
         1      99639  306,941,744,721 2015-03-31 08:41:10  306,941,853,285
         1      99640  306,941,853,285 2015-03-31 08:42:28  306,941,998,347
         1      99641  306,941,998,347 2015-03-31 08:43:46  306,942,181,093
         1      99642  306,942,181,093 2015-03-31 08:44:34  306,942,501,094
         1      99643  306,942,501,094 2015-03-31 08:46:55  306,942,801,213

##上面只截取了查询出来的部分信息，从上面的信息中我们可以知道306942332414确实在实例1的99642归档中

4.查看数据库检查点

select CHECKPOINT_CHANGE#,CONTROLFILE_CHANGE# from v$database;

CHECKPOINT_CHANGE# CONTROLFILE_CHANGE#
------------------ -------------------
   306,939,892,543     306,942,332,414

##使用的旧的控制文件恢复数据库，oracle就是以v$database中CONTROLFILE_CHANGE# 为恢复的起始scn的

5.查看控制文件中数据文件检查点

select file#,status,CHECKPOINT_CHANGE# from v$datafile where status='ONLINE' or status='SYSTEM' order by 3;

     FILE# STATUS  CHECKPOINT_CHANGE#
---------- ------- ------------------
         1 SYSTEM     306,939,892,543
      1003 ONLINE     306,939,892,543
         3 ONLINE     306,939,892,543
         4 ONLINE     306,939,892,543
        13 ONLINE     306,939,892,543
       203 ONLINE     306,939,892,543
       204 ONLINE     306,939,892,543
       230 ONLINE     306,939,892,543
       336 ONLINE     306,939,892,543
       387 ONLINE     306,939,892,543
       439 ONLINE     306,939,892,543
       486 ONLINE     306,939,892,543
       530 ONLINE     306,939,892,543
       570 ONLINE     306,939,892,543
       660 ONLINE     306,939,892,543
       733 ONLINE     306,939,892,543
       743 ONLINE     306,939,892,543
       856 ONLINE     306,939,892,543
       918 ONLINE     306,939,892,543
       983 ONLINE     306,939,892,543
         2 ONLINE     306,939,892,543

21 rows selected.

6.查看数据文件头数据文件检查点

select file#,status,CHECKPOINT_CHANGE# from v$datafile_header where status='ONLINE' ORDER BY 3;

     FILE# STATUS  CHECKPOINT_CHANGE#
---------- ------- ------------------
       856 ONLINE     308,896,612,927
       570 ONLINE     308,896,623,428
       439 ONLINE     308,896,625,566
      1003 ONLINE     308,896,627,156
       660 ONLINE     308,905,788,858
       530 ONLINE     308,906,056,288
         4 ONLINE     308,925,397,029
       983 ONLINE     308,925,462,664
       204 ONLINE     308,925,585,054
       486 ONLINE     308,925,585,054
       336 ONLINE     308,926,143,162
         3 ONLINE     308,926,143,162
         2 ONLINE     308,926,143,162
       733 ONLINE     308,933,830,692
         1 ONLINE     308,933,830,692
       387 ONLINE     308,933,917,122
        13 ONLINE     308,933,968,723
       230 ONLINE     308,943,247,932
       203 ONLINE     308,943,323,261
       743 ONLINE     308,943,330,393
       918 ONLINE     308,943,330,393

21 rows selected.

7.通过x$kcvfh查看起始恢复scn

select hxfil FILENUMBER,fhsta STATUS,fhscn SCN,fhrba_Seq SEQUENCE,INST_ID from x$kcvfh where fhrba_Seq <>0 order by 4;

FILENUMBER     STATUS SCN                SEQUENCE    INST_ID
---------- ---------- ---------------- ---------- ----------
       439         64 308896625566         102008          1
      1003         64 308896627156         102008          1
       570         64 308896623428         102008          1
       530         64 308906056288         102025          1
         4         64 308925397029         102067          1
         3         64 308926143162         102068          1
         2         64 308926143162         102068          1
       336          0 308926143162         102068          1
       733         64 308933830692         102083          1
         1       8256 308933830692         102083          1
       203         64 308943323261         102110          1
       856         64 308896612927         104383          1
       660         64 308905788858         104399          1
       486         64 308925585054         104442          1
       204         64 308925585054         104442          1
       983         64 308925462664         104442          1
       387         64 308933917122         104452          1
        13         64 308933968723         104452          1
       743         64 308943330393         104474          1
       918         64 308943330393         104474          1
       230          0 308943247932         104474          1

通过查询x$kcvfh 我们可以发现起始scn应该是308896625566，起始归档是实例1的102008号归档

8.通过log_history视图查看实例1102008号归档的FIRST_CHANGE#和NEXT_CHANGE#

查看数据文件头最小scn 308,896,612,927对应的归档日志

THREAD#  SEQUENCE#    FIRST_CHANGE# FIRST_TIME              NEXT_CHANGE#
---------- ---------- ---------------- ------------------- ----------------
         1     102008  308,896,364,623 2015-04-05 12:53:12  308,896,641,255

##我们发现第6步中查到的最小的数据文件头scn包含在实例1的102008号归档中

9.总结  

 1)通过上面的分析，我们可以知道，数据文件头的最小scn为308,896,612,927包含在实例1的102008号归档中(即该数据库文件的所有变化包含在102008号归档及以后的归档日志文件中)，但是我们recoverdatabase时却报需要的第一个归档是实例1的99642号归档日志。这是因为我们的控制文件是旧的控制文件，也需要通过跑归档来更新(99642到102008之间的归档应该都是空跑，因为这些归档对应的数据变化已经写入数据文件了)。

 2)使用旧的控制文件(控制文件时间早于数据文件备份集时间)，恢复数据库时，恢复的起始scn为v$database中CONTROLFILE_CHANGE# 

 3)所以如果使用旧的控制文件，应尽量restore离数据文件备份集时间比较近的(虽然归档空跑很快，但是如果我们的归档已经备份到带库等设备上，那么把那么多的归档恢复到本地也是一件十分耗时的事)

 4)如果可以尽量使用最近的控制文件进行数据库恢复(注意，注意可能上次全备后数据库结果发生了变化，比如新增了数据文件，那么此时用最新的数据文件restore数据文件时会报如下错误)

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/27/2015 10:50:35
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 682
RMAN-06100: no channel to restore a backup or copy of datafile 681 >>>>检查发现681和682两个数据文件都是在上次全备之后添加的，所以上次之前的备份集中没有两个文件的备份，所以恢复报错(遇到这种情况，我们需要restore 同全备时数据库结构一直的控制文件)

##oracle根据控制文件中记录的文件信息来restore数据文件，控制文件中记录有681和682两个文件，但是备份集中没有，所以restore的时候报错