导航：首页 > 数据库 >

OGG问题 ORA-01403的处理办法

发表于：2026-10-31 作者：千家信息网编辑

千家信息网最后更新 2026年10月31日，认识logdump分析工具及常用命令：http://book.51cto.com/art/201202/319253.htmhttp://www.killdb.com/2012/09/01/golde

千家信息网最后更新 2026年10月31日OGG问题 ORA-01403的处理办法

认识logdump分析工具及常用命令：http://book.51cto.com/art/201202/319253.htm

http://www.killdb.com/2012/09/01/goldengate-%E5%AD%A6%E4%B9%A0%E7%B3%BB%E5%88%974-logdump.html

在OGG中，报ORA-01403: no data found，原因一般就是源端要插入、更新一条数据，目标端已经存在，或者源端要删除一条数据，目标端已经删除了。目标端就会报错，然后挂掉。一般我们处理，就是先确定是那些数据的问题，如果数量少，在目标端删除或者增加这条数据即可，要是设计数量比较多，就跳过这一段的日志应用（比如对一张表进行10条插入或删除）直接进行下一段的应用。如果你无法判断该跳过多少日志，或者嫌麻烦，就直接进行单表的初始化。

下面进行一个简单的跳过日志的实验。

源端配置：

GGSCI (db1) 6> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT RUNNING EXTFPZX 00:00:00 00:00:03

GGSCI (db1) 7> view params EXTFPZX

extract extfpzx

userid ogg,password ogg

rmthost 192.168.25.101,mgrport 7809

rmttrail /u01/goldengate/dirdat/fp

ddl include mapped objname db_fpzx.*;

table db_fpzx.liuliu;

table db_fpzx.eee;

table db_fpzx.eee1;

GGSCI (db1) 8>

目标端配置：

GGSCI (db2) 4> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

REPLICAT RUNNING REPFPZX 00:00:00 00:00:00

GGSCI (db2) 5> view params repfpzx

REPLICAT repfpzx

USERID ogg,PASSWORD ogg

discardfile /u01/goldengate/discard/rep2_discard.dsc, append, megabytes 10

DDL INCLUDE MAPPED

DDLERROR DEFAULT IGNORE RETRYOP

ASSUMETARGETDEFS

map db_fpzx.liuliu, target db_fpzx.liuliu;

map db_fpzx.eee, target db_fpzx.eee;

map db_fpzx.eee1, target db_fpzx.eee1;

mapexclude db_fpzx.liu123,TABLEEXCLUDE db_fpzx.liu123;

GGSCI (db2) 6>

（不好意思，做测试的OGG，配置比较简陋，嘿嘿。）

从配置可以看出同步的几张表，我们就用liuliu这张表做实验。

源端和目标端数据一样：

在目标端删除一条数据：

源端和目标端执行info all ，主程序和子程序都是正常的。没有问题。

下面我们在源端删除id为2的数据：

此时两边再次执行info all ，查询状态：

源端是没有问题的，但是目标端变为 ABENDED ：

GGSCI (db2) 8> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

REPLICAT ABENDED REPFPZX 00:00:04 00:00:35

下面是问题分析及处理过程

首先得查询两端的配置（我已经贴出）确定错误日志文件是

/u01/goldengate/discard/rep2_discard.dsc

进入到此目录，查看日志

[oracle@db2 discard]$ pwd

/u01/goldengate/discard

[oracle@db2 discard]$ more rep2_discard.dsc

Oracle GoldenGate Delivery for Oracle process started, group REPFPZX discard file opened: 2016-11-25 15:40:10

Current time: 2016-11-25 15:51:40

Discarded record from action ABEND on error 1403

OCI Error ORA-01403: no data found, SQL

Aborting transaction on /u01/goldengate/dirdat/fp beginning at seqno 6 rba 1259

error at seqno 6 rba 1259

Problem replicating DB_FPZX.LIULIU to DB_FPZX.LIULIU

Record not found

Mapping problem with delete record (target format)...

ID = 2

Process Abending : 2016-11-25 15:51:40

日志很清楚地指出了在删除DB_FPZX.LIULIU表中ID为2的数据的时候，出了错"ORA-01403: no data found"，此时应该去查查目标库中此数据是否被删除了（我这里当然是删除了）

我们再往源端添加几条数据：

不用多说。目标库中肯定是没有这些数的，因为已经ABENDED了。

下面分析dump文件：

目标端

GGSCI (db2) 10> info repfpzx

REPLICAT REPFPZX Last Started 2016-11-25 15:40 Status ABENDED

