星期一, 4月 27, 2015

Goldengate升級之目標端(replicat端)升級

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的格式轉換命令,在extractdata pump進程中均配置,其配置方式如下:

 

EXTTRAIL ./dirdat/tr, format release 11.1

 

2、升級目標

將目標端OGG版本從11.1.0.2升級到與源端一致的11.2.0.1版本

 

3、升級前準備3.1 停止源端的extractdatapump進程

GGSCI>stop exttr

 

GGSCI>stop dpetr

 

3.2 停止目標端的replicatmgr進程

GGSCI>stop reptr

 

GGSCI>stop mgr

 

3.3 去除extractdatapump進程中的format release參數

因為在extractdatadump進程中都配置有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_nameedit params datadump_name的方式進入進行修改(具體操作:略)。

 

3.4 extractdatadump進程做ETROLLOVER操作

因為extractdatadump都修改了format release資訊,所以,都需要做ETROLLOVER操作

 

GGSCI>alter extract exttrETROLLOVER

 

GGSCI>alter extract dpetrETROLLOVER

 

3.5 修改源端datapump進程的EXTSEQNO號和EXTRBA

因為源端的extract-exttr進程執行ETROLLOVER操作後,進程的extseqnoextrba號被重置至下一個extseqno號的第0extrba,而datapump並不知道extract進程發生了這個變化,仍然守望在extract ETROLLOVER前的extseqnoextrba號上,永遠也等不到這個extseqno上有新的RBA變化,造成就無法將extract新抽取到的資料,傳遞到目標端去。

 

所以,在extract進程ETROLLOVER後,需要使用"Alterextract group_name EXTSEQNO X, EXTRBA 0"的命令,重置checkpoint位置,datadump進程才能正常的將資料繼續傳遞到遠端。

 

3.5.1 記錄下exttr進程ETROLLOVER後的extseqnoextrba

 

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進程的extseqnoextrba

 

GGSCI>Alter extract dpetr EXTSEQNO 4,EXTRBA 0

 

 

 

3.6 查出datadump進程ETROLLOVER後的Target ExtractTrailsextseqnoextrba

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 記錄下目標端replicatcheckpoint資訊

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

 

4OGG軟體升級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、驗證升級後replicatcheckpoint是否為一致5.1 查看升級後replicatcheckpoint是否與升級前一致

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了,所以需要手工修改replicatsequence#RBA號到與datadump進程的target extract trails中的seqnoRBA一致。

 

7.3 修改目標端replicatextseqnoextrba

根據上面一步,查出的源端的datadump進程的remotetrail fileseqno號和RBA,決定replicat要更改的extseqnoextrba

 

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 checkpointsequence#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 啟動目標端的replicatmgr進程

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正常的,接著升級前的狀態在同步資料。

 

沒有留言:

LinkWithin-相關文件

Related Posts Plugin for WordPress, Blogger...