GoldenGate--大事務拆分成小事務定位問題

linfeng_oracle發表於2014-06-16
Go

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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章