Checkpoint Lag 00:00:04 (updated 00:17:23 ago)

Log Read Checkpoint File /u01/goldengate/dirdat/fp000006

2016-11-25 15:51:36.385195 RBA 1259

查询显示repfpzx此时用的文件是/dirdat/fp000006，咱们就用logdump工具打开这个文件看看

[oracle@db2 goldengate]$ ./logdump

Oracle GoldenGate Log File Dump Utility for Oracle

Version 11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_120423.0230

Logdump 36 >open ./dirdat/fp000006

Current LogTrail is /u01/goldengate/dirdat/fp000006

Logdump 37 >count

LogTrail /u01/goldengate/dirdat/fp000006 has 9 records

Total Data Bytes 1347

Avg Bytes/Record 149

Delete 1

Insert 6

RestartOK 1

Others 1

Before Images 1

After Images 7

Average of 5 Transactions

Bytes/Trans ..... 355

Records/Trans ... 1

Files/Trans ..... 1

Count命令显示信息。由于这个文件操作比较少，可以看见里面的记录包括一次删除，6次插入。一次删除就是删除id为2的记录。6次插入就是我除了插入2,3,4,5,6以外还有一次插入（我之前插入id为2的记录）。当然了，这些数据没啥用，时间久了这里面的delete和insert计数太多了，根本不可能也没必要去搞清楚都是谁。

下面咱们看细节：

Logdump 38 >pos 1259 ----pos + RBA号，直接跳到这个记录上，这里为什么跳到1259呢？因为info repfpzx 命令查询出来的结果告诉我们，1259是他当前正在处理的事务。

Reading forward from RBA 1259

Logdump 39 >sfh ----寻找此号码之后，最近的一个有效记录。N表示next，下一条事务。

下面进行看图讲故事环节：

红色横线标注的，是此事务进行的操作

×××横线标注的，是此事务的BRA，由此可见，BRA并不是每个都+1的，而是跳着的！

红色箭头标注的，还用我说吗？就是关键数据啊2，3，4,不都是ID嘛！

由此可见，RBA为1259的事务是个删除操作，它涉及到的是db_fpzx.liuliu表中id为2的数据。和我们看dsc文件是一样的结果。（废话~~~）

注：关于logdump工具的一些关键命令：

Pos 跳到某一个RBA，这个RBA不需要一定存在，需要配合sfh使用

Sfh 跳到当前RBA的下一个有效RBA

pos eof 跳到文件末尾

Pos reverse 反向读取

我们目标端数据既然已经删除此数据了，我们就需要跳过1259，直接从1383开始恢复就可以了。

（另一种就是手工添加这条数据，启动进程，日志自然会删除它，然后就进行到下一步了）

命令是：

Alter replicat repfpzx（进程名），extrba 1383

执行完之后，进程会变为STOPPED状态，start它就行了。

PS：我本来以为在执行以上命令之前，先往目标库中插入ID为4的数据，OGG会把我在源库中插入的

insert into liuliu (id,name,www) values (2,'liu','liuliu222');

insert into liuliu (id,name,www) values (3,'liu','liuliu333');

先"复原"到目标库，然后在

insert into liuliu (id,name,www) values (4,'liu','liuliu444');

这一句上再次ABENDED，然后此时目标库中的数据应该是有1、2、3、4，没有5、6。

我再执行Alter replicat repfpzx（进程名），extrba （ID为5的RBA号），重启进程，5、6才能进入到目标库中

可是出乎我意料，我在目标端插入数据：

之后执行：

Alter replicat repfpzx，extrba 1383

目标端并没有出现我想要的这种情况：

而是依然只有1和4 两条数据，而且进程没有起来。

查看dsc文件显示：

……省略……

Current time: 2016-11-25 16:44:17

Discarded record from action ABEND on error 1

OCI Error ORA-00001: unique constraint (DB_FPZX.SYS_C0010982) violated (status = 1). INSERT INTO "DB_FPZX"."LIULIU" ("ID","AGE","NAME","EEE","WWW") V

ALUES (:a0,:a1,:a2,:a3,:a4)

Aborting transaction on /u01/goldengate/dirdat/fp beginning at seqno 6 rba 1383

error at seqno 6 rba 1697

Problem replicating DB_FPZX.LIULIU to DB_FPZX.LIULIU

Mapping problem with insert record (target format)...

ID = 4

AGE = NULL

NAME = liu

EEE = NULL

WWW = liuliu444

Continuing to discard records up to the last discarded record from action ABEND

Operation discarded from seqno 6 rba 1383