【Oracle】探究recover database until scn

本文通过实验对比了使用RMAN恢复数据库至特定SCN与使用数据泵进行初始化的区别,重点在于recoverdatabaseuntilscn命令是否包含指定SCN的问题。

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

ogg数据初始化中,对于使用rman进行数据初始化和导入导出、数据泵进行数据初始化,最终启动replicat进程时使用的是不同的两个参数。

对于rman进行初始化的,我们使用的语句是:

start replicat rep_ynkg , atcsn xxxxxx

对于导入导出及数据泵进行初始化的,我们使用的语句是:

start replicat rep_ynkg , aftercsn xxxxx

原因是使用rman进行恢复时使用recover database until scn xxxxxx;进行的恢复,这个语句的恢复结果并不包含最后指定的xxxxxx这个scn。而导入导出及数据泵进行初始化时使用的flashback_scn=xxxxxx这个参数是包含xxxxxx这个scn的。

之前只是了解这个概念,没有进行实验,最近刚好有人问这个问题,做了个小实验证明了下recover database until scn xxxxxx;不包最后指定的scn值。实验过程如下(实验步骤较长,对于非关键步骤只进行语言描述,就不贴出操作步骤了):

 

1.源库创建system.test测试表。

create table system.test as select * from dba_objects where 1=2;

2.源库增加goldengate extract进程,对system.test数据进行获取。

3.源库备份全库。

4.源库对测试表插入增量数据:

SQL> insert into system.test select * from dba_objects where rownum<=1;

 

1 row created.

 

SQL> commit;

 

Commit complete.

5.源库归档current logfile

6.将源库备份和归档传输到目标库所在主机。

7.在源库goldengate中使用logdump,查看捕获到增量数据的scn号。

Logdump 1 >open ./dirdat/t2000000

Current LogTrail is /home/oracle/ggs/dirdat/t2000000

Logdump 2 >ghdr on

Logdump 3 >detail data

Logdump 4 >ggstoken detail

略。。

Logdump 7 >n

___________________________________________________________________

Hdr-Ind    :     E  (x45)     Partition  :     .  (x04)  

UndoFlag   :     .  (x00)     BeforeAfter:     A  (x41)  

RecLength  :   198  (x00c6)   IO Time    : 2016/07/04 19:59:41.000.000   

IOType     :     5  (x05)     OrigNode   :   255  (xff)

TransInd   :     .  (x03)     FormatType :     R  (x52)

SyskeyLen  :     0  (x00)     Incomplete :     .  (x00)

AuditRBA   :         33       AuditPos   : 7736

Continued  :     N  (x00)     RecCount   :     1  (x01)

 

2016/07/04 19:59:41.000.000 Insert               Len   198 RBA 1053

Name: SYSTEM.TEST

After  Image:                                             Partition 4   G  s   

 0000 0007 0000 0003 5359 5300 0100 0900 0000 0549 | ........SYS........I  

 434f 4c24 0002 0004 ffff 0000 0003 0006 0000 0002 | COL$................  

 3230 0004 0005 0000 0001 3200 0500 0900 0000 0554 | 20........2........T  

 4142 4c45 0006 0015 0000 3230 3133 2d30 382d 3234 | ABLE......2013-08-24  

 3a31 313a 3337 3a33 3500 0700 1500 0032 3031 332d | :11:37:35......2013-  

 3038 2d32 343a 3131 3a34 373a 3337 0008 0017 0000 | 08-24:11:47:37......  

 0013 3230 3133 2d30 382d 3234 3a31 313a 3337 3a33 | ..2013-08-24:11:37:3  

Column     0 (x0000), Len     7 (x0007)  

 0000 0003 5359 53                                 | ....SYS  

Column     1 (x0001), Len     9 (x0009)  

 0000 0005 4943 4f4c 24                            | ....ICOL$  

Column     2 (x0002), Len     4 (x0004)  

 ffff 0000                                         | ....  

Column     3 (x0003), Len     6 (x0006)  

 0000 0002 3230                                    | ....20  

Column     4 (x0004), Len     5 (x0005)  

 0000 0001 32                                      | ....2  

Column     5 (x0005), Len     9 (x0009)  

 0000 0005 5441 424c 45                            | ....TABLE  

Column     6 (x0006), Len    21 (x0015)  

 0000 3230 3133 2d30 382d 3234 3a31 313a 3337 3a33 | ..2013-08-24:11:37:3  

 35                                                | 5  

