(转)goldengate 复制进程replicat出现ORA-01403 错误

简介: 最近,在goldengate的应用场景中,replicat进程经常出现append,start也启动不起来,查看日志,发现出现ora-01403错误,日志内容如下:   2012-09-27 19:06:39  INFO    OGG-00996  Oracle GoldenGate Delivery for Oracle, C_R_C6.

最近,在goldengate的应用场景中,replicat进程经常出现append,start也启动不起来,查看日志,发现出现ora-01403错误,日志内容如下:

 

  1. 2012-09-27 19:06:39  INFO    OGG-00996  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  REPLICAT C_R_C6 started. 
  2. 2012-09-27 19:06:40  WARNING OGG-01004  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  Aborted grouped transaction on '***.TB_COMMON_CUSTEMPRELATION'Database error 1403 (OCI Error ORA-01403: no data found, SQL <UPDATE "***"."TB_COMMON_CUSTEMPRELATION" SET "PK" = :a0,"FK" = :a1,"CREATETIME" = :a2,"LASTMODIFYTIME" = :a3,"LINEID" = :a5,"DELETEFLAG" = :a6,"NOTE" = :a7,"VERSION" = :a11 WHERE "BRANCHID" = :b0 AND "CUSTID" = :b1 AND "BUSINESTYPECODE" = :b2 AND "STAFFID" = :b3>). 
  3. 2012-09-27 19:06:40  WARNING OGG-01003  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  Repositioning to rba 1829839 in seqno 19. 
  4. 2012-09-27 19:06:40  WARNING OGG-01154  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  SQL error 1403 mapping ***.TB_COMMON_CUSTEMPRELATION to ***.TB_COMMON_CUSTEMPRELATION OCI Error ORA-01403: no data found, SQL <UPDATE "***"."TB_COMMON_CUSTEMPRELATION" SET "PK" = :a0,"FK" = :a1,"CREATETIME" = :a2,"LASTMODIFYTIME" = :a3,"LINEID" = :a5,"DELETEFLAG" = :a6,"NOTE" = :a7,"VERSION" = :a11 WHERE "BRANCHID" = :b0 AND "CUSTID" = :b1 AND "BUSINESTYPECODE" = :b2 AND "STAFFID" = :b3>. 
  5. 2012-09-27 19:06:40  WARNING OGG-01003  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  Repositioning to rba 1829839 in seqno 19. 
  6. 2012-09-27 19:06:41  ERROR   OGG-01296  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  Error mapping from ***.TB_COMMON_CUSTEMPRELATION to ***.TB_COMMON_CUSTEMPRELATION. 
  7. 2012-09-27 19:06:41  ERROR   OGG-01668  Oracle GoldenGate Delivery for Oracle, C_R_C6.prm:  PROCESS ABENDING. 

   从日志中分析,发现关键信息处为:

Database error 1403 (OCI Error ORA-01403: no data found, SQL <UPDATE "***"."TB_COMMON_CUSTEMPRELATION" SET "PK" = :a0,"FK" = :a1,"CREATETIME" = :a2,"LASTMODIFYTIME" = :a3,"LINEID" = :a5,"DELETEFLAG" = :a6,"NOTE" = :a7,"VERSION" = :a11 WHERE "BRANCHID" = :b0 AND "CUSTID" = :b1 AND "BUSINESTYPECODE" = :b2 AND "STAFFID" = :b3>)

