OGG基礎知識整理

一、GoldenGate介紹

---

 

GoldenGate軟件是一種基於日志的結構化數據復制軟件。GoldenGate 能夠實現大量交易數據的實時捕捉、變換和投遞，實現源數據庫與目標數據庫的數據同步，保持亞秒級的數據延遲。

GoldenGate能夠支持多種拓撲結構，包括一對一，一對多，多對一，層疊和雙向復制等等。

GoldenGate基本架構

 

 

Oracle GoldenGate主要由如下組件組成

 

● Extract

● Data pump

● Trails

● Collector

● Replicat

● Manager

Oracle GoldenGate 數據復制過程如下：

利用抽取進程(Extract Process)在源端數據庫中讀取Online Redo Log或者Archive Log，然后進行解析，只提取其中數據的變化信息，比如DML操作——增、刪、改操作，將抽取的信息轉換為GoldenGate自定義的中間格式存放在隊列文件(trail file)中。再利用傳輸進程將隊列文件(trail file)通過TCP/IP傳送到目標系統。

目標端有一個進程叫Server Collector，這個進程接受了從源端傳輸過來的數據變化信息，把信息緩存到GoldenGate 隊列文件(trail file)當中，等待目標端的復制進程讀取數據。

    GoldenGate 復制進程(replicat process)從隊列文件(trail file)中讀取數據變化信息，並創建對應的SQL語句，通過數據庫的本地接口執行，提交到目標端數據庫，提交成功后更新自己的檢查點，記錄已經完成復制的位置，數據的復制過程最終完成。

Oracle GoldenGate（OGG）可以在多樣化和復雜的 IT 架構中實現實時事務更改數據捕獲、轉換和發送；其中，數據處理與交換以事務為單位，並支持異構平台，例如：DB2，MSSQL等
     
     Golden Gate 所支持的方案主要有兩大類，用於不同的業務需求：
     
     ● 高可用和容災解決方案
     ● 實時數據整合解決方案
     
其中，高可用和容災解決方案 主要用於消除計划外和計划內停機時間，它包含以下三個子方案：
     1.  容災與應急備份
     2.  消除計划內停機

     3.  雙業務中心（也稱：雙活）

 

實時數據整合解決方案 主要為 DSS 或 OLTP 數據庫提供實時數據，實現數據集成和整合，它包含以下兩個子方案：

     1.  數據倉庫實時供給
     2.  實時報表

 

靈活拓撲結構實現用戶的靈活方案：

 

     下圖是一個典型的 Golden Gate 配置邏輯結構圖：

 

① Manager

顧名思義、Manager進程是Golden Gate中進程的控制進程，用於管理 Extract，Data Pump，Replicat等進程

在 Extract、Data Pump、Replicat 進程啟動之前，Manager 進程必須先要在源端和目標端啟動，在整個 Golden Gate 運行期間，它必須保持運行狀態
        
        ⒈ 監控與啟動 GoldenGate 的其它進程
        ⒉ 管理 trail 文件及 Reporting
        
在 Windows 系統上，Manager 進程是作為一個服務來啟動的，在 Unix 系統下是一個進程
        
② Extract
        
Extract 進程運行在數據庫源端上，它是Golden Gate的捕獲機制，可以配置Extract 進程來做如下工作：
        ⒈ 初始數據裝載：對於初始數據裝載，Extract 進程直接從源對象中提取數據
        ⒉ 同步變化捕獲：保持源數據與其它數據集的同步。

Extract 進程捕獲源數據的變化；如DML變化、 DDL變化等
        
③ Replicat
        
Replicat 進程是運行在目標端系統的一個進程，負責讀取 Extract 進程提取到的數據（變更的事務或 DDL 變化）並應用到目標數據庫，就像 Extract 進程一樣，也可以配置 Replicat 進程來完成如下工作：
        

⒈ 初始化數據裝載：對於初始化數據裝載，Replicat 進程應用數據到目標對象或者路由它們到一個高速的 Bulk-load 工具上
⒉ 數據同步，將 Extract 進程捕獲到的提交了的事務應用到目標數據庫中
        