Column     7 (x0007), Len    21 (x0015)  

 0000 3230 3133 2d30 382d 3234 3a31 313a 3437 3a33 | ..2013-08-24:11:47:3  

 37                                                | 7  

Column     8 (x0008), Len    23 (x0017)  

 0000 0013 3230 3133 2d30 382d 3234 3a31 313a 3337 | ....2013-08-24:11:37  

 3a33 35                                           | :35  

Column     9 (x0009), Len     9 (x0009)  

 0000 0005 5641 4c49 44                            | ....VALID  

Column    10 (x000a), Len     5 (x0005)  

 0000 0001 4e                                      | ....N  

Column    11 (x000b), Len     5 (x0005)  

 0000 0001 4e                                      | ....N  

Column    12 (x000c), Len     5 (x0005)  

 0000 0001 4e                                      | ....N  

Column    13 (x000d), Len     5 (x0005)  

 0000 0001 31                                      | ....1  

Column    14 (x000e), Len     4 (x0004)  

 ffff 0000                                         | ....  

  

GGS tokens:

TokenID x52 'R' ORAROWID         Info x00  Length   20

 4141 4156 7561 4141 4241 4141 584c 4241 4141 0001 | AAAVuaAABAAAXLBAAA..  

TokenID x4c 'L' LOGCSN           Info x00  Length    7

 3133 3036 3731 39                                 | 1306719  

TokenID x36 '6' TRANID           Info x00  Length    8

 392e 352e 3132 3330                               | 9.5.1230  

可以看到捕获到增量数据时,源端数据库提交的scn号为1306719

8.在目标机对数据库进行restore

9.对目标库使用语句进行recover,指定scn1306719

RMAN> recover database until scn 1306719;

10.使用resetlogs打开目标库,查看scn1306719时提交的增量数据是否存在。

SQL> alter database open resetlogs;

 

Database altered.

 

SQL> select count(*) from system.test;

 

  COUNT(*)

----------

 0

可以看到增量数据并不存在!!!!

11.之后我们删除目标端数据库的数据文件,重新进行恢复。最终指定scn1306720,比刚才的scn1

RMAN> restore database ;

略。。。

RMAN> recover database until scn 1306720;

 

Starting recover at 04-JUL-16

using channel ORA_DISK_1

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 07/04/2016 20:12:06

RMAN-20208: UNTIL CHANGE is before RESETLOGS change

 

RMAN> list incarnation;

 

 

List of Database Incarnations

DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time

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

1       1       SOURCEDB 310015860        PARENT  1          24-AUG-13

2       2       SOURCEDB 310015860        PARENT  925702     31-JAN-16

3       3       SOURCEDB 310015860        CURRENT 1306720    04-JUL-16

 

RMAN> reset database to incarnation 2;

 

database reset to incarnation 2

 

RMAN> recover database until scn 1306720;

12.使用resetlogs打开目标库,查看scn1306720时提交的增量数据是否存在。

SQL> alter database open resetlogs;

 

Database altered.

 

SQL> select count(*) from system.test;

 

  COUNT(*)

----------

 1

可以看到这次增量数据成功恢复进来了!!!

 

实验表明使用recover database until scn xxxxxx;并不包含指定的这个scn~

 

 

 

