記錄一次宕機後，OGG出現故障，OGG-01705的解決方法

背景說明：

2021年4月14日，晚上20點07分，數據庫一個節點因爲故障致使出現宕機狀況。宕機緣由，根據黑屏顯示，大概是kernel的問題，這個不作深刻研究，重啓後，數據庫啓動正常。

啓動ogg進程的時候，因爲源端包含ext抽取進程，dump傳輸進程。逐一將其進行重啓。ext抽取進程啓動後正常傳輸。dmp進程abended,發現啓動不了。我對其進行了分析，發現該問題仍是第一次遇到。

經過查看報錯日誌，view report dmpxxxx。 因爲不能拍圖，還有內網緣由，我就從網上找了這個告警。

ERROR OGG-01705 Input checkpoint position 160374765 for input trail file '/odc/xxxx/s027505' is greater than the size of the file (160301092).Please consult Oracle Knowledge Management Doc ID 1138409.1. for instructions.

處理方法：

1. 首先經過metalink查看報錯的 ID號，有了metalink 真好，涉及到Oracle方面的真是不愁找不到案例。

經過metalink查看，說的是ogg首先是經過cache裏面的數據，傳輸到目標端，而後再寫到trail文件中。看metalink，須要強大到英文理解能力。我繼續百度，看看其餘的案例。果真有不少這樣的案例。

如下是案例的地址：

http://blog.itpub.net/29302187/viewspace-2128573

而在goldengate中，datapump和extract在交換數據的時候data pump是從cache區域中去抓取數據傳送到目標端(而不是等到真的寫到磁盤後，能夠提升性能)。當意外down機時系統來不及將cache中的內容寫到磁盤，出現了datapump新建的檢查點是基於cache中的信息更新的，而trail文件的大小其實是要比檢查點寫的RBA小。當下次啓動時，前一個進程進行恢復動做，並將比文件大的一部份內容寫到了下一個trail文件中(extract啓動的時候會etrollover)。因此，要麼將進程的檢查點跳到下一個trail的指定RBA，要麼從新初始化。

從這篇文章中能夠看到，講了不少，主要的意思是如何計算rba，而後肯定後如何解決。

經過查看，發現仍是有點複雜。

2. 咱們以前遇到過不少次trail損壞的問題。並且對其也通過總結。 經驗總結仍是頗有必要的。

操做大概步驟：

按照咱們的方法來作。

分析：  因爲源端抽取是全量抽取，到了目標端是經過拆分來實現並行的，所以須要肯定目標端的scn號。咱們看dirdat目錄下的trail，發現有不少1.5k 的文件，說明傳輸的文件都沒有數據。那咱們就找到一個不是1.5k的看着正常的trail文件的最後一個（也就是出問題之後）。

首先查看目標端的info repxxx信息，

./ggsci

info repxxx*    --->能夠查看到seqno ,還有rba. 咱們此次能夠看到seqno,rba都一致了，也就是都應用了。

info repxxx1,detail   -->能夠查詢到 ogg_checkpoint表。

查詢下select max(xx傳輸過來的scn列), max(實際應用的scn列) from odc.ogg_checkpoint。 這兩個max裏面的列，我忘了。 經過查詢，這兩個列是一致的。

將數值記錄下來。  若是目標端有斷裂，這個最大值可能不一致。咱們選擇的時候選擇這裏面全部不一致的最大值裏面的最小值。以前咱們遇到過，目標端trail文件都損壞的狀況。

目標端操做：

經過logdump進行搜索scn。進行覈驗，是否checkpoint查詢出的scn是否一致，搜索步驟

Logdump 1 >open ./dirdat/r027506     ----->這個是目標端最後一個正常的trail

Current LogTrail is ./dirdat/r027506

Logdump  2 >ghdr on                     ------->查看header record信息

Logdump 4 >detail on   ---查看列信息，包括number和長度

Logdump 5 >GGSTOKEN ON  ------->OGG⽣成的tokens包括有事務ID(XID), DML操做的rowid，其它⼀些輔助信息。

Logdump 6 >pos 59193235    ------>是經過info查詢到的信息。

Logdump 7 >n               ---->若是往下翻查詢不到了，那就往上翻

Logdump 8 >pos 59193235 reverse   -->  reverse 這個是往上查詢的。能夠實際help下。大概就是這樣的。

Logdump 8 >n   翻了幾頁，就會發現有scn。 通過對比跟ogg_checkpoint查詢出來的一致。

源端操做：

咱們拿着這個scn去源端進行查看。

源端查看dirdat的文件，發現已經生成了不少trail文件了。其中20.07分的文件，貌似不全。由於每一個正常trail文件都是固定大小99M ？（記不清楚多大了）

經過info dmpxxx能夠查看到seqno，rba。

seqno對應的就是這個有問題的trail，咱們查看seqno號碼是假定是 sp556642吧。如今經過logdump查看下一個sp556643的開始的scn

cd /odc

./logdump

open ./dirdat/sp556643

ghdr on                     ------->查看header record信息

detail on   ---查看列信息，包括number和長度

GGSTOKEN ON  ------->OGG⽣成的tokens包括有事務ID(XID), DML操做的rowid，其它⼀些輔助信息

n   -->往下查找

n    -->往下查找可能不少次。

能夠查看到第一個scn  這個scn值是m吧。而目標端的是n。

發現m<n。那就說明556643這個文件數據再n以前，也就是數據沒丟。

咱們就執行下

alter extract dmpxxx ,extseqno 556643,extrba 0 

這樣就能讓dmp端從556643 這個文件開始向下掃描，而且數據不會丟。執行正常後，查看目標端的進程，都是running，而且有數據寫入，rba，seqno都在變。查看目標端的文件，都跳過了1.5k的文件。