④ Collector
     
Collector 是運行在目標端的一個后台進程，接收從 TCP/IP 網絡傳輸過來的數據庫變化，並寫到 Trail 文件里。

動態 collector：由管理進程自動啟動的 collector 叫做動態 collector，用戶不能與動態 collector 交互

靜態 collector：可以配置成手工運行 collector，這個 collector 就稱之為靜態 collector
        
⑤ Trails
        
為了持續地提取與復制數據庫變化，GoldenGate 將捕獲到的數據變化臨時存放在磁盤上的一系列文件中，這些文件就叫做 Trail 文件
        
這些文件可以在 source DB 上也可以在目標 DB 上，也可以在中間系統上，這依賴於選擇哪種配置情況，在數據庫源端上的叫做 Local Trail 或者 Extract Trail；在目標端的叫做 Remote Trail
        
⑥ Data Pumps
        
Data Pump 是一個配置在源端的輔助的 Extract 機制，Data Pump 是一個可選組件，如果不配置 Data Pump，那么由 Extract 主進程將數據發送到目標端的 Remote Trail 文件中，如果配置了 Data Pump，會由 Data Pump將Extract 主進程寫好的本地 Trail 文件通過網絡發送到目標端的 Remote Trail 文件中
        
使用 Data Pump 的好處是：
        ⒈ 如果目標端或者網絡失敗，源端的 Extract 進程不會意外終止
        ⒉ 需要在不同的階段實現數據的過濾或者轉換
        ⒊ 多個源數據庫復制到數據中心
        ⒋ 數據需要復制到多個目標數據庫
        
⑦ Data source
        
當處理事務的變更數據時，Extract 進程可以從數據庫（Oracle, DB2, SQL Server, MySQL等）的事務日志中直接獲取，或從 GoldenGate VAM中獲取。通過 VAM，數據庫廠商將提供所需的組件，用於 Extract 進程抽取數據的變更
        
⑧ Groups
        
為了區分一個系統上的多個 Extract 和 Replicat 進程，我們可以定義進程組
例如：要並行復制不同的數據集，我們可以創建兩個 Replicat 組，一個進程組由一個進程組成（Extract 進程或者 Replicat 進程），一個相應的參數文件，一個 Checkpoint 文件，以及其它與之相關的文件
如果處理組中的進程是 Replicat 進程，那么處理組還要包含一個 Checkpoint 表

GoldenGate簡介 
Oracle Golden Gate軟件是一種基於日志的結構化數據復制備份軟件，它通過解析源數據庫在線日志或歸檔日志獲得數據的增量變化，再將這些變化應用到目標數據庫，從而實現源數據庫與目標數據庫同步。Oracle Golden Gate可以在異構的IT基礎結構（包括幾乎所有常用操作系統平台和數據庫平台）之間實現大量數據亞秒一級的實時復制,從而在可以在應急系統、在線報表、 實時數據倉庫供應、交易跟蹤、數據同步、集中/分發、容災、數據庫升級和移植、雙業務中心等多個場景下應用。同時，Oracle Golden Gate可以實現一對一、廣播(一對多)、聚合(多對一)、雙向、點對點、級聯等多種靈活的拓撲結構。

GoldenGate技術架構 
和傳統的邏輯復制一樣，Oracle GoldenGate實現原理是通過抽取源端的redo log或者archive log，然后通過TCP/IP投遞到目標端，最后解析還原應用到目標端，使目標端實現同源端數據同步。 

Manager進程是GoldenGate的控制進程，運行在源端和目標端上。它主要作用有以下幾個方面：啟動、監控、重啟Goldengate的其他進程，報告錯誤及事件，分配數據存儲空間，發布閥值報告等。在目標端和源端有且只有一個manager進程，其運行狀態為running好stopped。 在windows系統上，manager進程作為一個服務來啟動，二在Linux/Unix系統上則是一個系統進程。

