我們的生產系統使用Oracle叢集軟體實現了OGG的高可用。當叢集中的一個例項當機，OGG會abend後自動重新啟動。嚴格來說這個高可用設計也是相對的，因為它避免不了節點當機時OGG的程式意外中斷。但是在利用vip和OGG相互關聯後可以做到OGG意外中斷後30秒內自動重啟並且繼續工作。

在高可用配置中有一個需要注意的引數：TRANLOGOPTIONS altarchivelogdest。該引數使用不當的後果是：例項當機導致OGG一直abend，直到例項恢復後OGG才能恢復。設想一下，如果該例項所在的主機升級打補丁，或者更換硬體等耗時操作，OGG就要一直等下去，完全失去了高可用的意義。

下面來看一個案例：

1. 雙節點RAC的thread 2正常shutdown,導致OGG異常中斷。由於找不到thread 2的預設歸檔路徑無法啟動。

ggserr.log 日誌的警告和錯誤如下：

OGG-01423 No valid default archive log destination directory found for thread 2.

OGG-00868 failed to validate configuration on alternative log format and destination. User must either include thread specifier in the log format or specify unique destination for each and every thread.

2. extract程式的配置檔案中配置了引數TRANLOGOPTIONS altarchivelogdest

EXTRACT ext1

setenv (NLS_LANG="AMERICAN_AMERICA.AL32UTF8")

userid ogg@RAC,password ogg

GETTRUNCATES

REPORTCOUNT EVERY 1 MINUTES, RATE

numfiles 5000

DISCARDFILE ./dirrpt/extsym.dsc,APPEND,MEGABYTES 1024

DISCARDROLLOVER AT 3:00

WARNLONGTRANS 2h,CHECKINTERVAL 3m

DBOPTIONS ALLOWUNUSEDCOLUMN

EXTTRAIL ./dirdat/nd,MEGABYTES 500

DYNAMICRESOLUTION

TRANLOGOPTIONS EXCLUDEUSER ogg

TRANLOGOPTIONS CONVERTUCS2CLOBS

TRANLOGOPTIONS altarchivelogdest primary instance orcl1 /u02/Archive/ORCL/, altarchivelogdest instance orcl2 /u03/Archive/ORCL/

TABLE HR.t1;

3. 問題原因以及解決方案

從上面的配置檔案中可以看出，兩個例項各自擁有不同的歸檔日誌路徑。只有當兩個例項都是active狀態時OGG才能找到指定歸檔路徑。如果其中一個例項當機，成為inactive狀態了，OGG不知道如何獲取該歸檔路徑了。 看起來有些傻，但是它就是這樣工作的。

處理辦法如下：

- 可以將兩個例項的歸檔放在同一個路徑下，都放在/u02/archive/orcl 或者都放在/u03/archive/orcl

- 在引數檔案中新增THREADOPTIONS PROCESSTHREADS EXCEPT

- 直接刪除該引數

我會選擇使用最後一種方式，刪除該引數。

那麼這個引數到底有什麼用處呢？

首先OGG是知道redo和歸檔日誌的路徑的，從info extract * ,detail 中看的清清楚楚，不需要透過引數指明它們在哪。如果rman備份後刪除了所有的歸檔日誌，而這些歸檔日誌正是OGG所需的，OGG就會中斷。補救措施可以將歸檔日誌恢復出來，可以恢復到原處，也可以恢復到其它地方。透過THREADOPTIONS PROCESSTHREADS EXCEPT可以讓OGG找到其它地方的歸檔日誌。

我的理解是這樣的，不知道是否正確。

關於Oracle GoldenGate 引數TRANLOGOPTIONS altarchivelogdest

相關文章