控制文件的scn是100，数据文件的scn是500，要恢复到的 scn是1...
控制文件的scn是100，数据文件的scn是500，要恢复到的 scn是1000，在recover的过程中，需要的归档日志是从最小的scn 100开始的，这时数据库对 控制文件在scn 100到500 具体做些什么啊？$ 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.
$ cp /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl.bak
$
$ cp /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl.bak /s01/oradata/DBDAO11G/controlfile/o1_mf_b8wnhj62_.ctl
$
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 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
简述一下 old controlfile 可能 不了解 归档日志和 当前日志的情况， 一般需要你手动输入其所需要sequence的归档日志的路径， 如你所说的100~500的过程中 基于datafile header的checkpoint scn已经是500了，所以其不需要镀银写 resilver write ，即不需要写数据文件 ，一般仅仅需要追平 控制文件的信息gap 。 还有这类原理性的提问 为什么要到 技术资料版 开贴？
页:
[1]