GoldenGate--大事务拆分成小事务定位问题
为了说明有时要把大事务拆分成小事务来定位问题，现在先模拟出问题：
数据库准备：
在源端数据库执行以下语句：
SQL> create user linfeng identified by linfeng;
用户已创建。
SQL> grant resource,connect to linfeng;
授权成功。
SQL> create table linfeng.big_tran
2 ( tran_id number,
3 username varchar2(20),
4 constraint pk_big_tran primary key(tran_id) using index
5 );
表已创建。
在目标端数据库执行以下语句（一张对应的交易跟踪表）：
SQL> create user linfeng identified by linfeng;
用户已创建。
SQL> grant resource,connect to linfeng;
授权成功。
SQL> create table linfeng.big_tran
2 ( tran_id number,
3 username varchar2(20),
4 constraint pk_big_tran primary key(tran_id) using index
5 );
表已创建。
Goldengate准备：
在源端配置一个Extract与Pump进程，参数如下，参数的含义请参阅官方文档。
Extract：
GGSCI>add extract ebtos001, tranlog, begin now --btos为大事务转小事务缩写
GGSCI>add exttrail G:\ggs11\dirdat\ebtos001\ex, extract ebtos001,megabytes 20
GGSCI>edit params ebtos001
extract ebtos001
userid ggs@ddlsource, password ggs
exttrail G:\ggs11\dirdat\ebtos001\ex
table linfeng.big_tran;
Pump：
GGSCI>add extract pbtos001, exttrailsource G:\ggs11\dirdat\ebtos001\ex
GGSCI>add rmttrail G:\ggs11_2\dirdat\rbtos001\re, extract pbtos001, megabytes 20
GGSCI>edit param pbtos001
extract pbtos001
userid ggs@ddlsource, password ggs
rmthost 192.168.1.100,mgrport 8079
rmttrail G:\ggs11_2\dirdat\rbtos001\re
table linfeng.big_tran;
再在目标端上配置一个Replicat进程，参数如下，参数的含义请参阅官方文档。
Rep：
GGSCI>dblogin userid ggs@ddltarget, password ggs
GGSCI>add checkpointtable ggs.ckptbtos
GGSCI>add replicat rbtos001, exttrail G:\ggs11_2\dirdat\rbtos001\re, checkpointtable ggs.ckptbtos
GGSCI>edit params rbtos001
replicat rbtos001
ASSUMETARGETDEFS
userid ggs@ddltarget, password ggs
SETENV ( NLS_LANG = ".ZHS16GBK")
DISCARDFILE G:\ggs11_2\dirdat\rbtos001\reprbtos001,APPEND, MEGABYTES 10M
map linfeng.big_tran, target linfeng.big_tran;
添加附加日志：
GGSCI (linfeng) 29> dblogin userid ggs@ddlsource, password ggs
Successfully logged into database.
GGSCI (linfeng) 30> add trandata linfeng.big_tran
Logging of supplemental redo data enabled for table LINFENG.BIG_TRAN.
启动各进程：
GGSCI> start extract ebtos001
GGSCI> start extract pbtos001
GGSCI> start replicat rbtos001
在源库插入7条记录：
SQL> insert into big_tran values(1,'a');
已创建 1 行。
SQL> insert into big_tran values(2,'b');
已创建 1 行。
SQL> insert into big_tran values(3,'c');
已创建 1 行。
SQL> insert into big_tran values(4,'d');
已创建 1 行。
SQL> insert into big_tran values(5,'e');
已创建 1 行。
SQL> insert into big_tran values(6,'f');
已创建 1 行。
SQL> insert into big_tran values(7,'g');
已创建 1 行。
SQL> commit;
提交完成。
目标数据库：
SQL> select * from big_tran;
TRAN_ID USERNAME
---------- --------------------
1 a
2 b
3 c
4 d
5 e
6 f
7 g
已选择7行。
现在在目标库上删除id为7的记录：
SQL> delete from big_tran where tran_id=7;
已删除 1 行。
SQL> commit;
提交完成。
SQL> select * from big_tran;
TRAN_ID USERNAME
---------- --------------------
1 a
2 b
3 c
4 d
5 e
6 f
已选择6行。
然后在源库提交一个事务，包含如下：
SQL> insert into big_tran values(8,'h');
已创建 1 行。
SQL> delete from big_tran where tran_id=7;
已删除 1 行。
SQL> update big_tran set username='aa' where tran_id=1;
已更新 1 行。
SQL> commit;
提交完成。
在目标端查看rep进程状态：
GGSCI (linfeng) 14> info all
Program Status Group Lag Time Since Chkpt
MANAGER RUNNING
REPLICAT ABENDED RBTOS001 00:00:00 00:00:36
状态：ABENDED
查看rep进程report：
GGSCI> view report RBTOS001
ERROR OGG-01296 Error mapping from LINFENG.BIG_TRAN to LINFENG.BIG_TRAN.
查看ggs event：
GGSCI (linfeng) 17> view ggsevt
WARNING OGG-01004 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: Aborted grouped transaction on 'LINFENG.BIG_TR
AN', Database error 1403 ().
WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: Repositioning to rba 1781 in seqno 0.
WARNING OGG-01154 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: SQL error 1403 mapping LINFENG.BIG_TRAN to LIN
FENG.BIG_TRAN.
WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: Repositioning to rba 1781 in seqno 0.
ERROR OGG-01296 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: Error mapping from LINFENG.BIG_TRAN to LINFENG
.BIG_TRAN.
ERROR OGG-01668 Oracle GoldenGate Delivery for Oracle, RBTOS001.prm: PROCESS ABENDING.
Last record for the last committed transaction is the following:
___________________________________________________________________
Trail name : G:\ggs11_2\dirdat\rbtos001\re000000
Hdr-Ind : E (x45) Partition : . (x04)
UndoFlag : . (x00) BeforeAfter: A (x41)
RecLength : 18 (x0012) IO Time : 2012-06-30 22:39:35.000000
IOType : 5 (x05) OrigNode : 255 (xff)
TransInd : . (x02) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 8 AuditPos : 873488
Continued : N (x00) RecCount : 1 (x01)
2012-06-30 22:39:35.000000 Insert Len 18 RBA 1668
Name: LINFENG.BIG_TRAN
___________________________________________________________________
Reading G:\ggs11_2\dirdat\rbtos001\re000000, current RBA 1916, 8 records
从上面信息可以看出事务起始位置是在：rba 1781 in seqno 0
如果有设置discard参数的话，也有类似的报错信息。
但是这些信息都不全，要想查看具体信息，可以在rep进程加上以下参数：
SHOWSYNTAX
Use the SHOWSYNTAX parameter to start an interactive session where you can view each Replicat SQL statement before it is applied. By viewing the syntax of SQL statements that failed, you might be able to diagnose the cause of the problem.
NODYNSQL
With DYNSQL, the default, Replicat uses dynamic SQL to compile a statement once, and then execute it many times with different bind variables.
NOBINARYCHARS
NOBINARYCHARS is an undocumented parameter that causes Oracle GoldenGate to treat binary data as a null-terminated string.
通过这三个参数的结合，在report文件中记录详细的SQL语句，和具体的出错位置，结合logdump和具体的SQL语句，相信很快能够定位出问题的原因。参数具体信息参考官方文档。
GGSCI> view param RBTOS001
replicat rbtos001
ASSUMETARGETDEFS
userid ggs@ddltarget, password ggs
SETENV ( NLS_LANG = ".ZHS16GBK")
DISCARDFILE G:\ggs11_2\dirdat\rbtos001\reprbtos001,APPEND, MEGABYTES 10M
SHOWSYNTAX
NODYNSQL
NOBINARYCHARS
map linfeng.big_tran, target linfeng.big_tran;
在操作层面上运行：
G:\ggs11_2> replicat paramfile G:\ggs11_2\dirprm\rbtos001.prm
WARNING OGG-01003 Repositioning to rba 1781 in seqno 0.
INSERT INTO "LINFENG"."BIG_TRAN" ("TRAN_ID","USERNAME") VALUES ('8','h')
Statement length: 72
(S)top display, (K)eep displaying (default): k
DELETE FROM "LINFENG"."BIG_TRAN" WHERE "TRAN_ID"='7'
Statement length: 53
(S)top display, (K)eep displaying (default): k
2012-06-30 23:15:34 WARNING OGG-01154 SQL error 1403 mapping LINFENG.BIG_TRAN to LINFENG.BIG_TRAN.
2012-06-30 23:15:34 WARNING OGG-01003 Repositioning to rba 1781 in seqno 0.
可以看到事务是在delete操作时报错的。
Logdump >Ghdr on
Logdump >Detail on
Logdump >Detail data
Logdump >Usertoken on
Logdump 40 >n
___________________________________________________________________
Hdr-Ind : E (x45) Partition : . (x04)
UndoFlag : . (x00) BeforeAfter: B (x42)
RecLength : 9 (x0009) IO Time : 2012/06/30 22:45:39.000.000
IOType : 3 (x03) OrigNode : 255 (xff)
TransInd : . (x01) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 8 AuditPos : 1311760
Continued : N (x00) RecCount : 1 (x01)
2012/06/30 22:45:39.000.000 Delete Len 9 RBA 1916
Name: LINFENG.BIG_TRAN
Before Image: Partition 4 G m
0000 0005 0000 0001 37 | ........7
Column 0 (x0000), Len 5 (x0005)
0000 0001 37 | ....7
Logdump 55 >n
___________________________________________________________________
Hdr-Ind : E (x45) Partition : . (x04)
UndoFlag : . (x00) BeforeAfter: A (x41)
RecLength : 18 (x0012) IO Time : 2012/06/30 22:45:39.000.000
IOType : 15 (x0f) OrigNode : 255 (xff)
TransInd : . (x02) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 8 AuditPos : 1314320
Continued : N (x00) RecCount : 1 (x01)
2012/06/30 22:45:39.000.000 FieldComp Len 18 RBA 2020
Name: LINFENG.BIG_TRAN
After Image: Partition 4 G e
0000 0004 ffff 0000 0001 0006 0000 0002 6161 | ................aa
Column 0 (x0000), Len 4 (x0004)
ffff 0000 | ....
Column 1 (x0001), Len 6 (x0006)
0000 0002 6161 | ....aa
通过logdump发现这是处于事务中间的一个删除语句出错了，检查发现这张表的该记录确实不存在，因此导致Error mapping错误的发生。但由于这是事务中间的一条记录，我们不能直接跳到故障语句之后，这里还需要借助另外两个参数的帮助。
GROUPTRANSOPS
Controls the number of records that are sent to the trail in one batch.
MAXTRANSOPS
Divides large source transactions into smaller ones on the target system.
通过这两个参数，可以把源端大事务拆分成小的事务。为了方便起见，现在设置这两个参数为1。
GGSCI> view param RBTOS001
replicat rbtos001
ASSUMETARGETDEFS
userid ggs@ddltarget, password ggs
SETENV ( NLS_LANG = ".ZHS16GBK")
DISCARDFILE G:\ggs11_2\dirdat\rbtos001\reprbtos001,APPEND, MEGABYTES 10M
--SHOWSYNTAX
--NODYNSQL
--NOBINARYCHARS
grouptransops 1
maxtransops 1
map linfeng.big_tran, target linfeng.big_tran;
再重启RBTOS001进程，RBTOS001进程在出错位置停下来后，手工跳过有问题的语句。
GGSCI> alter RBTOS001, extseqno 0, extrba 2020
GGSCI> start RBTOS001
至此，这个问题得到了解决。当然根治这个问题最好的办法还是全同步数据不一致的表，但在一个比较大的生产环境中重新全同步表还是比较麻烦的，在出错语句不是太多的情况下，这也不失为一种解决办法。而我们这个案例刚好是delete操作，因此可以简单的跳过，如果是update或insert则还需要进一步分析。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24996904/viewspace-1183689/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/24996904/viewspace-1183689/
1310
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
