Ref:
http://www.linfengyushu.com/ogg%E6%B3%A8%E6%84%8F.html/
OGG注意事項
1.針對ASM環境，源端抽取進程參數必須增加如下資訊：
userid ggs@10gasm,password ggs
TRANLOGOPTIONS ASMUSER sys@+ASM, ASMPASSWORD oracle —必須添加這行信
2.setenv (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
這裡的AMERICAN_AMERICA.ZHS16GBK是需要替換為實際資料庫的字
符集設置
3.RMTHOST *.*.*.*, MGRPORT 7839, compress
這裡compress一定要配置，加快傳送速率，減少datapump的延遲
4.如果是後來修改稱data pump，就需要根據extract 進程的錯誤提示資訊，使用如下命令：
GGSCI (gg1) 82> alter extract dpump,extseqno 2,extrba 1965317
修改data pump 讀取的trail 檔位置。
5. 在實際中配置GG Data pump 主要是為了應對網路故障問題，如果我們直接將trail 通過網路傳送到Target 端，那麼在這期間，任何網路故障都可能導致Extract process 的異常中斷。
而使用datapump後，即便網路故障，主提取進程仍然能隨著事務生成trail檔，而datapump則會暫時停止傳輸，等待網路通暢後在將堆積的本地trail檔發送至目標伺服器，從而實現了中斷點傳輸的功能。在實際應用中，每一個同步流程都應該配置datapump以應對網路問題。
6.RAC節點時鐘不同步（OGG-01028）
對於 主備用類型的RAC: 即2節點RAC，其中一個空閒備用，另一個接入應用； 可能存在空閒節點的scn 在短時間內 遠遠落後於繁忙節點的情況。
該問題的成因是 ogg 在RAC環境中通過 coordinator thread 來彙集每一個節點上的redo vector 以便scn 有序，
在以下幾種情形中會引發該OGG-01028
encountered commit SCN 0.234946815 (234946815) that is not greater thanthe highest SCN already processed 錯誤：
RAC中 一個thread 的scn明顯滯後於別的thread
redo log 因為寫出延遲導致沒有及時刷新等
如果你的環境是RAC系統 ， 那麼建議
比對 各thread 之間的 scn
比對 各節點的時間
檢查告警日誌
如：
select thread#,LAST_REDO_CHANGE# from v$thread;
THREAD# LAST_REDO_CHANGE#
———- —————–
1 11698506
2 11698595
SQL> alter session set nls_date_format='YYYY-MM-DD hh24:mi:ss';
Session altered.
SQL> select sysdate,dbtimezone from dual;
SYSDATE DBTIME
——————- ——
2011-12-29 22:11:10 +00:00
可以通過配置IOLATENCY and MAXCOMMITPROPAGATIONDELAY 參數減少該問題發生的概率
The key is in adjusting IOLATENCY and MAXCOMMITPROPAGATIONDELAY parameters to an optimum value based on the frequency of hitting the error.
Extract 會在oracle 寫入redo log後 等待一段時間才開始彙集事務。
THREADOPTIONS MAXCOMMITPROPAGATIONDELAY 90000 IOLATENCY 90000
同時配置NTP時鐘同步伺服器
Extract: OGG-01028 Encountered SCN That Is Not Greater Than The Highest SCN Already Processed„
原因分析：在Oracle RAC環境中，Extract會啟動一個coordinator執行緒對各個節點上的操作進行根據SCN進行排序，它在交易提交後會等待THREADOPTIONS MAXCOMMITPROPAGATIONDELAY參數所定義時間來確認空閒節點沒有交易，然後再
收集交易資料；寫入該交易後如果空閒節點後來又讀到了一個SCN號要小的交易，則會報告該錯誤。
可能原因：
各節點之間沒有配置時鐘同步。 一個節點比另外一個節點慢（IO問題可能性較大）。 解決辦法：
調整Extract參數： 示例9-5：
THREADOPTIONS MAXCOMMITPROPAGATIONDELAY IOLATENCY
MAXCOMMITPROPAGATIONDELAY有效範圍是0-90000ms，默認為3s（即3000ms）。 GGS V9.x多了一個IOLATENCY參數，可以與上面參數一起加大等待時間。IOLATENCY默認為1.5s，最大值為180000。
建議出現該錯誤後可以將此二參數設置為較大值，然後逐步降低獲取最佳設置。
需要補充說明的是，出現此錯誤後，因後面的交易可能已被寫入日誌，重啟Extract可成功啟動，但是可能出現如下問題：Extract會重寫當前佇列覆蓋前面的交易資料，後面的Data Pump進程可能會出現"abend with incompatible record errors"錯誤終止（舊版本可能出現）。
此問題的恢復步驟如下。
① 停止所有Data Pump和Replicat，針對所有的Extract記錄其Write Checkpoint的佇列Seqno。
② 對於每個Extract向下滾動一個佇列： 示例9-6：
ALTER EXTRACT [name], ETROLLOVER
啟動Extract查看是否滾動到了下一個佇列，記錄其新佇列seqno，應當是舊佇列號+1。 ③ 修改Data Pump從新的佇列開始傳輸： 示例9-7：
ALTER EXTRACT [pump_name], EXTSEQNO ##### EXTRBA 0
重啟Data Pump查看是否能夠重啟成功並從新的佇列傳輸。
④ 修改Replicat參數檔，加入或者打開HANDLECOLLISIONS，如果有GROUPTRANSOPS和MAXTRANSOPS請注釋掉，啟動Replicat，觀察其是否能夠讀取新傳輸過來的佇列如Replicat無法自動滾動到下一個佇列，需要通過如下命令手工滾動：
示例9-8：
alter replicat [replicat_name], EXTSEQNO ##### EXTRBA 0
等待Replicat處理到結尾沒有延遲時，可以關閉HANDLECOLLISIONS和恢復原來的
128 GROUPTRANSOPS和MAXTRANSOPS參數。
⑤ 重新啟動Replicat即可恢復正常複製。
Recommendation:-
The MAXCOMMITPROPAGATIONDELAY parameter can be used to set the delay time well above the max_commit_propogation_delay setting in the database, plus the default extra padding that Extract adds (2000 milliseconds).
In Oracle RAC, the max_commit_propogation_delay specifies the maximum amount of time allowed before the system change number (SCN) held in the SGA of an instance is refreshed by the log writer process (LGWR). Units are in hundredths of seconds.
To check Oracle's value:
Connect as a user with dba privileges and issue:
SQL> show parameter max_commit NAME TYPE VALUE
———————————— ———– —————————— max_commit_propagation_delay integer 0
To set MAXCOMMITPROPAGATIONDELAY : The value of MAXCOMMITPROPAGATIONDELAY must be greater than zero and less than 90000 milliseconds.
This is how the line should look in the Extract parameter file:
THREADOPTIONS MAXCOMMITPROPAGATIONDELAY 2700
Starting from GGS Version 9.x and above, an additional parameter IOLATENCY can be used if Extract abends with 'encountered SCN XXXXX' too often. IOLATENCY adjusts the delta between the database-configured max commit propogation delay and the internal value that Extract uses. By default IOLATENCY is set to 1.5 seconds
Note: Valid values for IOLATENCY are between 0 and 180000 milliseconds (3 minutes).
The combined parameters should look like this:
THREADOPTIONS MAXCOMMITPROPAGATIONDELAY IOLATENCY
The combination of MAXCOMMITPROPAGATIONDELAY and IOLATENCY can be used to ensure that:
1) the Oracle threads have written their most recent SCN data to the logs
2) the I/O processes have had time to complete, considering the various factors that increase I/O latency, such as hardware contention, file locking, long seek and queue times, etc.
The key is in adjusting IOLATENCY and MAXCOMMITPROPAGATIONDELAY parameters to an optimum value based on the frequency of hitting the error.
Hint: If the problem happens too often, you can start with high values for IOLATENCY and MAXCOMMITPROPAGATIONDELAY parameters. Once the error stops happening, you can gradually decrease the values to see the SCN number where this error starts appearing again. This would give you an idea of the boundary values specific to that environment.
Furthermore, the reason Extract successfully restarts after this error is that, on restart, it re-reads the operations, and this time they are all on disk and can be processed in correct SCN order. The side effect is that Extract rewrites operations into the trail. This may cause the data pump or Replicat to abend with incompatible record errors.
7.RAC環境下HA的OGG注意了
Parameter Required for Active-Active DML
Active-Active DML replication is fairly straight forward with OGG. The extract just needs to be aware
of the replicat database user in order exclude that activity.
To exclude replicat activity add this parameter to the extract:
TRANLOGOPTIONS EXCLUDEUSER
8.Extract: Block size mismatch (8192/512)„
裸設備的偏移量各作業系統預設為0，但AIX默認為4096。當創建裸設備時使用了-TO選項時，Oracle不會跳過4096位元組而是直接從0開始讀寫。 因此在AIX下使用裸設備時，出現此錯誤需要指定OGG從偏移量0開始讀取。
示例9-3： tranlogoptions rawdeviceoffset 0
9.佇列檔不自動刪除
實施時多次執行
ADD EXTTRAIL
ADD RMTTRAIL
gg goldengate 佇列檔不自動清除
首先確認manager參數檔mgr.prm中是否添加了定期清除參數：
PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3
修改之後，必須重啟manager即可看到佇列檔佔用的空間被按照上面指定的規則釋放。
如果還是沒有刪除，通過：GGSCI>INFO XXX, SHOWCH，查看是否存在多個Write Checkpoint，一個為相對路徑，一個為絕對路徑
原因如下：
源端：
在增加extract和datapump時，在GGSCI命令列指定的路徑和參數檔中的不一致，如果在命令行使用絕對路徑，在參數檔中必須使用絕對路徑。如果使用了相對路徑，則統一採用相對路徑。
目標端：
在GGSCI增加datapump時，RMTTRAIL如果使用了相對路徑，在增加replicat時必須使用相對路徑。
處理方法：
GGSCI>INFO XXX, SHOWCH /*showch命令可以查看到詳細的關於checkpoint的資訊，用於查看goldengate進程處理過的事務記錄。其中比較重要的是extract進程的recovery checkpoint，它表示來源資料庫中最早的未被處理的事務；通過recovery checkpoint可以查看到該事務的redo log位於哪個日誌檔以及該日誌檔的序號。所有序號比它大的日誌檔，均需要保留。*/
GGSCI>INFO XXX
記錄相關資訊，刪除不正確路徑的exttrail
通過alter命令設置為上面INFO資訊記錄的檢查點
GGSCI>alter xxx extseqno INFO看到的序號, extrba INFO看到的RBA號碼, [thread n]
GGSCI>start xxx
10.容災端入庫性能優化
將大表單獨拆分為獨立的進程，增加參數：
BATCHSQL
MAXTRANSOPS 10000
11.配置資料庫
完整性約束
禁用target表的trigger和級聯約束
Dboptions suppresstriggers：支持10205和11R2(11.2.0.2以後)，會話期間replicat不禁用trigger，但會阻止trigger執行；其他版本則須禁用完整性和觸發器約束；
12.APPEND方式RAC環境下實例異常引起資料丟失
GoldenGate從10.0版本開始更新了自己的佇列方式，從overwrite方式改成了append方式，但是運行在append方式下，GoldenGate的抽取進程可能會少抽取部分資料。
這是最近遇到一個挺奇怪的問題，發現GoldenGate的extract進程在RAC環境下運行的時候，在特殊的情況下會發生丟失資料的問題，這是個非常棘手的問題。
以下是故障發生時候和extract進程重新開機的時候，ggser.log檔中的記錄資訊：
2010-04-14 14:39:09 GGS ERROR 146 GoldenGate Capture for Oracle, extcdz2.prm: encountered commit SCN 628.2698994951 (2699938456839) that is not greater than the highest SCN already processed 628.2698995191 (2699938457079) Redo Thread 2 (2) xid 60.37.41 (0x003C.0025.00000029), starting seq.rba 659.313107528, scn 628.2698994950 (2699938456838), commit seq.rba 659.313108108 commit timestamp 2010-04-14 14:38:45.000000.
*注意紅色標注的部分。
經過兩天的分析和研究，基本可以確定GoldenGate佇列工作在append方式下，在發生這樣情況的時候，會引起extract抽取時間點的跳躍，少抽取部分資料。
以下是針對這種情況的分析思路和過程：
針對這個故障,首先建立一個測試extract進程,觀察從2010-4-14 14:00開始的資料能否被抽取到佇列中。通過測試發現，資料可以被抽取出來，這就排除了資料沒有採用特殊的資料處理方法。
我們現在分析的重點就是ext進程在重新開機的時候為什麼會少抽取資料？
首先分析源端的GoldenGate的ggserr.log檔中的error資訊，從錯誤資訊上可以看出在14：39：09的時候，GoldenGate發生了故障，而引起故障的原因是由於extract進程抽取到scn是2699938456839的交易的時候發現佇列中已經存在scn是2699938457079的交易了，佇列中存在的事務的scn大於將要寫入的交易的scn，這違反了GoldenGate的checkpoint驗證機制，extract進程自動停止了。
結合以上對ggserr日誌的分析，我們嘗試還原發生故障時候的場景。當exract進程發生故障停止的時候，它記下了最後的讀checkpoint點，這個檢查點到底是哪個scn呢，根據發生故障時候的ggserr日誌資訊，只可能有兩個scn，一個是2699938456839，一個是2699938457080。
假設一：checkpoint點是2699938456839
我們現在重新開機extract進程，extract進程首先進行初始化，它結束當前的佇列，重新打開一個新佇列，在新佇列中標記恢復標誌，extract初始化結束。Extract進程重新從2699938456839這個checkpoint點開始進行新資料的抽取,那麼新打開的佇列中的第一個事務應該是scan是2699938456839的交易。如果是這樣的話新佇列中會存在一條scn是2699938457079的重復資料。
假設二：checkpoint點是2699938457079
我們現在重新開機extract進程，extract進程首先進行初始化，它結束當前的佇列，重新打開一個新佇列，在新佇列中標記恢復標誌，extract初始化結束。Extract進程從2699938457080這個checkpoint點開始進行新資料的抽取,那麼新打開的佇列中的第一個事務應該是scan是2699938457080的交易。如果是這樣的話scn從2699938456839到2699938457078的交易沒有被extract進程捕獲出來，這應該就是extract進程少抽取資料的原因。根據這兩個假設我們來看一下實際的情況到底是什麼。
我們建立的測試佇列中是附加抽取了scn的。我們用logdump打開測試佇列e1，看看2699938457079對應的是什麼資料。以下是logdump摘錄的資訊：
2010/04/14 14:39: 03.000.000 FieldComp Len 148 RBA 15368978
Name: ORIUSR.T_ORI_APL
User tokens: 21 bytes
746b 2d73 636e 0032 3639 3939 3338 3435 3730 3738 | tk-scn.2699938457078
00 | .
Logdump 462 >n
_________________________________________________________________ 2010/04/14 14:39:03.000.000 FieldComp Len 38 RBA 15369278
Name: ORIUSR.T_ORI_ARCHINFO
After Image: Partition 4 GU s
0000 0006 0000 0002 3536 0001 000a 0000 0006 3130 | ……..56……..10
3030 3635 0002 000a 0000 0006 3338 3032 3030 | 0065……..380200
746b 2d73 636e 0032 3639 3939 3338 3435 3730 3739 | tk-scn.2699938457079
00 | .
Logdump 463 >n
___________________________________________________________________
2010/04/14 14:39:03.000.000 FieldComp Len 34 RBA 15369473
Name: ORIUSR.T_ORI_CHARGE
After Image: Partition 4 GU b
0000 000c 0000 0008 3134 3133 3739 3530 0014 0005 | ……..14137950….
0000 0001 3100 1e00 0500 0000 0132 | ….1……..2
User tokens: 21 bytes
746b 2d73 636e 0032 3639 3939 3338 3435 3730 3830 | tk-scn.2699938457080
通過logdump我們清楚了看到了這幾個scn對應的交易資訊，在ggserr.LOG檔中我們可以找到這樣的日誌資訊2010-04-15 08:34:17 GGS INFO 112 GoldenGate Capture for Oracle, extcdz2.prm: Recovery completed for target file /u01/ggs/dirdat/c2001663, at RBA 1251, CSN 2699938457079.。
我們用logdump打開c2001663佇列看看它裡面記錄的資訊：
2010/04/14 14:39:03.000.000 FieldComp Len 34 RBA 1251
Name: ORIUSR.T_ORI_CHARGE
After Image: Partition 4 G b
0000 000c 0000 0008 3134 3133 3739 3530 0014 0005 | ……..14137950….
0000 0001 3100 1e00 0500 0000 0132 | ….1……..2
通過對比兩個logdump中的資訊後發現：extract進程重新開機後，寫入c2001663佇列的第一個事務的scn是2699938457080。這個和我們第二個假設的情況相同，extract重新開機後第一個抽取的事務是2699938457080，GoldenGate把scn從2699938456839到2699938457078的交易資料忽略了。這顯然是少抽取了資料。
結合ggserr.LOG中的資訊和logdump的分析，我們基本可以得出如下的結論,scn從2699938456839到2699938457078之間的資料沒有被抽取出來。
這應該是append方式的一個缺陷吧。
13.資料庫thread與sid不對應
問題描述：
GGS ERROR 500 抽取進程extu1起不來，提示找不到thread2的歸檔（沒有保留哪天具體的報錯資訊）
問題分析：
rac資料庫曾經刪除又重建一個節點，故thread2對應的實例已經沒有了，更沒有它的歸檔了（之前是將該實例刪除前的歸檔日誌來騙過gg，但是後來這種方式不管用了）
問題處理：
在extu1的參數檔中跳過資料庫thread2的同步：
1).找出資料庫thread2對應gg的thread號
select distinct(thread#) from V$log；
info extract extu1,showch
2).跳過該thread ： THREADOPTIONS PROCESSTHREADS EXCEPT 3
14.表結構或資料不一致
問題描述：
2011-07-08 20:42:12 GGS ERROR 218 Error mapping from user.TMQAPR to user.TMQAPR.
問題分析：
出現該問題一般都是由於同步的源和目標表結構不一致，包括表字段和索引。
除表結構外，資料的不一致也可能導致mapping 錯誤，如原庫要delete或update時，gg庫找不到該條資料等，具體原因見report中的錯誤號：
2011-07-18 09:29:46 GGS WARNING 218 SQL error 1403 mapping ITM.SALES_CARD to ITM.SALES_CARD.
2011-07-18 09:29:46 GGS ERROR 218 Error mapping from ITM.SALES_CARD to ITM.SALES_CARD..
$ oerr ora 1403
01403, 00000, "no data found"
// *Cause:
// *Action:
問題處理：
1).如果是表字段不一致，需要修改表字段，異構資料庫還需要重新生成表結構定義檔，再重啟進程。
2). 如果是索引不一致，需要重建索引，異構資料庫還需要重新生成表結構定義檔，再重啟進程。(之前沒有關注索引是否一樣，以後關注一下索引)
3). 遇到這種情況，不能先去對比兩端的表結構（可能修改表結構的sql在後面執行），而應該先去查明原因。若是資料問題，可以跳過該表的同步，然後重新同步該表
15.discard file寫滿了
問題描述：
REPU1 report中報錯，discard 超出了限制大小（具體的報錯資訊沒記下，如果找到了，再補充）.
問題分析：
因為某些原因，導致gg一直寫discard，超過參數檔中限定的大小，就會報錯。解決了不斷discard的問題，就能解決discard文件寫滿的問題。
問題處理：
1).修改repu1的參數檔，增大discard檔限制：discardfile /goldengate/dirrpt/repu1.dsc,append,megabytes 2000m（可選） 。
2).查看discard文件/goldengate/dirrpt/repu1.dsc ，查看裡面的報錯資訊，undo不足，我是在做大表的delete，增加了undo表空間，再start repu1。
–下面是網上的一些報錯和解決，摘錄如下。其中一些也遇到過，但是因為錯誤提示很清楚，也容易解決，並沒有單獨去總結。
16.用戶不存在
問題描述：
2010-05-02 10:45:20 GGS ERROR 2001 Oracle GoldenGate Delivery for Oracle, rcrmheal.prm: Fatal error executing DDL replication: error [Error code [1918], ORA-01918: user 'KINGSTAR' does not exist, SQL /* GOLDENGATE_DDL_REPLICATION */ alter user kingstar account unlock ], no error handler present.
問題分析：
根據分析日誌可以確定是目標端不存在該使用者導致的故障。
問題處理：
方法1、如果不需要同步該使用者，可以在目標端去掉掉映射該使用者,再重啟進程。
例如去掉：MAP KINGSTAR.*, TARGET CRMKINGSTAR.*;
方法2、在目標端手工創建該使用者,再重啟進程。
17.表不存在
問題描述：
2010-05-10 15:02:12 GGS ERROR 101 Oracle GoldenGate Delivery for Oracle, rcrmheal.prm: Table CRMOLAP.TB_FT_OFSTK_CLIENT_BY_DAY does not exist in target database.
問題分析：
根據分析日誌可以確定是目標端不存在該表導致的故障。
問題處理：
方法1、如果不需要同步該表，可以在目標端排除掉該表,再重啟進程。
例如添加：MAPEXCLUDE OLAP.TB_FT_OFSTK_CLIENT_BY_DAY
方法2、在目標端手工創建該表, 異構資料庫還需要重新生成表結構定義檔，再重啟進程。
18.資料庫索引失效
問題描述
2010-07-05 14:48:32 GGS WARNING 218 Oracle GoldenGate Delivery for Oracle, rapcaxht.prm: SQL error 1502 mapping AXHT.DOCONTRACT to APCAXHT.DOCONTRACT OCI Error ORA-01502: index 'APCAXHT.PK_SID' or partition of such index is in unusable state (status = 1502), SQL .
問題分析：
資料庫索引失效引起的故障。
問題處理：
重建這個有問題的索引，再重啟進程，故障排除。
19.表結構不一致
問題描述：
2010-05-08 14:50:44 GGS ERROR 218 Oracle GoldenGate Delivery for Oracle, rcrmheal.prm: Error mapping from OLAP.TB_FT_OFSTK_BAL_HIS to CRMOLAP.TB_FT_OFSTK_BAL_HIS.
問題分析：
出現該問題一般都是由於同步的源和目標表結構不一致，包括表字段和索引。
問題處理：
1、 如果是表字段不一致，需要修改表字段，異構資料庫還需要重新生成表結構定義檔，再重啟進程。
2、 如果是索引不一致，需要重建索引，異構資料庫還需要重新生成表結構定義檔，再重啟進程。
20.磁碟空間不足
問題描述：
2010-05-07 04:05:31 GGS ERROR 103 Oracle GoldenGate Collector: Unable to write to file "./dirdat/crm/fl003629″ (error 28, No space left on device).
2010-05-07 04:05:31 GGS ERROR 190 PROCESS ABENDING.
問題分析：
根據分析日誌可以確定是磁碟空間不足導致的故障。
問題處理：
劃分足夠的磁碟空間，再重啟進程。
21.TCP/IP故障
問題描述：
2010-06-25 21:06:04 GGS WARNING 150 Oracle GoldenGate Capture for Oracle, BSAIAXEC.prm: TCP/IP error 10060 (由於連接方在一段時間後沒有正確答覆或連接的主機沒有反應，連接嘗試失敗。).
問題分析：
根據分析日誌可以確定是不能連接到遠端主機，包括ip位址或埠號。
問題處理：
需要打通能夠連接到遠端主機IP和埠，再重啟進程。
22.資料庫不能連接
問題描述：
2010-05-20 18:25:13 GGS ERROR 182 Oracle GoldenGate Delivery for Oracle, rtasaxta.prm: OCI Error during OCIServerAttach (status = 12154-ORA-12154: TNS:could not resolve the connect identifier specified).
問題分析：
這種故障是資料庫不能連接導致goldengate進程異常。
問題處理:
需要先解決資料庫異常，再重啟進程。
23.表空間不足
問題描述：
2010-02-01 17:19:18 GGS ERROR 103 Discard file (./dirrpt/rep1.dsc) exceeded max bytes (10000000).
問題分析：
根據錯誤可以看出直接引起GoldenGate進程停止的原因是discard檔被寫滿了，是什麼原因造成discard檔被寫滿的呢？從discard檔中我們看到是發生了ORA-01653: unable to extend 錯誤，看到這裡我相信大家都知道該怎麼處理了吧，我們只要擴展這個aaa.TB_LVY_TEMPINVOIC物件所在的表空間的大小即可。
問題處理：
1、找到相關物件存儲的表空間；
例如：select owner,table_name,tablespace_name from dba_tables
2、執行表空間擴展
例如：ALTER TABLESPACE tbs_03 ADD DATAFILE 'tbs_f04.dbf' SIZE 100K AUTOEXTEND ON NEXT 10K MAXSIZE 100K;
24.網路傳輸問題
問題描述：
2010-06-29 16:22:28 GGS ERROR 112 There is a problem in network communication, a remote file problem, encryption keys for target and source do not match (if using ENCRYPT) or an unknown error. (Remote file used is /oradataA/ggtrail/b1000008, reply received is Unable to lock file "/oradataA/ggtrail/b1000008″ (error 13, Permission denied). Lock currently held by process id (PID) 3674350).
問題分析：
問題處理：
方法1、手工去KILL掉相應的鎖進程，再重新開機進程。
方法2、不需理會，大概2小時後會自動釋放該鎖進程。
方法3、goldengate 10.4.0.76 會解決鎖問題。
25.參數變數配置不正確
問題描述：
Did not recognize parameter argument
問題分析：
進程參數檔配置不正確。
問題處理：
檢查參數設定檔，可能是進程名稱與設定檔不一致或者是參數不正確，重啟進程。
26.捕獲進程不能為表添加補充日誌
問題描述：
2010-07-19 16:20:03 GGS ERROR 2100 Oracle GoldenGate Capture for Oracle, ecrmheal.prm: Could not add TRAN DATA for table, error [ORA-32588: supplemental logging attribute all column exists, SQL ALTER TABLE "AXTECH"."TB_FUND_MATCHING" ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS /* GOLDENGATE_DDL_REPLICATION */], error code [32588], operation [ALTER TABLE "AXTECH"."TB_FUND_MATCHING" ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS /* GOLDENGATE_DDL_REPLICATION */ (size 113)].
問題分析：
因為表已經開啟了補充日誌（附加日誌），而對表做DDL操作時，參數"DDLOPTIONS ADDTRANDATA"會對表重新開啟補充日誌（附加日子），但如果該表超過32個欄位，並且該表沒有唯一索引時會出現上面的異常；
問題處理：
方法1、去掉參數"DDLOPTIONS ADDTRANDATA"。
方法2、DELETE TRANDATA 用戶.表
方法3、登錄資料庫執行: ALTER TABLE AXHT.BMBM2002 DROP SUPPLEMENTAL LOG DATA (ALL) COLUMNS
27.資料庫補充日誌（附加日誌）沒有打開
問題描述：
2010-10-14 09:25:50 GGS ERROR 190 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: No minimum supplemental logging is enabled. This may cause extract process to handle key update incorrectly if key column is not in first row piece.
2010-10-14 09:25:50 GGS ERROR 190 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: PROCESS ABENDING.
問題分析：
根據分析日誌可以確定是源端oracle補充日誌沒有打開導致的故障，如果主鍵或唯一索引是組合的(複合的),就需要為表配置supplemental log,否則就不必,也就是說,如果所有表的主鍵是單列的,那根本就不必去理會它是什麼意思，如果更新了主鍵中的部分欄位,那supplemental log的作用就是把該記錄其餘的組成部分的資料也傳輸到目的機,否則目的機就存在不確定性。
問題處理：
登錄資料庫，使用命令ALTER DATABASE ADD SUPPLEMENTAL LOG DATA打開補充日誌。然後重新添加捕獲進程和本地佇列。
28.表補充日誌（附加日誌）沒有打開
問題描述：
2010-10-14 09:30:49 GGS WARNING Z1-078 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: No valid default archive log destination directory found for thread 1.
2010-10-14 09:30:50 GGS ERROR 500 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: Found unsupported in-memory undo record in sequence 2, at RBA 39675920, with SCN 0.554993 (554993) … Minimum supplemental logging must be enabled to prevent data loss.
2010-10-14 09:30:51 GGS ERROR 190 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: PROCESS ABENDING.
問題分析：
根據分析日誌可以確定是源端oracle補充日誌沒有打開導致的故障。
問題處理：
登錄資料庫，使用命令ALTER DATABASE ADD SUPPLEMENTAL LOG DATA打開補充日誌。
29.DDL複製表沒找到
問題描述：
2010-10-14 13:32:10 GGS ERROR 2008 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: DDL Replication is enabled but table GGS.GGS_DDL_HIST is not found. Please check DDL installation in the database.
2010-10-14 13:32:10 GGS ERROR 190 Oracle GoldenGate Capture for Oracle, ECRMGGS.prm: PROCESS ABENDING.
問題分析：
根據分析日誌可以確定是DDL複製操作已經打開，但沒有找到安裝複製DDL執行腳本產生的表GGS.GGS_DDL_HIST導致的故障。
問題處理：
因為安裝複製DDL是使用用戶GGDDL，執行腳本後會在該用戶產生跟蹤goldengate運行的表，所以要實現支持DDL操作，在參數檔中登錄資料庫必須使用GGDLL和對應的密碼登錄。例如：USERID GGDDL@CRMDB,PASSWORD GGDDL
30.配置複製的DDL支援(必須SYSDBA登錄執行)
SQL> grant execute on utl_file to ogg;
SQL> @$GGHOME/marker_setup.sql; –建立一個DDL標記表
SQL> @$GGHOME/ddl_setup.sql; –INITIALSETUP選項運行ddl_setup.sql 將在資料庫中創建捕獲DDL語句的Trigger等必要元件(注意，執行時必須斷開GGSCI連接，否則報錯)
SQL> @$GGHOME/role_setup.sql; –建立GGS_GGSUSER_ROLE角色
SQL> grant GGS_GGSUSER_ROLE to ogg; –授予給extract group參數中定義的userid用戶
SQL> @$GGHOME/ddl_enable.sql; –enable ddl擷取觸發程式
注意：下面2個SQL腳本只是為了提高DDL複製性能，不是必須的
SQL> @?/rdbms/admin/dbmspool –創建DBMS_SHARED_POOL包
SQL> @ddl_pin –通過dbms_shared_pool.keep存儲過程將DDLReplication相關的物件keep在共用池中，以保證這些物件不要reload，提升性能
31.在目標端添加checkpoint表
[ogg@zlm gg11]$ ./ggsci
GGSCI (zlm) 1> edit params ./GLOBAL
GGSCHEMA ogg –DDL同步必須指定，DML同步不需要
32.具體測試內容和之前配置的單向複製一樣，步驟略，DML，DDL都順利複製到目標端，和之前一樣，第一次同步的時候會比較慢，之後就快了，可能是第一次同步需要創建檔的緣故。另外，這裡要特別注意，此時因為配置了雙向複製，當兩邊各自的ext1和rep1進程都是running狀態，如果此時源端和目標端對同一個表進行DML操作，如insert一條記錄，那麼這條記錄會不斷地在兩端來回複製，永不停歇，如下所示：
SQL> insert into test values(6);
1 row created.
SQL> select *from test;
ID
———-
1
2
3
4
5
6
6
6
6
6
這條插入id=6的資料就會不斷地插入test表，要解決這個問題，就需要在兩端的任意一個extract進程ext1裡添加一條TRANLOGOPTIONS EXCLUDEUSER ogg就可以了
32.– The following parameter speeds up replicat processing rate. The
– parameter alters the replicat oracle session to not wait for commits — to be persisted to the redo.
SQLEXEC "ALTER SESSION SET COMMIT_WRITE = NOWAIT"
– Use the BATCHSQL parameter to increase the performance of Replicat. — BATCHSQL causes Replicat to organize similar SQL statements into arrays and apply — them at an accelerated rate.
BATCHSQL
33.global file
– Specifies the name of the schema that contains the database objects that support DDL
– synchronization for Oracle
GGSCHEMA
– Specifies a non-default name for the DDL history table that supports DDL
– synchronization for Oracle.
DDLTABLE
– Specifies a non-default name for the DDL marker table that supports DDL
– synchronization for Oracle
MARKERTABLE
34.OGG-00446
啟動源端抽取進程extnd,ggserr.log錯誤顯示如下：
2012-08-1711:11:38 ERROR OGG-00446 Oracle GoldenGate Capture for Oracle, extnd.prm: Could not find archived log for sequence45835 thread 1 under default destinations SQL
2 則留言:
謝謝分享
謝謝分享
張貼留言