Goldegate的内容比较多，只通过一次的分享可能讲不了多少内容，我简单列了一个大纲，在接下来的几次我会逐步跟大家分享这部分内容。根据大家的建议和需求，我在这部分分享的时候除了纯技术的交流以外，还会结合实际中遇到的问题跟大家分享实践中的解决思路。

下面是我初步的规划。

第一节课我会跟大家交流goldengate系列课程设计方面的一些想法，然后会简单介绍goldengate的原理，相关组件等，包括常用的一些场景，注意事项等大方向上的思路。然后会进行不同场景下最佳实践的探讨。

根据我个人的经验，在非电信运营商行业比如税务等对goldengate的使用方式和运营商行业有很大的不同。在最佳实践系列中间，我们模拟不同场景，即包括像非电信行业常见的使用模式，也包括我们公司现在服务的电信行业的使用模式。关于不同场景的特点和适用性，以及长远来看方向性的内容，我也简单进行了总结。

后面的几个课题，主要是我们在日常工作中面临的最经典的一些问题，比如最佳实践和解决方案。我打算分别模拟普通行业和电信行业的环境搭建虚拟机，然后配置不同场景与大家一起进行探索学习，在后面的课程中会详细说明。主要会涉及到goldengate中延迟的监控，这种监控的数据自动化，利用成套的自动化脚本的办法和思路。当然有官方的工具，也有自己做的一些工具。还有故障的分析和定论，性能的优化，包括goldengate本身提供好的一些常用工具的使用方法。

“1，课程系列内容－总览”就先介绍到此，我们继续来看：

2，Oracle GoldenGate 的工作原理

关于goldengate的工作原理，我借用了官方文档上的经典视图。简单来讲，goldengate在源端数据库上和目的数据库上会各部署一个软件，通过源端监控和抽取数据库的操作日志，然后将日志解析打包，发送到目的端后将日志重新组装，然后再投递，通过这种方式进行数据同步和迁移。上面的图是经典视图，大家可能比较熟悉，我做几点补充说明。

第一是我们使用ogg抽取日志的方式跟dataguard，streams等技术的异同。Oracle 的dataguard， streams也是通过日志的抽取方式实现数据的传递的，在dataguard中我们都知道分为物理的和逻辑的，物理的dataguard实际上用的是oracle的恢复技术做的，通过恢复技术实现数据块拷贝、传输、还原，逻辑的dataguard是通过挖掘日志的方式实现的，这跟goldengate的方式是一致的。

另外和streams技术相比较，在goldengate之前，oracle是通过自身的streams技术来实现这种灵活的数据同步，可以自由确定数据范围，但自从把goldengate收购之后，streams技术就基本上本束之高阁了。但是这并不是意味着这项技术不再被使用了，而是被融合到了goldengate的新版产品当中，因为原来在streams中有一些很好的特性，在实现上更有技巧性，效果也更好。

Goldengate通过分析redo日志，然后把redo日志对应的操作以及操作中对应的数据，直接捕获，翻译，在翻译中使用自己的格式，然后按照这种格式放到对应的trail文件中去，传输到目的端，然后将trail文件根据目标库类型组装还原成sql，再执行这样的过程实现的。简单来讲就是有抽取和转换的过程，而这种抽取和转换的过程也导致这个技术有一个很大的限制，对于Oracle一些特殊的数据类型的支持不是很全面，对于Oracle一些特殊的事务的支持也不是很全面，当我们要传输的数据包含了特殊的数据类型或者特殊事务的时候，就会产生问题，比如goldengate不支持分布式事务。但在streams技术中，能够有效地避免这个问题，因为streams技术在捕获日志的同时会以LCR (logical change record)的存储格式，随后会根据LCR的存储格式进行组装和投递，这样能够实现对oracle所有的数据类型和事务的全支持。

Oracle收购goldengate后，就结合streams技术对其进行了改造，就产生了goldengate不同的抽取方式和模式。现在goldengate的抽取模式有两种，在早期只有一种，第二种是在11.2的后期版本才出现的，准确讲是在11.2.0.3版本中出现的，并且在12C以后，第二种模式会成为单一模式，而第一种模式则会渐渐被摒弃。

Oracle为了区分goldengate抽取数据的两种模式，给两种不同的方式起了不同的名字。第一种是经典抽取模式，这是在11g之前使用的抽取模式，就是捕获日志，然后进行数据类型、事务转换，形成trail格式，进行传送处理。

