控制文件的scn是100，数据文件的scn是500，要恢复到的 scn是1...

iongxiao

控制文件的scn是100，数据文件的scn是500，要恢复到的 scn是1000，在recover的过程中，需要的归档日志是从最小的scn 100开始的，这时数据库对 控制文件在scn 100到500 具体做些什么啊？

Liu Maclean(刘相兵

还有这类原理性的提问 为什么要到 技术资料版 开贴？

Liu Maclean(刘相兵

简述一下 old controlfile 可能 不了解 归档日志和 当前日志的情况， 一般需要你手动输入其所需要sequence的归档日志的路径， 如你所说的100~500的过程中 基于datafile header的checkpoint scn已经是500了，所以其不需要镀银写 resilver write ，即不需要写数据文件 ，一般仅仅需要追平 控制文件的信息gap 。

Liu Maclean(刘相兵

[oracle@dbdao1 ~]$ cp  /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl.bak


alter database open;



SQL> create table test_maclean as select * from dba_objects;

Table created.

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /
/
/
/

System altered.

SQL>
System altered.

SQL>
System altered.

SQL>
System altered.

SQL>
SQL>
SQL> delete test_maclean ;

86959 rows deleted.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.



[oracle@dbdao1 ~]$  cp  /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl.bak
[oracle@dbdao1 ~]$
[oracle@dbdao1 ~]$ cp  /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl.bak /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl   
[oracle@dbdao1 ~]$








SQL> recover database using backup controlfile;
ORA-00279: change 1046283 generated at 12/16/2014 02:15:45 needed for thread 1
ORA-00289: suggestion :
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_2_b8zq2wos_.arc
ORA-00280: change 1046283 for thread 1 is in sequence #2


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_2_b8zq2wos_.arc
ORA-00279: change 1046562 generated at 12/16/2014 02:16:44 needed for thread 1
ORA-00289: suggestion :
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_3_b8zq2x69_.arc
ORA-00280: change 1046562 for thread 1 is in sequence #3
ORA-00278: log file
'/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_2_b8zq2wos_.arc'
no longer needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_3_b8zq2x69_.arc
ORA-00279: change 1046565 generated at 12/16/2014 02:16:45 needed for thread 1
ORA-00289: suggestion :
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_4_%u_.arc
ORA-00280: change 1046565 for thread 1 is in sequence #4
ORA-00278: log file
'/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_3_b8zq2x69_.arc'
no longer needed for this recovery


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

SQL> alter system set events 'trace[CACHE_RCV.*] disk highest';

System altered.

SQL>
SQL> recover database using backup controlfile;
ORA-00279: change 1046565 generated at 12/16/2014 02:16:45 needed for thread 1
ORA-00289: suggestion :
/s01/fast_recovery_area/DBDAO11G/archivelog/2014_12_16/o1_mf_1_4_%u_.arc
ORA-00280: change 1046565 for thread 1 is in sequence #4


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/s01/oradata/DBDAO11G/onlinelog/o1_mf_1_b8wnhlmt_.log
Log applied.
Media recovery complete.







*** 2014-12-16 02:45:10.895
Started Serial Media Recovery
Dumping database incarnation table:
Resetlogs 0 scn and time: 0x0000.000ff302 12/16/2014 02:07:51
Recovery target incarnation = 1, activation ID = 0
Influx buffer limit = 16905 min(50% x 33810, 100000)
Start recovery at thread 1 ckpt scn 1046565 logseq 4 block 2
Initial buffer sizes: read 1024K, overflow 832K, change 805K

*** 2014-12-16 02:45:10.927
Media Recovery add redo thread 1

*** 2014-12-16 02:45:26.661
Media Recovery Log /s01/oradata/DBDAO11G/onlinelog/o1_mf_1_b8wnhlmt_.log
Log read is SYNCHRONOUS though disk_asynch_io is enabled!
----- Redo read statistics for thread 1 -----
Read rate (SYNC): 165Kb in 15.73s => 0.01 Mb/sec
Total redo bytes: 165Kb Longest record: 0Kb, moves: 0/427 moved: 0Mb (0%)
Longest LWN: 5Kb, reads: 124
Last redo scn: 0x0000.000ff91b (1046811)
Change vector header moves = 87/856 (10%)
----------------------------------------------

*** 2014-12-16 02:45:26.664
Media Recovery drop redo thread 1
File 1 (stop scn 1046814) completed recovery at checkpoint scn 1046814
File 2 (stop scn 1046814) completed recovery at checkpoint scn 1046814
File 3 (stop scn 1046814) completed recovery at checkpoint scn 1046814
File 4 (stop scn 1046814) completed recovery at checkpoint scn 1046814
File 5 (stop scn 1046814) completed recovery at checkpoint scn 1046814
KCBR: Number of read descriptors = 1024
KCBR: Influx buffers flushed = 2 times

*** 2014-12-16 02:45:26.668
Completed Media Recovery