OGG-15051|OGG 同步 Oracle 到 Kafka 时遇到的一个错误

JiekeXu

于 2022-08-22 18:10:05 发布

阅读量2.1k

点赞数

文章标签： java python 大数据编程语言数据库

本文链接：https://blog.csdn.net/JiekeXu/article/details/126476442

版权

作者 | JiekeXu

来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）

如需转载请联系授权 | (个人微信 ID：JiekeXu_DBA)

大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来学习 OGG 同步 Oracle 到 Kafka 时遇到的一个错误，欢迎点击上方蓝字关注我，标星或置顶，更多干货第一时间到达！

有时候随着业务的需要，需要将 Oracle 的部分数据通过 Kafka 进行分析，以获取最大的数据价值。那么就需要通过 OGG 抽取数据同步到 Kafka 了，搭建过程可查看上文，今天记录下遇到的一个罕见的错误，问题是这样的，通过 OGG 同步 Oracle 11g 数据到 Kafka 的一个应用进程 rep1，运行一段时间突然异常 ABENDED，查看日志报错如下：

七月 28, 2022 2:28:43 下午 oracle.goldengate.datasource.UserExitDataSource createColumnValue
严重: Unable to decode column 57 : Input length = 1
java.nio.charset.MalformedInputException: Input length = 1
  at java.nio.charset.CoderResult.throwException(CoderResult.java:281)
  at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:816)
  at oracle.goldengate.datasource.UserExitDataSource.createColumnValue(UserExitDataSource.java:1019)


Exception in thread "main" oracle.goldengate.util.GGException: Unable to decode column 57 : Input length = 1
  at oracle.goldengate.datasource.UserExitDataSource.createColumnValue(UserExitDataSource.java:1098)


Source Context :
  SourceModule            : [gglib.ggdal.adapter.java]
  SourceID                : [/scratch/aime/adestore/views/aime_adc4150560/oggcore/OpenSys/src/gglib/ggdal/Adapter/Java/JavaAdapter.cpp]
  SourceMethod            : [HandleJavaException]
  SourceLine              : [246]
  ThreadBacktrace         : [20] elements
                          : [/goldengate/libgglog.so(CMessageContext::AddThreadContext()+0x1e) [0x7f7b0b15c0ae]]
                          : [/goldengate/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...)+0x6ac) [0x7f7b0b14c9bc]]
                          : [/goldengate/libgglog.so(_MSG_String(CSourceContext*, int, char const*, CMessageFactory::MessageDisposition)+0x39) [0x7f7b0b13ad19]]
                          : [/goldengate/libggjava.so(+0x2e9e7) [0x7f7b013d99e7]]
                          : [/goldengate/replicat(GenericImpl::Write(ObjectMetadata*, std_rec_hdr_def const*, ggs::gglib::ggdal::CDALRecord&)+0x52) [0x816832]]
                          : [/goldengate/replicat(ggs::gglib::MultiThreading::MainThread::ExecMain()+0x5e) [0x7e2d8e]]
                          : [/goldengate/replicat(main+0x3b) [0x6e7e0b]]
                          : [/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f7b037c63d5]]
                          : [/goldengate/replicat() [0x550831]]


2022-07-28 14:28:43  ERROR   OGG-15051  Java or JNI exception:
oracle.goldengate.util.GGException: Unable to decode column 57 : Input length = 1.

ERROR OGG-15051 Java 或 JNI异常：无法解码第57列:输入长度= 1。

因我配置的 OGG 是同步部分表到 Kafka,对于 DDL 也是直接跳过不用捕获，直接通过重新同步一次表定义文件 ./dirdef/goldengate.def 到目标端即可解决，本次也将尝试这样做。步骤如下：

--源端删除表定义文件
rm -rf /goldengate/dirdef/goldengate.def
--重新生成表定义文件
/goldengate/defgen paramfile /goldengate/dirprm/test_ogg.prm


--test_ogg.prm 文件中提前写好需要同步到目标端的表
more /goldengate/dirprm/test_ogg.prm
defsfile /goldengate/dirdef/goldengate.def,FORMAT RELEASE 11.2
userid goldengate,password ogg12345
TABLE ds.test01;
TABLE prod.T_CRE;
TABLE prod.T_CRE_DOC_DATUM_RELATION;
TABLE prod.T_CRE_DOC_AUDIT_DETAIL;
TABLE prod.T_CRE_DOC_PROGRESS;
TABLE prod.T_CRE_DOC_DATUM;
---------------------------------
然后将生成的 goldengate.def scp 到目标端，然后重启 start rep1 即可。

但是本次这样操作却没能解决，因为也不是同一个问题。我这里使用的环境是 Oracle 11204 RAC，OGG 版本如下：

--源端
Oracle GoldenGate Command Interpreter for Oracle
Version 12.3.0.1.4 OGGCORE_12.3.0.1.0_PLATFORMS_180415.0359_FBO
Linux, x64, 64bit (optimized), Oracle 11g on Apr 15 2018 21:16:09
Operating system character set identified as UTF-8.


--目标端
Oracle GoldenGate for Big Data
Version 12.3.2.1.1 (Build 005)


Oracle GoldenGate Command Interpreter
Version 12.3.0.1.2 OGGCORE_OGGADP.12.3.0.1.2_PLATFORMS_180712.2305
Linux, x64, 64bit (optimized), Generic on Jul 13 2018 00:46:09
Operating system character set identified as UTF-8.

