抹茶柚子冰1. 项目背景与挑战
这次我们面临的是一个典型的大型Oracle数据库迁移项目：需要将9TB的业务数据从Oracle 11g实时迁移到19c环境，且要求全程业务零停机。这种体量的迁移通常意味着：
- 数据规模：9TB包含约2000张表，其中包含LOB字段的表占15%
- 版本跨度：从11.2.0.4直接升级到19.15，跨越多个主版本
- 业务连续性：7×24小时运行的订单系统，停机窗口≤5分钟
- 网络环境：源库与目标库通过10Gbps专线连接，实测带宽稳定在8Gbps
选择OGG 21c作为迁移工具主要基于三个技术判断：
- 图形化界面大幅降低配置复杂度，相比传统命令行方式效率提升40%以上
- 内置的自动冲突检测与处理机制能有效应对异构环境下的数据一致性问题
- 实测在表结构差异场景下的数据同步准确率达到99.998%
- 支持在线切换（Online Cutover）确保业务中断时间可控
关键决策点：当源库与目标库版本差超过2个主版本时，传统expdp/impdp方案会产生约17%的对象兼容性问题，而OGG的实时解析特性可规避大部分语法兼容性错误。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 源端环境准备
2.1 数据库参数调整
在11g源库需要特别关注的参数（经压力测试验证的最佳值）：
sql复制ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH;
ALTER SYSTEM SET streams_pool_size=8G SCOPE=SPFILE; -- 建议总内存的15%
ALTER SYSTEM SET parallel_max_servers=32 SCOPE=BOTH; -- 全量导出并发数
补充检查清单：
- 确认归档日志模式已开启
- 检查补充日志级别：
SELECT supplemental_log_data_min, supplemental_log_data_pk FROM v$database; - 为OGG用户分配的最小权限集：
sql复制GRANT CREATE SESSION, ALTER SESSION TO oggadmin; GRANT SELECT ANY DICTIONARY TO oggadmin; GRANT FLASHBACK ANY TABLE TO oggadmin;
2.2 OGG 21c安装注意事项
在RHEL 7.6上的实测安装经验：
- 必须配置的依赖包：
bash复制
yum install -y ksh libaio sysstat elfutils-libelf-devel - 磁盘空间规划建议：
- /opt目录预留50GB（包含安装包和解压空间）
- /ogg目录需要300GB（用于存放trail文件）
- 关键环境变量配置：
bash复制export OGG_HOME=/opt/ogg21c export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$OGG_HOME/lib
踩坑记录：在测试环境曾因未设置LD_LIBRARY_PATH导致Manager进程频繁崩溃，错误表现为"Error loading shared library libnnz19.so"。
3. 目标端19c环境配置
3.1 字符集与兼容性处理
由于11g源库使用ZHS16GBK字符集，而19c默认AL32UTF8，需要特别注意：
- 在OGG配置中强制指定字符集转换：
properties复制REPLICAT rpc19c TARGETDB LIBFILE libggjava.so SET property=oracle.receiver.charset=ZHS16GBK - 大对象字段特殊处理：
sql复制-- 目标库预先创建包含LOB字段的表空间 CREATE TABLESPACE lob_ts DATAFILE '+DATA' SIZE 500G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
3.2 性能优化配置
针对9TB数据量的接收端优化：
- 并行应用配置：
properties复制REPLICAT rpc19c PARALLELISM 8 MAXTRANSOPS 1000 - 使用Integrated模式提升吞吐量：
sql复制-- 目标库配置 ALTER SYSTEM SET parallel_max_servers=64 SCOPE=BOTH; BEGIN DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR( schema_name => '%', auto_cdr_flag => 'Y'); END;
4. 全量同步实施细节
4.1 初始化加载策略选择
经过对比测试选择的方案：
| 方案 | 耗时 | 网络负载 | 目标库压力 |
|---|---|---|---|
| 传统Export/Import | 28h | 中等 | 高 |
| OGG初始加载 | 19h | 低 | 中 |
| 表空间传输 | 9h | 最低 | 最低 |
最终采用混合模式：
- 80%的大表（>50GB）使用表空间传输
- 剩余表使用OGG初始加载
4.2 关键配置示例
初始化加载参数文件示例：
properties复制SOURCEISTABLE
SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
SETENV (ORACLE_SID=orcl11g)
USERID oggadmin@orcl11g, PASSWORD AACAAAAAAAAAAAIHAFZJKYO
TABLE HR.*;
MAP HR.*, TARGET HR.*;
批量生成加载命令的Shell脚本：
bash复制for t in $(cat /tmp/big_tables.lst); do
echo "START EXTRACT einit$t SOURCEISTABLE TABLE $t" >> init_load.cmd
echo "SEND EXTRACT einit$t REPORT" >> init_load.cmd
done
5. 增量同步配置要点
5.1 Extract进程高级参数
保障数据完整性的关键配置：
properties复制EXTRACT ext11g
TRANLOGOPTIONS EXCLUDEUSER ggs_admin
FETCHOPTIONS FETCHPKUPDATECOLS
GETTRUNCATES
REPORTCOUNT EVERY 30 MINUTES, RATE
WARNLONGTRANS 1h, CHECKINTERVAL 10m
5.2 数据验证机制
我们设计的双保险验证方案：
- OGG内置校验：
properties复制REPLICAT rpc19c ASSUMETARGETDEFS REPERROR (DEFAULT, EXCEPTION) - 自定义校验脚本（每小时运行）：
sql复制-- 采样0.1%的记录比对MD5值 SELECT COUNT(*) cnt, SYS.DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW(DBMS_LOB.SUBSTR(t.lob_col,2000,1)),2) hash_val FROM source_table@sourcelink t SAMPLE(0.1) GROUP BY SYS.DBMS_CRYPTO.HASH(...);
6. 切换方案设计
6.1 最终同步流程
经过三次演练验证的切换步骤：
- 业务峰值时段禁用触发器：
sql复制BEGIN FOR r IN (SELECT trigger_name FROM user_triggers) LOOP EXECUTE IMMEDIATE 'ALTER TRIGGER '||r.trigger_name||' DISABLE'; END LOOP; END; - 执行最后一次增量同步：
bash复制SEND EXTRACT ext11g, SKIPTRANS 1800 # 跳过当前长事务 - 切换DNS记录（TTL已提前设置为60s）
6.2 回退方案
准备的应急措施包括：
- 保留源库OGG进程持续运行24小时
- 预先配置反向复制链路（19c→11g）
- 准备数据库闪回点：
sql复制CREATE RESTORE POINT pre_cutover GUARANTEE FLASHBACK DATABASE;
7. 性能监控体系
7.1 关键指标看板
我们部署的监控项示例：
| 指标 | 预警阈值 | 采集频率 |
|---|---|---|
| Extract延迟 | >15min | 1min |
| Replicat延迟 | >10min | 1min |
| Trail文件积压 | >20个 | 5min |
| 网络吞吐量 | <5Gbps | 实时 |
7.2 实用监控脚本
长事务检测脚本（crontab每小时运行）：
sql复制SELECT
SID,
START_TIME,
(SYSDATE - START_DATE)*1440 duration_mins,
SQL_TEXT
FROM V$TRANSACTION t
JOIN V$SESSION s ON t.SES_ADDR = s.SADDR
WHERE (SYSDATE - START_DATE)*1440 > 30;
8. 经验总结与避坑指南
-
LOB字段处理：当遇到超过1GB的CLOB时，必须在目标端预先设置：
properties复制REPLICAT rpc19c LOBMEMORY 2GB -
时区问题：11g与19c的时区文件版本差异会导致TIMESTAMP WITH TIME ZONE类型数据异常，解决方案：
sql复制-- 目标库执行 DBMS_DST.upgrade_prepare(19); -
性能瓶颈定位：当遇到同步速度下降时，按此顺序排查：
- 检查网络
iftop -P -N - 检查磁盘IO
iostat -x 1 - 检查OGG进程状态
info all - 分析长事务
send extract ext11g, showtrans
- 检查网络
这次迁移最终实现：
- 全量同步耗时：11小时23分钟（平均2.3GB/分钟）
- 切换停机时间：3分42秒
- 数据差异量：9TB中仅3条记录需要手动修复