OGG運維手冊

GOLDENGATE運維手冊

OGG常用監控命令

說明

對GoldenGate實例進行監控，最簡單的辦法是通過GGSCI命令行的方式進行。通過在命令行輸入一系列命令，并查看返回信息，來判斷GoldenGate運行情況是否正常。命令行返回的信息包括整體概況、進程運行狀態、檢查點信息、參數文件配置、延時等。

除了直接通過主機登錄GGSCI界面之外，也可以通過GoldenGate Director Web界面登錄到每個GoldenGate實例，并運行GGSCI命令。假如客戶部署了很多GoldenGate實例，如果單獨登錄到每個實例的GGSCI界面，會很不方便，此時建議通過GoldenGate Director Web界面，登錄到每個實例，并運行命令行命令。

啟動GoldenGate進程

1) 首先以啟動GoldenGate進程的系統用戶（一般為oracle）登錄源系統。

2) 進入GoldenGate安裝目錄，執行./ggsci進入命令行模式。

3) 啟動源端管理進程GGSCI > start mgr

4) 同樣登陸到目標端GoldenGate安裝目錄，執行./ggsci，然后執行GGSCI > start mgr啟動管理進程。

5) 在源端執行GGSCI > start er *啟動所有進程

6) 同樣登錄到備份端執行GGSCI > start er *啟動所有進程

7) 使用GGSCI > info er * 或者 GGSCI > info <進程名>察看進程狀態是否為Running（表示已經啟動）。注意有的進程需要幾分鐘起來，請重復命令觀察其啟動狀態。

說明：無論源還是目標，啟動各extract/replicat進程前需要啟動mgr進程。

start 命令的一般用法是：start <進程名稱>

如：

GGSCI> start extdm  啟動一個名叫extdm的進程

也可以使用通配符，如：

GGSCI> start er *  啟動所有的extract和replicat進程

GGSCI> start extract *d*  啟動所有的包含字符‘d’extract進程

GGSCI> start replicat rep*  啟動所有以“rep“開頭的replicat進程

停止GoldenGate進程

依照以下步驟停止GoldenGate進程：

1) 以啟動GoldenGate進程的系統用戶（一般為oracle）登錄源主機，進入GoldenGate安裝目錄執行./ggsci進入命令行管理界面

2) （本步驟僅針對抽取日志的主extract進程， data pump進程和replicat進程不需要本步驟）驗證GoldenGate的抽取進程重起所需的日志存在，對各個主extXX進程，執行如下命令： 

ggsci> info extXX, showch

…..

Read Checkpoint #1

….

 

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

    Thread #: 1

    Sequence #: 9671

    RBA: 239077904

    Timestamp: 2008-05-20 11:39:07.000000

    SCN: 2195.1048654191

    Redo File: Not available

 

  Current Checkpoint (position of last record read in the data source):

    Thread #: 1

    Sequence #: 9671

    RBA: 239377476

    Timestamp: 2008-05-20 11:39:10.000000

    SCN: 2195.1048654339

    Redo File: Not Available

 

Read Checkpoint #2

…..

 

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

    Thread #: 2

    Sequence #: 5287

    RBA: 131154160

    Timestamp: 2008-05-20 11:37:42.000000

    SCN: 2195.1048640151

    Redo File: /dev/rredo07

 

  Current Checkpoint (position of last record read in the data source):

    Thread #: 2

    Sequence #: 5287

    RBA: 138594492

    Timestamp: 2008-05-20 11:39:14.000000

    SCN: 2195.1048654739

    Redo File: /dev/rredo07

 

…..

首先察看Recovery Checkpoint所需要讀取的最古老日志序列號，如舉例中的實例1需要日志9671及其以后所有歸檔日志，實例2需要序列號為5287及以后所有歸檔日志，確認這些歸檔日志存在于歸檔日志目錄后才可以執行下一步重起。如果這些日志已經被刪除，則下次重新啟動需要先恢復歸檔日志。

注意：對于OGG 11及以后版本新增了自動緩存長交易的功能，缺省每隔4小時自動對未提交交易緩存到本地硬盤，這樣只需要最多8個小時歸檔日志即可。但是緩存長交易操作只在extract運行時有效，停止后不會再緩存，此時所需歸檔日志最少為8個小時加上停機時間，一般為了保險起見建議確保重啟時要保留有12個小時加上停機時間的歸檔日志。

3) 執行GGSCI >stop er *停止所有源進程，或者分別對各個進程執行stop <進程名>單獨停止。

4) 以oracle用戶登錄目標系統，進入安裝目錄/oraclelog1/goldengate，執行./ggsci進入命令行。

5) 在目標系統執行stop er *停止復制

6) 在兩端進程都已停止的情況下,如需要可通過stop mgr停止各系統內的管理進程。

類似的，stop命令具有跟start命令一樣的用法。這里不再贅述。

注意，如果是只修改抽取或者復制進程參數，則不需要停止MGR。不要輕易停止MGR進程，并且慎重使用通配符er *， 以免對其他復制進程造成不利影響。

查看整體運行情況

進入到GoldenGate安裝目錄，運行GGSCI，然后使用info all命令查看整體運行情況。如下圖示：

wpsBA38.tmp 

Group表示進程的名稱（MGR進程不顯示名字）；Lag表示進程的延時；Status表示進程的狀態。有四種狀態：

STARTING: 表示正在啟動過程中

RUNNING：表示進程正常運行

STOPPED：表示進程被正常關閉

ABENDED：表示進程非正常關閉，需要進一步調查原因

 

正常情況下，所有進程的狀態應該為RUNNING，且Lag應該在一個合理的范圍內。

查看參數設置

使用view params <進程名> 可以查看進程的參數設置。該命令同樣支持通配符*。

wpsBA39.tmp 

查看進程狀態

