我们在使用logical dataguard 时候，standby 机器容易出现问题
我们经常采用
insert into test1 select * from test1@db_link as of scn xxx;
这个xxx是applied_scn 还是applied_scn+1 呢
大部分情况applied_scn 和applied_scn+1 的数据是一致的，但是比较繁忙的系统，这两部分数据则不一致
做个试验来证明：
主库：
SQL> select count(*) from test1;
COUNT(*)
----------
10000
从库：
SQL> select count(*) from test1;
COUNT(*)
----------
3508
当前applied_scn
SQL> select applied_scn from v$logstdby_progress;
APPLIED_SCN
-----------
4677895
SQL> select count(*) from test1@devdb as of scn 4677895;
COUNT(*)
----------
3507
SQL> select count(*) from test1@devdb as of scn 4677896;
COUNT(*)
----------
3508
我们开始的scn 应该为applied_scn+1，而不是applied_scn
从库：
SQL> truncate table test1;
Table truncated.
SQL> insert into test1 select * from test1@devdb as of scn 4677896;
3508 rows created.
开启apply
alter database start logical standby apply immediate;
SQL> select count(*) from test1;
COUNT(*)
----------
10000
两边数据完全一致，所以我们要同步到scn+1
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/8135069/viewspace-624830/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- p1Text="name|mode"
- rebuild online 和drop partition update global indexes
- rac 重建undo
- ORA-00600: internal error code, arguments: [kcbgcur_9], [335544649],
- 所有进程空闲时，logical dataguard 竟然延时
- rac 一个节点log switch 引起其他节点log switch
- ORA-04031
- shared pool 结构
- goldengate oracle to mysql配置
- Bug 4369756 - Log apply may dump [krvsmso]
