OGG ERRORS 总结
Table of Contents
1 libnnz11.so
完整的错误信息如下:
ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory
在通过ggsci启动时，有可能会遇到如上错误。找不到libnnz11.so动态库文 件. 通过find命令发现该文件在"$ORACLE_HOME/lib"路径中存在的:
$ find $ORACLE_HOME/ -name libnnz11.so /u01/app/oracle/product/11.2.0/dbhome_1/inventory/Scripts/ext/lib/libnnz11.so /u01/app/oracle/product/11.2.0/dbhome_1/inventory/backup/2019-03-08_10-41-36PM/Scripts/ext/lib/libnnz11.so /u01/app/oracle/product/11.2.0/dbhome_1/lib/libnnz11.so
难道是LD_LIBRARY_PATH 没有配置该路径么？
查看LD_LIBRARY_PATH 配置:
$ echo $LD_LIBRARY_PATH /u01/app/oracle/product/11.2.0/dbhome_1/lib:/opt/jdk1.8.0_181//jre/lib/amd64/server/:/opt/jdk1.8.0_181//lib:
配置是对的。那问题出在哪儿呢？
追踪进程吧:
strace ggsci
execve("/u01/app/ogg/ggsci", ["ggsci"], [/* 28 vars */]) = 0
..........
mmap(NULL, 2197528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f6c71c70000
mprotect(0x7f6c71c89000, 2093056, PROT_NONE) = 0
mmap(0x7f6c71e88000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f6c71e88000
close(3) = 0
open("/u01/app/ogg/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=6, ...}) = 0
open("/lib64/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/lib64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=77824, ...}) = 0
open("/usr/lib64/tls/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=6, ...}) = 0
open("/usr/lib64/x86_64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7ffd64847c10) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libnnz11.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=77824, ...}) = 0
writev(2, [{"ggsci", 5}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libnnz11.so", 11}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"
", 1}], 10ggsci: error while loading shared libraries: libnnz11.so: cannot open shared object file: No such file or directory
) = 116
exit_group(127) = ?
+++ exited with 127 +++
从追踪结果来看，ggsci 设定的查询路径是"u01/app/ogg"(这是我的 OGG_HOME路径),及该路径下的tls, "/lib64","/usr/lib64" 三个主路径, 并没有根据LD_LIBRARY_PATH的设置去查找。那么我们只有一个办法: 将该库文件复制一份到 以上三个路径中的一个即可。
解决方法
cp $ORACLE_HOME/lib/libnnz11.so $OGG_HOME/
2 00446
2.1 missing filename opening checkpoint file
2.1.1 错误信息
2019-07-02t23:26:17.998+0800 error ogg-00446 oracle goldengate delivery, xmsys.prm: missing filename opening checkpoint file. 2019-07-02t23:26:17.999+0800 error ogg-01668 oracle goldengate delivery, xmsys.prm: process abending.
2.1.2 分析与解决
出现此错误，原因是参数配置与命令不匹配。比如from file方式的数据应用进程,如果使用ggsci命令start命令 来启动, 则会出现这种错误。下面是两个案例，根本原因都是命令与参数配置不匹配，一种是初始化，一种是实时 应用。
- 案例1->初始化
参数配置 以下配置为一例 OGG FOR KAFKA 的 FROM FILE 方式初始化应用进程的配置。
SPECIALRUN END RUNTIME SETENV(NLS_LANG="AMERICAN_AMERICA.ZHS16GBK") TARGETDB LIBFILE LIBGGJAVA.SO SET PROPERTY=DIRPRM/XMINS.PROPS EXTFILE DIRDAT/II REPORTCOUNT EVERY 1 MINUTES , RATE GROUPTRANSOPS 10000
启动命令
START INITSP
日志
......... 2019-07-02T23:26:15.409+0800 INFO OGG-01360 ORACLE GOLDENGATE DELIVERY, XMSYS.PRM: REPLICAT IS RUNNING IN SPECIAL RUN MODE. 2019-07-02T23:26:15.615+0800 INFO OGG-15052 ORACLE GOLDENGATE DELIVERY, XMSYS.PRM: USING JAVA CLASS PATH: GGJAVA/GGJAVA.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-API-2.9.1.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-CORE-2.9.1.JAR:GGJAVA/RESOURCES/LIB/OPTIONAL/LOG4J-SLF4J-IMPL-2.9.1.JAR. 2019-07-02T23:26:17.988+0800 INFO OGG-01815 ORACLE GOLDENGATE DELIVERY, XMSYS.PRM: VIRTUAL MEMORY FACILITIES FOR: COM ANON ALLOC: MMAP(MAP_ANON) ANON FREE: MUNMAP FILE ALLOC: MMAP(MAP_SHARED) FILE FREE: MUNMAP TARGET DIRECTORIES: /HOME/OGG/DIRTMP. 2019-07-02T23:26:17.998+0800 ERROR OGG-00446 ORACLE GOLDENGATE DELIVERY, XMSYS.PRM: MISSING FILENAME OPENING CHECKPOINT FILE. 2019-07-02T23:26:17.999+0800 ERROR OGG-01668 ORACLE GOLDENGATE DELIVERY, XMSYS.PRM: PROCESS ABENDING.解决
通过操作系统命令 REPLICAT 执行初始化:
$OGG_HOME/REPLICAT PARAMFILE $OGG_HOME/DIRPRM/XMSYS.PRM
- 案例2->实时抽取
参数配置
passthru rmthost 192.168.153.129, mgrport 7809 rmttrail /u02/ggs/dirdat/td gettruncates table scott.*; sequence scott.*;
分析
作为抽取进行，第一行应为进程类型标识，应为:
extract <group name>
2.2 could not find archived log
遇到这个错误时，有可能真的是找不到归档文件，而有的时候可能未配置必要参数引起的找不到归档文件。
2.2.1 错误信息
在ggserr.log 中发现如下错误:
2019-05-31t10:56:53.629+0800 error ogg-00446 oracle goldengate capture for oracle, extxmdev.prm: could not find archived log for sequence 2649 thread 1 under default destinations sql <select name from v$archived_log where sequence# = :ora_seq_no and thread# = :ora_thread and resetlogs_id = :ora_resetlog_id and archived = 'yes' and deleted = 'no' and name not like '+%' and standby_dest = 'no' >, error retrieving redo file name for sequence 2649, archived = 1, use_alternate = 0not able to establish initial position for sequence 2649, rba 13816848. 2019-05-31t10:56:53.641+0800 error ogg-01668 oracle goldengate capture for oracle, extxmdev.prm: process abending.
2.2.2 分析与解决
从错误信息提示来看，是归档日志找不到引起的中断。那么归档文件是不是真的不存在呢？
- 归档不存在
经查看归档日志确实不存在。可根据数据的重要性采取不同的方法来处理此错误。
- 数据不重要
此时可以修改extract 的起始值,跳过缺失的归档文件，这在测试和开发环境 中应用较多。 首先查看可用归档:
select sequence# ,first_change#, next_change# ,deleted,applied,status from v$archived_log; sequence# first_change# next_change# del applied s ---------- ------------- ------------ --- --------- - 3759 16360310 16401138 yes no a 3760 16401138 16419033 no no a从上面的查询结果来看，3759号归档已被删除，最新可用归档是3760. 对应最早的 scn号是16401138. 将extract 进程的scn 值调整至16401138:
alter extrace extxmdev, scn 16401138 start ext extxmdev
- 数据重要
- 此时需要从备份中恢复相应的归档文件
- 归档存在
归档存在，仍遇到这种错误，很有可能 OGG所查找的归档文件与实际归档文件的存储路 径不同 。这种情况在源端为RAC环境中较为常见。因为 OGG 是通过oracle instance 中的参数来查找归档文件的: log_archive_dest[_n]/log_archive_format 而RAC 存储归档至ASM时，实际存储路径可能与参数配置有差异(因为ASM实行文件名自动管理).
这种情况 ，主要是通过tranlogoptions参数，让OGG 登录 ASM实例查找正确的归档文件。 需要在extract进程中配置如下参数:
tranlogoptions asmuser <username@tnsname>,ASMPASSWORD <passwrod> tranlogoptions rawdeviceoffset 0
3 00918
key column unid is missing from map ogg for bigdata中, 我们可能只需要某些字段。而同步的这些字段里并没有主键， 或者是没有包含全部的主键列。在replicat 端会遇到这个问题。
- 解决办法 在 colmap() 后加上keycols(用于做主键的字段) 即可。
4 01163
检查发现OGG for kafka 的replicat 进程状态为abend.
GGSCI (tycxdb1) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING REPFJ 00:00:00 00:00:03 REPLICAT ABENDED REPXM 00:00:00 149:23:41
4.1 错误信息
检查ggserr.log 发现如下报错:
2020-03-16T21:26:02.260+0800 ERROR OGG-01163 Oracle GoldenGate Delivery, repxm.prm: Bad column length (34) specified for column DIST_NAME in table BOSS.T_MKDISTRICT, maximum allowable length is 32.
很明显，是有人修改过了表结构，调整了字段长度。
4.2 问题分析
源端 发现有人在对应表上做了DDL操作:
SQL> select last_ddl_time from dba_objects where object_name='T_MKDISTRICT' AND owner='BOSS'; LAST_DDL_TIME ------------------- 2020-03-09 17:28:07 SQL> SELECT DATA_TYPE||'('||DATA_LENGTH||')' FROM dba_tab_cols where owner='BOSS' and table_name='T_MKDISTRICT' and COLUMN_NAME='DIST_NAME'; DATA_TYPE||'('||DATA_LENGTH||')' -------------------------------------------------------------------------------- VARCHAR2(64)可以看到，当前源库里的字段长度已经是64了。
4.3 解决办法
修改目标库中对应字段的最大长度。 MySQL示例:
alter table t_mkdistrict modify dist_name varchar(64);
重新在源库生成def
cd $OGG_HOME cat ./defgen paramfile dirprm/defgen.def
defgen.def 内容示例:
USERID ogg,PASSWORD ogg defsfile ./dirdef/defxm.def,format release 12.2 table boss.*;
将新生成的定义文件发送到目标端ogg
scp dirdef/defxm.def 100.100.2.3:/ogg/dirdef/
修改ogg replicat进程参数 添加或者修改下面一行。
SOURCEDEFS dirdef/defxm.def override
- NOTE
- 一定要加上override. 此参数的作用，ogg 进行元数据核对时，使用定义文件中的内容， 而不是使用OGG REPLICAT 默认的trail中的meta信息。没有此参数，replicat 进程 仍会默认读取trail中的meta信息，发现实际数据长度大于meta中定义的长度，就会报错。
5 01168
错误信息:
error ogg-01168 encountered an update for target table <schema>.<table_name>, which has no unique key defined. keycols can be used to define a key. use allownoopupdates to process the update without applying it to the target database. use applynoopupdates to force the update to be applied using all columns in both the set and where clause
分析
ogg 同步update 操作，如果目标库中表上没有主键，ogg 无法保证操作的唯一性，因 此会报错。对于这种没有主键表的操作，oracle官方给出了几点建议.见解决方案.
- 解决方法
- allownoopupdates 配置此参数后,将跳过该update操作
- applynoopupdates 配置此参数后, 将强制应用update操作.即根据set 和where 来确定操作范围。
- keycols 在原表定义keycols
- sys_guid
在不满足以下几种情况时，建议在原表建立sys_guid。
- 表上没有或者不适合通过keycols 关键词建立逻辑列.
- 没有重复行
- 表行数少
- 表上的dml操作较少，即使对表上所有字段开启supplimental log 也不会生成大量的redo log.
6 01201
这种错误，出现的场景之一是 direct load 加载数据，遇到此错误时，mgr会根据不同的原因给出不同的提示。
6.1 案例1
错误信息
2019-07-01 06:25:33 info ogg-00993 oracle goldengate capture for oracle, initfj.prm: extract initfj started. 2019-07-01 06:25:33 error ogg-01201 oracle goldengate capture for oracle, initfj.prm: error reported by mgr : access denied. 2019-07-01 06:25:33 error ogg-01668 oracle goldengate capture for oracle, initfj.prm: process abending.
目标端mgr report信息:
warning ogg-00936 access denied (request from xxx.xxx.x.xxx, rule #0).
分析与解决
根据mgr提示的信息，rule #0 说明没有rule规则。这个rule 是mgr里的一个属性，类似于防火墙，表示是否允许远程访问。其语法规则如下:
accessrule[, prog program_name][, ipaddr address][, pri rule][, login_id]{, allow | deny}
在mgr配置文件中添加如下内容即可，表示所有接受所有远程连接。
accessrule, prog *, ipaddr *, allow
6.2 案例2
错误信息 extract 日志:
2019-07-11t10:34:26.437+0800 info ogg-00993 oracle goldengate capture for oracle, gjxm.prm: extract gjxm started. 2019-07-11t10:34:26.440+0800 error ogg-01201 oracle goldengate capture for oracle, gjxm.prm: error reported by mgr : parameter file /home/ogg/dirprm/gjxm.prm does not exist.
- 分析与解决
提示找不到参数文件，实际的原因,有可能是真的找不到参数文件。也有可能是连不上对应的mgr(端口不对，或者目标端的mgr已经停掉)。
那么有以下几种可能:
- extract 指定的rmttask,没有相应的参数文件
- extract参数配置不正确(主要是rmthost 和 mgrport)
目标端mgr未启动 连接目标端执行如下内容:
ggsci info all正常情况mgr的状态应是running:
program status group lag at chkpt time since chkpt manager running
7 01223
7.0.1 场景1
进行数据初始化，使用rmtfile参数，直接将数据抽取到目标端服务器路径。由于之前出现问题，重新抽取时出现如下错误:
源端
2019-09-09T23:17:54.113+0800 INFO OGG-01230 Oracle GoldenGate Capture for Oracle, initzg.prm: Recovered from TCP error, host 192.168.153.21, port 7811. 2019-09-09T23:17:54.119+0800 WARNING OGG-01223 Oracle GoldenGate Capture for Oracle, initzg.prm: TCP/IP error 104 (Connection reset by peer), endpoint: 192.168.153.21:7811.
目标端
2019-09-09T23:17:49.108+0800 INFO OGG-01228 Oracle GoldenGate Collector: Timeout in 300 seconds. 2019-09-09T23:17:54.113+0800 INFO OGG-01229 Oracle GoldenGate Collector: Connected to ::ffff:192.168.180.1:41035. 2019-09-09T23:17:54.114+0800 WARNING OGG-01223 Oracle GoldenGate Collector: Error happened while opening the file. ERRNO = 0.
- 解决 清除目标端原有的数据文件，重新发起进程。
7.0.2 场景2
源端 view report 查看到的报错日志:
ThreadBacktrace : [14] elements : [/ogg/12c/libgglog.so(CMessageContext::AddThreadContext()+0x1e) [0x7fc078648ede]] : [/ogg/12c/libgglog.so(CMessageFactory::CreateMessage(CSourceContext*, unsigned int, ...)+0x340) [0x7fc078643bf0]] : [/ogg/12c/libgglog.so(_MSG_ERR_TCP_RECEIVE_PARAMS_ERROR(CSourceContext*, char const*, CMessageFactory::MessageDisposition)+0x31) [0x7fc07862547b]] : [/ogg/12c/extract(complete_tcp_msg(extract_def*)+0x607) [0x55a02d]] : [/ogg/12c/extract(flush_tcp(extract_def*, int)+0x23a) [0x55a4fa]] : [/ogg/12c/extract() [0x574b1c]] : [/ogg/12c/extract(RECOVERY_initialize()+0x515) [0x571175]] : [/ogg/12c/extract(extract_main(int, char**)+0x345) [0x5bd365]] : [/ogg/12c/extract(ggs::gglib::MultiThreading::MainThread::ExecMain()+0x4f) [0x6a8e1f]] : [/ogg/12c/extract(ggs::gglib::MultiThreading::Thread::RunThread(ggs::gglib::MultiThreading::Thread::ThreadArgs*)+0x104) [0x6a9324]] : [/ogg/12c/extract(ggs::gglib::MultiThreading::MainThread::Run(int, char**)+0x8b) [0x6a96eb]] : [/ogg/12c/extract(main+0x3f) [0x5bcdcf]] : [/lib64/libc.so.6(__libc_start_main+0xfd) [0x331161ed5d]] : [/ogg/12c/extract() [0x52eb29]] 2016-03-11 11:54:33 ERROR OGG-01232 Receive TCP params error: TCP/IP error 104 (Connection reset by peer), endpoint: 172.19.41.35:17811. 2016-03-11 11:54:33 ERROR OGG-01668 PROCESS ABENDING.解决方法
alter extract <extract group name> ,etrollover
执行此命令，使用关键词etrollover 的作用是强制生成一个新的文件。
7.0.3 场景3
extract 抽取数据，通过rmthost ,rmtfile/rmttrail直接将数据发送到目标端服务器。
源端
2016-08-02 01:08:16 WARNING OGG-01223 Oracle GoldenGate Capture for Oracle, lpg2.prm: TCP/IP error 104 (Connection reset by peer), endpoint: {target ip removed by me} :7810. 2016-08-02 01:08:37 INFO OGG-01230 Oracle GoldenGate Capture for Oracle, lpg2.prm: Recovered from TCP error, host {target ip removed by me}, port 7811. 2016-08-02 01:08:37 ERROR OGG-01033 Oracle GoldenGate Capture for Oracle, lpg2.prm: There is a problem in network communication, a remote file problem, encryption keys for target and source do not match (if using ENCRYPT) or an unknown error. (Remote file目标端
2016-08-01 20:08:37 WARNING OGG-01223 Oracle GoldenGate Collector for Oracle: Unable to lock file "/u01/app/oracle/product/ggate/dirdat/g2000000000" (error 11, Resource temporarily unavailable). Lock currently held by process id (PID) 20290.
解决方法 在 RMTHOST 一行 添加 NOSTREAMING 关键词。即异步方式传输数据。
RMTHOST *.*.*.* MGRPORT 7809 NOSTREAMING
8 01877
- 错误信息
2019-06-27T04:04:42.653+0800 WARNING OGG-00938 Oracle GoldenGate Manager for MySQL, mgr.prm: Manager is stopping at user request. 2019-06-27T06:53:06.837+0800 INFO OGG-00987 Oracle GoldenGate Command Interpreter for MySQL: GGSCI command (ogg): start mgr. 2019-06-27T06:53:07.175+0800 WARNING OGG-01877 Oracle GoldenGate Manager for MySQL, mgr.prm: Missing explicit accessrule for server collector.
- 原因
通过shell 方式添加参数文件，但是未添加初始化进程。使用如下命令添加：
add replicat <group name>, specialrun
extract / replicat 参数文件中未找到 groupname 参数文件中第一行，应该是
extract <group name>
或者
replicat <group name>
如果第一未指定 group name,会遇到这种错误。
9 02422
源端日志报错信息
2019-07-01 06:53:27 INFO OGG-00993 Oracle GoldenGate Capture for Oracle, initfj.prm: EXTRACT INITFJ started. 2019-07-01 06:54:00 WARNING OGG-01194 Oracle GoldenGate Capture for Oracle, initfj.prm: EXTRACT task INITFJ abended : Initial data load error reported by REPLICAT. 2019-07-01 06:54:00 ERROR OGG-01203 Oracle GoldenGate Capture for Oracle, initfj.prm: EXTRACT abending. 2019-07-01 06:54:00 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, initfj.prm: PROCESS ABENDING.
目标端报错信息
2019-06-26T18:20:28.369+0800 ERROR OGG-02422 Oracle GoldenGate Delivery for MySQL: Could not open checkpoint file /home/ogg/ogg_for_mysql/dirchk/INITFJ.cpr (error 2, No such file or directory). 2019-06-26T18:20:33.371+0800 ERROR OGG-01668 Oracle GoldenGate Delivery for MySQL: PROCESS ABENDING.
分析
从目标端的错误信息来看，很明显是文件或者路径不存在。在mgr 配置里，如果有 usecheckpoint , 那么replicate 一定要可以生成cpr文件(检查点文件),文件名规则为 replicate_name.cpr。
解决
如果dirchk目录下有其他的检查点文件, 根据命名规则复制一个新文件，即可解决。 或者重新添加replication 进程:
add replication initfj,specialrun
10 02245
场景: 通过fromfile 方式初始化数据。 此错误，大部分是由于无法正常处理数据。比如无法处理空值,比如实际值大于字符允许最大长度等。 处理此错误，一定要有discard 记录。该记录中记录了最明确的问题点。
10.1 示例1: OGG 无法处理空值
日志报错
2019-07-11T23:54:06.496+0800 WARNING OGG-01431 Oracle GoldenGate Delivery for MySQL, gjxm.prm: Aborted grouped transaction on uqs.ins_off_ins_prod_rel, Mapping error. 2019-07-11T23:54:06.506+0800 WARNING OGG-01003 Oracle GoldenGate Delivery for MySQL, gjxm.prm: Repositioning to rba 324447170 in seqno 2. 2019-07-11T23:54:06.656+0800 WARNING OGG-01151 Oracle GoldenGate Delivery for MySQL, gjxm.prm: Error mapping from BOSS.GJ_INS_OFF_INS_PROD_REL to uqs.ins_off_ins_prod_rel. 2019-07-11T23:54:06.690+0800 ERROR OGG-01296 Oracle GoldenGate Delivery for MySQL, gjxm.prm: Error mapping from BOSS.GJ_INS_OFF_INS_PROD_REL to uqs.ins_off_ins_prod_rel.
discard信息
Oracle GoldenGate Delivery for MySQL process started, discard file opened: 2019-07-11 14:17:38.924345 Mapping error to target column: PROD_SPEC_ID Mapping error to target column: PROD_SPEC_ID Current time: 2019-07-11 14:17:49 Discarded record from action ABEND on error 0 .............. PROD_SPEC_ID = 000000: 20 | | .......... 2019-07-11 11:20:25 WARNING OGG-01431 Aborted grouped transaction on uqs.ins_off_ins_prod_rel, Mapping error. ........ 2019-07-11 11:20:25 ERROR OGG-02245 Repositioning was attempted as REPERROR action, but is not supported by RMTTASK.
从以上报错来看应该是OGG 不能处理数据。
- 对比数据类型
从discard 报错信息来看, prod_spec_id 字段为空。没有实际值。对比源端与目标端的字段类型:
- 源端
PROD_SPEC_ID CHAR(1)
- 目标端
| prod_spec_id | bigint(20) | YES | | 0 |
查看源端数据
SQL> select count(distinct PROD_SPEC_ID) from test_; COUNT(DISTINCTPROD_SPEC_ID) --------------------------- 1 SQL> select replace(prod_spec_id,' ',1) from test_ where rownum=1; R - 1从查看结果来看，该字段只有一个值，值为一个空格。看来结论已经有了: OGG 无法将空格转换为数值类型
10.2 示例2: 无法处理超长数据
ggserr.log 提示信息
2019-07-17T04:59:54.242+0800 WARNING OGG-01431 Oracle GoldenGate Delivery for MySQL: Aborted grouped transaction on test.test, Mapping error. 2019-07-17T04:59:54.251+0800 ERROR OGG-02245 Oracle GoldenGate Delivery for MySQL: Repositioning was attempted as REPERROR action, but is not supported by RMTTASK. 2019-07-17T04:59:59.254+0800 ERROR OGG-01668 Oracle GoldenGate Delivery for MySQL: PROCESS ABENDING.
discard信息
Oracle GoldenGate Delivery for MySQL process started, group GJFJ8 discard file opened: 2019-07-17 04:58:20.204905 Mapping error to target column: REPLACE Current time: 2019-07-17 04:59:54 ......... REPLACE = 173449918020032271 000000: 31 37 33 34 34 39 39 31 38 30 32 30 30 33 32 32 |1734499180200322| 000010: 37 31 |71 | ......
查看源表信息
SQL> select max(length(replace)) from test.test; MAX(LENGTH(REPLACE)) -------------------- 18
查看目标表信息
+---------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------+--------------+------+-----+---------+----------------+ .......... | replace | smallint(6) | YES | | 0 | | ........
从以上对比来看，可以明确信息: replace 字段的实际值最大长度为18，而表中允许的最大长度为6. 目标表无法存储对应数据。
10.3 解决
更改源数据,使其符合目标表的长度,或者修改目标表，使其拥有足够长度存储数据。
update test_ set prod_spec_id=1;
Created: 2020-03-16 Mon 22:02