Extract進程 
Extract運行在數據庫源端，負責從源端數據表或者日志中捕獲數據。Extract的作用可以按照表來時間來划分：
初始時間裝載階段：在初始數據裝載階段，Extract進程直接從源端的數據表中抽取數據。

同步變化捕獲階段：初始數據同步完成以后，Extract進程負責捕獲源端數據的變化(DML和DDL)

GoldenGate並不是對所有的數據庫都支持ddl操作 

Extract進程會捕獲所有已配置的需要同步的對象變化，但只會將已提交的事務發送到遠程的trail文件用於同步。當事務提交時，所有和該事務相關的 日志記錄被以事務為單元順序的記錄到trail文件中。Extract進程利用其內在的checkpoint機制，周期性的記錄其讀寫的位置，這種機制是 為了保證Extract進程終止或操作系統當機，重新啟動Extract后，GoldenGate可以恢復到之前的狀態，從上一個斷點繼續往下運行。通過 上面的兩個機制，就可以保證數據的完整性了。

多 個Extract 進程可以同時對不同對象進行操作。例如，可以在一個extract進程抽取並向目標端發生事務數據的同時，利用另一個extract進程抽取的數據做報 表。或者，兩個extract進程可以利用兩個trail文件，同時抽取並並行傳輸給兩個replicat進程以減少數據同步的延時。
在進行初始化轉載，或者批量同步數據時， GoldenGate會生成extract文件來存儲數據而不是trail文件。默認情況下， 只會生成一個 extract文件，但如果出於操作系統對單個文件大小限制或者其他因素的考慮，也可以通過配置生成多個 extract文件。 extract文件不記錄檢查點。

Extract進程的狀態包括Stopped(正常停止),Starting(正在啟動)，Running(正在運行)，Abended(Abnomal End的縮寫，標示異常結束)。
Pump進程 
pump進程運行在數據庫源端，其作用是將源端產生的本地trail文件，把trail以數據塊的形式通過TCP/IP 協議發送到目標端，這通常也是推薦的方式。pump進程本質是extract進程的一種特殊形式，如果不使用trail文件，那么extract進程在抽取完數據以后，直接投遞到目標端，生成遠程trail文件。
與 Pump進程對應 的叫Server Collector進程，這個進程不需要引起我的關注，因為在實際操作過程中，無需我們對其進行任何配置，所以對我們來說它是透明的。它運行在目標端，其 任務就是把Extract/Pump投遞過來的數據重新組裝成遠程ttrail文件。 

注意：無論是否使用pump進程，在目標端都會生成trail文件 
pump進程可以在線或者批量配置，他可以進行數據過濾，映射和轉換，同時他還可以配置為“直通模式”，這樣數據被傳輸到目標端時就可以直接生成所需的格式，無需另外操作。 直通模式提高了data pump的效率，因為生成后的對象 不需要繼續進行檢索。
在大多數情況下，oracle都建議采用data pump，原因如下: 

1、為目標端或網絡問題提供保障 ：如果只在目標端配置trail文件，由於源端會將extract進程抽取的內容不斷的保存在內存中，並及時的發送到目標端。當網絡或者目標端出現故障時， 由於extract進程無法及時的將數據發送到目標， extract進程將耗盡內存然后異常終止。 如果在源端配置了data pump進程，捕獲的數據會被轉移到硬盤上，預防了 異常終止的情況。當故障修復，源端和目標端 恢復連通性時，data pump進程發送源端的trail文件到目標端。
2、 可以支持復雜的數據過濾或者轉換： 當使用數據過濾或者轉換時，可以先配置一個data pump進程在目標端或者源端進行第一步的轉換，利用另一個data pump進程或者 Replicat組進行第二部的轉換。