于是使用logdump来分析,分析过程如下:

 

 

  1. GGSCI (WIN-O6ODS01HLMM) 119> info c_r_c6 
  2.  
  3. REPLICAT   C_R_C6    Last Started 2012-09-27 10:29   Status ABENDED 
  4. Checkpoint Lag       00:00:00 (updated 01:53:55 ago) 
  5. Log Read Checkpoint  File ./dirdat/cm000019 
  6.                      2012-09-27 04:00:47.720000  RBA 1771589 
  7. 然后用logdump查看: 
  8. Logdump 48 >open ./dirdat/cm000019 
  9.  
  10. LogTrail ***dirdat\cm000015 closed 
  11.  
  12. Current LogTrail is ***\dirdat\cm000019 
  13.  
  14. Logdump 49 >pos 1771589 
  15.  
  16. Reading forward from RBA 1771589 
  17.  
  18. Logdump 50 >n 

 

  1. 2012/09/27 08:36:10.858.000 FieldComp            Len   194 RBA 1776078 
  2. Name: ***.TB_COMMON_CUSTEMPRELATION 
  3. After  Image:                                             Partition 4   G  m 
  4.  0000 000d 0000 0009 3937 3035 3130 3030 3100 0100 | ........970510001... 
  5.  0c00 0000 0833 3039 3130 3030 3600 0200 1500 0032 | .....30910006......2 
  6.  3031 322d 3038 2d32 383a 3130 3a33 303a 3037 0003 | 012-08-28:10:30:07.. 
  7.  0015 0000 3230 3132 2d30 392d 3237 3a30 383a 3336 | ....2012-09-27:08:36 
  8.  3a30 3900 0400 0700 0000 0346 5741 0005 000a 0000 | :09........FWA...... 
  9.  0000 0000 0000 0000 0006 000a 0000 0000 0000 0000 | .................... 
  10.  0000 0007 0004 ffff 0000 0008 000f 0000 000b 4457 | ..................DW 
  11. Column     0 (x0000), Len    13 (x000d) 
  12.  0000 0009 3937 3035 3130 3030 31                  | ....970510001 
  13. Column     1 (x0001), Len    12 (x000c) 
  14.  0000 0008 3330 3931 3030 3036                     | ....30910006 
  15. Column     2 (x0002), Len    21 (x0015) 
  16.  0000 3230 3132 2d30 382d 3238 3a31 303a 3330 3a30 | ..2012-08-28:10:30:0 
  17.  37                                                | 7 
  18. Column     3 (x0003), Len    21 (x0015) 
  19.  0000 3230 3132 2d30 392d 3237 3a30 383a 3336 3a30 | ..2012-09-27:08:36:0 
  20.  39                                                | 9 
  21. Column     4 (x0004), Len     7 (x0007) 
  22.  0000 0003 4657 41                                 | ....FWA 
  23. Column     5 (x0005), Len    10 (x000a) 
  24.  0000 0000 0000 0000 0000                          | .......... 
  25. Column     6 (x0006), Len    10 (x000a) 
  26.  0000 0000 0000 0000 0000                          | .......... 
  27. Column     7 (x0007), Len     4 (x0004) 
  28.  ffff 0000                                         | .... 
  29. Column     8 (x0008), Len    15 (x000f) 
  30.  0000 000b 4457 4930 3030 3531 3138 37             | ....DWI00051187 
  31. Column     9 (x0009), Len     8 (x0008) 
  32.  0000 0004 4253 3036                               | ....BS06 
  33. Column    10 (x000a), Len    15 (x000f) 
  34.  0000 000b 5a49 5930 3030 3031 3836 36             | ....ZIY00001866 
  35. Column    11 (x000b), Len    10 (x000a) 
  36.  0000 0000 0000 0000 0002                          | .......... 
  37.  
  38. Logdump 67 > 

从上面的信息看,发现记录update操作时数据 信息不全,有的列没有值(这种情况要关注更新主键时goldengate的处理,此文暂不讨论),接着在target端查看要update的这条记录,发现没有(这情况是target端缺失update数据),再看replicat配置文件 信息:

  1. REPLICAT c_r_c6 
  2. SETENV (NLS_LANG = "AMERICAN_AMERICA.ZHS16GBK")  
  3. GETENV (NLS_LANG) 
  4. USERID ************ 
  5. --HANDLECOLLISIONS 
  6. ASSUMETARGETDEFS 
  7. --DDLERROR DEFAULT IGNORE RETRYOP 
  8. --REPERROR DEFAULT, DISCARD 
  9. MAP ***.TB_COMMON_CUSTEMPRELATION ,TARGET ***.TB_COMMON_CUSTEMPRELATION , keycols (BRANCHID, CUSTID, BUSINESTYPECODE, STAFFID); 

handcollisions被 注释了,也就是说当target端缺失delete 、update数据时,target端无法自动处理。

解决:

停止replicat进程,先将要同步的表tb_common_custemprelation给跳过,然后将在目标端上重新初始化此表,保证源和目标上此表的数据是一致,然后再在replicat进程中将tb_commmon_custemprelation加进去,然后启动进程。

