OGG 灾难恢复复制前期准备需求

OGG作为优秀的数据复制工具，其灵活性易用性是我们最爱的优点。但是用来做灾备工具，我还是不赞成的。但是领导要求使用，我们只能出方案硬着头皮往上冲。

工作是要做的，说多了没用。花些时间再次深入分析OGG的特点，做好充分的准备迎接这次挑战。期待着过渡到Oracle ADG彻底解决现在的困境。

这篇博客内容是我为这个项目做的前期准备工作，需要和业务部门应用开发团队共同讨论的议题。其目的就是一条核心理念，只同步必要数据，减少出错。

拓扑结构

灾难恢复的拓扑结构和Oracle ADG相同，虽然配置了双向复制但是应用期间始终保持单项复制从Primary到Standby或者切换后从Standby到Primary，不要出现双向复制同时开启的active-active状态。

所需条件 

使用OGG作为灾难恢复工具比作为数据复制工具要复杂的多。为了减少错误发生的几率，我们需要在部署前做好准备工作。所有将要使用OGG作为灾难恢复工具的环境都需要满足一下需求。

• 为了减少人为误操作对主库的破坏（drop table），OGG只同步DML操作。

• 保证主库与备库一直处于同步状态，所有DDL操作需要提前申请。

• 主库是read write状态，备库置为read only状态。如果备库采用了read write状态，需要对数据冲突做特殊处理。

      需要测试备库是否可以在read only的状态下同步数据

• 主库需要与备用数据库结构保持一致，不要使用过滤、转换等复制操作。

• 主库版本，字符集需要和备库保持一致。

• 主库是否有序列sequences,如果有需要特殊配置。

• 主库如果有trigger在备库需要将其禁用，为了主库备库切换需要将禁用和启用trigger的语句写成可执行脚本。

• 主库如果有外键级联删除操作需要在备库将其禁用，为了主库备库切换需要将禁用和启用级联外键删除的语句写成可执行脚本。

• 主库核对所有数据类型，看是否有OGG不支持的类型。

      参考GoldenGate product documentation for a list of data types supported.

• 主库需要同步的表必须有主键或者唯一键

      如果实在不能创建可以使用TABLE和MAP的KEYCOLS选项指定列

• 确定业务表，只同步业务核心表。

• 确定临时表，所有临时表都不同步。

• 确定大表，分区表，为其创建单独的进程减少复制过程中对其它表的堵塞。

• 主库与备库的OGG用户需要有dba权限

• OGG对内存的需求：每个OGG抽取或是复制进程需要25-55Mb大小的内存。

以后会继续写一些实用脚本和切换方案
未完待续...

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29047826/viewspace-1455824/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29047826/viewspace-1455824/