3、有效的規划存儲資源 ：當從多個數據源同步到一個數據中心時，采用data pump的方式，可以在源端保存抽取的數據，目標端保存trail文件，從而節約存儲空間。
4、解決單數據源向多個目標端傳輸數據的單點故障： 當從一個數據源發送數據到多個目標端時，可以為每個目標端分別配置不同的data pump進程。這樣如果某個目標端失效或者網絡故障時，其他的目標端不會受到影響可以繼續同步數據。 
Replicat進程 
Replicat進程，通常我們也把它叫做應用進程。運行在目標端，是數據傳遞的最后一站，負責讀取目標端trail文件中的內容，並將其解析為DML或 DDL語句，然后應用到目標數據庫中。
和Extract進程一樣，Replicat也有其內部的checkpoint機制，保證重啟后可以從上次記錄的位置開始恢復而無數據損失的風險。
Replicat 進程的狀態包括Stopped(正常停止),Starting(正在啟動)，Running(正在運行)，Abended(Abnomal End的縮寫，標示異常結束)。 
Trail文件 
為了更有效、更安全的把數據庫事務信息從源端投遞到目標端。GoldenGate引進trail文件的概念。前面提到extract抽取完數據以后 Goldengate會將抽取的事務信息轉化為一種GoldenGate專有格式的文件。然后pump負責把源端的trail文件投遞到目標端，所以源、 目標兩端都會存在這種文件。 trail文件存在的目的旨在防止單點故障，將事務信息持久化，並且使用checkpoint機制來記錄其讀寫位置，如果故障發生，則數據可以根據checkpoint記錄的位置來重傳 。 當然，也可以通過extract通過TCP/IP協議直接發送到目標端，生成遠程trail文件。但這種方式可能造成數據丟失，前面已經提到過了，這里不再贅述。
Trail文件默認為10MB，以兩個字符開始加上000000~999999的數字作為文件名。如c:\directory/tr000001.默認情況下存儲在GoldenGate的dirdat子目錄中。可以為不同應用或者對象創建不同的trail文件。同一時刻，只會有一個extract進程處理一個trail文件。

10.0版本以后的GoldenGate，會在trail文件頭部存儲包含trail文件信息的記錄，而10.0之前的版本不會存儲該信息。每個trail文件中的數據記錄包含了數據頭區域和數據區域。在 數據頭區域中包含事務信息，數據區域包含實際抽取的數據  

進程如何寫trail文件

為了減小系統的I/O負載，抽取的數據通過大字節塊的方式存儲到trail文件中。同時為了提高兼容性，存儲在trail文件中的數據以通用數據模式(一種可以在異構數據庫之間進行快速而准確轉換的模式)存儲。 當然，根據不同應用的需求，數據也可以存儲為不同的模式。

默認情況下，extract進程以追加的方式寫入trail文件。當extract進程異常終止時，trail文件會被標記為需要恢復。當extract重新啟動時會追加checkpoint之后的數據追加到該trail文件中。在 GoldenGate 10.0之前的版本， extract進程采用的是覆蓋模式。即當 extract進程異常終止，則會將至上次完整寫入的事務數據之后的數據覆蓋現有trail文件中的內容。

這里是筆者理解不是很透徹，原文如下，望讀者給予建議

 

By default, Extract operates in append mode, where if there is a process failure, a recovery marker is written to the trail and Extract appends recovery data to the file so that a history of all prior data is retained for recovery purposes. In append mode, the Extract initialization determines the identity of the last complete transaction that was written to the trail at startup time. With that information, Extract ends recovery when the commit record for that transaction is encountered in the data source; then it begins new data capture with the next committed transaction that qualifies for extraction and begins appending the new data to the trail. A data pump or Replicat starts reading again from that recovery point. Overwrite mode is another version of Extract recovery that was used in versions of GoldenGate prior to version 10.0. In these versions, Extract overwrites the existing transaction data in the trail after the last write-checkpoint position, instead of appending the new data. The first transaction that is written is the first one that qualifies for extraction after the last read checkpoint position in the data source. checkpoint

checkpoint用於抽取或復制失敗后（如系統宕機、網絡故障燈），抽取、復制進程重新定位抽取或者復制的起點。在高級的同步配置中，可以通過配置checkpoint另多個extract或者replicat進程讀取同個trail文件集。

