recover database using backup controlfile

本文深入解析了Oracle数据库恢复过程中的关键概念,包括SCN(系统检查点、数据文件检查点、启动SCN、终止SCN),以及在不同场景下使用recoverdatabaseusingbackupcontrolfile和resetlogs的技术细节。详细阐述了在系统正常关闭、异常关闭、旧数据文件、备份控制文件、重建控制文件等情况下,如何正确应用这些恢复技术,确保数据一致性与完整性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

要理解recover database using backup controlfile,先理解 recover database 

也就是说,不加using backup controlfile的情况。


在普通的recover database 或者 recover tablespace, recover datafile时, Oracle会以当前controlfile所纪录的SCN为准,利用archive log和 redo log的redo entry, 把相关的datafile 的 block恢复到“当前controlfile所纪录的SCN”


而某些情况下,Oracle需要把数据恢复到比当前controlfile所纪录的SCN还要靠后的位置(比如说,control file是backup controlfile , 或者 controlfile是根据trace create的。),这时候,就需要用using backup controlfile. 恢复就不会受“当前controlfile所纪录的SCN”的限制。


这时候的限制就来自于你的语句(until time , until scn),或者可用的archive log(until cancel) ...

-------------------------------------------


首先这里我们先介绍四个SCN概念。


1、系统检查点scn
当一个检查点动作完成后,Oracle就把系统检查点的SCN存储到控制文件中。
select checkpoint_change# from v$database;


2,数据文件检查点scn
当一个检查点动作完成后,Oracle就把每个数据文件的scn单独存放在控制文件中。
select name,checkpoint_change# from v$datafile;


3,启动scn
Oracle把这个检查点的scn存储在每个数据文件的文件头中,这个值称为启动scn,因为它用于在数据库实例启动时,
检查是否需要执行数据库恢复。
select name,checkpoint_change# from v$datafile_header


4、终止scn
每个数据文件的终止scn都存储在控制文件中。
select name,last_change# from v$datafile


5、在数据库运行期间的scn值
  在数据库打开并运行之后,控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.
在安全关闭数据库的过程中,系统会执行一个检查点动作,这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候,Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较,如果这两个值相互匹配,oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致,就意味着所有数据块多已经提交,所有对数据库的修改都没有在关闭数据库的过程中丢失,因此这次启动数据库的过程也不需要任何恢复操作,此时数据库就可以打开了。当所有的数据库都打开之后,存储在控制文件中的数据文件终止scn的值再次被更改为null,这表示数据文件已经打开并能够正常使用了。   


以下条件需要使用using backup controlfile 
1)、使用备份控制文件
2)、重建resetlogs控制文件,如果重建立noresetlogs不必要使用using backup controlfile


2、alter database open resetlog 
指定RESETLOGS将重设当前LOG sequence number为1,抛弃所有日志信息。
以下条件需要使用resetlog
1)在不完全恢复(介质恢复)
2)使用备份控制文件
使用resetlogs打开数据库后无必完整地备份一次数据库。
3、create controlfile resetlogs/noresetlogs
1).用Noresetlogs重建控制文件时,控制文件中 datafile Checkpoint来自Online logs中的Current log头
2).用Resetlogs重建控制文件时,控制文件中datafile Checkpoint来自各数据文件头。

当system scn,datafile scn,start scn 不全相等,需要介质恢复,如果stopscn null需要实例恢复
resetlogs抛弃所有在上一次恢复没有用到的日志信息,确保不被重新用与恢复。


1、系统正常关闭:
system scn=datafile scn=start scn=stop scn
1)system scn=datafile scn=start scn,不需要介质恢复
2)stopscn not null,不需要实例恢复


2、系统异常关闭:
system scn=datafile scn=start scn,stop scn null
1)system scn=datafile scn=start scn,不需要介质恢复
2)stopscn null,需要实例恢复


3、旧数据文件
system scn=datafile scn>start scn,stop scn null/notnull
1)system scn=datafile scn>start scn,需要介质恢复成system scn=datafile scn=start scn
2)stopscn null,需要实例恢复,not null 不需要实例恢复


4、备份控制文件
system scn=datafile scn<=start scn(当数据文件为旧的相等),stop scn notnull/null
1)system scn=datafile scn<=start scn,需要使用using backup controlfile介质恢复成system scn=datafile scn=start scn=current log scn(当前日志最大SCN)
2)为保证上一次恢复没有用到log日志不被使用,必须resetlogs


5、重建noresetlogs控制文件
控制文件中 datafile Checkpoint来自Online logs中的Current log头
current log scn=system scn=datafile scn>=start scn,stop scn not null/null
1)current log scn=system scn=datafile scn>=start scn,需要介质恢复成system scn=datafile scn=start scn=redolog scn(当前日志最大SCN),stop scn not null
2)stopscn not null 不需要实例恢复


6、重建resetlogs控制文件
控制文件中datafile Checkpoint来自各数据文件头。 
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(当前日志最大SCN),stop scn not null
2)stop notnull,因为SCN已经为redolog scn,log已经不能使用,必须resetlogs。

