Oracle GoldenGate(OGG)診斷

pxbibm發表於2015-05-12

這篇文件簡要地列出了在使用 Oracle GoldenGate(OGG)時常見的問題以及診斷的步驟和工具。它描述了查詢 OGG 組*失敗原因的關鍵檔案。理解 OGG 怎樣捕獲和傳輸資料有助於理解為何會發生問題以及如何避免這些問題。正確的安裝和配置 OGG,再結合日誌可以極大地幫助問題解決。

注:
*組 - 是抽取或複製的官方術語。 從現在開始,我們使用這個術語來描述抽取或複製。

常見 OGG 問題

下面列出的是使用 OGG 時可能發生的典型問題。請參考後面的文件部分獲取這些問題的擴充套件及詳細資訊。

  • 資料庫報錯及資料庫問題
  • 非資料庫報錯
  • OGG 組掛起
  • 效能問題
  • OGG 組突然異常結束
  • 硬體故障(磁碟、伺服器)及損壞

研究問題

下面列出的檔案和資訊將幫助研究 OGG 問題。建議熟悉這些檔案和它們的位置。官方文件中的參考手冊上描述了怎樣定位和解釋它們。例如,報告文件幾乎總是需要的,且其內容大部分是自解釋的。

  • 報告文件 - 對 99% 的 OGG 問題都有用;因為在這裡報錯和警告大多是自解釋的,我們應該經常檢視這個檔案。
  • OGG 錯誤日誌,ggserr.log,報錯彙總,ggsci 命令日誌,事件(例如程式停止和啟動)的時間戳。
  • 使用 logdump 的跟蹤檔案 - OGG 抽取程式所捕獲記錄的詳細分析。
  • Discard 檔案,跟蹤問題記錄的文字顯示。
  • 資料庫警告日誌 - 對除了資料查詢錯誤(如 ORA-1403、ORA-0001)之外的資料庫相關問題有用。
  • 系統警告日誌 - 對於效能問題、資源問題有用。
  • 資料庫效能工具,健康檢查,AWR 報告。

診斷工具和設定

下面的列表提供了診斷/解決問題的工具。請您熟悉這些工具。許多診斷工具如 Logdump 通常是隻讀的,所以可以放心安裝到一個生產環境中。

  • 設定報告引數和正確的選項,例如 DDL REPORT,使用 REPORT,REPORTCOUNT 引數, 避免使用 REPORTROLLOVER。
  • LOGDUMP
  • 資料庫工具 - logminer,資料庫健康檢查報告,10046 會話跟蹤。
  • Pstack

診斷一個 OGG 問題的第一步

當一個問題發生時,第一步是找到最佳描述這個問題的檔案/資訊。例如,一個 OGG 組的異常結束(異常終止)總是會在報告檔案中記錄下來,其中可能包括多個警告和報錯。 分類這些錯誤將幫助進一步獲取相關資料。例如

  • 報錯是什麼?
  • 是哪個組?
  • 報錯資訊顯示在哪裡?
  • 哪個檔案提供了這個錯誤的詳細資訊,例如報告檔案?
  • 這個報錯是哪種型別?
  • 這個報錯是否被報錯資訊手冊或知識庫文件收錄?

常見 OGG 問題

資料庫報錯和資料庫問題

  • 報告檔案中的資料庫報錯,以及導致 OGG 異常終止的報錯之前的任何警告資訊。通常這是它失敗的準確原因,例如 ORA-01403(No data found)。
  • 與查詢相關的資料庫報錯(ORA-1403,ORA-0001)通常意味著目標表不同步和/或約束有差異(主鍵、外來鍵等),通常不可能去跟蹤為什麼會發生這種情況,因為它們在很久以前就已經發生了。重新同步和監控此表可作為一個潛在的解決方案。
  • 目標資料庫被除了 OGG 以外的操作更新嗎?搜尋早期的 trail 檔案,找到可能丟失的 DML 操作,判斷為什麼它們沒有被應用?
  • 非查詢相關錯誤,例如歸檔日誌找不到、許可權問題、替代位置不正確。 一個建議,嘗試剪下和貼上實際位置,並在 OS shell 中列出它們。
  • 報告檔案通常包含被 OGG 元件執行的實際 SQL。在 SQLPlus 下手工執行這個 SQL。
  • 常見覆制問題:ERROR OGG-01296 Error mapping from SCHEMA1.TABLE1 to SCHEMA1.TABLE1. 引起這個報錯的潛在原因有錯誤的大小、錯誤的列對映、不被接受的字元、錯誤的資料型別、字符集不相容等。