extract進程在數據源和trail文件中都會標識checkpoint，Replicat只會在trail文件中標示checkpoint。

在批處理模式中，extract和replicat進程都不會記錄checkpoint。如果批處理失敗，則整改批處理會重新進行。

checkpoint信息會默認存儲在goldengate的子目錄dirchk中。在目標端除了checkpoint文件外，我們也可以通過配置通過額外checkpoint table來存儲replicat的checkpoint信息。

Group 
我們可以通過為不同的extract和replicat進程進行分組來去區分不同進程之間的作用。例如，當需要並行的復制不同的數據集時，我們則可以創建兩個或者多個復制進程。
進程組中包含進程，進程文件，checkpoint文件和其他與進程相關的文件。對於replicat進程來說，如果配置了checkpoint table，則不同組的都會包含checkpoint table。

GGSCI 
GGSCI是GoldenGate Software Command Interface 的縮寫，它提供了十分豐富的命令來對Goldengate進行各種操作，如創建、修改、監控GoldenGate進程等等。
Commit Sequence Number
前文已經多次提到，Goldengate是以事務為單位來保證數據的完整性的，那么 GoldenGate又是怎么識別事務的呢？ 這里用到的是Commit Sequence Number(CSN)。CSN存儲在事務日志中和trail文件中 ，用於數據的抽取和復制。CSN作為事務開始的標志被記錄在trail文件中，可以通過@GETENV字段轉換函數或者logdump工具來查看。

二、GoldenGate安裝實施

2.1創建GoldenGate軟件安裝目錄

在數據庫服務器上創建文件系統：/u01/gg，作為GoldenGate的安裝目錄。

2.2 GoldenGate的管理用戶

安裝GoldenGate軟件和維護GoldenGate軟件時，可以使用系統上的oracle用戶。GoldenGate安裝目錄的所有者必須是GoldenGate管理用戶，本次實施過程中使用oracle用戶作為GoldenGate管理用戶，添加oracle用戶的環境變量(在生產端和容災端均要進行以下操作)：

 

export GG_HOME=/u01/ggexport LD_LIBRARY_PATH=$GG_HOME:$ORACLE_HOME/lib:/usr/bin:/libexport PATH=$GG_HOME:$PATH

2.3安裝GoldenGate軟件

切換到oracle用戶，將GG軟件的壓縮包存放到GoldenGate安裝目錄下，即/u01/gg，將這個壓縮包進行解壓到GoldenGate安裝目錄下(在生產端和容災端均要進行以下操作)：

tar -zxvf *.gz

 

進入到GoldenGate安裝目錄，運行GGSCI命令以進入GG界面(在生產端和容災端均要進行以下操作)：

 

cd /u01/gg./ggsci

 

在GGSCI界面下創建子目錄(在生產端和容災端均要進行以下操作)：

GGSCI>create subdirs

 

至此，GoldenGate軟件安裝完畢。

2.4設置數據庫歸檔模式

查看數據庫的歸檔模式：

SQL>archive log list;

 

如果是非歸檔模式，需要開啟歸檔模式：

 

shutdown immediate;startup mount;alter database archivelog;alter database open;

2.5打開數據庫的附加日志

打開附加日志並切換日志（保證Online redo log和Archive log一致）

 

alter database add supplemental log data ;alter database add supplemental log data (primary key, unique,foreign key) columns;alter system switch logfile;

2.6開啟數據庫強制日志模式

alter database force logging;

2.7創建GoldenGate管理用戶

在生產端和容災端均要進行以下操作：

 

--create tablespaceSQL>create tablespace ogg datafile '$ORACLE_BASE/oradata/test/ogg01.dbf' size 300M ;-- create the userSQL>create user ogg identified by ogg default tablespace ogg;-- grant role privilegesSQL>grant resource, connect, dba to ogg;

2.8編輯GLOBALS參數文件

切換到GoldenGate安裝目錄下，執行命令：

 

cd /u01/gg./ggsciGGSCI>EDIT PARAMS ./GLOBALS

 

在文件中添加以下內容：