使用info <進程名稱> 命令可以查看進程信息?？梢圆榭吹降男畔ㄟM程狀態、checkpoint信息、延時等。如：

wpsBA3A.tmp 

還可以使用info <進程名稱> detail 命令查看更詳細的信息。包括所使用的trail文件，參數文件、報告文件、警告日志的位置等。如：

wpsBA4B.tmp 

使用info <進程名稱> showch 命令可以查看到詳細的關于checkpoint的信息，用于查看GoldenGate進程處理過的事務記錄。其中比較重要的是extract進程的recovery checkpoint，它表示源數據中最早的未被處理的事務；通過recovery checkpoint可以查看到該事務的redo log位于哪個日志文件以及該日志文件的序列號。所有序列號比它大的日志文件，均需要保留。

wpsBA4C.tmp 

查看延時

GGSCI> lag <進程名稱> 可以查看詳細的延時信息。如：

wpsBA4D.tmp 

此命令比用info命令查看到的延時信息更加精確。

注意，此命令只能夠查看到最后一條處理過的記錄的延時信息。

此命令支持通配符 *。

查看統計信息

GGSCI> stats <進程名稱>,<時間頻度>,table . 可以查看進程處理的記錄數。該報告會詳細的列出處理的類型和記錄數。如：

wpsBA4E.tmp 

GGSCI> stats edr, total列出自進程啟動以來處理的所有記錄數。

GGSCI> stats edr, daily, table gg.test列出當天以來處理的有關gg.test表的所有記錄數。

查看運行報告

GGSCI> view report <進程名稱> 可以查看運行報告。如：

wpsBA4F.tmp 

也可以進入到<goldengate安裝目錄>/dirrpt/目錄下，查看對應的報告文件。最新的報告總是以<進程名稱>.rpt命名的。加后綴數字的報告是歷史報告，數字越大對應的時間越久。如下圖示：

wpsBA60.tmp 

如果進程運行時有錯誤，則報告文件中會包括錯誤代碼和詳細的錯誤診斷信息。通過查找錯誤代碼，可以幫助定位錯誤原因，解決問題。

 

OGG的常見運維任務指南

配置自動刪除隊列

1) 進入安裝目錄執行./ggsci；

2) 執行edit param mgr編輯管理進程參數，加入或修改以下行

