【Oracle】探究recover database until scn

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

SQL> alter database open resetlogs;
 
Database altered.
 
SQL> select count(*) from system.test;
 
  COUNT(*)
----------
 1
可以看到这次增量数据成功恢复进来了！！！

 

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