总结:此案例中是源目标端表中数据不一致导致的。

但是在goldengate应用场景中出现ORA-01403的原因有3个:

 

1) 如果是表字段不一致,需要修改表字段,异构数据库还需要重新生成表结构定义文件,再重启进程。

2) 如果是索引不一致,需要重建索引,异构数据库还需要重新生成表结构定义文件,再重启进程。

3) 遇到这种情况,不能先去对比两端的表结构(可能修改表结构的sql在后面执行),而应该先去查明原因。若是数据问题,可以跳过该表的同步,然后重新同步该表。

本文出自 “oracle研习” 博客,请务必保留此出处http://2874575.blog.51cto.com/2864575/1009786

目录
相关文章
|
SQL 运维 Oracle
【大数据开发运维解决方案】ogg(GoldenGate)三大进程常用参数
PORT 7809 管理进程的监听端口,默认使7809,当7809不可用时会从DYNAMICPORTLIST定义的列表中选择一个可用的端口,主要用于本地goldengate进程之间的通信 DYNAMICPORTLIST 7810-7860 动态端口,可以指定最大256个可用端口列表,用于主端和备端的进程通信,当目标端有防火墙设置时或者主端的投递进程传送数据要经过防火墙(就是主端有防火墙设置时)才能到达备端时,需要在网络上开通指定的端口。源端和目标段的Collector、Replicat、GGSCI进程通信也会使用这些端口,指定足够的端口去容纳进程数的扩张,这样就不需要停止和重启管理器进程
【大数据开发运维解决方案】ogg(GoldenGate)三大进程常用参数
|
Oracle 关系型数据库 算法
Goldengate进程的拆分与合并
Goldengate的拆分与合并分类: ORACLE GoldenGate 2013-10-10 15:22 721人阅读 评论(0) 收藏 举报在使用Goldengate作为复制解决方案时,随着负载的增加,replicat组件常常是最先出现性能瓶颈的。
942 0
|
监控 Oracle 关系型数据库
用飞信监控GoldenGate进程
监控GoldenGate进程 1)         在goldengate安装目录下建立文件ogginfo $vim ogginfo  info all 2)         配置飞信报警                                      下载飞信安装包http://down.
971 0
|
关系型数据库 Oracle
GoldenGate 配置extract,replicat进程自启动
在GoldenGate中主进程是manager进程,使用start mgr启动。可以在mgr进程中添加一些参数用来在启动mgr进程的同时启动extract和replicat进程   GGSCI (gg01) 130> VIEW params mgr   --mgr主进程端口号   PORT...
913 0
|
6月前
|
监控 Linux 应用服务中间件
探索Linux中的`ps`命令:进程监控与分析的利器
探索Linux中的`ps`命令:进程监控与分析的利器
136 13
|
5月前
|
运维 关系型数据库 MySQL
掌握taskset:优化你的Linux进程,提升系统性能
在多核处理器成为现代计算标准的今天,运维人员和性能调优人员面临着如何有效利用这些处理能力的挑战。优化进程运行的位置不仅可以提高性能,还能更好地管理和分配系统资源。 其中,taskset命令是一个强大的工具,它允许管理员将进程绑定到特定的CPU核心,减少上下文切换的开销,从而提升整体效率。
掌握taskset:优化你的Linux进程,提升系统性能
|
5月前
|
弹性计算 Linux 区块链
Linux系统CPU异常占用(minerd 、tplink等挖矿进程)
Linux系统CPU异常占用(minerd 、tplink等挖矿进程)
189 4
Linux系统CPU异常占用(minerd 、tplink等挖矿进程)
|
4月前
|
算法 Linux 调度
探索进程调度:Linux内核中的完全公平调度器
【8月更文挑战第2天】在操作系统的心脏——内核中,进程调度算法扮演着至关重要的角色。本文将深入探讨Linux内核中的完全公平调度器(Completely Fair Scheduler, CFS),一个旨在提供公平时间分配给所有进程的调度器。我们将通过代码示例,理解CFS如何管理运行队列、选择下一个运行进程以及如何对实时负载进行响应。文章将揭示CFS的设计哲学,并展示其如何在现代多任务计算环境中实现高效的资源分配。