OGG goldengate 日常維護

shilei1發表於2014-05-17
OGG日常維護


配置定時刪除過期佇列

用於自動刪除過期佇列,節省硬碟空間
建議配置在Mgr程式中,可集中管理所有佇列
在mgr引數中加入以下行
purgeoldextracts //dirdat/*, usecheckpoint, minkeepdays 7
其中,第一個引數為佇列位置,*可匹配備份中心所有佇列檔案;
第二個參數列示是首先要保證滿足檢查點需要,不能刪除未處理佇列;
第三個參數列示最小保留多少天,後面的數字為天數。例如,如果希望只保留佇列/ggs/dirdat/xm檔案3天,可以配置如下:
purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3


說明
Mgr程式引數需重啟Mgr程式後生效
臨時停止mgr程式並不影響資料複製。


配置自動定時重啟程式

用於自動恢復由於網路臨時中斷、資料庫或系統維護等原因造成的程式終止,降低人工工作量
建議在Mgr程式配置
在mgr引數檔案加入以下行
AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
以上參數列示每5分鐘嘗試重新啟動所有程式,共嘗試三次。以後每60分鐘清零,再按照每5分鐘嘗試一次共試3次。


說明
需重啟Mgr程式使引數生效
可查詢ggserr.log檔案檢視重啟嘗試資訊



長交易的管理


停止Extract之前需驗證檢查點和長交易,以防止下次啟動無法找到歸檔日誌:
                ggsci> info extXX, showch
檢視長交易
        例如,檢視extsz程式中節點1上最長的10個交易,可以透過下列命令:
        Ggsci> send extract extsz , showtrans thread 1  count 10
強制跳過或接受長交易
        Ggsci> SEND EXTRACT , SKIPTRANS <5.17.27634> THREAD <2> //跳過交易
        Ggsci>SEND EXTRACT , FORCETRANS <5.17.27634> THREAD <1> //強制認為該交易已經提交
說明:使用這些命令只會讓GoldenGate程式跳過或者認為該交易已經提交,但並不改變資料庫中的交易,他們依舊存在於資料庫中。因此,強烈建議使用資料庫中提交或者回滾交易而不是使用GoldenGate處理。



配置長交易告警
可以在extract程式中配置長交易告警,引數如下所示:
                warnlongtrans 12h, checkintervals 10m
以上表示GoldenGate會每隔10分鐘檢查一下長交易,如果有超過12個小時的長交易,GoldenGate會在根目錄下的ggserr.log裡面加入一條告警資訊。透過察看ggserr.log或者在ggsci中執行view ggsevt命令檢視這些告警資訊,可以配置Director或自定義指令碼傳送告警郵件。


修改檢查點 - Extract

修改主Extract的讀檢查點
修改全部檢查點
Alter extract begin [now]|[yyyy-mm-dd hh:mm:ss]
修改單個檢查點
Startup檢查點無需修改
Current Checkpoint的修改
ALTER EXTRACT myext [, THREAD 2], EXTSEQNO 1126, EXTRBA 0
RAC環境下讀取日誌的Extract必須針對每一個節點單獨指定thread號和日誌序列號/位元組進行修改
Recovery Checkpoint的修改 (內部命令)
ALTER EXTRACT myext [, THREAD 2], IOEXTSEQNO IOEXTRBA
同Current Checkpoint,對RAC各節點均需單獨修改
舉例:如果重啟時確認長事務無需複製,可以將Recovery設定為Current Checkpoint相同或之前的特定位置,跳過某些歸檔日誌



修改主Extract的寫檢查點
不能強制指定Extract寫檢查點的extseno和extrba
只能透過重啟或者ALTER EXTRACT myext, ETROLLOVER讓Extract滾動到下一個佇列,由於該命令不會寫佇列檔案頭尾資訊需手工修改後繼程式檢查點以保證其順利讀到下一個佇列。
注:如果是舊版本,只能透過ETROLLOVER滾動
修改Data Pump的讀檢查點
不能透過begin now或指定時間點修改Data Pump讀檢查點!
只能修改Data Pump讀取的佇列序列號和位元組
ALTER EXTRACT mydp, EXTSEQNO 26, EXTRBA 0

注:如果想要設定為從某個時間點開始,只能手工透過logdump查詢佇列中時間點附近的記錄並指定從該記錄位置開始


修改Data Pump的寫檢查點
同修改主Extract的寫檢查點,只能透過etrollover向下滾動一個佇列
修改Replicat讀檢查點
同修改Data Pump的讀檢查點,只能透過指定佇列序列號和RBA
修改Replicat寫檢查點
N/A,Replicat只使用一個檢查點



增加複製表的步驟

停止Extract/Data Pump/Replicat程式
注意停止Extract時檢查長交易和歸檔日誌
在源和目標建立複製表
在源端為該表新增附加日誌
修改Extract/Data Pump/Replicat引數中複製範圍包含該表
重啟Extract/Data Pump/Replicat程式
可以開始對新增表進行操作

