ITPub博客

首页 > Linux操作系统 > Linux操作系统 > resetlogs,noresetlogs, SCN,完全恢复,不完全恢复

resetlogs,noresetlogs, SCN,完全恢复,不完全恢复

原创 Linux操作系统 作者:tolywang 时间:2011-04-29 11:20:27 0 删除 编辑

 

----- 定义:

完全恢复 --  利用重做日志或增量备份将数据块恢复到最接近当前时间的时间点。
之所以叫做完整恢复是由于Oracle应用了归档日志和联机重做日志中所有的修改。
如果只是数据文件损坏,且存在备份及备份以来的所有归档日志文件,那么就能
把数据库完全恢复到发生介质损坏的那个时间点。完全恢复分为数据库级别,数据
文件级别以及表空间级别 。

不完全恢复 -- 需要将数据库恢复到历史上某个时间点,或由于丢失了联机日志
件或某个归档日志文件,或者使用了以前备份的控制文件进行恢复,进行的恢复
叫做不完全恢复。 换句话说,恢复过程中不会应用备份产生后生成的所有的重
做日志(可能应用部分或不应用)。 


通常出现下面的情况需要进行不完全恢复:
a. 几个或全部的联机重做日志文件损坏;
b. 由于个别归档日志文件的丢失无法进行完整的恢复;
c. 用户操作造成的数据丢失,比如,用户误删除了一张表, 这时可进行不完全
   恢复将数据库恢复到误操作之前的时间点;
d. 丢失了当前的控制文件,必须使用备份的控制文件打开数据库。不过只要
   所有的归档日志文件和联机日志文件都在,仍然能够恢复所有的数据。

为了执行不完整介质恢复,必须使用恢复时间点以前的备份来还原数据文件,
并在恢复完成后使用RESETLOG选项打开数据库。resetlogs会重置日志序列号
(变为1)强制清空或重建REDO, noresetlogs则不会 。

 

 


------ 关系:

1. 不完全恢复必须使用resetlogs ;
2. 使用resetlogs大多数情况下是做不完全恢复,但也可以做完全恢复(视丢失文件类型不同);
3. noresetlogs 必须做完全恢复时使用,但完全恢复不一定都是noresetlogs; 
4. 使用备份的控制文件需要使用using backup controlfile,使用using backup controlfile
   就需要使用resetlogs开启数据库;
5. 使用resetlogs方式重建控制文件需要使用using backup controlfile,同上,需要使用
   resetlogs开启数据库;
6. 如果是以noresetlogs方式重建控制文件,不必要使用using backup controlfile,详细
   可以参考通过backup controlfile to trace 导出的脚本;
   (因为resetlogs重建控制文件是针对Use this only if online logs are damaged,
    而noresetlogs方式重建控制文件是针对the current versions of all online logs
    are available )
7. create controlfile resetlogs/noresetlogs
 - 用noresetlogs重建控制文件时,控制文件中datafile Checkpoint SCN来自online logs
   中的current log头部,选择noresetlogs重建使得控制文件最新。如记录了最新的联机日志
   和日志序号。这个命令后介质恢复不是必需的。
 - 用resetlogs重建控制文件时(一般是在线日志损坏时),控制文件中datafile checkpoint SCN
   来自各数据文件头。

8. 使用备份的控制文件(using backup controlfile)则需要使用resetlogs方式打
   开数据库(当然不一定是不完全恢复,备份的控制文件不能自动进行完全恢复, 可
   以手工apply日志进行完全恢复; 重新创建控制文件则可以自动进行完全恢复);
9. 使用当前控制文件或noresetlogs方式重建控制文件来恢复,可以不需要resetlogs
   打开数据库;

备注: 备份的控制文件之所以不能自动进行完全恢复,是因为备份的控制文件的
检查点SCN是比较旧的SCN, Oracle需要知道从哪个归档日志文件开始恢复,以及
从这个归档日志文件的哪个位置开始恢复。存储在备份的控制文件中的日志序列号
以及对应于控制文件检查点SCN的RBA (Redo Bytes Address)指出了从哪个归档文件
开始以及从文件的哪个位置(重做记录)开始恢复。

 

 

 

 

----- 恢复相关的各种SCN及在恢复中的关系


数据库系统的当前SCN,是一直在变化的,其变动因素包括事务的提交与回滚,以及
每三秒一次的心跳。

