背景

从业这么多年以来，OGG一直是我工作中挺重要的一部分，做的项目和应用的场景也挺多。但是长久以来一直有这么一个问题，当源端跟目标端字符集不一致的时候，中文有可能会出现乱码。

2015或者2016年时候，有个业务，要在两个数据库之间同步数据，一个数据库字符集是AL32UTF8，另外一个是ZHS16GBK。当时配置好OGG之后，交付给业务部分使用。两天后业务部门说有的中文显示乱码。之后经过排查，发现从ZHS16GBK往AL32UTF8同步中文不会乱码，而反过来从AL32UTF8往ZHS16GBK同步中文就会乱码。后来查了资料，从子集往超集同步，中文不会乱码。配置的过程，抽取、投递和应用进程都需要配置NLS_LANG环境变量,而且要跟源库的字符集保持一致。

2019年之后，客户业务逐步迁移到省里，由省里统一运营，省里数据库字符集是AL32UTF8，我们本地是ZHS16GBK，省里的数据也要回传给本地一份，一看这字符集我就知道用不了OGG。数据回传历经了好几个阶段，用过dblink，用过东软的SaCa，但是效果都不是很好。总会少部分数据库，不定期就要重做。

去年的时候，回传方法又改成了某同步软件。当时有点震惊，该同步软件这么强大，从AL32UTF8往ZHS16GBk同步中文不乱码。

2025年4月某一天，突发奇想，也许到了2025年OGG已经支持了呢？就是基于这个想法，才有了这篇文章。

于是我就新建了两个虚拟机做了测试。下面记录一下测试过程。

环境信息

服务器IP	数据库版本	OGG版本	字符集
172.16.128.1	oracle 19.26	ogg 23.7.1 for oracle	AL32UTF8
172.16.128.1	oracle 19.26	ogg 23.7.1 for oracle	ZHS16GBK

测试过程

OGG配置

配置过程这里就不写了，只把参数贴在这里。核心思想，就是数据库会把相关信息写到线索文件里。

抽取进程

EXTRACT E_ORCL
USERIDALIAS oggpdb1 domain OracleGoldenGate
EXTTRAIL ORCL/lt
TRANLOGOPTIONS INTEGRATEDPARAMS(parallelism 2)
DBOPTIONS ALLOWUNUSEDCOLUMN
DDL include mapped
--GETUPDATEBEFORES
NOCOMPRESSDELETES
NOCOMPRESSUPDATES
FETCHOPTIONS NOUSESNAPSHOT
FETCHOPTIONS FETCHPKUPDATECOLS
BR BROFF
TABLE TEST.*;

应用进程

REPLICAT ORCL
useridalias oggpdb2 domain OracleGoldenGate
REPERROR DEFAULT, ABEND
--HANDLECOLLISIONS
DDL include mapped
DISCARDFILE ORCL.dsc, APPEND, MEGABYTES 100
MAP test.*, TARGET test.*;

核心点在于不设置环境变量，让OGG从数据库中读取。

生成测试数据

这里使用百灵生成十万条记录。

查OGG同步状态

抽取状态

应用状态

十万条记录完成同步

检查数据

源库

目标端

从实验结果可以看到中文并没有乱码！从日志里看是OGG发现字符集不一致，进行了转换。

以上的实验在21c和23ai上面都做过了。

结论

ogg21c和ogg23ai现在完全支持从AL32UTF8数据库往ZHS16GBK数据库同步中文不乱码了，使用的场景终于圆满了