OGG 19c Bug 35446910 报错 Mapping error 错误解决办法

JiekeXu之路

发布于 2023-12-26 14:39:07

28300

代码可运行

运行总次数：0

代码可运行

大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 OGG 19c Bug 35446910 报错 Mapping error 错误解决办法，欢迎点击上方蓝字“JiekeXu DBA之路”关注我的公众号，标星或置顶，更多干货第一时间到达！

前言

这个月我们同事对原来生产环境的 19c RAC 进行 schema 级别的拆分，将其从 RHEL7.6 RU 19.15 的两个 schema 拆分迁移到 RHEL7.9 RU 19.21 的 RAC 上，迁移前后表空间和 schema 名不变，唯一改变的则是 RU 补丁版本和数据库名及 IP 地址，同时也配置了 Oracle 到 Kafka 的数据同步，所以需要重新部署 OGG 来同步新迁移的数据，Oracle 到 Kafka 的数据同步可以参考我这篇使用 OGG12.3 同步 Oracle 部分表到 Kafka。

环境信息

新环境源端 OGG 版本：Linux, x64, 64bit (optimized) Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO 目标端 OGG for Kafka 版本：Linux, x64, 64bit (optimized) Oracle GoldenGate for Big Data Version 12.3.2.1.1 (Build 005)，可见，OGG 19.1 没有打过任何补丁。

--源端
$ ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 19.1.0.0.4 OGGCORE_19.1.0.0.0_PLATFORMS_191017.1054_FBO
Linux, x64, 64bit (optimized), Oracle 19c on Oct 17 2019 21:16:29
Operating system character set identified as US-ASCII.

Copyright (C) 1995, 2019, Oracle and/or its affiliates. All rights reserved.

GGSCI 1> info all

-- for kafka 目标端
$ ggsci

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.

Copyright (C) 1995, 2018, Oracle and/or its affiliates. All rights reserved.

问题现象

当目标端 OGG 运行一段时候后，rep 复制进程中的几个表就会报错 Mapping error，剩余其他几个表是正常同步的。view report rep1_yy 具体报错如下：

2023-12-19 14:50:01  WARNING OGG-01431  Aborted grouped transaction on CC_YY.T_CI_UKEY_APPLY, Mapping error.

2023-12-19 14:50:01  WARNING OGG-01003  Repositioning to rba 5159 in seqno 0.

2023-12-19 14:50:01  WARNING OGG-01151  Error mapping from CC_YY.T_CI_UKEY_APPLY to CC_YY.T_CI_UKEY_APPLY.

Source Context :
  SourceModule            : [er.replicat.errors]
  SourceID                : [/scratch/aime/adestore/views/aime_adc4150560/oggcore/OpenSys/src/app/er/replicat/reperrors.cpp]
  SourceMethod            : [repError]
  SourceLine              : [1673]
  ThreadBacktrace         : [15] elements
                          : [/goldengate/libgglog.so(CMessageContext::AddThreadContext()+0x1e) [0x7f6893d290ae]]
                          : [/goldengate/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...)+0x6ac) [0x7f6893d199bc]]
                          : [/goldengate/libgglog.so(_MSG_QualTableName_QualTableName(CSourceContext*, int, ggs::gglib::ggapp::CQualDBObjName<(DBObjType)1> const&, ggs::ggl
ib::ggapp::CQualDBObjName<(DBObjType)1> const&, CMessageFactory::MessageDisposition)+0x74) [0x7f6893d10e84]]
                          : [/goldengate/replicat(ggs::er::ReplicatContext::repError(short, int, char const*, extr_ptr_def*, ggs::gglib::gglcr::CommonLCR const*, std_rec_hd
r_def*, char*, ObjectMetadata*, bool)+0x2821) [0x63a461]]
                          : [/goldengate/replicat(ggs::er::ReplicatContext::replicate_io(ggs::gglib::gglcr::CommonLCR const*, ggs::gglib::gglcr::CommonLCR*, extr_ptr_def*, 
bool, int&, RepCsn&, bool*)+0x29b9) [0x6eb929]]
                          : [/goldengate/replicat(ggs::er::ReplicatContext::processRecord(ggs::gglib::gglcr::CommonLCR const*, ggs::gglib::gglcr::CommonLCR*, extr_ptr_def*&
, extr_ptr_def*&, bool&, int&, bool, RepCsn&)+0x318) [0x6f98d8]]
                          : [/goldengate/replicat(ggs::er::ReplicatContext::processReplicatLoop()+0x4614) [0x631494]]
                          : [/goldengate/replicat(ggs::er::ReplicatContext::run()+0x45) [0x610545]]
                          : [/goldengate/replicat() [0x6e506f]]
                          : [/goldengate/replicat(ggs::gglib::MultiThreading::MainThread::ExecMain()+0x5e) [0x7e2d8e]]
                          : [/goldengate/replicat(ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*)+0x173) [0x7e7153]]
                          : [/goldengate/replicat(ggs::gglib::MultiThreading::MainThread::Run(int, char**)+0x140) [0x7e79c0]]
                          : [/goldengate/replicat(main+0x3b) [0x6e7e0b]]
                          : [/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f688c3933d5]]
                          : [/goldengate/replicat() [0x550831]]

