在数据仓库建模中，未经任何加工处理的原始业务层数据，称之为ODS（Operational Data Store）数据。作为DBA来说，关心的肯定是如何把关系型数据库的业务数据同步到数据仓库中去…

一、领导的需求

我从一份领导的需求开始：

1.实现业务系统7*24小时不间断运行。

2.保证业务系统数据安全性。

3.降低生产系统压力，将部分查询和报表分析业务负载分离出去。

看似简单的几行字，实际上并不简单，对我们公司而言，至少走过了几年，痛苦的几年…

二、系统架构

我先介绍一下公司某业务数据库选型和架构，业务库采用了Oracle 11G RAC+DataGuard (3+2)，数据仓库是2套单实例的ORACLE 12C。

1. 主备节点之间采用光纤直连。

2. 正常情况下，主节点的数据（REDO）传递到备节点APPLY。

3. 切换至备库节点步骤：

当生产数据库发生灾难时，备库角色从standby变为primary，可以进行业务负载。
将DNS中主库域名解析地址由主库scan ip切换至备库scan ip。
应用配置无需更改，最大限度的提高业务恢复速度。

DataGuard有switch over、fail over两种切换方式。

switch over 功能，在容灾演练、生产环境服务器或存储硬件升级、服务器非存储类硬件故障或其它计划内的切换动作时，可以采用switch over方式进行切换。switch over切换过程是可逆的，即主备数据库可以反复相互切换。*
fail over功能，当生产环境服务器发生存储类故障且无法修复，可以采用failover方式强制切换。failover切换过程是不可逆的，备数据库变为主数据库后，是不能再回切回来的，即使原来的主数据库修好后，需要重建DataGuard，才能保持容灾同步关系。

2016年的某一个晚上，我们拉研发、测试人员等十几号人，埋头奋战了一夜，通过SWITCH OVER切换演练，做到了大部分应用程序无缝接管，保证了核心业务连续性。当然，也发现了一些问题，也及时进行经验总结。

在业务应用服务梳理中，遗漏了少部分外围的系统，事后才发现。
在DNS进行域名切换时，少部分服务出现访问异常，由于长事务等原因，后手动重启服务才解决的。

在我们引进ORACLE RAC+DataGuard架构后，带来的效果是明显的，解决我们数据库的单点故障，备库承担了大部分读的角色，同时也释放了主库的一部分读写压力。加上每天RMAN LEVEL0-LEVEL2的备份机制，保证了核心业务系统数据安全性，也朝着实现核心业务系统7*24小时不间断运行迈进了很重要的一步。

故事还没结束，才刚刚开始，呵呵！我的中心思想是业务报表数据同步，如何实现数据同步？如何给数据中心那边提供一个单纯，而又干净的数据仓库呢？

看到这，大部分读者首先想到是DBLINK最方便，在备库上用DBLINK同步。作为DBA来言，不能否认用DBLINK在某些方面确实能带来方便，如临时迁移数据、少部分基础表的数据同步等，但作为数据仓库建模，做大数据分析、报表，可想而知，数据量的规模，DBLINK太小家子气了，而且用DBLINK存在隐患。

不支持断点续传功能，如果源端数据库出问题（UNDO不足、TEMP不足等）、网络问题，需要重新同步数据，牵扯到效率问题。
不支持DDL，如果通过大量的自定义触发器来实现，在效率和准确性方面需要长时间验证，得不偿失。
几年前爆发的dblink导致SCN Headroom过低问题，有血的教训。

具体可以参考：
System Change Number (SCN), Headroom, Security and Patch Information (文档 ID 1376995.1)

Installing, Executing and Interpreting output from the “scnhealthcheck.sql” script (文档 ID 1393363.1)

三、利剑之一 Kettle+Azkaban

我们首先想到了ETL工具，想到了Kettle，也想到了Azkaban。

ETL是EXTRACT（抽取）、TRANSFORM（转换）、LOAD（加载）的简称，实现数据从多个异构数据源加载到数据库或其他目标地址，是数据仓库建设和维护中的重要一环，也是工作量较大的一块。
Azkaban是一个任务调度系统，用于负责任务的调度运行（如数据仓库调度），用以替代linux中的crontab。

