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

 

----- 定义：

完全恢复 --  利用重做日志或增量备份将数据块恢复到最接近当前时间的时间点。
之所以叫做完整恢复是由于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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-694069/