2023-12-19 14:50:01  ERROR   OGG-01296  Error mapping from CC_YY.T_CI_UKEY_APPLY to CC_YY.T_CI_UKEY_APPLY.

通过 stats rep1_yy 查看统计信息，查看复制进程处理的记录数。通过报告看到 Mapping 错误的表有 insert 操作，但是没有 update 操作，正常复制的表也是只有 insert 操作，没有 update 操作。

GGSCI 3> stats rep1_yy

Sending STATS request to REPLICAT rep1_yy ...

Start of Statistics at 2023-12-21 14:02:05.

Replicating from CC_YY.T_AUTH_CA_AUTH_TEMP to CC_YY.T_AUTH_CA_AUTH_TEMP:

*** Total statistics since 2023-12-19 16:50:35 ***
        Total inserts                                      2.00
        Total updates                                      0.00
        Total befores                                      0.00
        Total deletes                                      0.00
        Total discards                                     0.00
        Total operations                                   2.00

*** Daily statistics since 2023-12-21 00:00:00 ***
        Total inserts                                      2.00
        Total updates                                      0.00
        Total befores                                      0.00
        Total deletes                                      0.00
        Total discards                                     0.00
        Total operations                                   0.00

*** Hourly statistics since 2023-12-21 10:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2023-12-19 16:50:35 ***
        Total inserts                                      2.00
        Total updates                                      0.00
        Total befores                                      0.00
        Total deletes                                      0.00
        Total discards                                     0.00
        Total operations                                   2.00

然后去 dirrpt 目录下看日志 rep1_yy.dsc 发现了错误，当表做 update 更新的时候 SEQUENCE_NO 主键丢失，所以就 ABEND 了，也说明了前面的 insert 可以成功，当遇到 update 就 ABEND 了，则可以确定就是两边的表结构不一致导致 ABEND。那么到底是什么原因导致的呢？接着往下看！

more  /goldengate/dirrpt/rep1_yy.dsc

Oracle GoldenGate Delivery process started, group rep1_yy discard file opened: 2023-12-19 14:48:52.006938
Key column SEQUENCE_NO (0) is missing from update on table CC_YY.T_CI_UKEY_APPLY
Missing 1 key columns in update for table CC_YY.T_CI_UKEY_APPLY.
Current time: 2023-12-19 14:48:52
Discarded record from action ABEND on error 0


Aborting transaction on /goldengate/dirdat/yy beginning at seqno 0 rba 5159
                         error at seqno 0 rba 5159
Problem replicating CC_YY.T_CI_UKEY_APPLY to CC_YY.T_CI_UKEY_APPLY
Mapping problem with compressed update record (target format)...
*
PK_APPLY = f3fba1ad-8e9f-41d4-af8f-fb32b5074eba
000000: 66 33 66 62 61 31 61 64 2d 38 65 39 66 2d 34 31 |f3fba1ad-8e9f-41|
000010: 64 34 2d 61 66 38 66 2d 66 62 33 32 62 35 30 37 |d4-af8f-fb32b507|
000020: 34 65 62 61                                     |4eba            |

