Ref:
http://www.db2china.net/home/space.php?uid=153935&do=blog&id=33249
Goldengate升級之目標端（replicat端）升級
要升級replicat端的原因為：目標端OGG軟體版本與源端OGG軟體版本不同，在實際生產應用中，經常發現replicat端事務丟失的情況，所以，需要將目標端的OGG軟體升級為與源端OGG相同軟體版本。
1、升級前環境情況
源端OGG版本11.2.1.0.1
目標端OGG版本11.1.1.1.2
升級前，為了解決源端、目標端OGG版本不一致不能正常同步的問題，在源端抽取Tail file格式時，加了format release 11.1的格式轉換命令，在extract與data pump進程中均配置，其配置方式如下：
EXTTRAIL ./dirdat/tr, format release 11.1
2、升級目標
將目標端OGG版本從11.1.0.2升級到與源端一致的11.2.0.1版本
3、升級前準備3.1 停止源端的extract和datapump進程
GGSCI>stop exttr
GGSCI>stop dpetr
3.2 停止目標端的replicat和mgr進程
GGSCI>stop reptr
GGSCI>stop mgr
3.3 去除extract和datapump進程中的format release參數
因為在extract與datadump進程中都配置有formatrelease 11.1關鍵字，在目標端升級後，該配置需要取消，但是，取消該配置，並不只是從設定檔中刪除這麼簡單的事，還需要對進程做ETROLLOVER操作，否則進程啟動時，會報如下錯誤：
ERROR OGG-01416 File ./dirdat/tr000008, with format RELEASE 10.4/11.1, does not match
current format specification of RELEASE 11.2.Modify the parameter file to specify format RELEASE 10.4/11.1
or issueETROLLOVER prior to restart.
操作方法：在OGG中以edit paramsextract_name和edit params datadump_name的方式進入進行修改（具體操作：略）。
3.4 對extract與datadump進程做ETROLLOVER操作
因為extract與datadump都修改了format release資訊，所以，都需要做ETROLLOVER操作
GGSCI>alter extract exttrETROLLOVER
GGSCI>alter extract dpetrETROLLOVER
3.5 修改源端datapump進程的EXTSEQNO號和EXTRBA號
因為源端的extract-exttr進程執行ETROLLOVER操作後，進程的extseqno和extrba號被重置至下一個extseqno號的第0號extrba，而datapump並不知道extract進程發生了這個變化，仍然守望在extract ETROLLOVER前的extseqno和extrba號上，永遠也等不到這個extseqno上有新的RBA變化，造成就無法將extract新抽取到的資料，傳遞到目標端去。
所以，在extract進程ETROLLOVER後，需要使用"Alterextract group_name EXTSEQNO X, EXTRBA 0"的命令，重置checkpoint位置，datadump進程才能正常的將資料繼續傳遞到遠端。
3.5.1 記錄下exttr進程ETROLLOVER後的extseqno和extrba號
GGSCI> info exttr, detail
GGSCI (server1) 140> info exttr, detail
EXTRACT EXTTR Initialized 2015-01-30 13:02 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:00:27 ago)
Log Read Checkpoint Oracle Redo Logs
2015-01-30 13:18:27 Seqno 365, RBA 17822208
SCN 0.17726669 (17726669)
Target Extract Trails:
Remote Trail Name Seqno RBA Max MB
./dirdat/tr 4 0 100
Extract Source Begin End
……
3.5.2 修改datadump進程的extseqno和extrba號
GGSCI>Alter extract dpetr EXTSEQNO 4,EXTRBA 0
3.6 查出datadump進程ETROLLOVER後的Target ExtractTrails的extseqno和extrba號
GGSCI (server1) 160> info dpetr, detail
EXTRACT DPETR Initialized 2015-01-30 13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:02:10 ago)
Log Read Checkpoint File ./dirdat/tr000003
2015-01-30 13:18:18.000000 RBA 48953966
Target Extract Trails:
Remote Trail Name Seqno RBA Max MB
./dirdat/tr 4 0 100
……
3.7 備份目標端的OGG目錄
#cp –ra /u01/ogg /u01/ogg_backup
3.8 記錄下目標端replicat的checkpoint資訊
GGSCI (server2) 1> info reptr, showch
REPLICAT REPTR Last Started 2015-01-30 13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:10:36 ago)
Log Read Checkpoint File ./dirdat/tr000003
2015-01-30 13:18:16.296427 RBA 48953996
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in the data source):
Sequence #: 0
RBA: 0
Timestamp: Not Available
Extract Trail: ./dirdat/tr
Current Checkpoint (position of last record read in the data source):
Sequence #: 3
RBA: 48953996
Timestamp: 2015-01-30 13:18:16.296427
Extract Trail: ./dirdat/tr
……
Current Checkpoint為 Sequence #: 3 RBA: 48953996
4、OGG軟體升級4.1 將新版OGG 11.2.1.0.1軟體複製到原舊版OGG目錄下
$ cp ogg112101_fbo_ggs_Linux_x64_ora11g_64bit.zip/u01/ogg
4.2 刪除OGG目錄下的fbo_ggs_Linux_x64_ora11g_64bit.tar文件
fbo_ggs_Linux_x64_ora11g_64bit.tar檔是舊版OGG安裝時解壓出來的tar檔，新版OGG軟體unzip解壓時，也會生成此檔，當然也可以使用unzip解壓時的覆蓋替代手工刪除
$rm fbo_ggs_Linux_x64_ora11g_64bit.tar
4.3 在原版OGG目錄中安裝（解壓）新版OGG軟體
$unzip ogg112101_fbo_ggs_Linux_x64_ora11g_64bit.zip
$tar xvf fbo_ggs_Linux_x64_ora11g_64bit.tar
4.4 驗證升級成功情況
$cd $OGG
[oracle@server2 u01]$ cd $OGG
[oracle@server2 ogg]$ ./ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_120423.0230_FBO
Linux, x64, 64bit (optimized), Oracle 11g on Apr 23 2012 08:32:14
Copyright (C) 1995, 2012, Oracle and/or its affiliates. All rights reserved.
GGSCI (server2) 1>
從這裡看到，OGG軟體版本已經升級至11.2.1.0.1
5、驗證升級後replicat的checkpoint是否為一致5.1 查看升級後replicat的checkpoint是否與升級前一致
GGSCI (server2) 46> info reptr, detail
REPLICAT REPTR Last Started 2015-01-30 13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:12:58 ago)
Log Read Checkpoint File ./dirdat/tr000003
2015-01-30 13:18:16.296427 RBA 48953996
Extract Source Begin End
./dirdat/tr000003 * Initialized * 2015-01-30 13:18
./dirdat/tr000000 * Initialized * First Record
Current directory /u01/ogg
Report file /u01/ogg/dirrpt/REPTR.rpt
Parameter file /u01/ogg/dirprm/reptr.prm
Checkpoint file /u01/ogg/dirchk/REPTR.cpr
Checkpoint table GOLDENGATE.CHECKPOINT_REPTR_01
Process file /u01/ogg/dirpcs/REPTR.pcr
Stdout file /u01/ogg/dirout/REPTR.out
Error log /u01/ogg/ggserr.log
Current Checkpoint 跟升級前一樣，仍為Sequence #: 3 RBA: 48953996，進一步證明升級成功。
6、驗證升級後可正常同步資料場景準備6.1 先記錄下源端、目標端資料量為一致
（生產庫環境此步可以跳過，因為生產庫的表受業務的運算元據不斷發生變化，本案例為創建一張專用用於測試升級的表進行測試）
源端
目標端
SQL> select count(*) from goldengate.ogg_upg;
COUNT(*)
----------
2150000
SQL> select count(*) from goldengate.ogg_upg;
COUNT(*)
----------
2150000
源端和目標端資料量一致。
6.2 在目標端replicat進程啟動前在源端刪除部分資料
SQL> delete goldengate.ogg_upg where rownum <1000001;
1000000 rows deleted.
SQL> commit;
SQL> select count(*) from goldengate.ogg_upg;
COUNT(*)
----------
1150000
7、重建目標端replicat進程
重建replicat進程的原因：ogg_11.1.1.1.2每條replicat進程只有CHECKPOINT一張表，而ogg_11.2.x.x.1每條replicat進程有CHECKPOINT,CHECKPOINT_LOX兩張表，所以，如果在升級後，直接啟動replicat進程，是無法啟動的，會報如下錯誤：
ERROR OGG-00665 OCI Error describe for query (status = 942-ORA-00942: table or view does not exist), SQL<SELECT a.current_dir, a.seqno, a.rba, a.audit_ts, a.log_csn, a.log_xid, a.log_cmplt_csn, a.log_cmplt_xids, b.log_cmplt_xids FROM GOLDENGATE.CHECKPOINT_REPTR_01 a LEFT JOIN GOLDENGATE.CHECKPOINT_REPTR_01_lox b ON a.group_name = b.group_name AND a.group_key = b.group_key AND a.log_cmplt_csn = b.log_cmplt_csn WHERE a.group_name = 'REPTR' AND a.group_key = 2810015614>.
2015-01-28 05:12:59 ERROR OGG-01668 PROCESS ABENDING.
提示表不存在，這張表是指：GOLDENGATE.CHECKPOINT_REPTR_01_lox表（CHECKPOINT_LOX表），重建replicat的最終目的是讓在重建進程時，自動將兩張checkpoint表都自動創建起來。
7.1 刪除replicat進程與checkpoint表
GGSCI>dblogin userid goldengate,password goldengate
GGSCI>delete replicat reptr
GGSCI>delete checkpointtable GOLDENGATE.CHECKPOINT_REPTR_01
7.2 重新建立replicat進程
GGSCI>dbloginuserid goldengate, password goldengate
GGSCI>add checkpointtable goldengate.checkpoint_reptr_01
GGSCI>add replicat reptr, exttrail ./dirdat/tr,checkpointtable goldengate.checkpoint_reptr_01
到這一步，replicat啟動後，還是無法繼續應用源端投遞過來的trail的，因為源端的datapump進程做過ETROLLOVER了，所以需要手工修改replicat的sequence#和RBA號到與datadump進程的target extract trails中的seqno和RBA一致。
7.3 修改目標端replicat的extseqno和extrba號
根據上面一步，查出的源端的datadump進程的remotetrail file的seqno號和RBA，決定replicat要更改的extseqno和extrba號
GGSCI (server2) 37> Alter replicat reptrEXTSEQNO 4, EXTRBA 0
7.4 查看新建立的replicat進程的SEQ#和RBA號
GGSCI(server2) 27> info reptr, showch
GGSCI (server2) 3> info reptr, showch
REPLICAT REPTR Initialized 2015-01-30 13:39 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:00:07 ago)
Log Read Checkpoint File ./dirdat/tr000004
First Record RBA 0
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in the data source):
Sequence #: 4
RBA: 0
Timestamp: Not Available
Extract Trail: ./dirdat/tr
Current Checkpoint (position of last record read in the data source):
Sequence #: 4
RBA: 0
Timestamp: Not Available
Extract Trail: ./dirdat/tr
……
Start checkpoint 的sequence#和RBA號已經通過手工，都定位到了源端ETROLLOVER後的狀態
Current checkpoint的sequence#和RBA號已經通過手工，也都定位到了源端ETROLLOVER後的狀態
7.5 查看checkpoint表的資料內容
SQL>select * from goldengate.checkpoint_reptr_01;
No rows selected
SQL>select * from goldengate.checkpoint_reptr_01_lox;
No rows selected
這時，兩個checkpoint表中的資料還是空的，待replicat啟動運行後，進行狀態資訊就會寫入到checkpoint表中
8、啟動源端和目標端進程8.1 啟動目標端的replicat和mgr進程
GGSCI>start mgr
GGSCI>start reptr
8.2 啟動源端的datapump進程
GGSCI>start dpetr
9、驗證是否能繼續同步資料
此步最重要的，是要驗證在升級時間時，源端所做的操作能否同步到目標庫中來。本案例在升級過程中，對goldengate.ogg_upg表刪除了1000000行資料。
9.1 查看目標端goldengate.ogg_upg表的資料變化
源端
目標端
SQL> select count(*) from goldengate.ogg_upg;
COUNT(*)
----------
2050000
SQL> select count(*) from goldengate.ogg_upg;
COUNT(*)
----------
2050000
9.2 目標端查看checkpoint表內check狀態
select * from goldengate.checkpoint_reptr_01
-------------------------------------------------
REPTR 2149948420 4 19280017 2015-01-30 13:55:59.368501 2015/1/30 13:36:43 2015/1/30 14:01:01 /u01/ogg 17929533 7.16.20512 17929533 7.16.20512 1
從上面兩步看來，升級後replicat正常的，接著升級前的狀態在同步資料。
沒有留言:
張貼留言