苏三公子1. 项目背景与挑战
在金融行业核心系统升级过程中，我们面临一个关键挑战：如何将9TB规模的Oracle 11g生产数据迁移至19c版本，同时保证业务连续性。这个体量的数据库迁移通常意味着数小时的停机窗口，但业务部门给出的最大允许停机时间只有15分钟。
传统迁移方案如expdp/impdp或RMAN在此场景下存在明显局限：
- 导出导入方式需要至少8小时停机时间
- 物理备份恢复无法跨大版本（11g→19c）
- Data Guard技术对异构版本支持有限
经过技术评估，我们最终选择OGG 21c（Oracle GoldenGate）作为解决方案，主要基于以下考量：
- 支持异构数据库间实时数据同步
- 微服务架构提供更好的水平扩展能力
- 图形化界面降低操作复杂度
- 对DDL变更的完整支持
关键决策点：当数据量超过5TB时，建议优先评估OGG而非传统迁移工具，尤其对停机时间敏感的系统。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 微服务架构设计解析
2.1 OGG 21c微服务组件拓扑
在本次迁移架构中，我们部署了以下核心微服务组件：
| 服务名称 | 部署节点 | CPU/内存配置 | 磁盘要求 | 网络带宽 |
|---|---|---|---|---|
| Administration | 管理节点 | 8C/16G | 100GB | 10Gbps |
| Distribution | 中继节点 | 16C/32G | 500GB | 25Gbps |
| Receiver | 目标集群 | 4C/8G | 200GB | 10Gbps |
| Performance | 监控节点 | 4C/8G | 50GB | 1Gbps |
这种设计实现了：
- 管理平面与数据平面分离
- 弹性扩展处理能力
- 故障域隔离
2.2 关键配置参数
在oggca.sh图形化配置工具中，需要特别注意以下参数：
bash复制# 微服务通信端口配置
SERVER_PORT=9001
METRICS_PORT=9020
DYNAMIC_PORT_RANGE=9100-9200
# JVM调优参数
JAVA_OPTS="-Xms12G -Xmx12G -XX:MaxMetaspaceSize=2G"
实际踩坑：未配置DYNAMIC_PORT_RANGE会导致高并发时连接失败，建议预留至少100个端口。
3. 源端11g环境准备
3.1 数据库级配置
在源端Oracle 11gR2上需要执行的关键操作：
sql复制-- 开启补充日志
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE FORCE LOGGING;
-- 创建OGG用户
CREATE USER oggadmin IDENTIFIED BY "ComplexPwd#2023"
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
-- 授予权限
GRANT CONNECT, RESOURCE, DBA TO oggadmin;
GRANT EXECUTE ON DBMS_FLASHBACK TO oggadmin;
GRANT SELECT ANY DICTIONARY TO oggadmin;
3.2 表级准备策略
针对9TB数据中的核心表，需要特殊处理：
- 识别大对象表（>50GB）
- 检查LONG/RAW类型字段
- 确认主键/唯一键存在
我们开发的自动化检查脚本：
sql复制SELECT owner, table_name, tablespace_name,
ROUND(bytes/1024/1024/1024,2) GB
FROM dba_segments
WHERE owner IN ('APP1','APP2')
AND bytes > 10737418240
ORDER BY bytes DESC;
4. 目标端19c环境优化
4.1 存储布局设计
考虑到19c的In-Memory特性，采用新型存储架构：
code复制ASM磁盘组布局：
- DATA_OGG: 4TB (AUTOEXTEND ON) - 专用于OGG队列
- DATA_APP: 10TB (HIGH REDUNDANCY) - 应用数据
- RECO: 2TB - 归档日志
4.2 内存参数调优
在19c参数文件中关键修改：
sql复制-- OGG相关内存配置
memory_target=48G
pga_aggregate_target=16G
db_keep_cache_size=8G
-- In-Memory配置
inmemory_size=20G
inmemory_force=DEFAULT
5. 初始数据加载策略
5.1 分批次加载方案
针对9TB数据，采用三级并行加载：
- 基础数据（<1GB表）：直接OGG初始化加载
- 中型表（1-50GB）：使用并行EXPDP导出后IMPDP导入
- 超大表（>50GB）：采用表空间传输+OGG增量同步
5.2 加载性能优化
实测有效的参数组合：
bash复制# expdp参数示例
expdp system/password@src_db
PARALLEL=16
CLUSTER=YES
COMPRESSION=ALL
DUMPFILE=exp_%U.dmp
FILESIZE=50G
SCHEMAS=app_schema
经验值：每TB数据预计需要2小时加载时间（基于25Gbps网络）
6. 增量同步配置要点
6.1 Extract进程配置
关键参数示例：
sql复制EXTRACT ext_app1
USERID oggadmin@src_db, PASSWORD AAABBCCDDEEFF
EXTTRAIL /ogg/var/dirdat/et
TABLE app1.*;
TABLE app2.*;
6.2 Replicat进程优化
针对19c特性的特殊配置：
sql复制REPLICAT rep_app1
USERID oggadmin@tgt_db, PASSWORD GGTTEERRFF
MAP app1.*, TARGET app1.*;
MAP app2.*, TARGET app2.*;
BATCHSQL ONSIZE 100000
7. 典型问题排查指南
7.1 网络中断处理
当出现网络闪断时，按以下流程恢复：
- 检查进程状态：
info all - 查看延迟：
send extract ext_app1, report - 必要时重新定位：
alter extract ext_app1, begin now
7.2 数据不一致修复
使用以下命令生成校验报告：
bash复制./ggsci << EOF
DBLOGIN USERID oggadmin@src_db, PASSWORD xxx
VERIFY TABLE app1.t_customer, KEYCOLS(id), REPORT
EOF
8. 监控体系搭建
8.1 Prometheus监控配置
在OGG微服务中启用监控端点：
yaml复制# prometheus.yml 片段
- job_name: 'ogg_metrics'
metrics_path: '/metrics'
static_configs:
- targets: ['ogg-admin:9020']
8.2 关键监控指标
必须监控的核心指标包括：
- 提取延迟（extract_lag_sec）
- 应用速率（replicat_records_sec）
- 队列深度（trail_files_count）
- 内存使用（jvm_memory_used）
9. 性能调优实战
9.1 Extract进程优化
实测有效的参数组合：
sql复制EXTRACT ext_large
RMTHOST 192.168.1.100, MGRPORT 7809
RMTTRAIL /ogg/var/dirdat/rt
TRANLOGOPTIONS EXCLUDEUSER ggs_admin
DISCARDFILE /ogg/var/dirrpt/ext_large.dsc, PURGE
TABLE app1.t_large_table, KEYCOLS(id), FETCHCOLS(size);
9.2 网络传输优化
在分布式节点间配置：
bash复制# 网络参数调优
ifconfig eth0 mtu 9000
ethtool -G eth0 rx 4096 tx 4096
sysctl -w net.ipv4.tcp_window_scaling=1
10. 切换演练方案
10.1 最终同步流程
计划内的切换步骤：
- 停止源端应用连接
- 执行最终增量同步
- 验证数据一致性
- 切换连接字符串
10.2 回退机制
必须准备的应急方案：
- 保留11g环境至少7天
- 配置反向复制链路
- 准备连接字符串回切脚本
在实施过程中我们发现，当表数量超过5000时，OGG微服务控制台会出现响应延迟。解决方法是通过REST API批量操作：
python复制import requests
from requests.auth import HTTPBasicAuth
auth = HTTPBasicAuth('oggadmin', 'password')
headers = {'Content-Type': 'application/json'}
def create_extract(ext_name):
url = "https://ogg-admin:9001/services/v2/extracts"
data = {
"name": ext_name,
"config": f"EXTRACT {ext_name}\nUSERID oggadmin\nEXTTRAIL /ogg/var/dirdat/et\nTABLE app1.*;"
}
response = requests.post(url, json=data, auth=auth, headers=headers, verify=False)
return response.json()
这个项目最终实现了9TB数据在12分钟停机窗口内的成功迁移，过程中积累的关键经验是：对于超大规模迁移，必须提前进行至少三次全流程演练，每次演练后要优化以下方面：
- 网络传输效率（调整MTU和TCP参数）
- 磁盘IO调度策略（deadline改为noop）
- 批量操作自动化程度（REST API封装）
- 监控指标覆盖完整性（添加自定义指标）