<think>嗯,用户的问题是关于在RMAN中即使已经处于mount状态下备份了数据库,但在恢复时仍然需要使用UNTIL SCN。我需要仔细分析可能的原因,并给出合理的解释。 首先,用户提到在mount状态下进行了备份。在mount状态下,数据库的控制文件是打开的,但数据文件可能处于不一致的状态,因为数据库没有正常打开。这时候进行备份的话,备份的文件可能包含不一致的数据,所以恢复时需要指定一个具体的SCN来恢复到一致点。 接下来,用户使用recover database时还需要UNTIL SCN,这可能是因为即使备份是在mount状态下进行的,恢复过程仍然需要应用归档日志和在线日志来将数据库恢复到特定的时间点或SCN。尤其是在不完全恢复的情况下,必须指定一个终点,比如UNTIL SCN,以确保数据库的一致性。 另外,可能用户没有正确备份控制文件或者在恢复时没有使用正确的控制文件,导致RMAN无法识别备份的确切状态,从而需要手动指定SCN。控制文件记录了数据库的结构信息和备份的元数据,如果控制文件损坏或不是最新的,恢复过程可能需要更多的手动干预。 还有可能是在备份之后,用户进行了其他的数据库操作,导致有更多的归档日志产生,而恢复时需要应用这些日志直到指定的SCN。或者备份本身可能不完整,缺少部分数据文件或日志文件,导致自动恢复无法完成,必须手动指定终点。 需要提醒用户检查备份的完整性,确认控制文件是否正确备份和恢复,以及是否在恢复时正确指定了备份集的位置。此外,建议用户在进行备份时使用一致的备份方式,比如在数据库干净关闭后启动到mount状态,或者使用RMAN的OPEN RESETLOGS选项来确保备份的一致性,减少恢复时的复杂性。</think>在RMAN备份与恢复过程中,即使您在MOUNT状态下执行了备份,恢复时仍需使用`UNTIL SCN`的原因可能是以下情况导致的: --- ### **1. 备份时数据库处于不一致状态** - **根本原因** 在`MOUNT`状态下,数据库虽然加载了控制文件,但数据文件可能处于**不一致状态**(如实例崩溃后未正常打开)。此时备份的文件可能包含未提交事务或未完成的块写入。 - **恢复逻辑** RMAN默认会尝试将数据库恢复到**最新一致性状态**。若备份文件本身不一致,恢复过程需要应用归档日志(或在线日志)来修复数据文件,直到达到指定的`SCN`(系统变更号)以消除不一致性。 --- ### **2. 备份未包含所有必要文件** - **可能场景** - 备份时未包含**归档日志**(`BACKUP DATABASE PLUS ARCHIVELOG`未使用)。 - 备份后生成了新的归档日志,但未包含在恢复操作中。 - **恢复依赖** 即使备份是在`MOUNT`状态下完成,恢复时仍需要**应用日志文件**将数据库推进到一致点。如果未指定`UNTIL SCN`,RMAN可能因找不到足够的日志而报错。 --- ### **3. 控制文件未正确恢复** - **关键点** 控制文件记录了数据库的SCN信息。如果恢复时使用的控制文件**不是最新版本**(例如从备份恢复旧控制文件),RMAN可能无法自动确定恢复终点,需手动指定`UNTIL SCN`。 --- ### **4. 不完全恢复的强制要求** - **操作意图** 如果您明确需要执行**不完全恢复**(如恢复到某个时间点),则必须指定`UNTIL SCN`、`UNTIL TIME`或`UNTIL SEQUENCE`,无论备份是否完整。 --- ### **解决方案** #### **步骤1:确认备份一致性** ```bash # 检查备份时数据库状态 RMAN> LIST BACKUP SUMMARY; ``` - 确保备份标记为`FULL`或`INCREMENTAL LEVEL 0`,且状态为`AVAILABLE`。 #### **步骤2:恢复时指定完整日志** ```sql RUN { SET UNTIL SCN <your_scn>; RESTORE DATABASE; RECOVER DATABASE; } ``` - 使用`SET UNTIL SCN`明确恢复终点。 - 若需要自动选择SCN,可尝试: ```sql RECOVER DATABASE USING BACKUP CONTROLFILE; ``` #### **步骤3:验证控制文件** ```bash # 恢复最新控制文件(如有必要) RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; ``` #### **步骤4:调整备份策略** - **推荐备份命令** ```sql RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; RMAN> BACKUP DATABASE PLUS ARCHIVELOG; -- 包含数据文件+日志 RMAN> ALTER DATABASE OPEN; ``` - 在`MOUNT`状态下,先执行干净关闭(`SHUTDOWN IMMEDIATE`)以确保数据文件一致性。 --- ### **总结** | 关键因素 | 解决方法 | |-------------------------|----------------------------------| | 备份时数据文件不一致 | 在干净关闭后执行备份 | | 缺少归档日志 | 使用`PLUS ARCHIVELOG`选项 | | 控制文件不匹配 | 恢复最新控制文件或指定`UNTIL SCN`| | 故意执行不完全恢复 | 明确指定恢复终点 | 建议通过`RMAN> LIST INCARNATION`检查数据库化身(incarnation),确保恢复路径正确。如果问题持续,请提供`RMAN> SHOW ALL`输出和恢复操作的完整日志。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值