本文是关于如何处理OGG ora-01403错误。我觉得边肖很实用,就和大家分享一下作为参考。让我们跟着边肖看一看。
OG运维中有一个经典错误——1403。现象是目标复制更新或删除操作导致复制进程中止,因为在更新或删除过程中找不到目标数据。关于数据不在目标中的原因有很多可能,比如手动删除、触发器未禁用导致的删除、级联外键删除未禁用导致的删除等等。我们通常的故障排除方法是确认目标端的触发器、级联外键删除以及作业是否已启动。如果启用,请禁用它。然后检查源表是否有主键,主键在trandata中是否有效。如果以上故障排除没有问题,开始做表级初始化,数据泵导出导入,同步更改。
但是有时,我们可以采取“填补空白”的方法来快速恢复复制过程,而不是这样做。想法如下:
1.通过目标端的ggserr日志和replcat.dsc文件找到丢失的数据。
2.在源端,使用数据库链接执行插入到目标端从源表中选择*其中=(步骤1中确认的条件)手动填写空缺。
3.启动复制过程,复制过程将在中止之前重新操作失败的操作。
以下是演示上述过程的实验。
1.源插入第一个测试数据
插入到测试中(测试标识、国家、州、税种、税率)
值(1,' CN ',' 68 ',' WT3 ',0.0015);
提交;
2.目标确认同步
从fm_tax_rate_test中选择*;
国家统计税税率测试标识
- - - - -
CN 68 WT3 .0015 1
3.目标删除了复制记录,人为制造了1403个错误。
从fm_tax_rate_test中删除,其中test _ id=1;
提交;
由4.源更新第一个测试记录将导致目标复制过程中断。中断的原因是update语句中where子句定位的数据在目标端不存在,因为我只是手动删除了这条记录。
更新FM_TAX_RATE_TEST设置国家='美国',其中TEST _ id=1;
提交;
此时,目标终端已被中断,数据更改被添加到源中。预计这些故障导致的更改将在目标重新启动后应用。
插入到测试中(测试标识、国家、州、税种、税率)
数值(2,' TW ',' 68 ',' WT3 ',0.0015);
插入到测试中(测试标识、国家、州、税种、税率)
数值(3,' JP ',' 68 ',' WT3 ',0.0015);2
提交;
目标复制过程中断
GGSCI (cdbsym3) 6信息全部
自更改后更改时间的程序状态组延迟
管理器运行
replat RUNNING REPSYM 00:00:00 00336000:02
ABENDEDREPSYM _ T 00:10:20 00:00:01
目标ggserr.log中的错误信息片段
2015-03-31 13:50:26警告OGG-01004甲骨文公司为甲骨文公司交付的甲骨文公司,repsym_t.prm:在“OGG _测试”上中止了分组交易。error 1403数据库(OCI错误ORA-01403:no data found,SQLUPDATE "OG
G_TEST"."FM_TAX_RATE_TEST" SET "COUNTRY" = :a1,"STATE" = :a2,"TAX_TYPE" = :a3,"TAX_RATE" = :a4,"TEST_ID" = :a5 WHERE "TEST_ID" = :b0>).
2015-03-31 13:50:26 WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle, repsym_t.prm: Repositioning to rba 170249512 in seqno 12.
2015-03-31 13:50:26 WARNING OGG-01154 Oracle GoldenGate Delivery for Oracle, repsym_t.prm: SQL error 1403 mapping OGG_TEST.FM_TAX_RATE_TEST to OGG_TEST.FM_TAX_RATE_TEST OCI Error ORA-01403: no data found, SQL <UPDATE "OGG_TEST"."FM_TAX_RATE_TEST" SET "COUNTRY" = :a1,"STATE" = :a2,"TAX_TYPE" = :a3,"TAX_RATE" = :a4,"TEST_ID" = :a5 WHERE "TEST_ID" = :b0>.
2015-03-31 13:50:26 WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle, repsym_t.prm: Repositioning to rba 170249512 in seqno 12.
2015-03-31 13:50:26 ERROR OGG-01296 Oracle GoldenGate Delivery for Oracle, repsym_t.prm: Error mapping from OGG_TEST.FM_TAX_RATE_TEST to OGG_TEST.FM_TAX_RATE_TEST.
2015-03-31 13:50:26 ERROR OGG-01668 Oracle GoldenGate Delivery for Oracle, repsym_t.prm: PROCESS ABENDING.
target端discard文件中记录了test_id=1的数据执行udpate失败
more repsym_t.dsc
Oracle GoldenGate Delivery for Oracle process started, group REPSYM_T discard file opened: 2015-03-31 13:50:25
Current time: 2015-03-31 13:50:26
Discarded record from action ABEND on error 1403
OCI Error ORA-01403: no data found, SQL <UPDATE "OGG_TEST"."FM_TAX_RATE_TEST" SET "COUNTRY" = :a1,"STATE" = :a2,"TAX_TYPE" = :a3,"TAX_
RATE" = :a4,"TEST_ID" = :a5 WHERE "TEST_ID" = :b0>
Aborting transaction on ./dirdat/yt beginning at seqno 12 rba 170249512
error at seqno 12 rba 170249512
Problem replicating OGG_TEST.FM_TAX_RATE_TEST to OGG_TEST.FM_TAX_RATE_TEST
Record not found
Mapping problem with compressed key update record (target format)...
*
TEST_ID = 1
COUNTRY = US
STATE = 68
TAX_TYPE = WT3
TAX_RATE = .00150000
TEST_ID = 1
这时候很多运维人员最常用的就是按照csn一致性导出source表,重新初始化target端数据不一致的表。在使用下面的方式来修改复制进程参数文件,重启复制进程追进度。
map schema.table, target schema.table, filter (@GETENV ("TRANSACTION", "CSN") > 9527);
如果同步的表比较大,这个过程会很漫长。
如果只是缺少那么几条数据,别人被认为误删除了造成的,也需要这么大动干戈处理么?其实可以用个简单的方法来处理,在源库创建一个database link,将target端缺少的数据手工insert过去补全这个漏洞,然后启动复制进程。复制进程会再次尝试失败的update语句,where字句锁定刚才手工插入的数据,修改成功。 复制进程继续应用source端数据变化。
5. 源端创建database link。其中SERVICE_NAME = data为target数据库的SID
5-1 在tnsnames.ora中添加target端数据库的字符串
to19 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.78.2.19)(PORT = 1553))
)
(CONNECT_DATA =
(SERVICE_NAME = data)
)
)
5-2 创建database link指向target数据库; 其中ogg_test为target数据库的schema。
create public databbase link to19 connect to ogg_test identified by ogg_test;
5-3 通过database link手工同步丢失语句。其中select语句是源表的数据,insert into是目标数据库。
insert into ogg_test.fm_tax_rate_test@to19 select * from ogg_test.fm_tax_rate_test where test_id=1;
6. target启动复制进程
GGSCI (cdbsym3) 4> start repsym
Sending START request to MANAGER ...
REPLICAT REPSYM starting
GGSCI (cdbsym3) 5> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
REPLICAT RUNNING REPSYM 00:00:00 00:00:00
REPLICAT RUNNING REPSYM_T 00:00:00 00:00:01
数据变化已经被应用到复制端了
GGSCI (cdbsym3) 8> stats repsym total table dbp.rb_restraints
Sending STATS request to REPLICAT REPSYM ...
Start of Statistics at 2015-03-31 11:09:14.
Replicating from SYMBOLS.RB_RESTRAINTS to DBP.RB_RESTRAINTS:
*** Total statistics since 2015-03-31 11:08:13 ***
Total inserts 1.00
Total updates 4.00
Total deletes 0.00
Total discards 0.00
Total operations 5.00
End of Statistics.
7. 在数据库中查看复制进程启动后的数据变化
OGG_TEST@data> select * from ogg_test.fm_tax_rate_test;
COUNTR STAT TAX_TY TAX_RATE TEST_ID
------ ---- ------ ---------- ----------
US 68 WT3 .0015 1
TW 68 WT3 .0015 2
JP 68 WT3 .0015 3
其中第一条数据就是我们通过手工同步的数据,后面两条数据是故障之后的数据变化。
注意:如果手工同步之前源表的数据也执行delete操作就无法通过isnert into select 的方式获取并同步到target端了。
感谢各位的阅读!关于“OGG ora-01403错误怎么处理”这篇文章就分享到这里了,希望
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/99262.html