【OGG】OGG基礎知識整理

【OGG】OGG基礎知識整理

---

---

1、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能夠實現一對1、廣播(一對多)、聚合(多對一)、雙向、點對點、級聯等多種靈活的拓撲結構。

GoldenGate技術架構 
和傳統的邏輯複製同樣，Oracle GoldenGate實現原理是經過抽取源端的redo log或者archive log，而後經過TCP/IP投遞到目標端，最後解析還原應用到目標端，使目標端實現同源端數據同步。如下是OracleGoldenGate的技術架構：  

Manager進程 
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，緣由以下: 
一、爲目標端或網絡問題提供保障 ：若是隻在目標端配置trail文件，因爲源端會將extract進程抽取的內容不斷的保存在內存中，並及時的發送到目標端。當網絡或者目標端出現故障時， 因爲extract進程沒法及時的將數據發送到目標， extract進程將耗盡內存而後異常終止。 若是在源端配置了data pump進程，捕獲的數據會被轉移到硬盤上，預防了 異常終止的狀況。當故障修復，源端和目標端 恢復連通性時，data pump進程發送源端的trail文件到目標端。
二、 能夠支持複雜的數據過濾或者轉換： 當使用數據過濾或者轉換時，能夠先配置一個data pump進程在目標端或者源端進行第一步的轉換，利用另外一個data pump進程或者 Replicat組進行第二部的轉換。

三、有效的規劃存儲資源 ：當從多個數據源同步到一個數據中心時，採用data pump的方式，能夠在源端保存抽取的數據，目標端保存trail文件，從而節約存儲空間。
四、解決單數據源向多個目標端傳輸數據的單點故障： 當從一個數據源發送數據到多個目標端時，能夠爲每一個目標端分別配置不一樣的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工具來查看。不一樣的數據庫平臺的CSN顯示以下

GoldenGate對不一樣數據庫的支持狀況

 

 

*只能做爲目標端，不能做爲源端。但Goldengate能夠從mysql直接裝載的原表中抽取數據。（因爲筆者不瞭解mysql，這裏只是在字面意思翻譯，原文以下
the exception being that GoldenGate can extract records from MySQL source tables as part of a GoldenGate direct load.
** GoldenGate進行事務數據管理的API工具
*** 只支持鏡像複製，不支持數據操做、過濾，字段映射等。 

參考至：《Oracle GoldenGate Administrator Guide》
           《企業級IT運維寶典之GoldenGate實戰_第1章》聯動北方著

---

---

2、GoldenGate安裝實施

2.1建立GoldenGate軟件安裝目錄

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

2.2 GoldenGate的管理用戶

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

export GG_HOME=/u01/gg

export LD_LIBRARY_PATH=$GG_HOME:$ORACLE_HOME/lib:/usr/bin:/lib

export 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 tablespace

SQL>create tablespace  ogg  datafile '$ORACLE_BASE/oradata/test/ogg01.dbf' size 300M ;

-- create the user

SQL>create user ogg identified by ogg default tablespace ogg;

-- grant role privileges

SQL>grant  resource, connect, dba to ogg;

2.8編輯GLOBALS參數文件

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

cd /u01/gg

./ggsci

GGSCI>EDIT PARAMS ./GLOBALS

在文件中添加如下內容：

GGSCHEMA ogg  --指定的進行DDL複製的數據庫用戶

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

GGSCI>encrypt password ogg encryptkey default

Encrypted password:  AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB

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

2.9管理進程MGR參數配置

PORT 7839

DYNAMICPORTLIST 7840-7860

--AUTOSTART ER *

--AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3

PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 2

userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKY default

PURGEDDLHISTORY MINKEEPDAYS 11,MAXKEEPDAYS 14

PURGEMARKERHISTORY MINKEEPDAYS 11, MAXKEEPDAYS 14

2.10抽取進程EXTN參數配置

EXTRACT extn

setenv (NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252)

userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY default

REPORTCOUNT EVERY 1 MINUTES, RATE

DISCARDFILE ./dirrpt/discard_extn.dsc,APPEND,MEGABYTES 1024

 

DBOPTIONS  ALLOWUNUSEDCOLUMN

WARNLONGTRANS 2h,CHECKINTERVAL 3m

EXTTRAIL ./dirdat/na

 

TRANLOGOPTIONS EXCLUDEUSER OGG

TRANLOGOPTIONS ALTARCHIVEDLOGFORMAT %t_%s_%r.dbf

FETCHOPTIONS NOUSESNAPSHOT

TRANLOGOPTIONS CONVERTUCS2CLOBS

TRANLOGOPTIONS altarchivelogdest primary instance test /oradata/arch

--TRANLOGOPTIONS RAWDEVICEOFFSET 0