GGSCHEMA ogg --指定的進行DDL復制的數據庫用戶

 

利用默認的密鑰，生成密文：

 

GGSCI>encrypt password ogg encryptkey defaultEncrypted password:  AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB

 

記錄這個密文，將在以下進程參數的配置中使用。

2.9管理進程MGR參數配置

 

PORT 7839DYNAMICPORTLIST 7840-7860--AUTOSTART ER *--AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 2userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKY defaultPURGEDDLHISTORY MINKEEPDAYS 11,MAXKEEPDAYS 14PURGEMARKERHISTORY MINKEEPDAYS 11, MAXKEEPDAYS 14

2.10抽取進程EXTN參數配置

 

EXTRACT extnsetenv (NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252)userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY defaultREPORTCOUNT EVERY 1 MINUTES, RATEDISCARDFILE ./dirrpt/discard_extn.dsc,APPEND,MEGABYTES 1024DBOPTIONS ALLOWUNUSEDCOLUMNWARNLONGTRANS 2h,CHECKINTERVAL 3mEXTTRAIL ./dirdat/naTRANLOGOPTIONS EXCLUDEUSER OGGTRANLOGOPTIONS ALTARCHIVEDLOGFORMAT %t_%s_%r.dbfFETCHOPTIONS NOUSESNAPSHOTTRANLOGOPTIONS CONVERTUCS2CLOBSTRANLOGOPTIONS altarchivelogdest primary instance test /oradata/arch--TRANLOGOPTIONS RAWDEVICEOFFSET 0DYNAMICRESOLUTIONDDL INCLUDE ALLDDLOPTIONS addtrandata, NOCROSSRENAME, REPORTtable QQQ.*;table CUI.*;

2.11 傳輸進程DPEN參數配置

 

EXTRACT dpenRMTHOST 192.168.4.171 , MGRPORT 7839, compressPASSTHRUnumfiles 50000RMTTRAIL ./dirdat/naTABLE QQQ.*;TABLE CUI.*;

2.12建立OGG的DDL對象

 

$ cd /u01/gg $ sqlplus "/ as sysdba"SQL> @marker_setup.sqlEnter GoldenGate schema name:oggalter system set recyclebin=off;SQL> @ddl_setup.sqlEnter GoldenGate schema name: oggSQL> @role_setup.sqlGrant this role to each user assigned to the Extract, Replicat, GGSCI, and Manager processes, by using the following SQL command:SQL>GRANT GGS_GGSUSER_ROLE TOwhere is the user assigned to the GoldenGate processes.

 

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

SQL>GRANT GGS_GGSUSER_ROLE TO ogg;

 

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

運行以下腳本，使觸發器生效：

SQL> @ ddl_enable.sql

 

注：在生產端開啟抽取前，先禁用DDL捕獲觸發器，調用ddl_disable.sql。

2.13 數據初始化

在初始化過程中，源數據庫不需要停機，初始化過程分為三個部分：

生產端開啟抽取進程；

生產端導出數據；

容災端導入數據；

在生產端添加抽取進程、傳輸進程以及相應的隊列文件,執行命令如下：

 

//創建進程 EXTNGGSCI>add extract extn,tranlog,begin nowGGSCI>add exttrail ./dirdat/na,extract extn,megabytes 500//創建進程 DPENGGSCI>add extract dpen,exttrailsource ./dirdat/naGGSCI>add rmttrail ./dirdat/na,extract dpen,megabytes 500在生產端啟動管理進程：GGSCI> start mgr

啟用DDL 捕獲trigger：

 

$ cd /u01/gg$ sqlplus “/as sysdba”SQL> @ddl_enable.sql

在生產端啟動抽取進程：

GGSCI> start EXTN

 

在數據庫中，獲取當前的SCN號，並且記錄這個SCN號：

 

SQL>select to_char(dbms_flashback.get_system_change_number) from dual;603809

 

在數據庫中，創建數據泵所需目錄並賦予權限：

 

