从安全上来说，重新初始化OGG是最保险的方法。我们数次遇到OGG同步故障，无法解决的情况下都是推倒重来最稳妥。

而且你迁移之后，相关的OGG进程里面的remote参数也需要变更的。

谢谢回复。remote参数是配置在源端的投递进程上，这个本来就是需要重新建的。我现在数据量不大，只有几十个GB，重新初始化配置OGG倒也是可行的。

如果OGG已经跑了很久了，数据量是T级别的，再重新推到新建OGG是不是代价太大了？
能分享下你的OGG同步迁移的方案吗？我比较疑惑的是，源端数据库迁移之后，SCN号完全变了，那如何实现增量同步呢？

再一次感谢！

根据我的了解的话，源库迁移无论是采用数据泵还是rman备份恢复，迁移之后的SCN都会产生变化的。而唯一可能的，能保留原始SCN不变的情况，就是采用rman image copy的方式进行数据迁移了，因为image copy 保留的就是原始数据文件的一份镜像，效果上等同于OS COPY，而SCN记录有两个地方，一个是control文件，一个就是数据文件的文件头。那么control 文件恢复之后 scn会产生一些变化，但不会从10000重新变成1这样子。数据文件恢复之后，他的SCN号也不会产生变化了。这样就能最大程度的保证SCN的连续性。
我没有做过这种测试，只是理论上应该是如此，你可以搭建一个测试环境，试一下就知道了。一般这种事儿，测试就是最好的检验方法。

非常感谢！是的，测试是最好的检验方法。现在还没有测试环境，要等目前的数据都迁移完了，才有个环境可以测试。
等我测试了再来关闭问题。
非常感谢！