DYNAMICRESOLUTION

 

DDL INCLUDE ALL

DDLOPTIONS addtrandata, NOCROSSRENAME,  REPORT

 

table QQQ.*;

table CUI.*;

2.11 傳輸進程DPEN參數配置

EXTRACT dpen

RMTHOST 192.168.4.171 , MGRPORT 7839, compress

PASSTHRU

numfiles 50000

RMTTRAIL ./dirdat/na

TABLE QQQ.*;

TABLE CUI.*;

2.12創建OGG的DDL對象

$ cd /u01/gg 

$ sqlplus "/ as sysdba"

 

SQL> @marker_setup.sql

Enter GoldenGate schema name:ogg

alter system set recyclebin=off;

SQL> @ddl_setup.sql

Enter GoldenGate schema name: ogg

 

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:

 

SQL>GRANT GGS_GGSUSER_ROLE TO

 

where 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 數據初始化

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

生產端開啓抽取進程；

生產端導出數據；

容災端導入數據；

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

//建立進程 EXTN

GGSCI>add extract extn,tranlog,begin now

GGSCI>add exttrail ./dirdat/na,extract extn,megabytes 500

 

//建立進程 DPEN

GGSCI>add extract dpen,exttrailsource ./dirdat/na

GGSCI>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=4096m

 

expdp ogg/ogg schemas='CUI' directory=DATA_PUMP dumpfile=CUI_bak_%U flashback_scn=123456789 logfile=expdp_ CUI.log filesize=4096m

 

expdp 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.log

 

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

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

PORT 7839

DYNAMICPORTLIST 7840-7860

--AUTOSTART ER *

--AUTORESTART EXTRACT *,RETRIES 5,WAITMINUTES 3

PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 2

userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY default

2.15編輯GLOBALS參數文件

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

cd /u01/gg

./ggsci

ggsci>EDIT PARAMS ./GLOBALS

在文件中添加如下內容：

GGSCHEMA ogg  --指定的進行DDL複製的數據庫用戶

2.16 容災端複製進程REPN參數配置

REPLICAT repn

setenv (NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252)

userid ogg, password AACAAAAAAAAAAADAHBLDCCIIOIRFNEPB, ENCRYPTKEY default

SQLEXEC "ALTER SESSION SET CONSTRAINTS=DEFERRED"

REPORT AT 01:59

REPORTCOUNT EVERY 30 MINUTES, RATE

REPERROR DEFAULT, ABEND

assumetargetdefs

DISCARDFILE ./dirrpt/repna.dsc, APPEND, MEGABYTES 1024

DISCARDROLLOVER AT 02:30

ALLOWNOOPUPDATES

REPERROR (1403, discard)

 

DDL INCLUDE MAPPED 

DDLOPTIONS REPORT

 

MAPEXCLUDE QQQ.T0417

 

MAP QQQ.*, TARGET QQQ.*;

MAP CUI.*, TARGET CUI.*;

2.17建立複製進程repn

    執行如下命令建立複製進程repn：

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

2.18啓動生產端傳輸進程和容災端複製進程

GGSCI>start dpen

GGSCI>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目錄是否撐滿。

四．Logdump工具使用

 

 

五．Goldengate初級的性能優化

Batchsql

Insert abend

限制內存使用

顆粒度拆分

 

 

6、goldengate版本升級

 

 

7、goldengate雙向複製

 

8、生產庫與容災庫之間的回切

8、異構數據庫之間的數據轉換，數據過濾篩選

 

 

 

 

 

 

 

 

 

 

 

4、常見故障排除

故障（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 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命令查看總體運行狀況。以下圖示：

 

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 <進程名稱> 能夠查看運行報告。如：

 

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

 

若是進程運行時有錯誤，則報告文件中會包括錯誤代碼和詳細的錯誤診斷信息。經過查找錯誤代碼，能夠幫助定位錯誤緣由，解決問題。

 

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處理到哪條日誌序列號。在此序列號以前的歸檔，均可以被安全的清除。以下圖所示：

 

 

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）

---

---

About Me

............................................................................................................................... ● 本文整理自網絡 ● 本文在itpub（http://blog.itpub.net/26736162）、博客園（http://www.cnblogs.com/lhrbest）和我的微信公衆號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文博客園地址：http://www.cnblogs.com/lhrbest ● 本文pdf版及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 數據庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● QQ羣：230161599     微信羣：私聊 ● 聯繫我請加QQ好友(646634621)，註明添加原因 ● 於 2017-07-01 09:00 ~ 2017-07-31 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網絡，如有侵權或不當之處還請諒解 ● 版權全部，歡迎分享本文，轉載請保留出處 ............................................................................................................................... 拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公衆號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ羣，學習最實用的數據庫技術。