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

时间：2014-05-02 02:42:57 收藏：0 阅读：394

--从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‘;

恢复数据库时需要关注的scn信息,布布扣,bubuko.com