日常在進行資料庫維護時經常要停止ogg程式，有時會遇到提示當前有一個長時間執行的事務存在的錯誤，OGG提示可使用 SEND EXTRACT EHXZG001, FORCESTOP命令強制停止程式。然後最後重啟該程式需要讀取的是20939和12852兩個redo日誌。

GGSCI (gdlt2hxzgdb02) 21> stop *
Sending STOP request to EXTRACT EHXZG001 ...
There are open, long-running transactions. Before you stop Extract, make the archives containing data for those transactions available for when Extract restarts. To force Extract to stop, use the SEND EXTRACT EHXZG001, FORCESTOP command.
Oldest redo log files necessary to restart Extract are:
Redo Thread 1, Redo Log Sequence Number 20939, SCN 3340.2050804863 (14347241573503), RBA 47790608
Redo Thread 2, Redo Log Sequence Number 12852, SCN 3340.2057322291 (14347248090931), RBA 4788752.

關鍵點分析：
1.當資料庫中一個事務發起時，OGG的e程式將捕捉該事務，進而掃描相關的redo 日誌或archive 日誌。
2.當資料庫中一個事務較長未提交或回滾時，OGG將事務keep在記憶體中，因此同樣保持該事務而不提交或中斷。
3.當需要停止OGG e程式時，便會提示事務正在執行。

措施：
措施1：使用 SEND EXTRACT EHXZG001, FORCESTOP命令強制停止程式，但是，你必須保證重啟時包含該事務的日誌檔案存在並可用，意思就是說ogg程式重啟時會再次恢復捕捉該事務，當此時發現相應的日誌檔案不存在了，於是OGG便會報錯，一般提示找不到歸檔等，其實強制停止個人建議不在萬不得已情況下還是不要做。CSDN上有一篇文章闡述了過程並做了總結：http://blog.csdn.net/xiangsir/article/details/8806027
措施2：不在OGG層面操作，直接從源端資料庫進行回滾或提交，這樣雖然需要等待一定時間但相對比較保險。

OGG事務處理延伸分析：
1.OGG的抽取程式會實時捕捉事務，但投遞到目標端時，如果該事務未做提交，複製程式是不會將其寫入到目標資料庫中的，這樣避免了不一致性。
2.OGG有個Bounded Recovery機制，會每隔一段時間做一個檢查，如果檢測到長事務，OGG會將時間段內這個未提交或回滾的長事務從記憶體中儲存到磁碟上，往後每隔一段時間同樣做一次檢查。以上這個時間段是可以透過引數自定義的 BR BRINTERVAL 2H 。(兩個小時)。
3.Bounded Recovery機制在你強制停止抽取程式後重啟時，可以不必一整個事務都從資料庫的日誌中讀取，而已在檢查點內儲存的事務過程可以透過OGG 自己儲存的BR檔案讀取。
4.一個長事務中未受Bounded Recovery檢測儲存的過程，OGG透過記錄檢查點去歸檔中讀取。

本文乃darren__chan原創文章，請勿轉載。如須轉載請詳細標明轉載出處。

停止OGG e程式時遭遇長事務分析

相關文章