无奈，只能依靠搜索引擎了，只不过某度搜索到的内容几乎全部一样，说是 Kafka 消息过大，需要修改其配置文件。仔细查看报错内容还是不一样 “Unable to decode column 57 : Input length = 1”，放弃某度只能去 MOS 上寻求帮助了。

The message is 2885830 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration.


vi custom_kafka_producer.properties


max.request.size = 5024000
send.buffer.bytes = 5024000

终于在 MOS 上找到了一篇(文档 ID 2786080.1)文档，“OGG-15051 Java Or JNI Exception: Oracle.goldengate.util.GGException: Unable To decode column”，按照说明版本为 Oracle GoldenGate Big Data 19.1 或更高才会出现这个问题。我这里的版本为 12.3，有点小差别，不过还是先试试吧，死马当活马医咯。

请参考以下方法解决此问题。

原因：
21-06-12 23:53:24 ERROR OGG-15051 Java 或 JNI exception: oracle.goldengate.util.GGException: Unable to decode column 1: Input length = 2。


我们需要继续采用这种策略:通过 CHARMAP 指定 UTF-16 到 UTF-16 映射的覆盖，以便将 U+FFFE 更改为 U+FFFD(替换字符)。
这应该用替换字符替换坏字符 U+FFFE。

您应该继续使用这种策略:通过 CHARMAP 指定 UTF-16 到 UTF-16 映射的覆盖，以便将 U+FFFE 更改为 U+FFFD(替换字符)。虽然没看明白为何会出现这样的问题，但看着解决步骤倒是简单，那就试试吧。

The following is how we do it:


Step 1: Create a text file and name it myfile containing the following three
----步骤1:创建一个文本文件，命名为 myfile，包含以下三个文件(PS:文中没有说明此文件存放于何处？)
lines:
SOURCECHARSET utf-16be
TARGETCHARSET utf-16be
\xff\xfe \xff\xfd


Step 2: In replicat .prm file, add this via CHARMAP prior to the
REPLACEBADCHAR SUBSTITUTE ? FORCECHECK:
----步骤2:在 replicate.prm 文件中，通过 CHARMAP 将其添加到 REPLACEBADCHAR SUBSTITUTE ? FORCECHECK:


CHARMAP myfile
REPLACEBADCHAR SUBSTITUTE ? FORCECHECK


This should replace the bad character U+FFFE with a replacement character.
----这应该用替换字符替换坏字符 U+FFFE。

故按照此办法，在 ./dirprm/ 下配置了 myfile 文件，然后在 rep1.prm 参数文件中增加参数

more ./dirprm/myfile
SOURCECHARSET utf-16be
TARGETCHARSET utf-16be
\xff\xfe \xff\xfd




REPLACEBADCHAR SUBSTITUTE ? FORCECHECK:

最后，重新启动 rep1 应用进程则可正常。不知是否还有其他办法，这里没有再次去尝试，其他小伙伴如有更加简单的方法可一起交流讨论。如果是测试环境或者可接受数据丢失，当然还可以跳过这个事务，跳过这条记录，通过其他手段或者途径补全跳过的记录，下面简单说说跳过的方法及步骤。

-- 进入 OGG 查看当前的 trail 文件编号及 RBA 号。
./ggsci
GGSCI (jieke-ogg-test) 4> Info rep1
REPLICAT   REP1     Last Started 2022-07-25 10:44   Status ABENDED
Checkpoint Lag       00:00:00 (updated 00:00:07 ago)
Process ID           8960
Log Read Checkpoint  File /soft/dirdat/pd000000016
                     2022-07-29 23:06:46.000355  RBA 128554753
查看到当前 trail 文件编号是 16，RBA 是 128554753,记住这个信息，然后使用 logdump 工具查看。
./logdump
----开启详细日志显示
Logdump 1277 > ghdr on
Logdump 1278 > detail on
----打开 trail 文件
Logdump 1279 > open /soft/dirdat/pd000000016
----跳到上面查看到的异常的 RBA 号 128554753，使用 n 查看当前正在经历的 DDL 或者 DML 操作。
Logdump 1280 > pos 128554753
Logdump 1281 > n


----再次按 n 回车，查看下一条操作及 RBA 是多少（多数情况下会多次执行 n，跳过多条操作），记录下当前的 RBA 是 131749957


./ggsci
----跳过之前的 128554753 操作，跳到 131749957
GGSCI (jieke-ogg-test) 2> alter rep rep1 extseqno 16,extrba 131749957
GGSCI (jieke-ogg-test) 3> start rep1 with NOFILTERDUPTRANSACTIONS
GGSCI (jieke-ogg-test) 4> start rep1

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

❤️ 欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！

——————————————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————————————



Oracle 表碎片检查及整理方案
OGG|Oracle GoldenGate 基础2021 年公众号历史文章合集整理
2020 年公众号历史文章合集整理
我的 2021 年终总结和 2022 展望Oracle 19c RAC 遇到的几个问题
利用 OGG 迁移 Oracle11g 到 19COGG|Oracle GoldenGate 微服务架构Oracle 查询表空间使用率超慢问题一则国产数据库|TiDB 5.4 单机快速安装初体验Oracle ADG 备库停启维护流程及增量恢复Linux 环境搭建 MySQL8.0.28 主从同步环境