SQL>CREATE OR REPLACE DIRECTORY DATA_PUMP AS '/u01';SQL>grant read ,write on DIRECTORY DATA_PUMP to ogg;

 

在生產端利用數據泵導出數據：

 

expdp ogg/ogg schemas='QQQ' directory=DATA_PUMP dumpfile=QQQ_bak_%U flashback_scn=123456789 logfile=expdp_QQQ.log filesize=4096mexpdp ogg/ogg schemas='CUI' directory=DATA_PUMP dumpfile=CUI_bak_%U flashback_scn=123456789 logfile=expdp_ CUI.log filesize=4096mexpdp ogg/ogg schemas='test1' directory=DATA_PUMP dumpfile=test1_bak_%U flashback_scn=603809 logfile=expdp_QQQ.log filesize=4096m

 

把導出的文件傳輸到容災端，利用數據泵將數據導入：

 

Impdp ogg/ogg DIRECTORY=DATA_PUMP DUMPFILE=QQQ_bak_%U logfile=impdp_QQQ.logImpdp ogg/ogg DIRECTORY=DATA_PUMP DUMPFILE=CUI_bak_%U logfile=impdp_CUI.log

2.14 容災端管理進程MGR參數配置

 

PORT 7839DYNAMICPORTLIST 7840-7860--AUTOSTART ER *--AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 2userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY default

2.15編輯GLOBALS參數文件

切換到GoldenGate安裝目錄下，執行命令：

 

cd /u01/gg./ggsciggsci>EDIT PARAMS ./GLOBALS

 

在文件中添加以下內容：

GGSCHEMA ogg --指定的進行DDL復制的數據庫用戶

2.16 容災端復制進程REPN參數配置

 

REPLICAT repnsetenv (NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252)userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY defaultSQLEXEC "ALTER SESSION SET CONSTRAINTS=DEFERRED"REPORT AT 01:59REPORTCOUNT EVERY 30 MINUTES, RATEREPERROR DEFAULT, ABENDassumetargetdefsDISCARDFILE ./dirrpt/repna.dsc, APPEND, MEGABYTES 1024DISCARDROLLOVER AT 02:30ALLOWNOOPUPDATESREPERROR (1403, discard)DDL INCLUDE MAPPED DDLOPTIONS REPORTMAPEXCLUDE QQQ.T0417MAP QQQ.*, TARGET QQQ.*;MAP CUI.*, TARGET CUI.*;

2.17創建復制進程repn

    執行以下命令創建復制進程repn：

GGSCI>add replicat repn, exttrail ./dirdat/na, nodbcheckpoint

2.18啟動生產端傳輸進程和容災端復制進程

 

GGSCI>start dpenGGSCI>start REPLICAT repn aftercsn 123456789

2.19測試場景

（1）在生產端數據庫上，創建一張表。

（2）在生產端數據庫上，修改這個張表的數據。

（3）在生產端數據庫上，刪除這張表。

三．GoldenGate基本運維命令

（1）查看進程狀態

GGSCI>info all

——查看GG整體運行情況，比如進程Lag延時，檢查點延時。

GGSCI>info <進程名>

——查看某個進程的運行狀況，比如抽取進程正在讀取哪個歸檔日志或者聯機重做日志，傳輸進程正在傳送哪一個隊列文件，復制進程正在使用哪一個隊列文件。

GGSCI>info <進程名> showch

——查看某個進程運行的詳細信息。

（2）查看進程報告

GGSCI>view report <進程名> 

——報錯時，從進程報告里獲取錯誤信息。

（3）在操作系統上，查看GoldenGate安裝目錄的使用率

$ df -h

——查看ogg目錄是否撐滿。

四、常見故障排除

故障（1）

錯誤信息：