注意:以上操作僅限於DML複製。如配置了DDL複製則可以自動生成附加日誌和在目標端建立表結構。




場景分析 – 新增複製表忘記附加日誌

場景描述
在新增複製表時,忘記了新增新增表附加日誌
場景分析
Insert操作可以正常複製,不受附加日誌影響
Update/Delete因為沒有主鍵列資訊記入日誌,目標端無法生成對應SQL
處理方法
源庫對該表新增附加日誌
重新對該表進行初始化(見後面)

Q:可否修改時間點或使用當前佇列進行恢復?


停止Extract/Data Pump/Replicat程式
注意停止Extract時檢查長交易和歸檔日誌
修改Extract/Data Pump/Replicat引數中複製範圍排除該表
如使用萬用字元時,Extract/Data Pump可透過tableexclude排除表
tableexclude ctais2.KJ_*;
tableexclude ctais2.DJ_YZCWSBQC;
table ctais2.*;
如使用萬用字元時,Replicat可透過mapexclude排除表
MAPEXCLUDE fin.TEST
MAP fin.*, TARGET fin.*;
重啟Extract/Data Pump/Replicat程式
說明:在一個複製鏈路的任何一個環節去掉該表即可排除該表複製,但建議在主Extract進行排除,可以避免各程式做不必要的工作;同時,在各個程式引數均明確去掉該表可以保持前後的邏輯統一性和易讀性



修改複製表結構的步驟


OGG在讀取表結構定義後將其快取在記憶體中,不自動進行重新整理,因此凡涉及表結構變更,例如表中列的增刪改和主鍵(或唯一索引)的變化均需按照下列步驟執行 (Q:普通索引如何?)
操作步驟
檢查無延遲後停止源和目標端各程式(注意檢驗重啟時歸檔日誌可用性)
修改目標表結構;
修改源表結構;
如果表有主鍵(或唯一索引),並且本次修改未修改主鍵,則可以直接啟動源和目標所有程式繼續複製,完成本次修改;否則,如果表無主鍵和唯一索引或者本次修改了主鍵則需重新為該表增加附加日誌
ggsci> dblogin userid goldengate, password XXXXXX
ggsci> delete trandata schema.mytable
ggsci> add  trandata schema.mytable
重新啟動源端和目標端的抓取和複製程式。



如何打資料庫補丁

影響打補丁流程的重點是附加日誌的分析
開發時要求補丁按照DDL和DML進行劃分
對資料庫補丁指令碼進行分析
核心是補丁中是否存在依賴於本次需新增或修改的表附加日誌的操作
新增表資料的Update和Delete
原有表的PK修改(或無PK時UI修改、無PK/UI表任意列修改)以及對這些表的Update和Delete操作
以下不影響附加日誌,無需予以特殊考慮
本次補丁涉及範圍外的所有表的增刪改操作
新增表的Insert操作
臨時表及其任何操作
其它資料庫物件的增刪改操作


對資料庫補丁指令碼進行分析(續)
準備在目標端的指令碼
所有源端的DDL操作
排除掉所有OGG可以複製過來的DML操作
按照邏輯順序對這些指令碼進行排序
打補丁操作步驟
停止Extract/Data Pump/Replicat程式,注意檢查長交易和歸檔日誌
根據補丁修改Extract/Data Pump/Replicat引數中複製範圍
在兩端執行DDL指令碼
在ggsci中修改本次補丁需新增或修改的附加日誌
在源端執行DML指令碼
在目標端執行排除掉可複製操作後的DML指令碼
重啟Extract/Data Pump/Replicat程式,觀察複製直到沒有延遲
如果補丁需要依據邏輯順序分為多個DDL和DML指令碼,則繼續重複以上步驟直到完成所有指令碼


複製表的重新初始化

監控各程式到全部沒有延遲
停止各程式,從源端匯出此部分表並匯入目標端
在Replicat引數中單獨對該部分表加入衝突處理:
MAP dbo.tcust, TARGET dbo.tcust, HANDLECOLLISIONS;
啟動各程式直到沒有延遲,去除該表的handlecollisions引數並重啟Replicat
注意:如該表沒有主鍵或唯一索引,不能使用本方法。只能在一個空閒時段或者鎖定該表進行重新初始化。

Q:為什麼不像安裝實施時那樣,等待所有交易最早開始時間小於程式停止時間後再做重新初始化?



日常維護中如果遇到計劃內停機時,例如硬體、作業系統、資料庫等維護需要進行,應當
首先手工停止OGG所有複製程式和MGR程式
執行對應的維護操作
等待資料庫恢復後,重新啟動OGG的MGR程式和其它複製程式
避免程式出現異常退出
程式異常退出可能會帶來未知的風險,如資料丟失、資料重複或OGG檔案異常等
某些特定條件的異常退出程式來不及寫入錯誤資訊,給問題排除帶來一定困難
GGSERR檔案會寫入錯誤資訊引起報警
如果MGR程式出現問題,則無法自動重啟其它程式

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/196700/viewspace-1163233/,如需轉載,請註明出處,否則將追究法律責任。

相關文章