第二种抽取模式就是在11.2.0.3及以后,仅仅在oracle数据库才支持的一种模式，叫做集成模式，就是抽取进程自己不直接去读redo日志去进行解析转换，而是和oracle的logminner 配合起来，利用logminner的功能，读取日志组装LCR，进行传送处理。

这一点就是关于抽取模式的变化，对于oracle数据库来，可以使用经典模式或集成模式，而其他数据库只能使用经典模式。对于oracle dba，可能会遇到很多的集成模式的应用和学习。这种模式在11g推出以后，刚开始还是有很多问题的，但在后期12C里面比较成熟了。这种模式相比较经典模式，的确存在很多的优越性，而且随着12C版本的成熟，会表现出越来越多的优势。

第三点，是关于泵出的环节。我们刚刚讲过，在goldengate中，步骤一般是捕获、泵出、交付。对于泵出的这个环节，我们大家在日常的配置中一般是会配这个环节的，这个环节会启动对应的pump进程，但是其实这个环节并不是必需的，配置或者不配置这个环节，goldengate都能够正常地工作，但是有什么区别呢，如果不配置该环节，当网络中断，会造成很多问题。而配置之后，相当于checkpoint机制，能够应对各种故障和问题。在数据传输时，如果有必要，可以进行压缩和加密，在pump进程里进行相关的参数设置即可。

第四点，是关于交付的环节，也就是投递进程。一般来说，若在数据同步过程中出现性能问题，基本都是在交付即投递阶段出现的，所以后期的性能优化主题，虽然我们会分析从源端到目的端整个环节，可能会有哪些点导致性能问题，但是最主要的场景还是在投递阶段，我们所采用的大部分手段也是在这一部分进行优化。

第五点，大家可能注意到，在原理图上有一个词叫做双向。这个图上，从源库进行捕获解析传送完成交付，而在目的库上也做了同样的操作到源库，也就是说，goldengate可以用于双活的场景，但是它有很大的限制和问题，常规使用一般是单向的。一旦我们真的要使用双向，建议遵循一个原则，就是从源库抽的数据送到目的库，然后从目的库抽的数据到源库中时，两个数据的范围不一样。比如从源库到目标库是一批表，而相反方向的抽取对应另外一批表，这样库是双活的，但数据是没有交集的，这种是用得比较多的双活场景。同一批表在多个库里面的变化，跟踪，相互数据同步，原理上是可以做的，但是需要做大量细节的处理和判断，不仅仅很麻烦，而且很可能出现数据冲突，引发数据不一致。为了保证数据库的健壮稳定，建议使用Extended RAC实现真正意义上的双活。

 

3，GoldenGate组件与目录结构

接下来我们来了解goldengate的组件和对应的结构。对于从源端抽取数据传输到目标端这样一个宏观的过程，具体是通过哪些组件相互协作，而这些组件又对应哪些具体的进程呢？我们来一一说明。

上面列出了主要的组件和文件目录。首先来看第一个组件 manager，这个进程是goldengate的调度和管理进程。它的功能主要如下：

• 按照参数配置的情况在网络上监听相应端口，探测别的goldengate给它发送的所有命令和数据，进行接收、存储和处理。这是manager的主要功能。
• 对trail文件进行维护，对其它进程监控调度。manager进程会对trail文件进行校验，检查，并按配置进行清理。其它进程工作的时候是否有延迟，有没有出故障，出了故障以后需不需要自动重启，对应的管控和操纵策略，都是由manager去落实的，具体的落实策略，是通过manager对应的配置文件里面的参数设置的。

第二个，extract 抽取进程，顾名思义就是主要靠该进程进行挖掘和读取日志，并将日志里面的信息进行转换，转存到trail文件里面去。它的功能比较单纯，但实际上是整个ogg体系中工作量最大的进程之一，关于这个进程的参数也特别多，不同参数配置的效果，推荐大家多看看官方文档，多去试用。

关于抽取进程，到底配多少个，多点好还是少点好呢？这里有一个原则，大家可以参考。因为抽取进程是需要从所有日志里面抽取自己需要的对象的操作日志，所以原则上抽取进程要尽量少，一般配置一到两个抽取进程，最多不超过三个。实践中常见糟糕的例子，比如某单位抽取过程涉及到很多个用户，每个用户下有很多个表格，］为了能够同时抽取这些用户的数据，配置了十几个抽取进程。每一个抽取进程在抽取数据的时候，都会读数据库的所有日志，然后从日志中过滤和检索出它负责的那部分的对象数据的变化，也就相当于数据库的日志需要经过十多次的抽取，分析，和对应的处理，而这种抽取和分析的过程是很消耗CPU资源的，所以如果抽取进程过多，会极大地占用源端库的CPU资源。

