--从controlfile读取scn信息 set linesize 140 col dummy for a140 set linesize 140 numformat 999999999999999999 prompt --系统scn select checkpoint_change# from v$database; prompt --数据文件scn select file#,checkpoint_change# from v$datafile; prompt --终止scn select file#,last_change# from v$datafile;
--从数据文件头获取信息 --查询v$datafile_header set linesize 140 numformat 999999999999999999 col error for a20 select file#,STATUS online_fromctlf,error ,recover,fuzzy,checkpoint_change# from v$datafile_header;
--查询v$datafile_header的基表 set linesize 140 numformat 9999999999999 select hxfil file#,fhsta status,fhscn scn ,fhrba_seq seq#,fhrba_bno seq#_block,fhrba_bof seq#_block_startbyte from x$kcvfh; --看状态是不是8192与0，还有获得rba以便知道恢复时从哪个logfile（archivelog 或 redo)开始。 select hxfil,fhsta,fhrba_seq from x$kcvfh;
select max(fhafs) from x$kcvfh; --查看datafile是否需要recover,如果是0则不需要，大于0，则代表数据文件处于不一致的状态，那么需要至少需要recover到什么SCN。 --open read write下应该都是0 --fhafs absolute fuzzy scn, 即Minimum PITR SCN。 --代表了此数据文件的所有数据块中，现在最大的那个scn。我们实施recover时至少得把这个数据文件的所有数据块recover到这个scn，所有数据块scn才一致。
--查询日志情况
--查询v$log select GROUP# ,SEQUENCE#,ARCHIVED,STATUS,FIRST_change# from v$log order by sequence# asc;
查询v$log_history select sequence#,first_change#,next_change# from v$log_history;
查询v$archived_log set lin 140 col name for a100 select NAME,sequence#,first_change#,next_change#,decode(STATUS,'A','Available','D','Deleted','U','Unavailable','X','Expired') status from v$archived_log;
--库open时从current redo log中读取信息，获得当前最新的scn号。 select dbms_flashback.get_system_change_number from dual; set linesize 140 numformat 999999999999999999 col current_scn for a30 select current_scn from v$database; --我们会发现这个scn会不断刷新，尽管DB没有事务。还是有些内部事务我不知道呢？还是每隔一段时间就必须得刷新呢？ --答案是：用current_scn查，就如同sequence，你查一下它就往前一点，不往前怎么得出current的scn呢？而用dbms_flashback查，则查多次也不会往前递增（除非有其他事务使scn前进）
recover是系统scn>启动scn
介质恢复（数据文件更旧） system SCN=datafile SCN>start SCN，stop SCN NULL/notNULL 旧数据文件 系统启动时，每个数据文件scn（来自control file)会与每个数据文件头的启动scn做比较，假如有些不一致，甚至全部都不一致，则要进行recover，即media recover。
实例恢复 然后，会看end scn(来自控制文件）是否为空，假如是，证明并没有一致性关闭
数据库。没有一致关闭数据库（即关闭时没有执行全量checkpoint)，可以用shut abort模拟，表现为数据文件在执行checkpoint后，还对数据文件中的数据块有write操作，即fuzzy=yes，此时数据文件中的数据块的scn号，会出现有的比数据文件头的scn号还大的情况，我们就要实行intance recovery。 所以实例恢复，从checkpoint scn开始，往后的日志要应用到数据文件中。
控制文件更旧 system SCN=datafile SCN<=start SCN，stop SCN notNULL/NULL recover database using backup controlfile; 这里可以选择AUTO。 此时会从这个旧的控制文件的scn号，去v$archived_log中寻找是在哪个low scn与high scn之间，从而确定是哪个归档日志开始recover。从backup controlfile的scn号，一直recover到当前v$datafile_header的scn，然后会提示找不到最新一号的日志。因为backup controlfile没有记载新的归档日志与logfile信息，只能从归档目的地按图索骥地recover,此时我们再执行一次recover database using backup controlfile until cancel;并指定current online redo log，即可完成apply。 尽管如此，控制文件的scn号与datafile的scn是没有变化的（真不知道这个recover起什么作用） 此时就可以alter database open resetlogs了。一旦使用了using backup controlfile，oracle就会认为是不完全恢复，所以就必须open resetlogs了。 还有另外一种不用Open resetlogs的方法，使用旧的控制文件backup to trace,reuse database ... noresetlogs来重建控制文件，这样就可以recover database自动恢复并open database而不用resetlogs了(切记：必须有所有的online redo logs才可以这样！)。
因为backup controlfile只有备份时刻的archived log信息，并没有DB crash时刻 重建控制文件，才能成功open库。
重建控制文件，假如指定noresetlog，那么open时候不指定resetlogs也可以。 控制文件会跟数据文件的scn号。
ERROR
NULL if the datafile header read and validation were successful. If the read failed then the rest of the columns are NULL. If the validation failed then the rest of columns may display invalid data. If there is an error then usually the datafile must be restored from a backup before it can be recovered or used.
RECOVER File needs media recovery (YES | NO)
查看数据文件头dbid:select FHDBI from x$kcvfh
FUZZY
数据文件里面的有的数据块的scn号，大于数据文件头的scn号。
x$kcvfh是v$datafile_header的源，v$datafile_header相信大家在oracle恢复工作时会经常和他碰面，因为他不仅包含了checkpoint_change#,更重要的是它包含了这个checkpoint_change#所在的logfile的sequence＃，准确的说rba，有了rba，在恢复时就能准确的知道到底需要哪个logfile（archivelog or redo）。
x$kcvfh有三个字段非常有意义。
1）FHRBA_SEQ：表示当前联机日志对应的日志序列号
2）FHRBA_BNO：表示the log file block number
3）FHRBA_BOF：表示the byte offset
其实fhrba_seq,fhrba_bno,fhrba_bo |