<think>嗯,用户询问的是Oracle数据库恢复命令"RECOVER DATABASE USING BACKUP CONTROLFILE"的使用方法和适用场景。这个问题需要深入理解Oracle恢复机制,特别是控制文件在恢复过程中的关键作用。 用户可能是一位DBA或者数据库运维人员,正在处理数据库恢复问题。从引用内容来看,用户已经查阅了一些资料,但需要更系统的解释。用户的核心困惑点在于:什么情况下必须使用这个命令?以及具体如何操作? 先梳理关键概念:普通恢复时,Oracle以当前控制文件记录的SCN作为恢复终点。但使用备份控制文件时会出现两个问题:一是备份控制文件记录的SCN早于数据文件实际SCN(ORA-01207错误);二是需要恢复到比备份控制文件记录更靠后的时间点。 从引用[3][4]可以明确,这个命令的核心作用是解除控制文件SCN对恢复的限制。适用场景主要有三种: 第一种是控制文件完全丢失后使用备份控制文件恢复(引用[5]的案例) 第二种是执行不完全恢复到特定时间点(引用[2]提到的until子句组合) 第三种是重建控制文件后的恢复(引用[1]隐含的场景) 操作流程上要特别注意三个要点:一是必须在mount状态下执行;二是必须指定until子句或使用cancel选项;三是归档日志必须完整(引用[4][5]的测试案例)。常见的错误场景是忘记auto选项导致恢复不完整。 用户可能还会关心性能影响。虽然引用中未提及,但根据经验,使用备份控制文件恢复通常比普通恢复慢20%-30%,因为需要扫描更多归档日志。建议在回答中补充这个实践细节。 最后需要强调风险点:如果联机日志丢失,即使使用这个命令也无法完全恢复(引用[2]提到"current/active redo丢失"的情况)。这个关键限制应该在回答中突出说明。</think>以下是关于 Oracle 数据库命令 `RECOVER DATABASE USING BACKUP CONTROLFILE` 的使用方法和适用场景的详细说明,结合引用内容整理: --- ### **一、核心原理** 1. **普通恢复的限制** 标准 `RECOVER DATABASE` 以**当前控制文件记录的 SCN** 为恢复终点,将数据文件恢复到该 SCN 点 [^3][^4]。 2. **备份控制文件的特殊性** 备份控制文件记录的 SCN **早于数据文件当前 SCN**(如 `ORA-01207: file is more recent than control file` [^5])。此时需用 `USING BACKUP CONTROLFILE` 解除恢复终点限制,允许恢复到更高 SCN(如联机日志的最大 SCN 或手动指定的终点)[^3][^4]。 --- ### **二、适用场景** 1. **控制文件丢失或损坏后** - 使用**备份的控制文件**替换损坏文件(需先 `SHUTDOWN` 替换文件,再 `STARTUP MOUNT`)[^5]。 - 启动时报错 `ORA-01207`(数据文件 SCN > 控制文件 SCN),必须用此命令恢复 [^5]。 2. **不完全恢复到特定时间点** - 需恢复到**备份控制文件记录的时间点之后**(如 `UNTIL TIME`、`UNTIL SCN`)[^3][^4]。 3. **重建控制文件后** - 通过 `CREATE CONTROLFILE` 重建控制文件(隐含备份性质),需用此命令同步数据文件 [^3]。 > 📌 **关键区别**:普通恢复以控制文件 SCN 为终点;`USING BACKUP CONTROLFILE` 以日志/指定点为准。 --- ### **三、使用方法** #### **场景 1:完全恢复(归档日志完整)** ```sql STARTUP MOUNT; -- 指定备份控制文件恢复 RECOVER DATABASE USING BACKUP CONTROLFILE; -- 自动应用所有可用归档和联机日志 ALTER DATABASE OPEN RESETLOGS; -- 必须重置日志 ``` #### **场景 2:不完全恢复(指定终点)** ```sql STARTUP MOUNT; -- 恢复到指定时间/SCN RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL TIME '2023-01-01 12:00:00'; -- 或 RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL SCN 123456; ALTER DATABASE OPEN RESETLOGS; ``` #### **场景 3:手动应用日志(`UNTIL CANCEL`)** ```sql STARTUP MOUNT; RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; -- 按提示逐个应用归档日志(输入 `AUTO` 自动应用,`CANCEL` 停止) ALTER DATABASE OPEN RESETLOGS; ``` --- ### **四、注意事项** 1. **强制重置日志(`RESETLOGS`)** 恢复后必须用 `ALTER DATABASE OPEN RESETLOGS` 打开数据库,重置日志序列 [^4]。 2. **日志完整性要求** - 完全恢复需**所有归档日志和联机日志完整** [^4]。 - 若联机日志丢失,只能恢复到最近归档日志的终点(可能丢失数据)。 3. **与 `UNTIL CANCEL` 的区别** - `RECOVER ... UNTIL CANCEL`:用户手动控制恢复终点。 - `RECOVER ... USING BACKUP CONTROLFILE UNTIL CANCEL`:解除控制文件限制 + 手动控制终点 [^2][^4]。 --- ### **五、典型错误处理** ```sql -- 启动时报 ORA-01152/ORA-01110(数据文件需恢复) STARTUP MOUNT; RECOVER DATABASE USING BACKUP CONTROLFILE; -- 使用备份控制文件恢复 ALTER DATABASE OPEN RESETLOGS; ``` --- ### **引用总结** > [^1]: 理解 `USING BACKUP CONTROLFILE` 需先掌握普通恢复机制。 > [^2]: 此命令允许在控制文件旧于数据文件时执行恢复 [^2][^5]。 > [^3]: 解除控制文件 SCN 限制,恢复终点取决于日志或手动指定 [^3][^4]。 > [^4]: 本质是以日志最大 SCN 为终点进行块级恢复 [^4]。 > [^5]: 典型场景:替换备份控制文件后报 `ORA-01207` [^5]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值