第三个， replicate投递进程，它是在目的端的，主要是根据trail文件中的数据，组装SQL，然后在目的数据库上执行，从而完成数据的投递，这个过程中还支持过滤及数据处理，参数也非常多。

投递进程遇到任何故障，不管是停机，或者是意外终止之类，在下一次启动的时候都能够紧接上一次的场景，不丢数据，也不会产生问题，之所以能够实现这一点，是因为goldengate有类似于数据库的checkpoint机制和恢复机制，checkpoint都是以对应的文件的形式在dirchk目录中。同时在replicate投递过程中，可以定义一个checkpoint table，它会在表格里记录详细的投递进度。

第四个进程是collector进程，也就是收集进程，事实上collector进程是由manager进程产生的，属于manager进程的子进程。所以在前面说manager进程有接受数据功能，其实是由manager派生出来的collector进程来实现这个收集的过程。为什么这样呢， 因为goldengate的同步模式中支持多个源对一个目标。当目标数据库接收到好多个源发来的数据，为了效率考虑，就由manager进程根据生成一个或多个collector进程进行接收。

第五个是trail队列，trail文件是goldengate定义的二进制格式，extract出来的内容一般都会处理成这种格式，然后传输到目的端，在目的端进行输出，所以trail就是两端共用的一种数据格式。在操作这种格式的文件时，如果这种文件有好多个，就形成一个trail文件队列。

大家可能会发现在我们的组件中少了一个东西，我们从经典视图中看出，传数据是需要有人来做的，但是在这个集成组件中我们并没有看到有哪一个进程是专门用来传数据的，传数据是谁来完成的呢？goldengate中是这样的， extract可以从日志中抽取数据，也可以通过一些参数的设置，让它不负责从日志中抽取数据，而是从trail文件中抽取数据并传递到远方。同样是抽取，只不过这里的抽取并不是从数据库里面抽取，而是从trail文件中抽取，同时还要注意，从trail文件中抽取的时候出于效率考虑，不光是从数据在磁盘上落地的时候抽，而且直接从缓存中抽取进行传送，这种缓存输出和trail文件是配合的。

checkpoint，这个简单来讲就是各个进程，定期触发检查点，然后把在检查点时的状态传输到文件中去，用于在某些情况下的恢复，以及状态、完整性、数据一致性保障。

参数文件，goldengate不同的进程在不同的场景下均能最佳的完成功能，每一个独立的进程都有自己的参数文件，抽取进程有抽取的参数文件，传输进程有传输的参数文件，投递进程有投递的参数文件，每一个进程的参数文件都是以进程的名字来命名的，存放在goldengate的dirprm目录下。

图片剩下部分就是文件目录，goldengate软件部署之后，就是一个绿色的压缩包，解压就好，然后初始化，就就会生成子文件夹，这些文件夹每一个都是有固定的用途和命名的，而其中比较重要的是放参数文件的目录，和放trail文件的目录，日志目录，放进程文件的目录等。

dirdat目录，是放trail文件的。整个软件里面这个目录是最消耗空间的，所以当你配置goldengate环境时，需要很好地评估一下要配置的环境数据的产生量大概是多少，在遇到故障的时候能停多少时间。比如说，我目的端的投递停了，但源端的数据抽取传输还在继续，那么传递的日志会在trail文件里一直放着.那么能容忍多长时间的中断,在中断期间会产生多大的trail,有多大的数据变化,这些都要考虑到安装目录的大小.

 

4，GoldenGate支持的数据库和操作系统平台

上图是goldengate支持的数据库和操纵系统。这是很早之前的一张图，这里可以看出goldengate几乎支持所有的数据库和所有的操作系统平台，这些库和系统的新版本继续支持。

goldengate最大的优势之一就是跨数据库，跨平台实现持续高效的数据传输，那么它是如何实现跨数据库跨平台的情况下，软件又很小。比如软件包11g及之前版本基本都是二三十兆的样子，12c版本也就是300兆这么大，它是如何做到的呢？其实就是源于他模块化的开发思路，所谓模块化的开发思路，首先就是它的抽取，传输，投递和一些监控管理等都是由各个具体的进程来实现的，而这些进程，如果你仔细观察会发现其实就是安装目录下的一些小程序，而这些程序加起来就实现了goldengate的功能。这是它模块化的第一个层次，也就是内部结构的模块化。同时针对每一个数据库版本的每一个平台都会开发一个独立的包，这个包里的程序和对应的进程，就只支持者一个库及系统组合，这是它模块化的第二个层次。

