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}, {"\n", 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