★ FEATURED ARTICLE 简介面向Oracle DBA与数据同步实施人员的一份OGG部署实操文档聚焦Windows源库向Linux目标库进行Oracle GoldenGate 12.2.0.2数据同步的完整落地过程。压缩包仅含1个PDF文件约496KB篇幅精炼适合按章节查阅与实验对照。内容覆盖源库归档、强制日志与附加日志开启goldengate用户及权限配置目标库授权差异OGG解压与可视化安装、子目录初始化、GLOBALS与checkpoint表设置以及Manager、Extractor、Replicat组件配置要点同时给出监控、日志管理与故障排查思路便于读者搭建跨平台同步链路并定位常见配置问题。已有298人学习可作为异构环境数据复制入门与部署排错的参考材料。1. 从 Windows 到 Linux 的数据同步OGG 这套链路到底怎么搭生产库跑在一台 Windows 机器的 Oracle 实例上报表侧要整体搬到 Linux 的新机器中间只给了 4 小时停机窗口——这种局面下指望全量导入再追一次增量基本等于赌运气。我头一回接 oracle linux OGG 数据同步这类需求时也怀疑过跨操作系统能不能直接复制实际搭完才确认OGG 的抽取端只读源库 redo 与归档日志复制端只认 trail 文件和 SQL操作系统差异被 trail 这层抽象吃掉了Windows 到 Linux 是它的常规用法不是偏门场景。这套链路的现实价值很直接不停机把增量持续送到目标端中途出错还能按 SCN 回退重放而不是推倒重来。它适合手上已经有 OGG 安装介质、要自己完整落地一次的 DBA 和后端工程师也适合已经在跑 OGG、却被跨平台参数和端口规划绊过的人。下面按“库要调成什么样 → 软件怎么装 → 进程怎么配 → 初始化怎么对齐 → 哪儿最容易翻车”的顺序拆。2. 数据库侧先调成“能抽日志”的状态四个开关与一套账号权限OGG 抽取不是定时查表它读的是源库的在线 redo 和归档日志。所以数据库这一层没配置到位后面进程参数写得再漂亮也跑不起来。这一章把源库、目标库分别要做什么讲清楚重点是几个容易只做一半的地方归档开了但强制日志没开、附加日志加了但没切日志生效、12c 的参数在 11g 上根本不存在。2.1 源库四个开关归档、force logging、附加日志、enable_goldengate_replicationWindows 源库这一侧先用 sysdba 登录确认现状再决定改哪几个。归档模式是地基没开归档就没有可读的历史日志强制日志是为了堵住 nologging 操作的漏洞——直接路径插入、索引 rebuild 这类操作在 nologging 下不写 redoOGG 抽不到对应行目标端就会出现“数据少了一截但进程一切正常”的玄学现象数据库级附加日志是给后续表级 trandata 打底。-- 1) 先看现状已经在归档模式就跳过切换步骤 archive log list; -- 2) 未归档时开启需要重启到 mount 状态 shutdown immediate; startup mount; alter database archivelog; alter database open; -- 3) 强制记录日志防止 nologging 操作绕过 redo alter database force logging; -- 4) 数据库级最小附加日志表级 trandata 依赖它 alter database add supplemental log data; -- 5) 12c 及以上才有的开关11g 执行会报 ORA-02065 alter system set enable_goldengate_replication true scopeboth;这段里最需要留意的是第 5 条。这条语句是 12.2 之后才引入的如果源库还是 11.2.0.4敲下去直接报 ORA-02065 无效选项不用慌跳过即可11g 没有这个开关也能正常抽取。很多照抄脚本的人在这一步以为环境有问题反复重装其实只是版本差异。第 4 条执行完必须切一次日志附加日志才会对后续的 redo 生效-- 附加日志对后续 redo 生效 alter system switch logfile; -- 确认结果两列都应该是 YES select SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING from v$database;SUPPLEMENTAL_LOG_DATA_MIN为 YES 表示最小附加日志已开FORCE_LOGGING为 YES 表示强制日志已开。RAC 环境下alter system switch logfile只切当前实例换成alter system archive log current更稳妥。另外别忘了看一眼归档空间抽取进程依赖日志留存空间满了归档写不进去抽取会直接卡死-- 归档空间水位超过 80% 就要提前扩容或调整保留策略 select * from v$flash_recovery_area_usage; select name, space_limit/1024/1024 mb_limit, space_used/1024/1024 mb_used from v$recovery_file_dest;2.2 目标库为什么只做一半附加日志、force logging 都不是它的事目标库的角色是“被写入”它不产生需要被抽取的日志所以附加日志、表级 trandata、force logging 在目标端统统不需要。这一点是新手最容易做冗余的地方看到源库脚本就整段复制过去执行倒也不会报错但会白白让目标库多写一份补充日志日志量上涨恢复和备份成本跟着涨。真正需要在目标库做的是账号权限和 12c 的那个开关。目标库的复制进程要用 DML 语句往业务表里写数据因此除了常规的连接、会话权限还要额外给insert any table, update any table, delete any table。有些环境图省事给了 DBA 角色测试阶段没问题上生产之后审计大概率过不去还是按最小权限来。配置项Windows 源库Linux 目标库归档模式必须开启建议开启便于恢复与闪回force logging必须开启不需要数据库级附加日志必须开启不需要表级 add trandata每张同步表都要加不需要DML any table 权限不需要必须授予enable_goldengate_replication12c 及以上必须12c 及以上必须表里这一行“归档建议开启”不是套话。目标库一旦被误操作没有归档就只能全量重来而全量重来的代价是又一次几小时的停机窗口这笔账怎么算都不划算。2.3 goldengate 账号表空间、建用户与 grant_admin_privilege 到底做了什么两端各建一个专用账号别用业务用户也别用 sys。表空间给 300M 起步、自动扩展checkpoint 表和 trail 元数据都放在这里。建完用户之后有一句关键调用dbms_goldengate_auth.grant_admin_privilege它一次性把 OGG 需要的那些dbms_*包执行权限、若干v$与dba_视图的查询权限打包授予比手工一条条 grant 靠谱得多。-- 源库和目标库都要执行路径按各自环境改 create tablespace goldengate datafile /u01/app/oracle/oradata/test1/ogg01.dbf size 300m autoextend on; create user goldengate identified by goldengate default tablespace goldengate; grant connect, resource, create session, alter session to goldengate; grant flashback any table to goldengate; -- 打包授予 OGG 管理员所需权限 exec dbms_goldengate_auth.grant_admin_privilege(GOLDENGATE); -- 仅目标库需要复制进程要能往任意业务表写数据 grant insert any table, update any table, delete any table to goldengate; -- 两端都开11g 跳过这一句 alter system set enable_goldengate_replication true scopeboth;flashback any table这个权限容易被忽略。它的用途是当日志里信息不足、或者需要按 SCN 做一致性查询时OGG 能直接闪回读表。少了它某些一致性校验场景会失败报错信息还很不直观。有一点要提醒grant_admin_privilege里的用户名必须大写。Oracle 默认用户名大小写不敏感但这个包的入参是字符串小写传进去会找不到用户。类似的坑在后面 GLOBALS 文件里的GGSCHEMA也会遇到——那里恰恰要写小写因为它是实际存储的 schema 名。这两种写法不一致是很多人第一次部署时反复卡住的地方。2.4 上线前自检三条 SQL 加一个视图配置做完不要急着装软件先把这几项确认一遍能省掉后面大量排查时间。自检的核心是确认“日志真的能抽”而不是“我以为开了”。-- 1) 归档与附加日志状态 select log_mode, SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI from v$database; -- 2) 12c 参数是否生效 show parameter enable_goldengate_replication; -- 3) 账号权限是否被正确授予 select * from dba_goldengate_privileges where grantee GOLDENGATE;第三条查的是dba_goldengate_privileges这个视图能直接看到grant_admin_privilege到底授了哪些权限。如果视图查出来是空的说明那句 exec 没执行成功或者用户名传成了小写。源库 Windows 侧还要顺手确认归档目标路径所在磁盘的剩余空间跨平台同步的日志量往往比预估的大尤其是首次全量期间抽取进程并发读日志归档生成速度会明显上升。3. 两端安装与 GGSCI 初始化Windows 图形安装、Linux 静默解压、MGR 参数一行都别省安装这一步本身不难难点在于两端的环境差异Windows 那边是图形界面加服务注册Linux 这边是解压加图形安装器中间还夹着目录权限、环境变量和端口。我一般会把这一步拆成“装软件、建目录、配全局参数、起 MGR、验端口”五件事做完一件验一件别攒到最后一起调。3.1 Windows 源端图形安装、安装目录与 MGR 服务注册Windows 上的 OGG 介质是压缩包解压后进Disk1目录运行安装程序图形界面里要选对两件事一是目标数据库版本必须和本机ORACLE_HOME对应的版本一致选错了后面连库会报库版本不匹配二是安装目录路径里不要有空格、中文和特殊字符我见过装在D:\Program Files\ogg下面结果参数文件里的路径被空格截断进程起不来的情况。安装完成后用命令行进到安装目录启动 GGSCI第一件事是建子目录# Windows 命令行进入 OGG 安装目录 cd /d D:\ogg GGSCI # GGSCI 内部执行创建 dirprm/dirdat/dirrpt 等标准子目录 GGSCI create subdirscreate subdirs会在当前目录下建出一整套标准目录结构dirprm放参数文件、dirdat放 trail 文件、dirrpt放报告、dirchk放检查点。这一步两端都必须做漏了后面所有edit params都会失败。Windows 端还有一个容易被忽略的动作把 MGR 注册成系统服务。如果只是前台start mgr机器一重启抽取就停了而目标端复制进程还在正常跑表面上一切正常实际上延迟已经悄悄涨到几十小时。# 在 GGSCI 里把 MGR 注册为 Windows 服务随机器启动 GGSCI install add service注册成服务之后MGR 的运行身份要确认清楚建议用专用的系统账号而不是随便一个登录用户否则改密码之后服务起不来。3.2 Linux 目标端解压、runInstaller 与数据库版本对应关系Linux 这一侧是标准的解压加图形安装流程。用 oracle 用户操作不要用 root 装完再改属主权限问题会在后面以各种奇怪的方式冒出来。# 切换到 oracle 用户解压安装介质 su - oracle unzip 122022_fbo_ggs_Linux_x64_shiphome.zip # 进入 Disk1 目录执行安装器 cd fbo_ggs_Linux_x64_shiphome/Disk1 ./runInstallerrunInstaller是图形界面需要 DISPLAY 可用或者用 X11 转发。界面里最关键的一项同样是数据库版本选择它决定了 OGG 链接哪一套客户端库。选完之后指定安装目录一般放/u01/app/ogg安装器会自动把LD_LIBRARY_PATH相关配置写进环境脚本。装完补一下环境变量写进 oracle 用户的.bash_profile否则每次开新会话都要手工 export# 追加到 ~/.bash_profile export GG_HOME/u01/app/ogg export PATH$GG_HOME:$PATH export LD_LIBRARY_PATH$GG_HOME:$LD_LIBRARY_PATH装完之后同样进 GGSCI 执行create subdirs。如果执行时报目录已存在说明这个目录之前装过 OGG要么复用要么彻底清干净别在半残留的目录上继续配检查点文件残留会导致新进程起来就报错。3.3 GLOBALS、checkpoint 表与 MGR 进程参数GLOBALS 是全局参数文件两端都要配位置在 OGG 安装目录下文件名就叫GLOBALS没有后缀。它定义三件事OGG 用哪个 schema 存元数据、检查点表叫什么、要不要写系统日志。# GGSCI 内执行两端一致 GGSCI edit params ./GLOBALS文件内容三行GGSCHEMA goldengate CHECKPOINTTABLE goldengate.ggschkpt SYSLOG NONEGGSCHEMA这里写小写是因为它对应数据库中实际的 schema 名而前面grant_admin_privilege(GOLDENGATE)要大写是因为那是作为字符串参数传入的。这个大小写的不对称是 OGG 部署里最经典的一处不一致配错了表现是 GGSCI 登录成功但一加检查点就报找不到表。接着登录数据库并创建检查点表# 用 goldengate 账号登录数据库 GGSCI dblogin userid goldengate password goldengate # 在数据库里创建检查点表两端都要做 GGSCI add checkpointtable goldengate.ggschkpt检查点表记录的是每个进程读到哪个位置、写到哪个位置是断点续传的依据。它丢了复制进程就不知道该从哪儿接着来只能重头扫 trail 文件。MGR 是管理进程负责拉起其他进程、分配动态端口、清理过期 trail。参数里几行值得逐个讲# GGSCI edit params mgr PORT 7809 DYNAMICPORTLIST 7800-7810 USERID goldengate, PASSWORD goldengate AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60 LAGREPORTMINUTES 10 LAGCRITICALMINUTES 10 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 12 PURGEDDLHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 14, FREQUENCYHOURS 3 PURGEMARKERHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 14, FREQUENCYHOURS 3PORT 7809是 MGR 的固定监听端口DataPump 进程用RMTHOST ... MGRPORT 7809连过来所以两端这个端口必须一致且可达。DYNAMICPORTLIST是实际传数据的端口范围MGR 会从这个区间里挑一个给传输用——只开 7809 不开这段范围是跨机器部署最常见的“连上了但传不动”的原因。AUTORESTART让进程异常退出后自动拉起重试 3 次、间隔 5 分钟、60 分钟后重置计数避免进程疯狂重启刷日志。PURGEOLDEXTRACTS控制 trail 清理MINKEEPHOURS 12表示至少保留 12 小时这个值要和你的最大故障恢复窗口匹配配小了出事时想重放都没有文件。3.4 跨机器必须打通的端口与连通性验证Windows 源端到 Linux 目标端方向是源端主动连目标端所以要通的是目标端的 7809 加动态端口段。验证别只用 pingping 通不代表端口通。# Linux 侧确认 MGR 在监听 netstat -anp | grep 7809 # Windows 侧测试目标端端口PowerShell Test-NetConnection 10.0.100.141 -Port 7809如果 7809 通但动态端口段被防火墙挡了现象会非常迷惑DataPump 进程状态是 RUNNINGinfo datapump看不到报错但目标端dirdat目录里始终不出现新文件。这时候去看ggserr.log一般能找到重试连接的记录。所以规划阶段就把整段端口一起放行别只放一个 7809。4. 抽取、投递、复制三条进程参数逐行拆开配初始化按 SCN 对齐进程配置是这套方案的主体。源端两个进程Extract 抽日志、DataPump 传文件目标端一个进程Replicat 应用数据三条链路串起来。参数文件不是越长越好但每个参数背后都对应一个具体故障场景配的时候要知道它在防什么。4.1 源端 DDL 支持marker_setup、ddl_setup 与 add trandata如果只同步 DML这一段可以跳过但只要业务会加字段、建索引就必须配。DDL 同步依赖几个官方脚本在源端用 sysdba 依次执行-- 源端 sysdba 执行顺序不能乱 grant execute on utl_file to goldengate; /u01/app/ogg/marker_setup /u01/app/ogg/ddl_setup /u01/app/ogg/role_setup GRANT GGS_GGSUSER_ROLE TO goldengate; /u01/app/ogg/ddl_enable -- 提高 DDL 复制性能参数是 OGG 管理员的 schema 名 ?/rdbms/admin/dbmspool.sql /u01/app/ogg/ddl_pin goldengatemarker_setup建的是 DDL 标记表用来在 redo 里定位 DDL 语句ddl_setup建历史表和触发器role_setup建角色。三个脚本都要求用 sysdba 跑用普通账号会中途报权限不足。然后是表级附加日志。这一步决定 OGG 能不能拿到行级的完整前镜像# GGSCI 内登录后逐表添加 GGSCI dblogin userid goldengate password goldengate GGSCI add trandata test.t1add trandata有个硬性前提表上必须有主键或唯一索引。没有的话命令会直接拒绝这时候要么补主键要么显式指定列作为替代键。替代键的作用是过滤重复行选错了会出现更新丢失选列的原则是能唯一标识一行且更新频率低。4.2 Extract 进程从 redo 里抽增量写到本地 trailExtract 是源端的第一个进程读 redo 或归档日志把变更写成 trail 文件。参数如下# GGSCI edit param extgsxf EXTRACT extgsxf SETENV (ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SIDtest1) SETENV (NLS_LANGAMERICAN_AMERICA.AL32UTF8) USERID goldengate, PASSWORD goldengate EXTTRAIL ./dirdat/gs TRANLOGOPTIONS LOGRETENTION DISABLED BRINTERVAL 20M TRANLOGOPTIONS BUFSIZE 2048000 GETREPLICATES CACHEMGR CACHESIZE 2GB GETTRUNCATES DDL INCLUDE MAPPED, OBJTYPE TABLE INCLUDE MAPPED OBJTYPE INDEX DDLOPTIONS ADDTRANDATA RETRYOP RETRYDELAY 10 MAXRETRIES 10 DDLOPTIONS REPORT DISCARDFILE ./dirrpt/extgsxf.dsc, APPEND, MEGABYTES 1000 DISCARDROLLOVER AT 6:00 REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 1 HOURS, RATE FETCHOPTIONS FETCHPKUPDATECOLS REPORT AT 0:01 FETCHOPTIONS MISSINGROW ABEND STATOPTIONS REPORT FETCHWARN LONGTRANS 1H, CHECKINTERVAL 10m DYNAMICRESOLUTION TABLE test.*;几处关键点。SETENV里三行缺一不可ORACLE_HOME写错进程起不来ORACLE_SID写错连到别的库NLS_LANG不一致会导致中文变成问号——这是跨平台同步里非常高频的一个翻车点。LOGRETENTION DISABLED表示不依赖 OGG 自己管理日志保留交给数据库的归档策略配了它就要确保归档保留时间够长。CACHEMGR CACHESIZE 2GB是大事务的缓冲遇到一次性更新几十万行的批处理缓存给小了会报长事务告警甚至中断。LONGTRANS 1H是长事务阈值超过一小时就告警配合CHECKINTERVAL 10m每十分钟检查一次。GETTRUNCATES让 truncate 也能同步过去不放这个参数的话目标端会留着已经被清空的数据。FETCHOPTIONS MISSINGROW ABEND是我强烈建议保留的一行——遇到找不到行的情况直接中止而不是跳过跳过意味着数据静默不一致比报错可怕得多。配完参数后注册进程并启动GGSCI add extract extgsxf tranlog, begin now GGSCI add exttrail ./dirdat/gs, extract extgsxf, megabytes 1024 GGSCI start extgsxfmegabytes 1024是单个 trail 文件的大小太大回放粒度粗太小文件数量多、管理麻烦1G 是个比较稳的折中。4.3 DataPump 进程把 trail 文件投递到对端DataPump 不做任何数据转换只负责搬运所以参数很短# GGSCI edit param dpgskf EXTRACT dpgskf PASSTHRU DYNAMICRESOLUTION RMTHOST 10.0.100.141, MGRPORT 7809 RMTTRAIL ./dirdat/gs DISCARDFILE ./dirrpt/dpgskf.dsc, APPEND, MEGABYTES 100 DISCARDROLLOVER AT 6:00 REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 1 HOURS, RATE TABLE test.*;PASSTHRU表示不做数据库层面的转换这是 DataPump 的标准写法加了它才能不依赖本地数据库连接。RMTHOST后面跟目标端 IP 和 MGR 端口注意这里填的是 MGR 端口不是动态端口动态端口由 MGR 协商分配。GGSCI add extract dpgskf, exttrailsource ./dirdat/gs GGSCI add RMTTRAIL ./dirdat/gs, extract dpgskf, megabytes 1024 GGSCI start dpgskfexttrailsource指向本地读取位置RMTTRAIL指向远端写入位置两个名字可以一样但概念不同配反了进程起不来。4.4 Replicat 进程在目标端把 trail 还原成 SQLReplicat 是唯一真正往目标库写数据的进程# GGSCI edit param repgs1 REPLICAT repgs1 SETENV (ORACLE_HOME /u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SID test1) SETENV (NLS_LANG AMERICAN_AMERICA.AL32UTF8) USERID goldengate, PASSWORD goldengate ASSUMETARGETDEFS DBOPTIONS DEFERREFCONST DBOPTIONS SUPPRESSTRIGGERS DISCARDFILE ./dirrpt/repgs1.dsc, APPEND, MEGABYTES 1000 DISCARDROLLOVER AT 6:00 REPERROR (DEFAULT, ABEND) DDL INCLUDE MAPPED, OBJTYPE TABLE INCLUDE MAPPED OBJTYPE INDEX DDLOPTIONS REPORT REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 30 MINUTES, RATE REPORT AT 0:01 STATOPTIONS RESETREPORTSTATS NUMFILES 150 GETTRUNCATES DYNAMICRESOLUTION ALLOWNOOPUPDATES GROUPTRANSOPS 1000 MAP test.*, TARGET test.*;ASSUMETARGETDEFS表示两端表结构完全一致不再去读源端定义文件。跨平台同步时这个假设要成立——Windows 和 Linux 上表的列类型、长度、字符集必须对得上对不上就得改成SOURCEDEFS方式并生成定义文件那是另一套流程。DBOPTIONS SUPPRESSTRIGGERS抑制目标端触发器避免同步写入再触发一次业务逻辑造成数据翻倍。GROUPTRANSOPS 1000把最多 1000 条操作合并成一个事务提交是吞吐和回放粒度之间的权衡调大提升性能但故障时重放的数据量更大。REPERROR (DEFAULT, ABEND)表示除明确忽略的错误外一律中止这和前面抽取端的MISSINGROW ABEND是同一个思路宁可停下来查不要静默跳过。GGSCI add replicat repgs1, exttrail ./dirdat/gs, checkpointtable goldengate.ggschkpt4.5 初始化数据SCN 对齐、expdp 与 sourceistable 两种打法增量链路配好之后还差最后一块存量数据。逻辑是取一个 SCN 作为分界点该点之前的数据用导出导入搬该点之后的增量交给 OGG 重放。分界点取错就会出现主键冲突或者数据空洞。-- 在源库取当前 SCN 作为一致性点 select to_char(current_scn) from v$database; -- 按该 SCN 导出保证导出内容与增量衔接 expdp test/test TABLEStest.t1 DUMPFILEt1.dmp flashback_scn1085057导出文件拷到目标端后导入然后复制进程从这个 SCN 之后开始# 目标端启动复制进程从指定 SCN 之后开始应用 GGSCI start replicat repgs1, aftercsn 1085057另一种做法是不落文件直接用sourceistable做初始化抽取适合表不大、想省掉导出导入环节的场景。源端加一个特殊抽取进程GGSCI add extract init_t1, sourceistable GGSCI edit params init_t1EXTRACT init_t1 USERID goldengate, PASSWORD goldengate RMTHOST 10.0.100.141, MGRPORT 7809 RMTFILE ./dirdat/i1, maxfiles 999, megabytes 500 TABLE test.t1, SQLPREDICATE AS OF SCN 1085057;目标端配一个specialrun复制进程直接消费这个文件GGSCI add replicat ri1, specialrun GGSCI edit params ri1SPECIALRUN END RUNTIME REPLICAT ri1 USERID goldengate, PASSWORD goldengate EXTFILE ./dirdat/i1 MAP test.t1, TARGET test.t1;启动顺序是先开常规抽取和投递再跑初始化抽取然后前台执行一次./replicat paramfile dirprm/ri1.prm完成存量装载最后start replicat rp1, aftercsn 同一个SCN。这个顺序错了会出现增量先应用、存量后覆盖的倒挂。4.6 进程状态观测info all 与 ggserr.log进程起来之后日常就看两个地方。一是info all看三个进程是否 RUNNING、延迟多少GGSCI info all GGSCI info extract extgsxf, detail GGSCI info replicat repgs1, detaildetail里能看到当前读到的 RBA、序列号、最后一条操作时间延迟异常时对比源端和目标端的 RBA 位置就能判断卡在抽取、传输还是应用。二是ggserr.log在 OGG 安装目录下所有进程的启停和报错都记在这里出问题第一件事就是tail -f它。5. 跨平台同步的避坑记录五个把我卡到凌晨的现象与解法这一节写的都是实际踩过的不是从手册上抄的。每条按“看到什么、为什么、怎么解”来说遇上了能直接对上号。5.1 现象Extract 启动几秒就 ABENDED报找不到 redo 或 ORA-01291原因归档没开、附加日志没生效、或者开关改完没切日志。还有一种情况是数据库刚做完大批量 nologging 操作那段时间的 redo 里根本没有行数据。解决先查v$database的LOG_MODE和SUPPLEMENTAL_LOG_DATA_MIN两个都要 YES再确认改完配置后执行过alter system switch logfile。如果是 nologging 造成的历史空洞只能对相关表重新做一次全量初始化增量补不回来。5.2 现象Replicat 报 ORA-00001 唯一约束冲突进程反复中止原因初始化 SCN 和aftercsn没对齐。导出用的 SCN 是 1085057复制却从更早的位置开始同一批 insert 被应用了两遍或者反过来导出用了较晚的 SCN增量却从更早开始中间一段既不在导出文件里也没被重放。解决导出的flashback_scn和start replicat的aftercsn必须是同一个值抄的时候别抄错一位。真出了冲突用REPERROR临时跳过只会让不一致扩散正确做法是清掉目标表、重新按统一 SCN 做一次初始化。5.3 现象目标端中文变成问号或者插入时报字符长度超限原因两端NLS_LANG不一致或者源库是 ZHS16GBK、目标库是 AL32UTF8同一列在 UTF-8 下字节长度翻倍。Windows 源端的默认字符集和 Linux 目标端往往不同这是跨平台同步特有的问题。解决两端SETENV (NLS_LANG...)统一写成AMERICAN_AMERICA.AL32UTF8同时在设计阶段就把 varchar2 列按字节语义检查一遍必要时扩长度或者改成VARCHAR2(x CHAR)。这个问题在测试阶段用英文数据测不出来一定要用真实中文样本验证。5.4 现象DataPump 显示 RUNNING但目标端 dirdat 目录一直不出现新文件原因7809 端口通了DYNAMICPORTLIST那段范围被防火墙或者安全组挡了。MGR 协商出来的传输端口连不上进程会不停重试状态看起来正常。解决把动态端口段整体放行别只开 7809验证时用目标端netstat观察实际建立的连接端口再回源端测同端口连通性。ggserr.log里通常有连接重试的记录只是不会以 ERROR 级别出现容易被忽略。5.5 现象Replicat 报找不到 trail 文件或者文件序号跳变原因MGR 的PURGEOLDEXTRACTS清理太激进MINKEEPHOURS设得太小复制进程还没消费完的文件就被删了也可能是目标端 MGR 起来之前源端就开始投递文件落在了错误的位置。解决MINKEEPHOURS至少覆盖你的最大故障恢复窗口我这个环境设的 12 小时启动顺序上先起目标端 MGR 再起源端投递。已经丢了文件的只能按最后一个成功的检查点重新初始化没有别的捷径。6. 上线之后怎么确认真的同步对了三条验证与一个延迟定位习惯进程全绿不等于数据对。我一般在上线当天做三组验证结构、存量、增量。结构比dba_tab_columns的行数和关键列类型存量比count(*)和主键max/min增量则是手工造三类操作——insert、update、delete再加一次 truncate——逐条到目标端核对。最省事的做法是写一条对账 SQL两端各跑一次比对结果-- 两端分别执行比对行数与主键区间 select T1 tab, count(*) cnt, min(object_id) min_id, max(object_id) max_id from test.t1;日常巡检我固定看三个指标按这个顺序查基本能定位到卡在哪一段检查项命令正常表现异常指向抽取延迟info extract extgsxf, detail延迟秒级源库日志生成过快或归档空间不足传输状态info extract dpgskf, detail目标端文件持续增长网络或动态端口问题应用延迟info replicat repgs1, detail延迟与抽取接近目标端锁冲突或大事务有一回目标端延迟涨到 40 分钟info replicat显示进程一直在跑最后是在报告文件里看到某个大更新卡在了行锁上——业务侧有个未提交的长事务占着同一批行。从那以后我每次上线都强制走一遍“延迟三段对比”先看抽取端 RBA 有没有追上最新归档再看传输端目标文件是否持续增长最后看应用端最后一条操作时间。三段里哪一段停住问题就在那一段不用全链路瞎猜。跨平台这套链路真正难的不是装软件而是让“配置生效”这件事可验证。开关改完切日志、进程起来看 detail、初始化对齐同一个 SCN、上线后三段对延迟这几步做扎实Windows 到 Linux 的同步就能稳稳跑住。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