所以，goldengate进行部署时，需要根据相应的数据库类型版本和操作系统平台选择不同的包版本。

 

5，Oracle GoldenGate 拓扑结构

上图是goldengate的拓扑结构图，从这个图可以看出，goldengate支持单向的数据传输，也支持双向的数据传输，所谓的双向，也就是能实现主备，活动和活动的两种，其中活动和活动的双活的形式就是前面提到的最好用在非相同数据集的传输，第三种对等传输，也就是多节点传输，一个库到数据变化传输到另外一个库，而另外库的数据变化又传输到其他库，当然这种方式最好也用在非相同数据集的传输，不然会需要较复杂的设置，因为涉及到复杂的实现机制。广播的方式，也就是同一个源，向多个目标库分发。也可以把多个库的变化集中到一个数据仓库里面，这就是整合。或者也可以前面一些方式的组合，形成级联式。单向、广播、整合这三种场景是比较普遍使用的。另外这些模式不是全部的，而是彼此之间都可以相互搭配，形成新的模式。

那么在搭配组合的过程中，级联的层数有没有限制呢？答案是没有限制，你可以根据自己的需要，进行任意层数的搭配。

 

6，Oracle GoldenGate 应用场景

 

上图是goldengate的使用场景，第一种是用于容灾，可以从源库传输数据到目标库，而目标库用来做备份。第二种是用于升级迁移。第三种就是用于压力卸载，读写分离，比如报表库或者查询库的实现。第四种是像数据仓库一样对数据的提取和汇总。第五种就是数据分发。

 

7，税务和电信ogg的常用场景区别

电信行业表现出的特点是高压力，高要求，而税务我则指的是除电信以外的其他行业，一般场景，其中税务会比较典型一点。

这两个行业很大的一个区别就是，在一般行业，因为高峰期业务量也可控，因此会直接使用抽取进程从源端库抽取数据，然后往目标库进行投递，这个源库就是生产库。在这种情况下，优点是抽取的模式比较灵活，能够配置的参数较多，功能也比较全面，缺点是会消耗主库上的资源。

在高压环境，比如像电信行业这样的环境，goldengate一般不在生产库上部署，利用生产库的读写分离库，比如ADG，然后从ADG上抽取数据再同步到目标库，使用这种方式的好处是对生产库没有影响，但由于ADG本身只读不写的限制，导致goldengate的很多功能在这种场景下受限。

因此我们在设计goldengate的配置结构时，不能一成不变的照搬，而需要根据场景结合需求去做一些合理的设计。在我们目前的工作中，大部分情况下只是部署一个进程直接进行抽取，在12C里面我们可以考虑Downstream模式，一种能够很好地和集成模式配合的方式，能实现抽取的卸载。也就是说在高压环境中，不同于ADG，直接创建一个可以读写的中间库，将生产库的日志传送到这个中间库，goldengate在中间库上抽取，即不占生产库的资源，又克服adg不能写限制goldengate功能的问题，这个就是Downstream模式。

在设计的时候可以先确定大的模式，然后再在细节上进行优化和调试。

 

8，goldengate日常运维必须的参考资料（官方文档+mos）

10.x（E15881_01）、11.1（E18101_01）、11.2（E35209_01）、12.1(E40035-01)

以上给出一些常使用的资料，这些资料大致有两类。第一就是官方文档，官方文档我们可以从oracle官网上去下载 ，在图上我也把10g对应的一些离线包的编号都标注出来了，便于查找。

在官方文档中我们使用最多的是管理员手册（administrator guide）和参考手册（reference guide）。

官方文档是用来日常查阅或者处理常规的一些故障的，当遇到疑难杂症的时候，建议通过 MOS，metalink进行查询解决。里面有很多经典的问题的解决思路。后续我们会深入探讨。

 

9，oracle收购goldengate后的战略变化，即ogg 12c之后的重点方向（经典模式与集成模式，Downstream）

早期的goldengate支持多种操作系统、多种数据库的能力在12C版本还是不变的。在oracle收购以后，做的最主要的变化是goldengate中对于oracle数据库的支持上做了大量的改良和提升，使得能够支持很多oracle的特性 ，实现功能上的扩展，这是战略和方向上的改进。第二个方面，在技术上，主要是抽取模式上的变化，出现经典模式和集成模式，集成模式是12C以后的主导模式。

 

© 2016 – 2020, morinson. 版权所有. 欢迎转载，但请保留作者及出处。