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

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

时间: 2024-10-29 19:12:32

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

转载 Sql2005中,恢复数据库时,旁边显示“restricted user”,怎么办?

从其它机器上考过来的一个sql2005的数据库备份(*.bak,直接通过‘备份’操作得到,不是detach的),在自己机器上的sql2005里建一个同名数据库,通过‘恢复’操作将其恢复后,发现旁边显示"restricted user".因为自己是用windows集成帐户登陆,所以改用sa登陆,结果一样. 后来发现,在数据库属性里‘options’选项卡里的最下面-----‘Restrict  Access’:把值改为multiple即可 ==============Update at

向SQL Server中附加本地数据库报错:附加数据库时出错。有关详细信息,请单击&quot;消息&quot;列中的超链接。

报错现象: 使用SQL Server附加报错:(使用visual连接也会报错:无法打开物理文件***试为文件附加自动命令的数据库,但失败.已存在同名的数据库) 问题分析: 这是由于权限不够所导致的 解决办法: 1.打开数据库文件夹的属性,具体操作流程如图所示 2.问题解决 原文地址:https://www.cnblogs.com/litstar/p/12590982.html

创建Odoo8数据库时的“new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)“问题

Odoo8创建数据库时,显示如下错误信息: DataError: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII) HINT: Use the same encoding as in the template database, or use template0 as template. 解决方法: First, we need to drop template1.

Oracle数据库备份恢复,巡检需要关注的对象设置以及相关恢复概述

数据库备份恢复,巡检需要关注的对象设置: 1.数据库名称,以及DBID:  --dbid在v$database中 [email protected]>select dbid,name from v$database; DBID NAME ---------- --------- 1385095721 ORCL 2.控制文件的位置: show parameter control_files; select name from v$controlfile; 3.日志文件的位置以及数据库的归档设置:

恢复数据库备份时提示日志错误

可以打开了恢复的时候增加了这个参数 WITHOUT ROLLING FORWARD 恢复数据库备份时提示日志错误,码迷,mamicode.com

(转)连接带有密码的ACCESS数据库时出现“无法启动应用程序。工作组信息文件丢失,或是已被其它用户以独占方式打开”的解决方法

原文:http://www.cnblogs.com/chiname/articles/582539.html 连接带有密码的ACCESS数据库时出现“无法启动应用程序.工作组信息文件丢失,或是已被其它用户以独占方式打开”的解决方法:此问题是由数据库的连接串引起的,可用下面的串连接即可 Provider=Microsoft.Jet.OLEDB.4.0;Persist Security Info=true;Data Source=<YourPath>;Jet OLEDB:Database Pass

备份和恢复数据库

查看实例编号,名称和日志模式:SYS AS [email protected]>select dbid,name,log_mode from v$database; DBID NAME      LOG_MODE---------- --------- ------------1391294860 ORCL      ARCHIVELOG 1 row selected. RMAN:    登录:    [[email protected] ~]$ rman    RMAN> CONNECT T

ORACLE中没有参数文件和控制文件如何通过rman恢复数据库

场景: 一个DEV告诉我生产环境下某个用户的表都看不到了,需要恢复,而此时生产库上存储自动备份的参数文件控制文件的磁盘目录文件坏块,所以导致rman备份的只有数据文件和归档日志文件,这种情况下,如何在测试服务器上利用rman恢复数据呢?google了很多资料,咨询了朋友,恢复过程如下: 前期准备工作:事先查询好先查询下原来的数据文件路径SQL> select name from v$datafile; NAME-------------------------------------------

Oracle RMAN 恢复数据库到不同主机(二)

我们在recover database时报一个错误: RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 149 and starting SCN of 3507749 这里是提醒恢复到一个未知的scn号.我们在备份时只有148号归档,149号还是online redo,所以没有copy过来,如果我们不指定recover的结束时间,最后就会提示我们上面的信息:RMAN-0605