而涉及到数据库启动关闭时检查的SCN有四种,其中三种记录在控制文件中:系统SCN、
datafile SCN、stop SCN,另一种是记录在各个数据文件头中的start SCN。

其中,数据文件头的start SCN来自系统当前SCN,而控制文件的系统SCN来自系统当
前SCN,datafile SCN来自读取各个数据文件头已经改写好的start SCN,stop SCN在
数据库启动后一直为NULL,而正常关闭时会被置为系统当前SCN。 数据库正常关闭的
时候,会在执行完所有事务后,执行一次完全checkpoint事件,将数据文件头上的start
SCN,以及控制文件中记录的三种SCN:系统SCN、datafile SCN、stop SCN,都置为系
统当前的SCN。

数据库再次启动时,首先检查数据文件头的start SCN,是否与控件文件记录的系统SCN
和datafile SCN相同,如果三者之一有不相同则要进行media recovery。

然后再检查控制文件中的stop SCN,是否与数据文件头当中的start SCN相同,如果相同,
表明上次是正常关闭,这时SCN检查通过,数据库系统正常启动后stop SCN会被置为NULL;
如果stop SCN是NULL,表明上次没有正常关闭(即没有执行checkpoint将stop SCN置为关
闭时的系统SCN),那么需要进行instance recovery。

 

我们可以看到,这个检查过程中,不包括redo log的SCN检查。涉及用到redo log的SCN的
时候,是当系统需要进行media recovery的时候。

如果是用noresetlogs进行完全恢复,它将使用redo log当中的SCN,作为最新的SCN,然
后将这个SCN值写入到控制文件和数据文件的上面几种SCN中。

如果是用resetlogs进行不完全恢复,将控制文件当中的系统SCN设为0,将控制文件当中的
datafile SCN和数据文件头的start SCN设为冷备份当中的数据文件头的SCN,这时也不需要
用到redo log的SCN。

数据库启动时,是不检查redo log的SCN的,只有在media recovery中使用noresetlogs进行
完全恢复时才会将redo log的SCN写入控制文件及数据文件的各种SCN(一般使用noresetlogs
时redo log文件都是完好的).

 

 

 


----- 恢复起点及终点RBA(Redo Bytes Address)问题

low cache rba就是CKPT记录的DBWR写的进度,即dbwr 进度点所对应的日志文件点(rba)。
on disk rba就是LGWR的写进度,lgwr写日志文件的最末位置的地址(没有写进日志文件
的日志自然就丢失了),也就是写到磁盘上的日志截止点。这是恢复所能达到的最新状态。

如果数据库carsh,low cache rba是恢复的起点,on disk rba是恢复的终点。

dbwr成功写完后并不把此刻scn信息写到控制文件中,只有CKPT才更新控制文件和数据文件头,
dbwr只要成功将dirty data写入数据文件就是成功, CKPT只要能将最新DBWR写完的SCN更新到
控制文件和数据文件头就算成功。但是由于CKPT进程不是实时更新dbwr写完的scn到控制文件
中,而是采用每3妙更新一次的策略,因此最后有ckpt进程写进控制文件的scn信息有可能不是
当前dbwr刚刚写完的scn值。这点应该注意,也就是说dbwr写的进度与ckpt进程更新控制文件的
进度是不同的。
 

 

 

 


----- 各种情况下的恢复:

 


1. 所有控制文件丢失,而其他文件没有丢失


恢复方式A:  从备份中恢复控制文件。

恢复原理: 这时控制文件记录的数据文件检查点SCN显然要小于当前数据文件头
中记录的检查点SCN (控制文件比数据文件要旧,也比联机日志或归档日志要旧),
开启到mount状态,可以通过v$datafile及v$datafile_header 中的字段
checkpoint_change# 进行对比。不一致就需要进行介质恢复。

然后通过recover database using backup controlfile; 去恢复数据库,这时
Oracle需要知道从哪个归档日志文件开始恢复,以及从这个归档日志文件的哪个
位置开始恢复。

存储在备份的控制文件中的日志序列号以及对应于控制文件检查点SCN的Low RBA
(Redo Bytes Address)指出了从哪个归档文件开始以及从文件的哪个位置(重做
记录)开始恢复。


转储控制文件后可以看到控制文件中数据库检查点SCN, 这个是恢复的起点SCN,
Database checkpoint: Thread=1 scn: 0x0000.00119459, 这个16进制转化为
10进制后就和 v$database中CHECKPOINT_CHANGE# 值相同。

