今天處理了個復制進程異常掛起的CASE，出錯日志是：

2012-08-20 10:33:02? WARNING OGG-00869? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? No unique key is defined for table 'WL_PSINFO'. All viable columns will be used to represent the key, but may not guarantee uniqueness.? KEYCOLS may be used to define the key.
2012-08-20 10:34:12? WARNING OGG-01431? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? Aborted grouped transaction on 'MBS7_INV.WL_PSINFO', Mapping error.
2012-08-20 10:34:12? WARNING OGG-01003? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? Repositioning to rba 124252822 in seqno 77.
2012-08-20 10:34:12? WARNING OGG-01151? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? Error mapping from MBS7_INV.WL_PSINFO to MBS7_INV.WL_PSINFO.
2012-08-20 10:34:12? WARNING OGG-01003? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? Repositioning to rba 124252822 in seqno 77.
2012-08-20 10:34:12? ERROR?? OGG-01296? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? Error mapping from MBS7_INV.WL_PSINFO to MBS7_INV.WL_PSINFO.
2012-08-20 10:34:12? ERROR?? OGG-01668? Oracle GoldenGate Delivery for Oracle, r_inv1.prm:? PROCESS ABENDING.

從日志看是該表缺少主鍵，但OGG也是可以基于無主鍵的情況下同步的，進一步分析目標表和結合掛起的時間，本來該表是無主鍵的，在發生異常前剛在源端做了創建主鍵的操作，而此時目標表是存在重復記錄的：

目標端：

select id,ordercode, consigncode from mbs7_inv.WL_PSINFO group by id,
??????????????? ordercode, consigncode having count(*) > 1

.....有1千多條重復記錄，而與此同時在源端是不存在重復記錄。

進一步查詢發現該表的重復記錄只有前幾個字段相同，后面幾個字段還是不一樣的：

select *
? from mbs7_inv.WL_PSINFO
?where id in
?????? (select id
????????? from (
select id,ordercode, consigncode from mbs7_inv.WL_PSINFO group by id,
??????????????? ordercode, consigncode having count(*) > 1)) order by id

所以不能用傳統刪除重復記錄的方法來處理。

為了OGG進程能正常運作，打算先在源端備份這些刪除掉的真實記錄，然后在目標端做刪除處理后再導入，處理方法是：

1 先在源端備份這些記錄：

create table system.WL_PSINFO_bak?? as select * from?
mbs7_inv.WL_PSINFO a? where a.id in?
(select id
????????? from (
select id,ordercode, consigncode from?mbs7_inv.WL_PSINFO@link_102?group by id,
??????????????? ordercode, consigncode having count(*) > 1))

?

2 在目標端刪除這些記錄：

delete from mbs7_inv.WL_PSINFO a? where id in?
(
select id?
????????? from (
select id,ordercode, consigncode from mbs7_inv.WL_PSINFO group by id,
??????????????? ordercode, consigncode having count(*) > 1))

commit;

3 重新把源端備份的數據導回來：

insert into mbs7_inv.WL_PSINFO select * from?system.WL_PSINFO_bak@link_100;

?

4 啟動復制進程即可：

ggsci>start r_inv1

?

總結：主要是要理解OGG的復制原理，它是讀日志或DDL同步表進行同步處理的，如果源端進行得動作，在目標端執行不了，為了保證數據一致性，OGG會讓復制進程掛起，所要要結合警告日志和兩邊表結構情況來分析。

總結

以上是生活随笔為你收集整理的OGG重复记录导致复制进程挂起的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。