Kettle是一款国外开源的ETL工具，JAVA开发的，数据抽取高效稳定。Kettle 中文名称叫水壶，该项目的主程序员MATT 希望把各种数据放到一个壶里，然后以一种指定的格式流出。

Azkaban是一个Linkedin开源的，JAVA开发的，批量工作流任务调度器，用于在一个工作流内以一个特定的顺序运行一组工作和流程，定义了一种KV文件格式来建立任务之间的依赖关系，友好WEB界面，便于维护和跟踪工作流。

kettle和Azkaban的引入，也验证了一句话，“好东西永远不愁卖，何况还不要钱”。

关键工作流程：

如图所示，首先在Spoon上编排数据抽取任务（任务中包含多个转换，多任务并行执行），其次将源表的数据经过处理输出到目标端数据库中，更新原有记录，再次在Spoon上完成任务编排，通过组件kitchen来调用编排好任务，最后将调用的内容编写成shell脚本，由azkaban进行任务调度。

Azkaban友好的WEB界面，运维人员能方便的查看任务执行情况，以及任务执行日志。

目前公司业务报表情况统计如下：

四、利剑之二GOLDENGATE

随着公司业务数据的不断增长，业务数据种类越来越多，领导对各类数据整合的要求也越来越高，数据中心能否及时对实时数据深层次的挖掘、分析？已成为重要一环，目前面临的刺手问题是数据的实时性。

基于数据的可靠性、实时性等要求，我们开始尝试Oracle下GoldenGate产品，先简单介绍GoldenGate产品。

2009年被Oracle收购，成为Oracle在实时数据集成，数据复制和数据高可用性领域的战略性产品。
跨异构环境，对系统负载影响很低，对交易型数据做实时抓取、路由、转换和传递。
和其他产品关键差异点：
性能：非侵入式、低影响和亚秒级的延迟
弹性、可扩展：开放和模块化的架构，支持异构数据源和目标
可靠：保持交易事务的完整性，对中断和失败容忍度高

从官方找了二张goldengate的工作流程图：

作为ORACLE铁粉的我，我相信它的实力。

曾经有过这么一段故事，有点久了，希望不会影响您的判断，有一丁点参考价值，我都开心。在2014年5月左右，跟ORACLE工程师James经过2周的时间，共同完成了对oracle goldengate同步工具（产品）的测试工作，文档《江苏某支撑平台oracle goldengate同步工具测试用例_v1.3》。

在测过过程中发现一些性能瓶颈，如下：

Analyz操作分析表不能同步，需要在目标端手动执行。
没有主键和唯一索引的大表的update、delete操作，目标端执行时间较长，对某业务表（表大小53G）进行130万条记录删除，目标端执行8小时以上（速度相差近300倍）。
在数据校验测试中，有主键和唯一建的表与无主键和唯一建的表，在数据量基本相同情况下，速度相差6倍以上。
业务高峰期OGG软件后台进程消耗CPU资源情况如下：
一个复制进程要消耗4%CPU；一个抽取进程要消耗3%CPU；
目标端开启8个复制进程时，cpu消耗36%左右，开启4个复制进程时，cpu消耗20%左右。

废话少说，开始我们的介绍，首先了解一下数据库基础环境。

主要的实施步骤

源端/OGG为共享文件目录。
源端在dataguard中备库某一节点上部署Manager、Extract、DataPump进程。
在目标端节点上部署Manager、Replicat进程。

说明：源端使用ASM存放数据文件或日志文件，必须使用SYS用户登录ASM实例，在源端extract参数文件中要配置：

TRANLOGOPTIONS ASMUSER SYS@<ASM_instance>, ASMPASSWORD <password>

经过1~2个月的反复测试和验证过程中，在DDL/DML同步、断点续传、实时性、数据安全性等取得了很好的效果，尤其是在备库节点承担了OGG抽取进程的所有消耗，对主库基本无影响下进行的，也满足了数据中心对数据的实时性的要求。花了将近半年的时间，在数据中心的大力协助下，我们成功的把Kettle上300多张核心业务的表迁移到OGG上，丰富了多维度的报表开发，实时报表也上线了，管理后台的财务报表也计划从业务库迁移至数据仓库。这下，大家都开心了，是不是可以“假装友好的”拥抱一下，开个玩笑，哈哈！