且可以看到low cache rba: 0x27.6c.0, 其中log sequence = 0x27 = 39 表示日
志序列号 ,  block number是6c = 109, 最后的0表示日志记录偏移量(即具体从
109号块中的那个重做记录开始恢复)。 

low cache rba:(0x27.6c.0) 


具体恢复到哪里截止由谁决定呢 ? 是目前的数据文件还是online redo log ?
如果数据文件完好,应该是由数据文件中的start scn决定的 。 

--------------------------------------------------------------------
备份控制文件
system scn=datafile scn<=start scn(当数据文件也为旧的相等),stop scn not null/null
1)system scn=datafile scn<=start scn,需要使用using backup controlfile
介质恢复成system scn=datafile scn=start scn=current log scn(当前日志最大SCN)
--------------------------------------------------------------------


输入auto开始恢复,会应用完所有的归档日志文件,然后报错找不到最后
的归档文件,其实这时是准备应用联机日志文件,但是由于是恢复的备份
控制文件,而当前使用的联机日志文件的信息保存在当前控制文件中(而不
在备份的控制文件中),但我们丢失了当前的控制文件,所以auto时报告
无法找到归档日志文件的错误信息。 我们需要手工尝试apply每组联机
日志文件,运气好的话,尝试第一组联机日志文件就会提示Media recovery
complete了,如果不成功,我们需要再次发出recover database using
backup controlfile; 再次输入第二组联机日志文件。

最后我们以resetlogs打开数据库,alter database open resetlogs;
虽然是以resetlogs打开的数据库,但由于我们应用了所有需要应用的
日志文件,数据没有丢失,其实是一次完全恢复。

具体的过程: http://space.itpub.net/35489/viewspace-692729 

 

 

恢复方式B: 使用trace文件脚本重新生成控制文件(redo log没有损坏)。

这种方法通常是在没有控制文件(二进制文件)备份的情况下使用的,如果存在备份
的控制文件 , 应该使用备份的控制文件尝试恢复.

恢复原理:
因为redo log没有损坏,那么重建控制文件会使用noresetlogs选项。重建控制文件
后,显然有关的检查点SCN号都丢了。那么这时候控制文件中的各种检查点SCN是从
哪里来的呢 ?

这时查询v$log中的current redo log的first_change# 及v$database中的系统检
查点SCN, 发现重建的控制文件中的系统检查点SCN从当前redo log的low SCN获得,
而控制文件里记录的数据文件检查点SCN(v$datafile)从数据文件头部(v$datafile_header)
获得. 

具体讨论: http://www.itpub.net/viewthread.php?tid=1423740  

重建控制文件以后,数据库会自动启动到mount状态,于是我们可以开始进行恢复。
recover database;  恢复完成后,直接打开数据库,不需要resetlogs, 数据完全
恢复。


恢复步骤:
(1). 使用脚本重新生成控制文件(因为在线日志没有损坏,所以用noresetlogs选项)。
SQL> startup nomount ;
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 'G:\ORADATA\ORCL\REDO01.LOG'  SIZE 50M,
  9    GROUP 2 'G:\ORADATA\ORCL\REDO02.LOG'  SIZE 50M,
10    GROUP 3 'G:\ORADATA\ORCL\REDO03.LOG'  SIZE 50M
11  -- STANDBY LOGFILE
12  DATAFILE
13    'G:\ORADATA\ORCL\SYSTEM01.DBF',
14    'G:\ORADATA\ORCL\SYSAUX01.DBF',
15    'G:\ORADATA\ORCL\UNDOTBS01.DBF',
16    'G:\ORADATA\ORCL\USERS01.DBF',
17    'G:\ORADATA\ORCL\NAM01.DBF'
18  CHARACTER SET ZHS16GBK
19  ;

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED

(2). SQL> recover database; (使用重建的控制文件可以自动进行完全恢复) 
(3). SQL> alter database open ;
(4). 完全恢复完成。如果在线日志有损坏,重建控制文件需要使用resetlogs
     选项,恢复时需要 RECOVER DATABASE USING BACKUP CONTROLFILE;
     ALTER DATABASE OPEN RESETLOGS;


待续......

 

2. 部分数据文件(非system文件)丢失,而其他文件没有丢失

3. 非当前联机日志文件丢失,而其他文件没有丢失

4. 当前联机日志文件丢失,而其他文件没有丢失

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-694069/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13509319