广西移动营业和客服数据库数据复制应急查询平台--案例

广西移动营业和客服数据库数据复制应急查询平台

业务需求

将广西移动在白沙机房（BOSS1.5机房）新建一个基于SAN环境的计算机系统，有6个数据库(Oracle 9i RAC)，其中的2个数据库（一个是Oracle 9i RAC，两个节点，另外一个是双机互备模式）根据业务需要分别复制到应急数据库（Oracle 9i Single）的2个实例，因此需采购相应的复制软件进行数据库的复制。

本工程是对其中的营业数据库和客服数据库进行复制，复制到应急数据库。

数据库复制系统的建立应实现将营业库和客服库的数据变化分别复制到应急库，使得应急营业库和应急客服库的数据和生产系统的营业库及客户库的数据同步。并能在生产系统的营业库或者客户库有故障时，替代故障库，接管应用。当故障库修复以后，能及时将应急库中的数据同步到修复后的生产数据库。

方案设计

根据广西移动数据复制系统的业务需求，采用DSG RealSync软件实现数据复制：系统总体结构如下图所示：

生产系统

广西移动BOSS 1.5系统中需要本期工程进行复制的业务类型主要包括三种：

客服：系统的数据量约为100GB

帐务：系统的数据量约为800GB

营业：系统的数据量约为500GB

客服数据库单独运行，运行在两台IBM P690服务器上，组成RAC环境；

帐务和营业两个业务运行在一个ORACLE DATABASE的两个USER上，运行在两台IBM P690服务器上，组成RAC环境；

在容灾系统上安装两个ORACEL INSTANCE，运行两个ORACEL DATABASE。分别对应生产系统的客服数据库和营业帐务数据库中的两个用户。

性能参考

全同步

DSG RealSync提供了不停机的首次全同步功能，该功能支持数据库在正常业务时间不中断的情况下进行全同步。避免了采用存储拷贝方式进行全同步时必需要求的业务中断。

对于广西移动的数据量，两个用户数据量约为800GB，采用10个并发任务进行全同步，同步时间共计约5小时左右。

日志分析速度

系统每天处理的日志量达到400GB左右.

CPU资源速度

源端日志分析CPU占用量为单个CPU的10%，高峰期可达到单个CPU的60%.

解决方案特点

容灾与其他任何保险策略一样，当没有灾难出现时，我们根本无法意识到容灾系统所起到的作用，无法回收容灾系统建设所需的大量投资。但从系统安全性角度考虑，我们又必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。但是在大部分情况下，当未出现灾难时，我们的容灾端系统总是处于空闲状态，花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。

为此我们采用双active的结构，让容灾系统的数据库也处于OPEN状态，这样实际上广西移动就拥有了第二数据中心，而不仅仅是一个灾难备份系统，通过第二数据中心可以实现如下功能：

核心业务的灾备平台

通过数据同步建立的第二数据中心可以实现对业务关键数据的容灾及保护，在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像，以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。

业务负载分担

第二数据中心的数据处于实时可读取状态，数据库处于OPEN状态，实现BOSS系统业务模块的重新部署。

通过第二数据中心实现对BOSS核心系统的业务模块进行负载分担，将那些只对数据进行读取操作的模块都迁移到第二数据中心上来，主要包括：

地市统计报表

地市业务查询

提供其他系统的数据访问接口；

 

这样作将达到两个好处：

提高数据访问的效率，提高外围系统部署的灵活性；

提高核心系统的运行效率，提高核心系统运行的稳定和可靠性；

本文出自 “Oracle大型数据库灾备专栏” 博客，谢绝转载！