OGG-00446  Could not find archived log for sequence 53586 thread 1 under alternative destinations. SQL . Last alternative log tried /arch_cx/1_53586_776148274.arc., error retri eving redo file name for sequence 53586, archived = 1, use_alternate = 0Not able to establish initial position for sequence 53586, rba 44286992. 處理辦法： 將缺失的歸檔日志從備份中恢復出來。如果依舊找不到所需歸檔日志，那么只能重新實施數據初始化。   故障（2） 錯誤信息： OGG-01154  Oracle GoldenGate Delivery for Oracle, repn.prm:  SQL error 1691 mapping DATA_USER.DMH_WJXXB to DATA_USER.DMH_WJXXB OCI Error ORA-01691: unable to extend lob segment DATA_USER.SYS_LOB0000083691C00014$$ by 16384 in tablespace DATA_USER_LOB_U128M_1 (status = 1691), SQL . 處理辦法： 數據庫中該表空間已滿，需要對該表空間進行擴容。   故障（3） 錯誤信息： OGG-00664  OCI Error during OCIServerAttach (status = 12541-ORA-12541: TNS:no listener). 處理方法： 啟動數據庫的監聽器。   故障（4） 錯誤信息： OGG-00665  OCI Error describe for query (status = 3135-ORA-03135: connection lost contact Process ID: 8859 Session ID: 131 Serial number: 31), SQL.

處理方法：

在沒有關閉OGG進程的情況下，提前關閉了數據庫，導致OGG進程出現異常。如果是發現了這個錯誤提示，應該馬上關閉OGG進程，注意數據庫的歸檔日志情況，保證歸檔日志不會缺失，然后等待數據庫啟動成功后，馬上啟動OGG進程。

 

故障（5）

錯誤信息：

OGG-01161  Bad column index (4) specified for table QQQ.TIANSHI, max columns = 4.

處理方法：

對照一下生產端與容災端的這一張表的表結構，如果容災端的表缺少一列，則在容災端，登陸數據庫，增加這一列，然后啟動復制進程。

 

故障（6）

錯誤信息：

ERROR   OGG-00199  Table QQQ.T0417 does not exist in target database.

處理方法：

查看源端抽取進程的參數，DDL復制參數是否配置，針對這張表，重新實施數據初始化。

 

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 AvailableRead 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命令查看整體運行情況。如下圖示：

 

 

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

STARTING: 表示正在啟動過程中

RUNNING：表示進程正常運行

STOPPED：表示進程被正常關閉

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

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

查看參數設置

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

 

 

查看進程狀態

使用info <進程名稱> 命令可以查看進程信息。可以查看到的信息包括進程狀態、checkpoint信息、延時等。如：

 

 

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

 

 

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

 

 

查看延時

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

 

 

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

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

此命令支持通配符 *。

查看統計信息

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

 

 

 

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

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

查看運行報告

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

 

 

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

 

 

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

 

 

OGG的常見運維任務指南

配置自動刪除隊列

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

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

purgeoldextracts //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 AvailableRead 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 10mexttrail /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 XXXXXXXGGSCI > 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.SHOULIXINXImapexclude myschema.mytableMAP 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 XXXXXXggsci> delete trandata schema.mytableggsci> 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</eof<>connect / as sysdbaalter 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);exitEOF

 

建立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 ./GLOBALSGGSCHEMA goldengate

 

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

 

SQL> show parameter recyclebinNAME TYPE------------------------------------ ---------------------------------VALUE------------------------------recyclebin stringon

 

如不是off，需要關閉recyclebin：

alter system set recyclebin=off

建立OGG的DDL對象：

 

sqlplus "/ as sysdba"SQL> @marker_setup.sqlEnter GoldenGate schema name:goldengateSQL> @ddl_setup.sqlEnter GoldenGate schema name:goldengateSQL> @role_setup.sqlGrant this role to each user assigned to the Extract, Replicat, GGSCI, and Manager processes, by using the following SQL command:GRANT GGS_GGSUSER_ROLE TOwhere 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復制時）停止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 XXXXXPURGEDDLHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7PURGEMARKERHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7

 

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

異常處理預案

網絡故障

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

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

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

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

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

 

GGSCI > edit param mgrport 7809autorestart 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處理到哪條日志序列號。在此序列號之前的歸檔，都可以被安全的清除。如下圖所示：

 

 

 

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下。