UPDATE_TIME = 2023-12-19 11:21:39
000000: 32 30 32 33 2d 31 32 2d 31 39 20 31 31 3a 32 31 |2023-12-19 11:21|
000010: 3a 33 39                                        |:39             |

FK_USER_UPDATE = 0397fc36-0074-4fb3-992b-9bd60a48595e
000000: 30 33 39 37 66 63 33 36 2d 30 30 37 34 2d 34 66 |0397fc36-0074-4f|
000010: 62 33 2d 39 39 32 62 2d 39 62 64 36 30 61 34 38 |b3-992b-9bd60a48|
000020: 35 39 35 65                                     |595e            |

USER_NAME_UPDATE = 张三
000000: e7 94 98 e9 9c 96                               |......          |

APPROVE_STATE = APPROVEING_1ST
000000: 41 50 50 52 4f 56 45 49 4e 47 5f 31 53 54       |APPROVEING_1ST  |

*
Process Abending : 2023-12-19 14:48:52

我们去排查目标端 param 参数是否出现中文字符或者中文引号，缺少分号等情况，但是检查下来都没有问题，如下显示都是正常配置，接下来我们去检查 trandata 信息吧。

GGSCI  52> view params rep1_yy

REPLICAT rep1_yy
sourcedefs /goldengate/dirdef/goldengate.def
TARGETDB LIBFILE libggjava.so SET property=dirprm/kafka_prod.props
REPORTCOUNT EVERY 1 MINUTES, RATE
GROUPTRANSOPS 10000
GETUPDATEBEFORES
HANDLECOLLISIONS
REPLACEBADCHAR SUBSTITUTE ? FORCECHECK
MAP CC_YY.T_AUTH_CA_AUTH_TEMP,target CC_YY.T_AUTH_CA_AUTH_TEMP;
map CC_YY.T_CI_OPERATE_FLOW_HIS,target CC_YY.T_CI_OPERATE_FLOW_HIS;
map CC_YY.T_CI_RN_PROGRESS,target CC_YY.T_CI_RN_PROGRESS;
map CC_YY.T_CI_UKEY_APPLY,target CC_YY.T_CI_UKEY_APPLY;
map CC_YY.T_CI_CORP,target CC_YY.T_CI_CORP;
map CC_YY.T_CI_CORP_TEMP,target CC_YY.T_CI_CORP_TEMP;
--mapexclude CC_YY.T_CI_CORP_TEMP;

我们回到源库，去检查报错表 T_CI_UKEY_APPLY 的 trandata 信息，也没有发现异常，尝试重新添加 trandata 信息。甚至直接添加整个 schema 的 trandata 信息也是无果。然后在 SQL 级别和 OGG 级别尝试开启所有列补充日志也是没有效果。

--查看，删除，重新添加 trandata
GGSCI  > info trandata CC_YY.T_CI_UKEY_APPLY
GGSCI  > delete trandata CC_YY.T_CI_UKEY_APPLY
GGSCI  > add trandata CC_YY.T_CI_UKEY_APPLY

GGSCI  > add schematrandata <your_schema_name>

--- from source SQL 
alter table CC_YY.T_CI_UKEY_APPLY drop supplemental log data (all) columns;
alter table CC_YY.T_CI_UKEY_APPLY add  supplemental log data (all) columns;

--- from source GGSCI
GGSCI  > dblogin USERIDALIAS alias_ogg
GGSCI  > Add Trandata CC_YY.T_CI_UKEY_APPLY allcols

2023-12-19 13:56:53  INFO    OGG-15131  Logging of supplemental redo log data is already enabled for table CC_YY.T_CI_UKEY_APPLY.

2023-12-19 13:56:53  WARNING OGG-00706  Failed to add supplemental log group on table CC_YY.T_CI_UKEY_APPLY due to ORA-32588: supplemental logging attribute all column exists
 SQL ALTER TABLE "CC_YY"."T_CI_UKEY_APPLY" ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS  /* GOLDENGATE_DDL_REPLICATION */.

