济南建设个人网站平台企业网站营销的实现方式
下面是本人做的信息截自我做的一次恢复演练，我使用了旧的控制文件来恢复数据库，通过下面的信息我们可以知道当使用旧的控制文件进行数据库恢复时，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 #99642Specify log: {<RET>=suggested | filename | AUTO | CANCEL}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,7461 99637 306,939,873,746 2015-03-31 08:35:04 306,939,892,5431 99638 306,939,892,543 2015-03-31 08:35:43 306,941,744,7211 99639 306,941,744,721 2015-03-31 08:41:10 306,941,853,2851 99640 306,941,853,285 2015-03-31 08:42:28 306,941,998,3471 99641 306,941,998,347 2015-03-31 08:43:46 306,942,181,0931 99642 306,942,181,093 2015-03-31 08:44:34 306,942,501,0941 99643 306,942,501,094 2015-03-31 08:46:55 306,942,801,2134.查看数据库检查点
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,5431003 ONLINE 306,939,892,5433 ONLINE 306,939,892,5434 ONLINE 306,939,892,54313 ONLINE 306,939,892,543203 ONLINE 306,939,892,543204 ONLINE 306,939,892,543230 ONLINE 306,939,892,543336 ONLINE 306,939,892,543387 ONLINE 306,939,892,543439 ONLINE 306,939,892,543486 ONLINE 306,939,892,543530 ONLINE 306,939,892,543570 ONLINE 306,939,892,543660 ONLINE 306,939,892,543733 ONLINE 306,939,892,543743 ONLINE 306,939,892,543856 ONLINE 306,939,892,543918 ONLINE 306,939,892,543983 ONLINE 306,939,892,5432 ONLINE 306,939,892,54321 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,927570 ONLINE 308,896,623,428439 ONLINE 308,896,625,5661003 ONLINE 308,896,627,156660 ONLINE 308,905,788,858530 ONLINE 308,906,056,2884 ONLINE 308,925,397,029983 ONLINE 308,925,462,664204 ONLINE 308,925,585,054486 ONLINE 308,925,585,054336 ONLINE 308,926,143,1623 ONLINE 308,926,143,1622 ONLINE 308,926,143,162733 ONLINE 308,933,830,6921 ONLINE 308,933,830,692387 ONLINE 308,933,917,12213 ONLINE 308,933,968,723230 ONLINE 308,943,247,932203 ONLINE 308,943,323,261743 ONLINE 308,943,330,393918 ONLINE 308,943,330,39321 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 11003 64 308896627156 102008 1570 64 308896623428 102008 1530 64 308906056288 102025 14 64 308925397029 102067 13 64 308926143162 102068 12 64 308926143162 102068 1336 0 308926143162 102068 1733 64 308933830692 102083 11 8256 308933830692 102083 1203 64 308943323261 102110 1856 64 308896612927 104383 1660 64 308905788858 104399 1486 64 308925585054 104442 1204 64 308925585054 104442 1983 64 308925462664 104442 1387 64 308933917122 104452 113 64 308933968723 104452 1743 64 308943330393 104474 1918 64 308943330393 104474 1230 0 308943247932 104474 18.通过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
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 同全备时数据库结构一直的控制文件)