简介面向Oracle 11g数据库运维与开发人员这份Oracle GoldenGate 11.2.1.0.3版安装包专门解决Windows x64环境下的实时数据同步与迁移问题。包内含GoldenGate核心组件从抽取、传输到复制均有对应程序并提供管理控制工具。资源共185个文件压缩包大小34.1MB其中52个jar支撑Java代理38个sql为数据库配置脚本17个exe为可执行程序12个dll包含ICU、Xerces等依赖库另有大量txt、xml、properties等参数文件可满足部署、调优和故障排查需求。目前已有1408人学习或下载适合需要快速掌握GoldenGate基础架构的数据库管理人员。通过此安装包可获得完整组件清单与运行库明显降低自建实验环境收集依赖的时间成本配合官方文档即可完成环境搭建、进程配置和数据一致性验证并了解数据抽取、传输与复制链路的工作机制是学习和部署该版本GoldenGate的实用参考。1. GoldenGate 11.2.1.0.3 在 Windows 上的真实分量老库同步绕不开的版本还在找 Oracle GoldenGate 11.2.1.0.3 for Oracle 11g Windows x64 的多半不是追新而是被存量系统绑住了。不少企业内部跑着 Oracle 11g 的 Windows Server 2003/2008 主机数据库升级排不上日程但同步链路又必须稳定于是这个老版本反而成了刚需。它能解决什么问题简单说在 Windows x64 上搭一套完整的抽取、投递、复制链路支撑数据容灾、报表库分发、生产库到查询库的实时同步。适合三类人维护老库的 DBA、做数据迁移或灾备的工程师、刚接手旧项目需要快速上手的实施新人。这个版本不炫技但用对了很稳前提是你知道介质怎么校验、参数怎么配、以及 Windows 平台上那些藏得比较深的坑。2. 安装前的准备介质校验、目录规划与 Windows 2003 的兼容性边界2.1 先看清解压出来的东西是什么GoldenGate 11.2.1.0.3 在 Windows 上不是传统的 run installer 安装方式而是解压即用。解压后你会看到几个关键目录和可执行文件dirprm 放参数文件dirdat 放 trail 队列文件dirchk 放检查点文件dirrpt 放运行报告和 discard 文件另外还有 ggsci.exe、ggsvc.exe 两个核心工具。ggsci 是主交互命令行进去之后所有进程管理、参数编辑、状态查看都从这里做ggsvc 负责把 OGG 注册成 Windows 服务方便开机自启。我一般拿到介质先做两件事一是核对解压后的文件是否完整少了 ggsci.exe 或 Lib 目录基本没法跑二是确认路径里没有中文和空格。路径带空格在 Windows 2003 上会引发非常诡异的问题比如 GGSCI 能启动但参数文件读取不到或者投递进程连不上远端。排查半天发现是路径问题属于那种最不值得踩的坑。介质解压目录不要放在 Oracle 数据库软件目录下独立建一个目录管理起来更清爽。2.2 目录规划队列文件别放 C 盘OGG 的磁盘消耗大头在 dirdat 目录下的 trail 文件文件命名类似 et000000、et000001 这种按序号递增。队列文件的增长速度很容易被低估特别是抽取大表或业务高峰时段一小时写几百 MB 到几个 GB 都很正常。所以目录规划的第一个原则dirdat 独立放一个磁盘别和系统盘挤在一起。系统盘满了不只是 OGG 挂掉Windows 本身也会出各种连锁问题。目录用途注意事项D:\OGGOGG 安装根目录路径不要带空格和中文D:\OGG\dirprm存放 MGR、EXTRACT、REPLICAT 参数文件文件名与进程名对应D:\OGG\dirdattrail 队列文件独立磁盘预留足够余量D:\OGG\dirrpt运行报告和 discard 文件定期清理避免日志爆盘D:\OGG\dirchk检查点文件不要手动删除删了等于进程白干另一个常见做法是给 OGG_HOME 单独设一个环境变量后续写脚本、配服务都引用这个变量。命令行窗口里临时设置只对当前会话有效如果 OGG 要注册成服务服务进程不会读取命令行里 set 出来的变量必须写到系统环境变量里。这个区别在 Windows 2003 上尤其明显先记着第 4 章会专门讲。2.3 环境变量和系统级准备在启动 GGSCI 之前先把三个环境变量配好set NLS_LANGAMERICAN_AMERICA.ZHS16GBK set OGG_HOMED:\OGG set PATH%OGG_HOME%;%PATH%NLS_LANG 三个段分别是语言、地域、字符集。字符集必须和源库一致否则后面同步中文数据必乱码。怎么确认源库字符集登录数据库执行SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETERNLS_CHARACTERSET看返回结果是 ZHS16GBK 还是 AL32UTF8然后把 NLS_LANG 第三段配成对应的值。Windows 2003 上还有一个隐藏依赖这个版本的 OGG 编译期依赖老版 VC 运行库。如果你在全新系统上安装启动 ggsci 时报找不到 MSVCR71.dll 或类似错误装一个 Visual C 2005/2008 运行库就能解决。2013 运行库不一定兼容老版本别装错了。最后就是防火墙MGR 默认监听 7809 端口动态端口列表里的 7810-7820 也要放行否则远程投递链路会在没有任何报错的情况下频繁断连表现成一种黑匣子式的故障。提示这份介质明确标注 for Oracle 11g Windows x64只用于 11g 和对应的 Windows x64 环境。生产库如果是 19c 或 Linux 平台别用这个版本版本错配带来的问题比不配 OGG 还麻烦。3. 从 MGR 到 EXTRACT 再到 REPLICAT把第一条同步链路跑起来3.1 数据库侧先做两件事补充日志和归档OGG 抽取依赖数据库日志所以数据库侧的前置条件比 OGG 自身安装更关键。以 DBA 权限执行下面三条ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE FORCE LOGGING; SELECT LOG_MODE, SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;补充日志的作用是让日志里记录足够的前镜像信息。没有它UPDATE 操作在目标端可能无法定位到正确的行导致更新出错或跳过。FORCE LOGGING 则是强制所有操作都写日志避免某些 nologging 操作产生的数据变更在日志里缺失。查询返回的 LOG_MODE 应该是 ARCHIVELOGSUPPLEMENTAL_LOG_DATA_MIN 应该是 YES。如果数据库还在 NOARCHIVELOG 模式那 OGG 根本没有数据来源先切归档模式再说。这两步做完之后还要建一个专门给 OGG 用的数据库用户赋予必要的权限。11g 里常见的做法是给用户授予 CONNECT、RESOURCE再单独授予 SELECT ANY TABLE以及 SELECT 相关数据字典视图的权限。参数文件里的 USERID 就用这个用户。有人图省事直接用 SYSTEM 账号我不建议后期审计和权限收口都麻烦。3.2 初始化目录并在 GGSCI 里启动 MGR打开命令行切到 OGG 根目录执行ggsci进入交互界面。第一次进来先执行create subdirs会自动把 dirprm、dirdat、dirrpt、dirchk 这些标准目录全部建好。然后编辑 MGR 的参数文件GGSCI create subdirs GGSCI edit params mgr在打开的 MGR.prm 里写PORT 7809 DYNAMICPORTLIST 7810-7820 AUTOSTART ER * AUTORESTART ER *, RETRIES 3, WAITMINUTES 5 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 6逐个解释。PORT 是 MGR 的固定监听端口默认 7809被占用就换。DYNAMICPORTLIST 是 MGR 向外发起连接时使用的动态端口范围源端和目标端防火墙都要放行这一段。AUTOSTART 让 MGR 一启动就自动拉起所有 extract 和 replicat 进程省得每次重启手动 start。AUTORESTART 是进程异常退出后的自动恢复机制RETRIES 3 表示最多重试三次WAITMINUTES 5 表示每次间隔五分钟。PURGEOLDEXTRACTS 是 trail 文件的自动清理开关USECHECKPOINTS 表示按检查点判断哪些文件已经不被需要MINKEEPHOURS 6 表示至少保留最近六小时的文件。有很多人不敢配 PURGEOLDEXTRACTS怕误删没投递完的队列。实际上 USECHECKPOINTS 参数保证只清理已确认投递完成的 trail 文件比手动清理安全得多。我当时第一次部署就没配结果 dirdat 在业务高峰期一天写了几十 GB差点把磁盘撑爆。这个参数配好之后基本可以放手。参数保存退出然后启动 MGRGGSCI start mgr GGSCI info mgrinfo mgr 显示 RUNNING 才算正常。如果显示 UNKNOWN 或者启动后马上掉线大概率是端口被占用第 4 章会展开说。3.3 EXTRACT 抽取进程参数文件和注册MGR 就绪后配置抽取进程。这里以同步 HR 用户下的 EMPLOYEES 和 DEPARTMENTS 两张表为例。在 GGSCI 里执行edit params EORA文件名就是进程名写参数EXTRACT EORA USERID ogg, PASSWORD ogg123 EXTTRAIL ./dirdat/et TABLE HR.EMPLOYEES; TABLE HR.DEPARTMENTS;第一行声明进程名必须和文件名一致。USERID 是数据库账号密码OGG 会用它连接源库读取日志解析数据。这里直接明文写密码是简化做法如果公司安全规范不允许可以改用 USERIDALIAS 配合 credential store需先执行 ADD CREDENTIALSTORE 相关命令。EXTTRAIL 指定本地 trail 文件的前缀和路径./dirdat/et 会生成 dirdat 目录下 et000000、et000001 这样递增的文件。TABLE 参数决定同步范围支持通配写法比如TABLE HR.*同步整个 schema也支持排除指定表。写完之后要注册进程这一步比写参数容易漏GGSCI ADD EXTRACT EORA, TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL ./dirdat/et, EXTRACT EORAADD EXTRACT 才是正式创建进程并生成检查点文件的地方。TRANLOG 表示该进程从日志抽取BEGIN NOW 表示从当前日志位置开始捕获。ADD EXTTRAIL 把 trail 文件和抽取进程绑定这样 OGG 才知道抽取出来的数据写到哪里。很多人写完了参数直接 start然后报找不到检查点文件就是因为跳过了 ADD 这一步。这个坑在第 4 章还会细讲。3.4 REPLICAT 投递进程MAP 语法的对端映射抽取进程负责从日志抓数据写 trailREPLICAT 负责从 trail 读数据并在目标端应用。编辑参数文件 RORA.prmREPLICAT RORA USERID ogg, PASSWORD ogg123 ASSUMETARGETDEFS DISCARDFILE ./dirrpt/RORA.dsc, APPEND, MEGABYTES 100 MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES; MAP HR.DEPARTMENTS, TARGET HR.DEPARTMENTS;ASSUMETARGETDEFS 表示两端表结构完全一致不需要额外生成 def 文件。这个参数省事但有个前提两端表的列名、列顺序、数据类型必须一模一样。如果做过字段变更或目标端表结构有调整就别用这个参数改用 DEFGEN 工具生成定义文件。DISCARDFILE 是出错记录文件处理不了的数据会写在这里MEGABYTES 100 限制最大 100MB防止错误数据无限堆积。MAP 是核心语法格式是MAP 源schema.源表, TARGET 目标schema.目标表。同名同步是最简写法跨库跨 schema 时写成MAP HR.EMPLOYEES, TARGET REPORTDB.HR_EMPLOYEES;即可。REPLICAT 也支持通配比如MAP HR.*, TARGET HR.*;但要注意通配符会圈进来你们可能不想同步的表。注册命令GGSCI ADD REPLICAT RORA, EXTTRAIL ./dirdat/et, BEGIN NOW注意 EXTTRAIL 路径要和抽取进程写的一致REPLICAT 从同一个 trail 目录读文件。如果路径写错启动 replicat 时它发现队列里没有内容可读进程状态会显示 RUNNING 但延迟一直在增长。3.5 启动顺序和第一步验证三个角色都配好之后启动顺序有讲究必须是 MGR → EXTRACT → REPLICATGGSCI start mgr GGSCI start extract EORA GGSCI start replicat RORA GGSCI info allinfo all 会列出所有进程的状态、位置和延迟。正常状态是 MGR、EXTRACT、REPLICAT 都是 RUNNING延迟显示 00:00:00。如果 EXTRACT 状态是 ABENDED立刻执行view report EORA看报告文件尾部错误原因会写在那里。最常出现在报告里的问题是权限不足、表不存在、或者参数拼写错误。链路验证不要只盯着进程状态。在源库执行一条 UPDATE然后到目标端查数据是否同步过来。也可以在 GGSCI 里执行stats extract EORA看捕获了多少 DML 操作和实际执行的操作数对比能快速确认链路是不是真的在跑。4. 常见问题排查与避坑记录Windows 版 OGG 的五个高发现场4.1 MGR 端口冲突启动即失败或远程连不上现象执行 start mgr 后过了几秒 info mgr 显示 UNKNOWN或者 MGR 进程在但远程投递始终连不上。检查 Windows 事件日志也看不出明显报错。原因7809 端口已被其他进程占用最常见的是服务器上已经跑了一个 OGG 实例或者防火墙没有放行该端口。Windows 2003 自带防火墙对入站连接的拦截有时不弹提示直接丢包表现就是远程连不上而本机完全正常。解决先执行netstat -ano | findstr 7809看返回结果里有没有 LISTENING 状态的其他 PID。有的话确认是不是旧 OGG 实例是则停掉旧 MGR 或改新实例端口。没有占用的话检查防火墙入站规则放行 7809 和动态端口段 7810-7820。改完端口后重启 MGR再执行 info mgr 确认状态。4.2 start extract 报 OGG-00446找不到检查点文件现象参数文件和数据库权限都确认过没问题start extract EORA 报 ERROR OGG-00446提示无法打开检查点文件。原因检查点文件不是自动生成的而是 ADD EXTRACT 命令创建进程时生成的存放在 dirchk 目录下。跳过 ADD 直接 start或者 dirchk 目录被误删、被清理工具手动删除都会导致这个错误。还有一个隐蔽场景进程之前删除过参数文件还在但检查点已经不存在了。解决确认 dirchk 目录存在。如果进程从未成功注册过执行ADD EXTRACT EORA, TRANLOG, BEGIN NOW重新注册。如果进程之前存在先DELETE EXTRACT EORA把残留进程信息删干净再重新 ADD。注意 DELETE 之后参数文件不会丢但检查点位置会重置同步起点会变成当前日志位置需要评估业务上是否能接受。4.3 目标端中文乱码全部变成问号现象表结构同步正常数字和英文都对但中文数据同步到目标端全部变成 ??或者显示为乱码字符。原因NLS_LANG 环境变量与源库实际字符集不一致。GGSCI 启动时读取 NLS_LANG 的值去解释日志中的字符编码配错了日志里的中文按错误字符集解析写入目标端自然就是乱码。解决先查源库字符集执行SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETERNLS_CHARACTERSET。如果返回 ZHS16GBK环境变量配成AMERICAN_AMERICA.ZHS16GBK如果返回 AL32UTF8配成AMERICAN_AMERICA.AL32UTF8。改完环境变量后重启 extract 和 replicat 进程光改不重启不生效。还有一点这个环境变量要写在系统环境变量里不要在命令行窗口临时 set因为 OGG 服务进程运行时不会继承命令行窗口的变量。4.4 dirdat 队列文件疯长磁盘被写满现象dirdat 目录下 et 开头文件越来越多磁盘可用空间快速下降。查看 trail 文件生成时间发现旧文件一直没被清理。原因MGR.prm 里没配 PURGEOLDEXTRACTS或者 replicat 进程停止了一天以上导致 trail 文件堆积。OGG 清理 trail 文件的机制是只清理所有进程都已消费过的文件如果 replicat 停了EXTRACT 还在持续写旧文件永远不会被清理。解决在 MGR.prm 里补上PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 6。USECHECKPOINTS 是关键它让清理逻辑基于检查点而非时间戳不会误删还没投递的文件。同时查看 replicat 状态如果它已经 lag 了几个小时考虑是让它追日志还是重新初始化。追一个超大 lag 往往比重建链路更慢实际工作中很多人在这上面浪费了大半天最后发现删掉 replicat 重新初始化反而半小时搞定。4.5 Windows 重启后进程不自动拉起现象服务器重启后MGR 有时在跑但 extract 和 replicat 全部是 DOWN 状态数据同步中断。业务方没发现等发现时已经 lag 了几小时。原因OGG 的进程默认不是 Windows 服务MGR 没启动就不会有 AUTOSTART 的动作。即使 MGR 在跑如果环境变量只配在命令行窗口级别服务和进程读取不到 NLS_LANG、OGG_HOME也会出现启动失败。解决用 ggsvc 把 MGR 注册成 Windows 服务执行ggsvc -install后设置服务为自动启动。服务登录账号用本地管理员账户。把 OGG_HOME、PATH、NLS_LANG 写进系统环境变量。MGR.prm 里保留 AUTOSTART 和 AUTORESTART 参数。这样 Windows 开机后服务自动拉起 MGRMGR 再自动拉起所有抽取和投递进程。部署完我一般会专门重启一次服务器验证这个链路避免现场翻车。5. 用 GGSCI 做链路体检延迟、队列和统计一个都别漏链路跑通之后不要急着收工我用 GGSCI 里的几组命令给整套环境做一次全面体检。这些命令组合起来的逻辑是先看进程状态再看延迟再对比统计数字最后确认队列消费正常。GGSCI info all GGSCI lag extract EORA GGSCI lag replicat RORA GGSCI stats extract EORA, totalsonly GGSCI stats replicat RORA, totalsonlyinfo all 看的是每个进程是否 RUNNING以及进程后面的延迟字段。lag extract 和 lag replicat 分别查看源端抽取和投递端的落后秒数正常应该在 00:00:00 到 00:00:05 之间。stats 命令带 totalsonly 参数会输出进程启动以来处理过的 Insert、Update、Delete 总数拿源端实际执行的操作数和这个数字对比能快速判断链路是否有丢数据。还有一个容易被忽略的点trail 队列文件的消费确认。进入 dirdat 目录看正在写的文件序号再到目标端看 replicat 的报告确认它读到了哪个序号的文件。两个序号之间的差距就是队列积压量。PURGEOLDEXTRACTS 只清理已经消费完的文件如果发现旧文件一直存在没被清理说明消费侧可能卡住了而不是磁盘规划的问题。最后补一个 count 对比技巧在 GGSCI 里分别源端和目标端执行COUNT * FROM HR.EMPLOYEES对比总行数一致基本可以确认数据完整性。这个命令不用额外装工具比写 SQL 脚本方便。我第一次部署这套 11.2.1.0.3 时就是忽略了 lag 和 stats 的交叉验证只看 info all 全是 RUNNING 就交工了结果第二天发现投递端的队列已经堆积了好几个小时。从那以后任何环境的 OGG 部署完成我强制把 info all、lag、stats、队列文件序号这四步过一遍再收工省得半夜被电话吵醒去现场查一个本来十分钟就能发现的问题。希望帮到你。本文还有配套的精品资源点击获取 Windows 下 GoldenGate 11.2.1.0.3 同步部署与排障
简介面向Oracle 11g数据库运维与开发人员这份Oracle GoldenGate 11.2.1.0.3版安装包专门解决Windows x64环境下的实时数据同步与迁移问题。包内含GoldenGate核心组件从抽取、传输到复制均有对应程序并提供管理控制工具。资源共185个文件压缩包大小34.1MB其中52个jar支撑Java代理38个sql为数据库配置脚本17个exe为可执行程序12个dll包含ICU、Xerces等依赖库另有大量txt、xml、properties等参数文件可满足部署、调优和故障排查需求。目前已有1408人学习或下载适合需要快速掌握GoldenGate基础架构的数据库管理人员。通过此安装包可获得完整组件清单与运行库明显降低自建实验环境收集依赖的时间成本配合官方文档即可完成环境搭建、进程配置和数据一致性验证并了解数据抽取、传输与复制链路的工作机制是学习和部署该版本GoldenGate的实用参考。1. GoldenGate 11.2.1.0.3 在 Windows 上的真实分量老库同步绕不开的版本还在找 Oracle GoldenGate 11.2.1.0.3 for Oracle 11g Windows x64 的多半不是追新而是被存量系统绑住了。不少企业内部跑着 Oracle 11g 的 Windows Server 2003/2008 主机数据库升级排不上日程但同步链路又必须稳定于是这个老版本反而成了刚需。它能解决什么问题简单说在 Windows x64 上搭一套完整的抽取、投递、复制链路支撑数据容灾、报表库分发、生产库到查询库的实时同步。适合三类人维护老库的 DBA、做数据迁移或灾备的工程师、刚接手旧项目需要快速上手的实施新人。这个版本不炫技但用对了很稳前提是你知道介质怎么校验、参数怎么配、以及 Windows 平台上那些藏得比较深的坑。2. 安装前的准备介质校验、目录规划与 Windows 2003 的兼容性边界2.1 先看清解压出来的东西是什么GoldenGate 11.2.1.0.3 在 Windows 上不是传统的 run installer 安装方式而是解压即用。解压后你会看到几个关键目录和可执行文件dirprm 放参数文件dirdat 放 trail 队列文件dirchk 放检查点文件dirrpt 放运行报告和 discard 文件另外还有 ggsci.exe、ggsvc.exe 两个核心工具。ggsci 是主交互命令行进去之后所有进程管理、参数编辑、状态查看都从这里做ggsvc 负责把 OGG 注册成 Windows 服务方便开机自启。我一般拿到介质先做两件事一是核对解压后的文件是否完整少了 ggsci.exe 或 Lib 目录基本没法跑二是确认路径里没有中文和空格。路径带空格在 Windows 2003 上会引发非常诡异的问题比如 GGSCI 能启动但参数文件读取不到或者投递进程连不上远端。排查半天发现是路径问题属于那种最不值得踩的坑。介质解压目录不要放在 Oracle 数据库软件目录下独立建一个目录管理起来更清爽。2.2 目录规划队列文件别放 C 盘OGG 的磁盘消耗大头在 dirdat 目录下的 trail 文件文件命名类似 et000000、et000001 这种按序号递增。队列文件的增长速度很容易被低估特别是抽取大表或业务高峰时段一小时写几百 MB 到几个 GB 都很正常。所以目录规划的第一个原则dirdat 独立放一个磁盘别和系统盘挤在一起。系统盘满了不只是 OGG 挂掉Windows 本身也会出各种连锁问题。目录用途注意事项D:\OGGOGG 安装根目录路径不要带空格和中文D:\OGG\dirprm存放 MGR、EXTRACT、REPLICAT 参数文件文件名与进程名对应D:\OGG\dirdattrail 队列文件独立磁盘预留足够余量D:\OGG\dirrpt运行报告和 discard 文件定期清理避免日志爆盘D:\OGG\dirchk检查点文件不要手动删除删了等于进程白干另一个常见做法是给 OGG_HOME 单独设一个环境变量后续写脚本、配服务都引用这个变量。命令行窗口里临时设置只对当前会话有效如果 OGG 要注册成服务服务进程不会读取命令行里 set 出来的变量必须写到系统环境变量里。这个区别在 Windows 2003 上尤其明显先记着第 4 章会专门讲。2.3 环境变量和系统级准备在启动 GGSCI 之前先把三个环境变量配好set NLS_LANGAMERICAN_AMERICA.ZHS16GBK set OGG_HOMED:\OGG set PATH%OGG_HOME%;%PATH%NLS_LANG 三个段分别是语言、地域、字符集。字符集必须和源库一致否则后面同步中文数据必乱码。怎么确认源库字符集登录数据库执行SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETERNLS_CHARACTERSET看返回结果是 ZHS16GBK 还是 AL32UTF8然后把 NLS_LANG 第三段配成对应的值。Windows 2003 上还有一个隐藏依赖这个版本的 OGG 编译期依赖老版 VC 运行库。如果你在全新系统上安装启动 ggsci 时报找不到 MSVCR71.dll 或类似错误装一个 Visual C 2005/2008 运行库就能解决。2013 运行库不一定兼容老版本别装错了。最后就是防火墙MGR 默认监听 7809 端口动态端口列表里的 7810-7820 也要放行否则远程投递链路会在没有任何报错的情况下频繁断连表现成一种黑匣子式的故障。提示这份介质明确标注 for Oracle 11g Windows x64只用于 11g 和对应的 Windows x64 环境。生产库如果是 19c 或 Linux 平台别用这个版本版本错配带来的问题比不配 OGG 还麻烦。3. 从 MGR 到 EXTRACT 再到 REPLICAT把第一条同步链路跑起来3.1 数据库侧先做两件事补充日志和归档OGG 抽取依赖数据库日志所以数据库侧的前置条件比 OGG 自身安装更关键。以 DBA 权限执行下面三条ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE FORCE LOGGING; SELECT LOG_MODE, SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;补充日志的作用是让日志里记录足够的前镜像信息。没有它UPDATE 操作在目标端可能无法定位到正确的行导致更新出错或跳过。FORCE LOGGING 则是强制所有操作都写日志避免某些 nologging 操作产生的数据变更在日志里缺失。查询返回的 LOG_MODE 应该是 ARCHIVELOGSUPPLEMENTAL_LOG_DATA_MIN 应该是 YES。如果数据库还在 NOARCHIVELOG 模式那 OGG 根本没有数据来源先切归档模式再说。这两步做完之后还要建一个专门给 OGG 用的数据库用户赋予必要的权限。11g 里常见的做法是给用户授予 CONNECT、RESOURCE再单独授予 SELECT ANY TABLE以及 SELECT 相关数据字典视图的权限。参数文件里的 USERID 就用这个用户。有人图省事直接用 SYSTEM 账号我不建议后期审计和权限收口都麻烦。3.2 初始化目录并在 GGSCI 里启动 MGR打开命令行切到 OGG 根目录执行ggsci进入交互界面。第一次进来先执行create subdirs会自动把 dirprm、dirdat、dirrpt、dirchk 这些标准目录全部建好。然后编辑 MGR 的参数文件GGSCI create subdirs GGSCI edit params mgr在打开的 MGR.prm 里写PORT 7809 DYNAMICPORTLIST 7810-7820 AUTOSTART ER * AUTORESTART ER *, RETRIES 3, WAITMINUTES 5 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 6逐个解释。PORT 是 MGR 的固定监听端口默认 7809被占用就换。DYNAMICPORTLIST 是 MGR 向外发起连接时使用的动态端口范围源端和目标端防火墙都要放行这一段。AUTOSTART 让 MGR 一启动就自动拉起所有 extract 和 replicat 进程省得每次重启手动 start。AUTORESTART 是进程异常退出后的自动恢复机制RETRIES 3 表示最多重试三次WAITMINUTES 5 表示每次间隔五分钟。PURGEOLDEXTRACTS 是 trail 文件的自动清理开关USECHECKPOINTS 表示按检查点判断哪些文件已经不被需要MINKEEPHOURS 6 表示至少保留最近六小时的文件。有很多人不敢配 PURGEOLDEXTRACTS怕误删没投递完的队列。实际上 USECHECKPOINTS 参数保证只清理已确认投递完成的 trail 文件比手动清理安全得多。我当时第一次部署就没配结果 dirdat 在业务高峰期一天写了几十 GB差点把磁盘撑爆。这个参数配好之后基本可以放手。参数保存退出然后启动 MGRGGSCI start mgr GGSCI info mgrinfo mgr 显示 RUNNING 才算正常。如果显示 UNKNOWN 或者启动后马上掉线大概率是端口被占用第 4 章会展开说。3.3 EXTRACT 抽取进程参数文件和注册MGR 就绪后配置抽取进程。这里以同步 HR 用户下的 EMPLOYEES 和 DEPARTMENTS 两张表为例。在 GGSCI 里执行edit params EORA文件名就是进程名写参数EXTRACT EORA USERID ogg, PASSWORD ogg123 EXTTRAIL ./dirdat/et TABLE HR.EMPLOYEES; TABLE HR.DEPARTMENTS;第一行声明进程名必须和文件名一致。USERID 是数据库账号密码OGG 会用它连接源库读取日志解析数据。这里直接明文写密码是简化做法如果公司安全规范不允许可以改用 USERIDALIAS 配合 credential store需先执行 ADD CREDENTIALSTORE 相关命令。EXTTRAIL 指定本地 trail 文件的前缀和路径./dirdat/et 会生成 dirdat 目录下 et000000、et000001 这样递增的文件。TABLE 参数决定同步范围支持通配写法比如TABLE HR.*同步整个 schema也支持排除指定表。写完之后要注册进程这一步比写参数容易漏GGSCI ADD EXTRACT EORA, TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL ./dirdat/et, EXTRACT EORAADD EXTRACT 才是正式创建进程并生成检查点文件的地方。TRANLOG 表示该进程从日志抽取BEGIN NOW 表示从当前日志位置开始捕获。ADD EXTTRAIL 把 trail 文件和抽取进程绑定这样 OGG 才知道抽取出来的数据写到哪里。很多人写完了参数直接 start然后报找不到检查点文件就是因为跳过了 ADD 这一步。这个坑在第 4 章还会细讲。3.4 REPLICAT 投递进程MAP 语法的对端映射抽取进程负责从日志抓数据写 trailREPLICAT 负责从 trail 读数据并在目标端应用。编辑参数文件 RORA.prmREPLICAT RORA USERID ogg, PASSWORD ogg123 ASSUMETARGETDEFS DISCARDFILE ./dirrpt/RORA.dsc, APPEND, MEGABYTES 100 MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES; MAP HR.DEPARTMENTS, TARGET HR.DEPARTMENTS;ASSUMETARGETDEFS 表示两端表结构完全一致不需要额外生成 def 文件。这个参数省事但有个前提两端表的列名、列顺序、数据类型必须一模一样。如果做过字段变更或目标端表结构有调整就别用这个参数改用 DEFGEN 工具生成定义文件。DISCARDFILE 是出错记录文件处理不了的数据会写在这里MEGABYTES 100 限制最大 100MB防止错误数据无限堆积。MAP 是核心语法格式是MAP 源schema.源表, TARGET 目标schema.目标表。同名同步是最简写法跨库跨 schema 时写成MAP HR.EMPLOYEES, TARGET REPORTDB.HR_EMPLOYEES;即可。REPLICAT 也支持通配比如MAP HR.*, TARGET HR.*;但要注意通配符会圈进来你们可能不想同步的表。注册命令GGSCI ADD REPLICAT RORA, EXTTRAIL ./dirdat/et, BEGIN NOW注意 EXTTRAIL 路径要和抽取进程写的一致REPLICAT 从同一个 trail 目录读文件。如果路径写错启动 replicat 时它发现队列里没有内容可读进程状态会显示 RUNNING 但延迟一直在增长。3.5 启动顺序和第一步验证三个角色都配好之后启动顺序有讲究必须是 MGR → EXTRACT → REPLICATGGSCI start mgr GGSCI start extract EORA GGSCI start replicat RORA GGSCI info allinfo all 会列出所有进程的状态、位置和延迟。正常状态是 MGR、EXTRACT、REPLICAT 都是 RUNNING延迟显示 00:00:00。如果 EXTRACT 状态是 ABENDED立刻执行view report EORA看报告文件尾部错误原因会写在那里。最常出现在报告里的问题是权限不足、表不存在、或者参数拼写错误。链路验证不要只盯着进程状态。在源库执行一条 UPDATE然后到目标端查数据是否同步过来。也可以在 GGSCI 里执行stats extract EORA看捕获了多少 DML 操作和实际执行的操作数对比能快速确认链路是不是真的在跑。4. 常见问题排查与避坑记录Windows 版 OGG 的五个高发现场4.1 MGR 端口冲突启动即失败或远程连不上现象执行 start mgr 后过了几秒 info mgr 显示 UNKNOWN或者 MGR 进程在但远程投递始终连不上。检查 Windows 事件日志也看不出明显报错。原因7809 端口已被其他进程占用最常见的是服务器上已经跑了一个 OGG 实例或者防火墙没有放行该端口。Windows 2003 自带防火墙对入站连接的拦截有时不弹提示直接丢包表现就是远程连不上而本机完全正常。解决先执行netstat -ano | findstr 7809看返回结果里有没有 LISTENING 状态的其他 PID。有的话确认是不是旧 OGG 实例是则停掉旧 MGR 或改新实例端口。没有占用的话检查防火墙入站规则放行 7809 和动态端口段 7810-7820。改完端口后重启 MGR再执行 info mgr 确认状态。4.2 start extract 报 OGG-00446找不到检查点文件现象参数文件和数据库权限都确认过没问题start extract EORA 报 ERROR OGG-00446提示无法打开检查点文件。原因检查点文件不是自动生成的而是 ADD EXTRACT 命令创建进程时生成的存放在 dirchk 目录下。跳过 ADD 直接 start或者 dirchk 目录被误删、被清理工具手动删除都会导致这个错误。还有一个隐蔽场景进程之前删除过参数文件还在但检查点已经不存在了。解决确认 dirchk 目录存在。如果进程从未成功注册过执行ADD EXTRACT EORA, TRANLOG, BEGIN NOW重新注册。如果进程之前存在先DELETE EXTRACT EORA把残留进程信息删干净再重新 ADD。注意 DELETE 之后参数文件不会丢但检查点位置会重置同步起点会变成当前日志位置需要评估业务上是否能接受。4.3 目标端中文乱码全部变成问号现象表结构同步正常数字和英文都对但中文数据同步到目标端全部变成 ??或者显示为乱码字符。原因NLS_LANG 环境变量与源库实际字符集不一致。GGSCI 启动时读取 NLS_LANG 的值去解释日志中的字符编码配错了日志里的中文按错误字符集解析写入目标端自然就是乱码。解决先查源库字符集执行SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETERNLS_CHARACTERSET。如果返回 ZHS16GBK环境变量配成AMERICAN_AMERICA.ZHS16GBK如果返回 AL32UTF8配成AMERICAN_AMERICA.AL32UTF8。改完环境变量后重启 extract 和 replicat 进程光改不重启不生效。还有一点这个环境变量要写在系统环境变量里不要在命令行窗口临时 set因为 OGG 服务进程运行时不会继承命令行窗口的变量。4.4 dirdat 队列文件疯长磁盘被写满现象dirdat 目录下 et 开头文件越来越多磁盘可用空间快速下降。查看 trail 文件生成时间发现旧文件一直没被清理。原因MGR.prm 里没配 PURGEOLDEXTRACTS或者 replicat 进程停止了一天以上导致 trail 文件堆积。OGG 清理 trail 文件的机制是只清理所有进程都已消费过的文件如果 replicat 停了EXTRACT 还在持续写旧文件永远不会被清理。解决在 MGR.prm 里补上PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 6。USECHECKPOINTS 是关键它让清理逻辑基于检查点而非时间戳不会误删还没投递的文件。同时查看 replicat 状态如果它已经 lag 了几个小时考虑是让它追日志还是重新初始化。追一个超大 lag 往往比重建链路更慢实际工作中很多人在这上面浪费了大半天最后发现删掉 replicat 重新初始化反而半小时搞定。4.5 Windows 重启后进程不自动拉起现象服务器重启后MGR 有时在跑但 extract 和 replicat 全部是 DOWN 状态数据同步中断。业务方没发现等发现时已经 lag 了几小时。原因OGG 的进程默认不是 Windows 服务MGR 没启动就不会有 AUTOSTART 的动作。即使 MGR 在跑如果环境变量只配在命令行窗口级别服务和进程读取不到 NLS_LANG、OGG_HOME也会出现启动失败。解决用 ggsvc 把 MGR 注册成 Windows 服务执行ggsvc -install后设置服务为自动启动。服务登录账号用本地管理员账户。把 OGG_HOME、PATH、NLS_LANG 写进系统环境变量。MGR.prm 里保留 AUTOSTART 和 AUTORESTART 参数。这样 Windows 开机后服务自动拉起 MGRMGR 再自动拉起所有抽取和投递进程。部署完我一般会专门重启一次服务器验证这个链路避免现场翻车。5. 用 GGSCI 做链路体检延迟、队列和统计一个都别漏链路跑通之后不要急着收工我用 GGSCI 里的几组命令给整套环境做一次全面体检。这些命令组合起来的逻辑是先看进程状态再看延迟再对比统计数字最后确认队列消费正常。GGSCI info all GGSCI lag extract EORA GGSCI lag replicat RORA GGSCI stats extract EORA, totalsonly GGSCI stats replicat RORA, totalsonlyinfo all 看的是每个进程是否 RUNNING以及进程后面的延迟字段。lag extract 和 lag replicat 分别查看源端抽取和投递端的落后秒数正常应该在 00:00:00 到 00:00:05 之间。stats 命令带 totalsonly 参数会输出进程启动以来处理过的 Insert、Update、Delete 总数拿源端实际执行的操作数和这个数字对比能快速判断链路是否有丢数据。还有一个容易被忽略的点trail 队列文件的消费确认。进入 dirdat 目录看正在写的文件序号再到目标端看 replicat 的报告确认它读到了哪个序号的文件。两个序号之间的差距就是队列积压量。PURGEOLDEXTRACTS 只清理已经消费完的文件如果发现旧文件一直存在没被清理说明消费侧可能卡住了而不是磁盘规划的问题。最后补一个 count 对比技巧在 GGSCI 里分别源端和目标端执行COUNT * FROM HR.EMPLOYEES对比总行数一致基本可以确认数据完整性。这个命令不用额外装工具比写 SQL 脚本方便。我第一次部署这套 11.2.1.0.3 时就是忽略了 lag 和 stats 的交叉验证只看 info all 全是 RUNNING 就交工了结果第二天发现投递端的队列已经堆积了好几个小时。从那以后任何环境的 OGG 部署完成我强制把 info all、lag、stats、队列文件序号这四步过一遍再收工省得半夜被电话吵醒去现场查一个本来十分钟就能发现的问题。希望帮到你。本文还有配套的精品资源点击获取