非資料庫報錯
  • 在知識庫文件中查詢顯示在報告檔案中的報錯資訊。
  • 例如檢查點檔案報錯、報告檔案無法寫入、常見的許可權問題等。
OGG 組 hang 住
  • 判斷它確實是在 hanging,而不是慢。OGG 組 hang 的證據有:多個 SEND 命令超時,trail 檔案不增長等。
  • 通常由表鎖或等待一些資源所引起(下游的抽取在等待歸檔日誌)。
  • 您可以使用如下命令 kill 掉 ogg 組 
    ggsci > kill 
    或在 OS 命令列使用 
    kill -9 
    殺程式並嘗試重啟。這會清除掉鎖之類的資源。
  • 在 KILL 並且重啟之後加入 TRACE 和 TRACE2 引數。檢查這些 trace 檔案中記錄的最後執行的活動。
效能問題
  • 在 OGG 組出現延遲前是否有大型批處理任務執行過?
  • 是否一個組做了太多工作?
  • 是否有資源問題,記憶體、磁碟效能等?
  • 如果複製遇到大的延遲,是這個複製本身還是 trails 檔案產生得不夠快。
  • 使用像 REPORTCOUNT 這樣的引數來記錄效能指標。
  • 是否使用了佔用資源的引數,如 FETCH,inserting many tokens,大量過濾器,轉換函式,SQLEXEC 呼叫?
  • 是否 Extract 啟動緩慢?
  • 整合的抽取和整合的複製需要資料庫效能分析。
OGG 組異常終止
  • 在 OS 命令列中執行組,例如
    ./extract paramfile dirprm/myext.prm 
    最後一行會顯示為什麼 OS 終止了這個程式。
  • 請參考 
    Document 1458985.1 Oracle GoldenGate - How To Use GDB To Generate Stack Trace For Troubleshooting Purpose 
    來收集 dmp 檔案。
硬體錯誤(磁碟,伺服器)及損壞
  • 當伺服器或磁碟等物理元件失敗時,OGG 資料檔案(dir*目錄)或 OGG trails 檔案可能出現損壞,導致 OGG 組無法啟動。在這樣的情況下,更多地是去恢復而非診斷。此方面有大量的知識庫文件,可以透過查詢 GoldenGate corruption 來找到它們。

提交格式良好的 SRs

向 Oracle 提出服務請求時,提供準確而確鑿的資訊將大大加快分析和解決的過程。 有時,在收集相關資訊時,您將對這個問題有更多瞭解,並在 My Oracle Support 已有知識文件的輔助下能夠自行解決這個問題。正如前面提到的,報告檔案是非常重要的,所以總是應該在SR中提供它。下面列出的資訊/文件在開一個 SR 時通常是一個好的起點。

  • 準確的基本資訊,OGG 版本,資料庫/平臺/OS 版本。
  • 精確而簡短的摘要,例如:抽取因 "Error..."而異常終止。
  • 總是附上報告檔案和引數檔案。
  • 導致這個報錯的事件,例如:伺服器當掉/修改引數以增加新的表等。
  • 最近做了什麼可能相關的修改。

參考

知道去哪裡找到資訊對診斷來說至關重要。下面的參考文件是配置和維護一個 OGG 例項的起點。

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

相關文章