2023-12-19 13:56:53  INFO    OGG-10471  ***** Oracle Goldengate support information on table CC_YY.T_CI_UKEY_APPLY ***** 
Oracle Goldengate support native capture on table CC_YY.T_CI_UKEY_APPLY.
Oracle Goldengate marked following column as key columns on table CC_YY.T_CI_UKEY_APPLY: SEQUENCE_NO.

GGSCI 7> info trandata CC_YY.T_CI_UKEY_APPLY

问题原因

最终在 MOS 上找到了一篇 (Doc ID 2963276.1) Replicat Abends With Key Column <COL_NAME> (0) Is Missing From Update On Table <SCHEMA.TABLENAME> 一样报错的文章，文中描述此问题属于 Bug 35446910,刚好命中此版本 V19.1, Oracle GoldenGate - Version 19.1.0.0.2 and later。

描述中说当我们删除 trandata 后，必须添加 trandata 才能启用 LOGICAL_REPLICATION（PS：实践中 add trandata 也不行），add schemarandata 无法启用 LOGICAL_REPLICATION，因此出现了此问题。删除 trandata 后，它将 LOGICAL_REPLICATION 设置为 DISABLED，添加 schemarandata 之后，由于这没有使关键 cols 进入踪迹，则一直保持为 DISABLED，这是预期的行为。

与 MOS 文章不同的是说 add trandata–>delete trandata–>add schematrandata 这样无法将 LOGICAL_REPLICATION 设置为 ENABLED，确实这样无法变为 ENABLED，那么我后面继续使用 add trandata 也没有将其变为 ENABLED，所以就出现了上面遇到 update 就 ABENDED 的问题。这里顺便说下 LOGICAL_REPLICATION，视图 ALL_ALL_TABLES/DBA_TABLES.LOGICAL_REPLICATION 是 Oracle 19c 新增的一个 VARCHAR2(8) 类型字段，指示是否为表启用逻辑复制（ENABLED）或（DISABLED），如果启用了数据库范围的列数据补充日志记录，则忽略此设置。

SQL> select LOGICAL_REPLICATION from dba_tables where TABLE_NAME='<TABLENAME>';

LOGICAL_
--------
DISABLED

解决方法

删除 transdata 可能会禁用逻辑复制,如果表的逻辑复制被禁用，即使为模式添加了 schemarandata，也不会为表记录任何补充日志数据,实践表明在 19.21 中，删除 trandata 后 add trandata 也不会启用表的逻辑复制（恰巧上周迁移时新建 OGG 环境后刚好执行了 delete trandata 命令），那么我们则可以按照 MOS 文章中的临时解决办法通过 SQL 语句为表启用 LOGICAL REPLICATION。

SELECT LOGICAL_REPLICATION FROM DBA_TABLES 
WHERE TABLE_NAME='T_CI_UKEY_APPLY' AND OWNER='CC_YY';

ALTER TABLE CC_YY.T_CI_UKEY_APPLY ENABLE LOGICAL REPLICATION;

SELECT LOGICAL_REPLICATION FROM DBA_TABLES WHERE TABLE_NAME='T_CI_UKEY_APPLY' AND OWNER='CC_YY';

当对这几个表启用逻辑复制后，重新启动 rep 复制进程正常，使用 stats 查看统计信息相关表的 update 已经有数据进入了，观察了两天没有再次 ABENDED 说明问题得到了解决。

参考链接

Doc ID 2963276.1 Replicat Abends With Key Column <COL_NAME> (0) Is Missing From Update On Table <SCHEMA.TABLENAME> (Doc ID 2963276.1) Bug 35446910 : Extract Does Not Captured Key Cols For An Update After Re-Adding The Schema Trandata。 Bug 35289372 : Extract Does Not Captured Key Cols For An Update After Re-Adding The Trandata https://community.oracle.com/mosc/discussion/3954985/replicat-abend-missing-1-key-columns-in-update-for-table 19c 官方文档:ALL_ALL_TABLES 列信息描述 https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/ALL_ALL_TABLES.html#GUID-B8CF1D2A-9AA0-4C94-BBBA-4672C7CF735F

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2023-12-22，如有侵权请联系 cloudcommunity@tencent.com 删除

迁移