[转]恢复数据库时须要关注的scn信息

恢复数据库时须要关注的scn信息

Reference：https://www.cnblogs.com/ljbguanli/p/6898173.html

--从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_bof这3个字段相应的就是rba，rba的意思是：

Recent entries in the redo thread of an Oracle instance are addressed using a 3-part redo byte address, or RBA. An RBA is comprised of ：

    the log file sequence number (4 bytes) 

    the log file block number (4 bytes) 

    the byte offset into the block at which the redo record starts (2 bytes) 

 

在datafile header上记录rba，在恢复时就能很准确的知道须要哪个日志文件（通过the log file sequence number)以及哪个block（通过the log file block number）以及

在这个日志block上从哪个byte開始读取恢复（通过the byte offset）

 

 

 

select hxfil file_num,fhrba_seq sequence,fhrba_bno sequence_block,fhrba_bof block_offset  from  x$kcvfh; 

 

col file_name for a30

select HXFIL File_num,substr(HXFNM,1,45) File_name, FHSCN SCN,FHRBA_SEQ Sequence from X$KCVFH;

 

推断datafile做recover须要的archive log的sequence是多少，也就是说做recover到这个sequence。那么control file和datafile header中的记录就一致了。

 

         The value for the column X$KCVFH.FHSTA (file header status) for an open database with an online datafiles in versions prior to version 10 were all 4, 

9i,10g  

open状态

9i所有是4 (fuzzy)

10g 8196(system,fuzzy),其它4

 

一致关闭后，startup mount（fuzz=no)

8192（system)  0(其余）

 

 

（10g以后）(scn与time互换）

scn-> time

select to_char(scn_to_timestamp(9065273060811),'yyyy-mm-dd hh24:mi:ss') scn from dual;

 

time -> scn

select timestamp_to_scn( to_timestamp('2013-09-13 07:15:31','yyyy-mm-dd hh24:mi:ss') ) scn from dual;

 

尽管參数“_allow_resetlogs_corruption”能够在checkpoint SCN不一致时强制打开数据库，可是这种数据库在open后必须立即作全库的export。然后重建数据库并import数据。

 

 

下面条件须要使用using backup controlfile 

1）、使用备份控制文件

2）、重建resetlogs控制文件,假设重建立noresetlogs不必要使用using backup controlfile

 

 

下面条件须要使用resetlog

1）在不全然恢复（介质恢复）

2）使用备份控制文件

 

1. recover database using backup controlfile

假设丢失当前控制文件，用冷备份的控制文件恢复的时候，用来告诉oracle，不要以controlfile中的scn作为恢复的终点。 

 

2. recover database until cancel

假设丢失current/active redo的时候，手动指定终点。

 

 

 

3. recover database using backup controlfile until cancel;

假设 丢失当前controlfile而且current/active redo都丢失，会先去 自己主动 应用归档日志,能够实现最大的恢复；

 

4. recover database until cancel using backup controlfile;

假设 丢失当前controlfile而且current/active redo都丢失，以旧的redo中的scn为恢复终点。由于没有应用归档日志，全部会丢失数据。

 

二、总结

1、using backup controlfile用于恢复备份的控制文件与当前的控制文件不一致的情形

2、一旦使用了using backup controlfile方式，控制文件的类型将由 current 转移到 backup 类型，同一时候open_resetlogs为required

3、一旦使用了using backup controlfile方式，兴许再次使用recover database将变得无效

4、必需要使用 resetlogs 方式打开数据库。即使我们做的是全然恢复

 

recover database using backup controlfile until cancel;

然后输入測试库的redo，逐个试，直接能起库为止。/paic/hq/t1inv/data/oradata/t1inv/redo61.log

recover automatdic standby DATABASE until TIME '2013-12-09 06:30:00';