如下图所示，分别部署了6个抽取进程、投递进程和复制进程。

对于百万级以下新增表同步，基本做到在线实施。当然，期间replicat进程会出现大量 Error ORA-01403: no data found的错误，导致replicat进程ABENDING，一般选择业务低峰期，通过skiptransaction后，手动补齐差异数据来实现。

不知不觉中，dataguard已经上线了1年多，一直高效、稳定的执行他的职责。因此，我们还上了异构平台的数据同步（Oracle->mysql），如天眼系统数据同步、对账系统数据同步、火车票项目数据同步等。

五、小插曲

当然也出现过小插曲，2019年6月左右上线的新增城市站点项目，给我们带来了不少困惑，项目上线后，replicat出现数据延时，从1小时积压到10多小时，突然感觉replicat进程HANG了，而且是所有的replicat进程都不工作了。通过目标端info repyw2、send repyw2,status，源端send extyw2, showtrans等命令，发现RBA刷新非常慢，存在长事务。于是组织相关的研发人员讨论，战火开始了，您懂得。

通过对代码的排查，发现新增站点处理流程中加入事务管理，而且在调度中通过city_id字段采用并发机制，反复对某城市站点表中SYNC_FLAG字段更新（业务逻辑有点复杂，此处省略了），导致了处理未提交事务。我们内部初步认为是长事务导致replicat进程HANG ，造成数据延时。通过mos找到蛛丝马迹，Goldengate 12.1.2 Integrated Replicat Appears To Hang when Applying a transaction against an 11.2.0.4 database (Doc ID 1609690.1)。

经过多次跟研发沟通，研发同意在新增站点处理流程取消事务管理，引进了中间表进行改造，等业务逻辑测通后，且降低和控制并发（从300降到50,30,10）的情况下，再次上线，发现问题依旧，但是数据延时由10多小时降到1小时30分钟左右，期间加入提升replicat进程性能的批处理进程模式BATCHSQL。期间通过业务日志系统发现部分城市站点出现了ORA-08103对象不存在错误。

BATCHSQL BATCHESPERQUEUE 1000,BATCHTRANSOPS 2000 ,OPSPERBATCH 6000 , OPSPERQUEUE 6000

此时，我多想在ORACLE support上开个SR，寻求ORACLE的帮助啊！无奈，只能打消这念想，继续前行…

关键的一步,分两种思路走

第一，继续优化业务逻辑，结合ORA-8103触发场景，我们暂且用DELETE代替了TRUNCATE，优先避免错误发生，先不考虑DELETE效率低下，以及带来高水位问题。

cause: This ORA-08103 occurs on the next block read after the truncate command.
Possible solutions are:
- Use DELETE instead of TRUNCATE  
- Use SELECT FOR UPDATE as this will try to lock the table

第二，我们对新增站点处理流程进行存储过程的改写，采用事务类型的临时表来代替中间表。此处，应该有掌声，这是同事张春蕾的杰作，当然，也少不了研发同事的大力协作。有兴趣的可以提供该过程的代码。

等再次上线后，成功的解决了replicat进程HANG，数据延时等问题，不想再赘述枯燥地细节，当然有兴趣者，我们可以一起探讨，谢谢！

六、总结

结束了吗？

结束了，我反问，是不是快了点（尴尬了）…

严肃一点，再来一次，真的结束了吗？

没有。从理论上说，文章结束了，但从实践上说，还没有，我们才刚开始…

这不是废话嘛!
…
…
…

好了，言归正传，我来总结和展望一下吧。

公司数据平台基于Kettle+Azkaban和GOLDENGATE两大利器，基本覆盖了公司内部各个业务线，目前能够满足绝大部分业务的数据同步需求，实现业务DB数据准确、高效地入仓。
而对业务服务类的日志数据（Log）入仓的部分又是另一个课题，卖个关子，公司有一套稳定的HADOOP集群平台，通过flume、kafka、spark等技术解决了公司大部分用户行为的分析需求，但是，重点来了，对于两者的数据整合、后续构建高可用容灾等，我们不得不又面临的重要难题，也许分布式架构的NEWSQL（TIDB，小强DB等）是我们下一站，加油！我们才真正的开始…

创作场景

关于数据同步的最佳实践