GoldenGate--大事務拆分成小事務定位問題
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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 頭疼，大事務問題如何解決？
- 大事務
- mysql大事務MySql
- 為什麼要避免大事務以及大事務如何解決？
- 前方一系列大事務問題來襲，請及時拉響警報
- Spring大事務到底如何優化？Spring優化
- 記在Linux上定位後臺服務偶發崩潰的問題Linux
- TCP粘包拆包問題TCP
- 注意Spring事務這一點，避免出現大事務Spring
- Java服務.問題排查.問題復現Java
- 微服務異常問題微服務
- JVM問題定位工具JVM
- 微服務架構分散式事務管理問題微服務架構分散式
- 微服務思考(02)：微服務實施前有哪些問題？微服務
- 定時任務裡面事務不生效問題
- Oracle查詢回滾大事務所需時間Oracle
- ios XCUIElement 元素定位問題iOSUI
- SAS服務效能問題專案
- SpringCloud微服務帶來的問題SpringGCCloud微服務
- OOM分析之問題定位（二）OOM
- 解決高度塌陷、定位問題
- 磁碟問題定位與解決
- Netty拾遺（七）——粘包與拆包問題Netty
- TCP 粘包 - 拆包問題及解決方案TCP
- 管理Mac應用使用定位服務Mac
- 業務測開的尷尬定位
- 關於node服務部署的問題
- WebSocket 服務掛掉問題記錄Web
- Spark任務OOM問題如何解決？SparkOOM
- WebAssembly解決了哪些業務問題？Web
- 十大微服務面試問題微服務面試
- 服務網格大事：Istio釋出1.0版本
- 大事務導致資料庫恢復時間長資料庫
- MySQL：5.6 大事務show engine innodb status故障一例MySql
- 轉賬問題是屬於業務問題還是屬於技術問題？
- Spark —— Spark OOM Error問題排查定位SparkOOMError
- 如何定位瀏覽器卡死問題瀏覽器
- 網路問題定位工具記錄
- ios8系統定位問題iOS