oracle recover database,【Oracle】探究recover database until scn

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

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

start replicat rep_ynkg,atcsnxxxxxx

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

aftercsnxxxxx

原因是使用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),190)">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),190)">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),190)">0000 0005 5641 4c49 44 | ....VALID

Column 10 (x000a),190)">0000 0001 4e | ....N

Column 11 (x000b),190)">Column 12 (x000c),190)">Column 13 (x000d),190)">0000 0001 31 | ....1

Column 14 (x000e),190)">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,指定scn为1306719

RMAN> recover database until scn 1306719;

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

sql> alter database open resetlogs;

Database altered.

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

COUNT(*)

----------

0

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

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

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-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打开目标库,查看scn为1306720时提交的增量数据是否存在。

1

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

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

总结

如果觉得编程之家网站内容还不错,欢迎将编程之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值