purgeoldextracts /<goldengate安裝目錄>/dirdat/*, usecheckpoint, minkeepdays 7

其中，第一個參數為隊列位置，*可匹配備份中心所有隊列文件；

第二個參數表示是首先要保證滿足檢查點需要，不能刪除未處理隊列；

第三個參數表示最小保留多少天，后面的數字為天數。例如，如果希望只保留隊列/ggs/dirdat/xm文件3天，可以配置如下：

purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3

3) 停止MGR進程，修改好參數后重啟該進程

GGSCI > stop mgr

輸入y確認停止

GGSCI > start mgr

注：臨時停止mgr進程并不影響數據復制。

 

配置啟動MGR時自動啟動Extract和Replicat進程

1) 進入安裝目錄執行./ggsci；

2) 執行edit param mgr編輯管理進程參數，加入以下行

AUTOSTART ER *

3) 停止MGR進程，修改好參數后重啟該進程

GGSCI > stop mgr

GGSCI > start mgr

注意：一般建議不用自動啟動，而是手工啟動，便于觀察狀態驗證啟動是否成功，同時也便于手工修改參數。

 

配置MGR自動重新啟動Extract和Replicat進程

GoldenGate具有自動重起extract或者replicat進程的功能，能夠自動恢復如網絡中斷、數據庫臨時掛起等引起的錯誤，在系統恢復后自動重起相關進程，無需人工介入。

1) 進入安裝目錄執行ggsci進入命令行界面；

2) 執行edit param mgr編輯管理進程參數，加入以下行

AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60

以上參數表示每5分鐘嘗試重新啟動所有進程，共嘗試三次。以后每60分鐘清零，再按照每5分鐘嘗試一次共試3次。

3) 停止MGR進程，修改好參數后重啟該進程，使修改后的參數文件生效

GGSCI > stop mgr

GGSCI > start mgr

 

長事務管理

在停止抽取進程前需要通過命令檢查是否存在長交易，以防止下次啟動無法找到歸檔日志：

ggsci> info extXX, showch

…..

Read Checkpoint #1

….

 

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

    Thread #: 1

    Sequence #: 9671

    RBA: 239077904

    Timestamp: 2008-05-20 11:39:07.000000

    SCN: 2195.1048654191

    Redo File: Not available

 

  Current Checkpoint (position of last record read in the data source):

    Thread #: 1

    Sequence #: 9671

    RBA: 239377476

    Timestamp: 2008-05-20 11:39:10.000000

    SCN: 2195.1048654339

    Redo File: Not Available

 

Read Checkpoint #2

…..

 

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

    Thread #: 2

    Sequence #: 5287

    RBA: 131154160

    Timestamp: 2008-05-20 11:37:42.000000

    SCN: 2195.1048640151

    Redo File: /dev/rredo07

 

  Current Checkpoint (position of last record read in the data source):

    Thread #: 2

    Sequence #: 5287

    RBA: 138594492

    Timestamp: 2008-05-20 11:39:14.000000

    SCN: 2195.1048654739

    Redo File: /dev/rredo07

 

…..

為了方便長交易的管理，GoldenGate提供了一些命令來查看這些長交易，可以幫助客戶和應用開發商查找到對應長交易，并在GoldenGate中予以提交或者回滾。

(一) 查看長交易的方法

Ggsci> send extract <進程名> , showtrans [thread n] [count n]

其中，<進程名>為所要察看的進程名，如extsz/extxm/extjx等；

Thread n是可選的，表示只查看其中一個節點上的未提交交易；

Count n也是可選的，表示只顯示n條記錄。例如,查看extsz進程中節點1上最長的10個交易，可以通過下列命令：

Ggsci> send extract extsz , showtrans thread 1  count 10

 

輸出結果是以時間降序排列的所有未提交交易列表，通過xid可以查找到對應的事務，請應用開發商和DBA幫助可以查找出未提交原因，通過數據庫予以提交或者回滾后GoldenGate的checkpoint會自動向前滾動。

(二) 使用GoldenGate命令跳過或接受長交易的方法

在GoldenGate中強制提交或者回滾指定事務，可以通過以下命令（<>中的為參數）：

Ggsci> SEND EXTRACT <進程名>, SKIPTRANS <5.17.27634> THREAD <2> //跳過交易

Ggsci>SEND EXTRACT <進程名>, FORCETRANS <5.17.27634> THREAD <1> //強制認為該交易已經提交

說明：使用這些命令只會讓GoldenGate進程跳過或者認為該交易已經提交，但并不改變數據庫中的交易，他們依舊存在于數據庫中。因此，強烈建議使用數據庫中提交或者回滾交易而不是使用GoldenGate處理。

(三) 配置長交易告警

可以在extract進程中配置長交易告警，參數如下所示：

extract extsz

……

warnlongtrans 12h, checkintervals 10m

exttrail /backup/goldengate/dirdat/sz

….

以上表示GoldenGate會每隔10分鐘檢查一下長交易，如果有超過12個小時的長交易，GoldenGate會在根目錄下的ggserr.log里面加入一條告警信息?？梢酝ㄟ^察看ggserr.log或者在ggsci中執行view ggsevt命令查看這些告警信息。以上配置可以有助于及時發現長交易并予以處理。

說明：在OGG 11g中，extract提供了BR參數可以設置每隔一段時間（默認4小時）將長交易緩存到本地硬盤（默認dirtmp目錄下），因此extract只要不停止一般需要的歸檔日志不超過8個小時（極限情況）。但是如果extract停掉后，便無法再自動緩存長交易，需要的歸檔日志就會依賴于停機時間變長。

 

表的重新再同步（需時間窗口）

如果是某些表由于各種原因造成兩邊數據不一致，需要重新進行同步，可以參照以下步驟。

1) 確認需要修改的表無數據變化（如果有條件建議停止應用系統并鎖定除去sys和goldengate以外的其它所有用戶防止升級期間數據變化，或者鎖定所要再同步的表）；

2) 重啟dpe進程（為了能夠對統計信息清零）；

3) 停止目標端的rep進程；

注意：步驟4-6為將源端數據通過exp/imp導入到目標端，客戶也可以選擇其它初始化方式，比如在目標端為源端表建立dblink，然后通過create table as select from的方式初始化目標端表。

4) 在源端使用exp導出該表或者幾張表數據。例如：

exp goldengate/XXXX file=nanhai.dmp tables=ctais2.SB_ZSXX grants=y

5) 通過ftp傳輸到目標端；

6) 在目標端，使用imp導入數據；

nohup imp goldengate/XXXXX file=nanhai.dmp fromuser=ctais2 touser=ctais2 ignore=y &

7) 如果這些表有外鍵，在目標端檢查這些外鍵并禁止它們（記得維護dirsql下的禁止和啟用外鍵的腳本SQL）；

8) 啟動目標端的rep進程；

9) 使用stats mydpe命令觀察data pump的統計信息，觀察里面是否包含了本次重新同步表的數據變化，如確認該時段內這些表無數據變化，則重新初始化成功；否則中間可能產生重復數據，目標replicat會報錯，將錯誤處理機制設置為reperror default,discard，等待replicat跟上后對discard中的記錄進行再次驗證，如果全部一致則重新初始化也算成功完成，當然也可以另擇時段對這些表重新執行初始化。

表的重新再同步（無需時間窗口）

如果是某些表由于各種原因造成兩邊數據不一致，需要重新進行同步，但實際業務始終24小時可用，不能提供時間窗口，則可以參照以下步驟。（因較為復雜，使用需謹慎?。?

1) 確認ext/dpe/rep進程均無較大延遲，否則等待追平再執行操作；

2) 停止目標端的rep進程；

注意：步驟3-5為將源端數據通過exp/imp導入到目標端，客戶也可以選擇其它初始化方式，比如expdp/impdp。

3) 在源端獲得當前的scn號。例如：

select dbms_flashback.get_system_change_number from dual;

以下以獲得的scn號為1176681為例

4) 在源端使用exp導出所需重新初始化的表或者幾張表數據，并且指定到剛才記下的scn號。例如：

exp / tables=ctais2.SB_ZSXX grants=n statistics=none triggers=n compress=n FLASHBACK_SCN=1176681

5) 通過ftp傳輸到目標端；

6) 在目標端，使用imp導入數據；

nohup imp goldengate/XXXXX file=nanhai.dmp fromuser=ctais2 touser=ctais2 ignore=y &

7) 如果這些表有外鍵，在目標端檢查這些外鍵并禁止它們（記得維護dirsql下的禁止和啟用外鍵的腳本SQL）；

8) 編輯目標端對應的rep參數文件，在其map里面加入一個過濾條件，只對這些重新初始化的表應用指定scn號之后的記錄（一定要注意不要修改本次初始化之外的其它表，會造成數據丟失?。?

map source.mytab, target target.mytab, filter ( @GETENV ("TRANSACTION", "CSN") >     1176681 ) ;

9) 確認參數無誤后，啟動目標端的rep進程；

10) 使用info repxx或者lag repxx直到該進程追上，停止該進程去掉filter即可進入正常復制。

 

 

 

 

 

數據結構變更和應用升級

（僅復制DML時）源端和目標端數據庫增減復制表

(一) 增加復制表

在GoldenGate的進程參數中，如果通過*來匹配所有表，因此只要符合*所匹配的條件，那么只要在源端建立了表之后GoldenGate就能自動復制，無需修改配置文件，但是需要為新增的表添加附加日志。

步驟如下：

GGSCI 〉dblogin userid goldengate, password XXXXXXX

GGSCI > info trandata .

如果不是enable則需要手動加入：

GGSCI > add trandata .

注：（僅對Oracle 9i）如果該表有主鍵或者該表不超過32列，則顯示enabled表示添加成功；如果無主鍵并且列超過32列，則可能出現錯誤顯示無法添加則需要手工處理，此時請根據附錄二中方法手工處理。

 

如果沒有使用統配符，則需要在主Extract、Data Pump里面最后的table列表里加入新的復制表；在目標端replicat的map列表同樣也加入該表的映射。

 

然后，新增表請首先在目標端建立表結構。

 

如果有外鍵和trigger，需要在目標表臨時禁止該外鍵和trigger，并維護在dirsql下的禁止和啟用這些對象的對應腳本文件。

 

對于修改了文件的所有源和目標進程，均需重啟進程使新的參數生效。

 

(二) 減少復制表

GoldenGate缺省復制所有符合通配符條件的表，如果有的表不再需要，可以在源端drop掉，然后到目標drop掉，無需對復制做任何修改。

如果其中幾個表依然存在，只是無需GoldenGate復制，則可以通過以下步驟排除：

1) 在源端系統上首先驗證所需歸檔日志存在后通過stop extXX停止對應的extXX進程；

2) 在目標端系統上ggsci中執行stop repXX停止目標端的復制進程；

3) 在源端修改ext進程的參數文件排除所不復制的表:

Ggsci> edit param extXX

……

tableexclude ctais2.TMP_*;

tableexclude ctais2.BAK_*;

tableexclude ctais2.MLOG$_*;

tableexclude ctais2.RUPD$_*;

tableexclude ctais2.KJ_*;

 

tableexclude myschema.mytable;

 

table ctais2.*;

…….

在文件定義table的行前面加入一行“tableexclude .;” 注意寫全schema和表的名稱。

注：如果是沒有使用通配符，則直接注釋掉該表所在的table行即可。

4) 在目標端修改rep進程參數，同樣排除該表:

GGSCI>edit param repXX

在map前面加入一行：

--mapexclude CTAIS2.SHOULIXINXI

mapexclude myschema.mytable

MAP ctais2.* ,TARGET ctais2.*; 

注：如果是沒有使用通配符，則直接注釋掉該表所在的map行即可。

 

5) 在目標端系統上啟動復制進程 repXX

GGSCI > start  repXX

6) 在源端系統上啟動源端的抓取進程extXX 

GGSCI > start  extXX

即可進入正常復制狀態。

 

（僅復制DML時）修改表結構

當數據庫需要復制的表結構有所改變，如增加列，改變某些列的屬性如長度等表結構改變后，可以按照下列步驟執行：

1) 按照本文前面所述操作順序停止源和目標端各抽取及投遞進程（注意停源端抽取要驗證一下歸檔日志是否存在防止無法重起），無需停止manager進程；

2) 修改目標表結構;

3) 修改源表結構;

4) 如果表有主鍵，并且本次修改未修改主鍵，則可以直接啟動源和目標所有進程繼續復制，完成本次修改；否則，如果表無主鍵或者本次修改了主鍵則需繼續執行下列步驟；

ggsci> dblogin userid goldengate, password XXXXXX

ggsci> delete trandata schema.mytable

ggsci> add  trandata schema.mytable

（僅對Oracle 9i）如果表超過了32列則上述操作可能會報錯，此時需要手工進行處理，請參考附錄二如何手動為表刪除和增加附加日志。

5) 重新啟動源端和目標端的抓取和復制進程。

 

（僅復制DML時）客戶應用的升級

如果是客戶的應用進行了升級，導致了源系統表的變化，在不配置DDL復制到情況下，需要對GoldenGate同步進程進行修改，可以參照以下步驟。

1) 停止源和目標端各抽取及投遞進程（注意停源端抽取要驗證一下歸檔日志是否存在防止無法重起），無需停止manager進程；

2) 對源系統進行升級;

3) 在目標端將客戶升級應用所創立的存儲過程、表、function等操作再重新構建一遍。對業務表的增刪改等DML操作不必在目標端再執行，它們會被OGG復制過去;

4) 在目標端手工禁止建立的trigger和外鍵，并將這些sql以及反向維護的（即重新啟用trigger和外鍵）SQL添加到目標端OGG dirsql目錄下對應的腳本文件里;

注意：在安裝實施時，應當將執行的禁止trigger和外鍵的表放到目標dirsql下，文件名建議為disableTrigger.sql和disableFK.sql。同時，需要準備一個反向維護（即重新啟用trigger和外鍵，建議為enableTrigger.sql和enableFK.sql）SQL，同樣放置到目標端OGG的dirsql目錄下，以備將來接管應用時重新啟用。

5) 對于升級過程中在源端增加的表，需要為新增的表添加附加日志。步驟如下：

GGSCI 〉dblogin userid goldengate, password XXXXXXX

GGSCI > info trandata .

如果不是enable則需要手動加入：

GGSCI > add trandata .

注：（僅對Oracle 9i）如果該表有主鍵或者該表不超過32列，則顯示enabled表示添加成功；如果無主鍵并且列超過32列，則可能出現錯誤顯示無法添加則需要手工處理，此時請根據附錄二中方法手工處理。

6) 對于升級過程中在源端drop掉的表，GoldenGate缺省復制所有符合通配符條件的表，可以直接在目標端drop掉，無需對復制做任何修改；

7) 如果升級過程中修改了主鍵的表則需繼續執行下列步驟；

ggsci> dblogin userid goldengate, password XXXXXX

ggsci> delete trandata schema.mytable

ggsci> add  trandata schema.mytable

（僅對Oracle 9i）如果表超過了32列則上述操作可能會報錯，此時需要手工進行處理，請參考附錄二如何手動為表刪除和增加附加日志。

8) 重新啟動源端和目標端的抓取和復制進程。

 

配置DDL復制自動同步數據結構變更

是否打開DDL復制

對于OGG的DDL復制具體限制請參考附錄。鑒于這些限制，另外一個重要因素是DDL的trigger會對源庫性能帶來一定的影響，在國網原則上并不推薦DDL復制。如果有特殊理由需要打開DDL復制，可以與Oracle工程師予以協商。

打開DDL復制的步驟

以下內容為配置DDL復制的步驟，僅作參考，具體請參照GoldenGate的官方安裝文檔。

? （可選，但強烈建議）定期收集統計信息，提高數據字典訪問速度

OGG的DDL復制需要大量訪問數據字典信息，通過數據庫定期收集統計信息（例如，每月一次），可以有效提高OGG DDL復制的性能。以下為一個例子:

sqlplus /nolog <<eof< span="">

connect / as sysdba

alter session enable parallel dml;

execute dbms_stats.gather_schema_stats('CTAIS2',cascade=> TRUE);

execute dbms_stats.gather_schema_stats('SYS',cascade=> TRUE);

execute dbms_stats.gather_schema_stats('SYSTEM',cascade=> TRUE);

exit

EOF

 

? 建立OGG復制用戶，或給現有用戶賦權限：

CREATE USER goldengate   IDENTIFIED BY goldengate DEFAULT TABLESPACE ts_ogg;

GRANT CONNECT TO goldengate;

GRANT RESOURCE TO goldengate;

grant dba to goldengate;

? 指定DDL對象所在的schema，這里直接建立在goldengate用戶下：

Ggsci>EDIT PARAMS ./GLOBALS

GGSCHEMA goldengate

? 檢查數據庫的recyclebin參數是否已關閉：

SQL> show parameter recyclebin

 

NAME                                 TYPE

------------------------------------ ---------------------------------

VALUE

------------------------------

recyclebin                           string

on

 

如不是off，需要關閉recyclebin：

alter system set recyclebin=off

? 建立OGG的DDL對象：

 

sqlplus "/ as sysdba"

SQL> @marker_setup.sql

Enter GoldenGate schema name:goldengate

SQL> @ddl_setup.sql

Enter GoldenGate schema name:goldengate

SQL> @role_setup.sql

Grant this role to each user assigned to the Extract, Replicat, GGSCI, and Manager processes, by using the following SQL command:

 

GRANT GGS_GGSUSER_ROLE TO

 

where is the user assigned to the GoldenGate processes.

注意這里的提示：它需要你手工將這個GGS_GGSUSER_ROLE指定給你的extract所使用的數據庫用戶（即參數文件里面通過userid指定的用戶），可以到sqlplus下執行類似的sql:

GRANT GGS_GGSUSER_ROLE TO ggs1;

這里的ggs1是extract使用的用戶。如果你有多個extract，使用不同的數據庫用戶，則需要重述以上過程全部賦予GGS_GGSUSER_ROLE權限。

? 啟動OGG DDL捕捉的trigger

在sqlplus里面執行ddl_enable.sql腳本啟用ddl捕捉的trigger。

說明：ddl捕捉的trigger與OGG的extract進程是相互獨立的，它并不依賴于extract進程存在。即使OGG的extract進程不存在或者沒有啟動，但是trigger已經啟用了，那么捕捉ddl的動作就一直延續下去。如想徹底停止捕捉DDL捕捉，需要執行下步禁用ddl的trigger。

 

? （可選）安裝提高OGG DDL復制性能的工具

為了提供OGG的DDL復制的性能，可以將ddl_pin腳本加入到數據庫啟動的腳本后面，該腳本需要帶一個OGG的DDL用戶（即安裝DDL對象的用戶，本例中是goldengate）的參數:

SQL> @ddl_pin <ddl_user>

 

? （如果不再需要DDL復制時）停止OGG DDL捕捉的trigger

在sqlplus里面執行ddl_disable.sql腳本啟用ddl捕捉的trigger。

 

DDL復制的典型配置

GoldenGate的data pump進程和replicat的ddl開關默認是打開的，只有主extract是默認關閉的，所以DDL的配置一般只在主extract進行。 結合附錄所述的OGG的各種限制，如果需要打開DDL復制，則建議只打開跟數據有密切關系的表和index的DDL復制，參數如下：

DDL &

INCLUDE MAPPED OBJTYPE 'table' &

INCLUDE MAPPED OBJTYPE 'index'

DDLOPTIONS ADDTRANDATA, NOCROSSRENAME

 

另外，在mgr里面加入自動purge ddl中間表的參數：

userid goldengate,password XXXXX

PURGEDDLHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7

PURGEMARKERHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7

 

   對于其它對象，依然建議使用手工維護的方式在兩端同時升級。要注意的是級聯刪除和trigger，在目標端建立后應當立即禁用。

異常處理預案

網絡故障

如果MGR進程參數文件里面設置了autorestart參數，GoldenGate可以自動重啟，無需人工干預。

當網絡發生故障時, GoldenGate負責產生遠地隊列的Datapump進程會自動停止. 此時, MGR進程會定期根據mgr.prm里面autorestart設置自動啟動Datapump進程以試探網絡是否恢復。在網絡恢復后, 負責產生遠程隊列的Datapump進程會被重新啟動，GoldenGate的檢查點機制可以保證進程繼續從上次中止復制的日志位置繼續復制。

需要注意的是，因為源端的抽取進程（Capture）仍然在不斷的抓取日志并寫入本地隊列文件，但是Datapump進程不能及時把本地隊列搬動到遠地，所以本地隊列文件無法被自動清除而堆積下來。需要保證足夠容量的存儲空間來存儲堆積的隊列文件。計算公式如下：

存儲容量≥單位時間產生的隊列大小×網絡故障恢復時間

MGR定期啟動抓取和復制進程參數配置參考：

GGSCI > edit param mgr

port 7809

autorestart er *,waitminutes 3,retries 5,RESETMINUTES 60

每3分鐘重試一次，5次重試失敗以后等待60分鐘，然后重新試三次。

 

RAC環境下單節點失敗

在RAC環境下，GoldenGate軟件安裝在共享目錄下?？梢酝ㄟ^任一個節點連接到共享目錄，啟動GoldenGate運行界面。如果其中一個節點失敗，導致GoldenGate進程中止，可直接切換到另外一個節點繼續運行。建議在Oracle技術支持協助下進行以下操作：

1) 以oracle用戶登錄源系統（通過另一完好節點）；

2) 確認將GoldenGate安裝所在文件系統裝載到另一節點相同目錄；

3) 確認GoldenGate安裝目錄屬于oracle用戶及其所在組；

4) 確認oracle用戶及其所在組對GoldenGate安裝目錄擁有讀寫權限；

5) 進入goldengate安裝目錄；

6) 執行./ggsci進入命令行界面；

7) 執行start mgr啟動mgr；

8) 執行start er *啟動所有進程；

檢查各進程是否正常啟動，即可進入正常復制。以上過程可以通過集成到CRS或HACMP等集群軟件實現自動的切換，具體步驟請參照國網測試文檔。

 

Extract進程常見異常

對于源數據庫，抽取進程extxm如果變為abended，則可以通過在ggsci中使用view report命令察看報告，可以通過搜索ERROR快速定位錯誤。

一般情況下，抽取異常的原因是因為其無法找到對應的歸檔日志，可以通過到歸檔日志目錄命令行下執行

ls –lt arch_X_XXXXX.arc

察看該日志是否存在，如不存在則可能的原因是：

§ 日志已經被壓縮

GoldenGate無法自動解壓縮，需要人工解壓縮后才能讀取。

§ 日志已經被刪除

如果日志已經被刪除，需要進行恢復才能繼續復制，請聯系本單位DBA執行恢復歸檔日志操作。

一般需要定期備份歸檔日志，并清除舊的歸檔日志。需要保證歸檔日志在歸檔目錄中保留足夠長時間之后，才能被備份和清除。即：定期備份清除若干小時之前的歸檔，而不是全部歸檔。保留時間計算如下：

某歸檔文件保留時間≥抽取進程處理完該文件中所有日志所需的時間

可以通過命令行或者GoldenGate Director Web界面，運行info exXX showch命令查看抓取進程exXX處理到哪條日志序列號。在此序列號之前的歸檔，都可以被安全的清除。如下圖所示：

wpsBA61.tmp 

 

Replicat進程常見異常

對于目標數據庫，投遞進程repXX如果變為abended，則可以通過在ggsci中使用view report命令察看報告，可以通過搜索ERROR快速定位錯誤。

復制進程的錯誤通常為目標數據庫錯誤，比如：

1) 數據庫臨時停機；

2) 目標表空間存儲空間不夠；

3) 目標表出現不一致。

可以根據報告查看錯誤原因，排除后重新啟動rep進程即可。

需要注意一點：往往容易忽略UNDO表空間。如果DML語句中包含了大量的update和delete操作，則目標端undo的生成速度會很快，有可能填滿UNDO表空間。因此需要經常檢查UNDO表空間的大小。

 

異常處理一般步驟

如果GoldenGate復制出現異常，可以通過以下步驟嘗試解決問題：

1. 通過ggsci>view report命令查找ERROR字樣，確定錯誤原因并根據其信息進行排除；

2. 通過ggsci>view ggsevt查看告警日志信息；

3. 檢查兩端數據庫是否正常運行，網絡是否連通；

4. 如不能確定錯誤原因，則可以尋求Oracle技術支持。在尋求技術支持時一般需要提供以下信息：

a) 錯誤描述

b) 進程報告，位于dirrpt下以大寫進程名字開頭，以.rpt結尾，如進程名叫extsz，則報告名字叫EXTSZ.rpt；

c) GGS日志ggserr.log，位于GGS主目錄下；

d) 丟失數據報告，在復制進程的參數disardfile中定義，一般結尾為.dsc；

e) 當前隊列，位于dirdat下。

 

附錄

 Oracle GoldenGate V11.1數據復制限制

不支持文件等非結構化數據復制

GoldenGate依賴對于數據庫日志的解析獲取數據變化，因此只能支持數據庫中的數據變化復制，無法支持文件等非結構化數據的復制。

Oracle數據類型限制

GoldenGate支持Oralce常見數據類型的復制。

l GoldenGate不支持的數據類型

a) ANYDATA

b) ANYDATASET

c) ANYTYPE

d) BFILE

e) BINARY_INTEGER

f) MLSLABEL

g) PLS_INTEGER

h) TIMEZONE_ABBR

i) TIMEZONE_REGION

j) URITYPE

k) UROWID

l GoldenGate有限制支持XML Type復制

? 僅限于Oracle 9i及以后版本

? 表必須有主鍵或者唯一索引

l GoldenGate有限制支持UDT用戶自定義類型復制

? 如有該類型數據請聯系技術支持人員并提供腳本。

Oracle DML操作支持

GoldenGate當前支持普通表的所有DML操作和有限制支持部分特殊對象的DML操作，對于特殊表或對象請參照后面特殊對象一節的說明。

l GoldenGate不支持nologging的表等對象

當表或表空間被設置為nologging后，使用sqlloader或者append等非常規模式插入數據將不會被寫入到數據庫日志，因此GoldenGate無法獲取這些數據變化。建議將所有需要的業務表設置為logging狀態，對于nologging的表不予以復制。

l GoldenGate暫不支持對象和操作如下

a) REF

b) 使用COMPRESS 選項建立的表空間和表

c) Database Replay

l GoldenGate支持Sequence序列的復制

l GoldenGate可以通過復制源表支持對于同義詞或者DBLink的復制。

由于對于這些對象本身的操作發生于其所鏈接的源數據庫對象，數據庫日志中并不記錄對這些鏈接目標對象的操作，因此GoldenGate不復制對同義詞或者DBLink本身的操作，但這些操作會應用在源表上并產生日志，因此可以通過復制源表復制變化。

l GoldenGate有限制支持IOT索引組織表復制

? 僅限于Oracle 10.2及以后版本

? 能夠支持使用MAPPING TABLE創建的IOT，但是只抽取基表的數據變化，而不是MAPPING TABLE。

? 不支持以compress模式存儲的IOT。例如，不支持存儲在一個使用compress選項的表空間里的IOT。

l GoldenGate有限制支持Clustered Table復制

? 僅限于Oracle 9i及以后版本

? 不支持Encrypted加密和compressed壓縮的clustered tables

l GoldenGate有限制支持物化視圖復制

? 不支持使用WITH ROWID選項創建的物化視圖

? 源表必須有主鍵

? 不支持物化視圖的Truncate但支持DELETE FROM

? 目標物化視圖必須是可更新的

? 只在Oracle 10g或以后的版本支持物化視圖的Full refresh

Oracle DDL復制限制

GoldenGateDDL復制的原理是通過Trigger從源數據庫獲取sql，到目標端進行重現，在實際使用中有較多限制，即源端能夠執行的sql到了目標端未必能夠執行成功。以下為常見的一些問題：

? 當SQL語句里面設計的對象在目標不存在時，DDL無法執行成功。例如，源建立了一個DBLINk或create table as select * from mydblink，此時目標端可能并沒有這個dblink指向的庫或對象，所以sql語句會報錯；

? 當兩端的物理位置不同時，建立data file或tablespace等與物理位置相關的語句需要在目標端替換為目標的物理位置；

? 當創建約束沒有指定名稱時，在源和目標會生成不同名稱的對象，這樣以后對這些對象再進行修改時就無法正確映射到目標端；

? 當復制帶有LOB的表時，ddl操作必須等待DML操作全部完成以后再復制；

? 不能復制表明和列名帶有中文的表；

? 表或其它對象的定義里面不能加入中文注釋;

? 不能復制帶有編譯錯誤的CREATE trigger/procedure/function/package等對象；

? 不能復制結尾帶有‘/’的sql語句.

此外，GoldenGate DDL復制需要關閉Oracle的_RECYCLEBIN參數（Oracle 10.1）或者RECYCLEBIN參數（Oracle 10.2及以后版本）。

還有一個比較重要的是：由于是Trigger based，GoldenGate的DDL復制可能會降低源數據庫的性能，所以不推薦使用DDL復制，具體請參照國網OGG實施原則。

 

說明：更多詳細信息請參照OGG的官方參考手冊。

 

 

 

Oracle 9i中如何為超過32列的無主鍵表添加附加日志

為數據庫表添加附加日志操作的本質是執行如下的SQL語句：

Alter table

add supplemental log group (column,..) always;

 

Oracle GoldenGate的add trandata 也是調用這個語句執行：

1) 當表有主鍵時，會將所有作為主鍵的列放到columns子句里面添加到附加日志組里；

2) 如果沒有主鍵，則會找唯一索引，將唯一索引列放到columns子句里面添加到附加日志組里;

3) 如果沒有主鍵和唯一索引，則會將所有列添加到附加日志組中去。

 

在對于無主鍵和唯一索引表添加附加日志時，Oracle 9i有個限制: 即每個附加日志組不可以超過32個列（大致數字，與實際列定義長度有關）.此時調用GoldenGate的add Trandata命令會失敗，其處理方法是將該表的所有列拆分為若干組，每組不超過32各列，然后分別添加附加日志組（對不同組合設置不同附加日志組名）。以下為一個超過32列表添加附加日志例子：

ALTER TABLE SIEBEL.XYZ_SQL ADD SUPPLEMENTAL LOG GROUP GGS_XYZ_SQL_649101_1(ACTION ,ACTION_HASH ,ADDRESS ,BUFFER_GETS ,CHILD_ADDRESS ,CHILD_LATCH ,CHILD_NUMBER ,COMMAND_TYPE ,CPU_TIME ,DISK_READS ,ELAPSED_TIME ,EXECUTIONS ,FETCHES ,FIRST_LOAD_TIME ,HASH_VALUE ,INSTANCE_ID ,INVALIDATIONS ,IS_OBSOLETE ,KEPT_VERSIONS ,LAST_LOAD_TIME ,LITERAL_HASH_VALUE ,LOADED_VERSIONS ,LOADS ,MODULE ,MODULE_HASH ,OBJECT_STATUS ,OPEN_VERSIONS ,OPTIMIZER_COST ,OPTIMIZER_MODE ,OUTLINE_CATEGORY ,OUTLINE_SID ,PARSE_CALLS) always;

ALTER TABLE SIEBEL.XYZ_SQL ADD SUPPLEMENTAL LOG GROUP GGS_XYZ_SQL_649101_2(PARSING_SCHEMA_ID ,PARSING_USER_ID ,PERSISTENT_MEM ,PLAN_HASH_VALUE ,REMOTE ,ROWS_PROCESSED ,RUNTIME_MEM ,SERIALIZABLE_ABORTS ,SHARABLE_MEM ,SNAP_ID ,SORTS ,SQLTYPE ,SQL_TEXT ,TYPE_CHK_HEAP ,USERS_EXECUTING ,USERS_OPENING) always;

 

說明：通過手工方式加入附加日志后，不能在ggsci中使用info trandata查看到附加日志，此時可以通過下列語句查詢是否有表沒有加入到附加日志：

SQL> select * from dba_log_groups where owner='SIEBEL'  and table_name=’XXX’;

如想驗證是否所需的列均在附加日志中，可以再查詢dba_log_group_columns。

如需將附加日志組drop掉，可以采用如下格式：

Alter table

 drop supplemental log group ;

 

 

 

 ogg的字符集分析淺談 

我們所熟知oracle的字符集一旦創建完畢后最好不要修改，關于oracle goldengate的字符集問題還是需要注意的，因為如果目標端和源端字符集不一致，而有些字符無法在目標端表示ogg可能無法保證數據一致性。

源庫字符集：

SQL> select value from v$nls_parameters where parameter='NLS_CHARACTERSET';

VALUE

----------------------------------------------------------------

AL32UTF8

如果這里小魚在源端設置SETENV（NLS_LANG=“AMERICAN_AMERICA.ZHS16GBK”）去指定源端客戶端的字符集

GGSCI (dg01) 21> view params exiaoyu

extract exiaoyu

SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")

SETENV (ORACLE_SID="xiaoyu")

userid ogg,password ogg

dynamicresolution

gettruncates

report at 2:00

reportrollover at 3:00

warnlongtrans 3h,checkinterval 10m

exttrail ./dirdat/dd

table xiaoyu.*;

table xiaoyugg.*;

來看看對應的extract進程的報告，發現此時ogg發覺源端客戶端的NLS_LANG變量和源端數據庫字符集不一致，從而選擇源端數據庫字符集，并沒有根據extract進程參數中的SETENV指定。

GGSCI (dg01) 52> view report exiaoyu

** Running with the following parameters **

***********************************************************************

2013-06-04 04:50:27 INFO OGG-03035 Operating system character set identified as UTF-8. Locale: en_US, LC_ALL:.

extract exiaoyu

SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")

Set environment variable (NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)

SETENV (ORACLE_SID="xiaoyu")

Set environment variable (ORACLE_SID=xiaoyu)

userid ogg,password ***

2013-06-04 04:50:28 INFO OGG-03500 WARNING: NLS_LANG environment variable does not match database character set, or not set. Using database character set value of AL32UTF8.

[oracle@ogg 11.2]$ oggerr 3500

03500, 00000, "WARNING: NLS_LANG environment variable does not match database character set, or not set. Using database character set value of {0}"

// *{0}: nls_charset (String)

// *Cause: The NLS_LANG environment variable is not set to the same as the

// database character set. Oracle GoldenGate is using the database

// character set.

// *Action: None

看來源端設置NLS_LANG跟oracle database的字符集不一致時，ogg還是會選擇oracle database的字符集，而忽略掉extract的進程參數SETEVN NLS_LANG

接下來測試目標端：

這里也指定SETENV（NLS_LANG=”AMERICAN_AMERICA.ZHS16GBK”）

GGSCI (ogg.single) 15> view params rxiaoyu

replicat rxiaoyu

SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")

SETENV (ORACLE_SID="xiaoyu")

userid ogg,password ogg

assumetargetdefs

gettruncates

report at 2:00

reportrollover at 3:00

discardfile ./dirrpt/discard_rxiaoyu.dsc,append,megabytes 100

map xiaoyu.xiaoyu10,target xiaoyu.xiaoyu10,filter(@getenv("transaction","csn")>1074454806);

map xiaoyu.*,target xiaoyu.*;

map xiaoyugg.*,target ogg.*;

觀察目標端的replicat進程，發現ogg選擇了進程參數中SETENV（NLS_LANG=“AMERICAN_AMERICA.ZHS16GBK”）

GGSCI (ogg.single) 17> view report rxiaoyu

。。。

2013-06-05 03:14:14 WARNING OGG-03504 NLS_LANG character set ZHS16GBK on the target is different from the source database character set AL32UTF8. Replication may not be valid if the source data has an incompatible character for the target NLS_LANG character set

此時ogg給出的提示需要在replicat進程中正確設置SETENV NLS_LANG變量，這里源端傳遞的是AL32UTF8字符集，目標端通過replicat進程參數SETENV NLS_LANG指定的是ZHS16GBK，而ogg也采用了replicat進程的參數，并沒有選擇源端的字符集。

[oracle@ogg 11.2]$ oggerr 3504

03504, 00000, "NLS_LANG character set {0} on the target is different from the source database character set {1}. Replication may not be valid if the source data has an incompatible character for the target NLS_LANG character set."

// *{0}: nls_lang_charset (String)

// *{1}: src_db_charset (String)

// *Cause: The NLS_LANG environment variable on the target is set to a

// different character set than the character set of the source

// database.

// *Action: Set the NLS_LANG environment variable on the target to the

// character set of the source database that is shown in the message.

// You can use the SETENV parameter in the Replicat parameter file to

// set it for the Replicat session.

而ogg報出的3504警告是為了提醒目標端字符集和源端不一致，可能會引起replicat進程異常，這里ogg也推薦在replicat進程中設置NLS_LANG使目標端和源端一致。

那么對于字符集對ogg的影響就是源端和目標端，如果源端和目標端database字符集一直，這里在進程中直接采用一致的SETENV NLS_LANG都等于缺省的數據庫字符集即可，而對于源端和目標端字符集不一致的，則需要在目標端手動指定replicat進程參數SETENV NLS_LANG等于源端字符集，當然對于最后在數據庫中數據行小魚認為還是需要再次轉化成目標端oracle database的字符集。（ogg也是一個同步復制產品，其技術原理依然不能脫離oracle database）