DataGuard - 利用Cascaded Redo Log Destinations避免WAN穩
2024-07-21 02:05:59
供稿：網友
最近一直頭疼于dataguard環境中萬一網絡失敗將導致的primary庫短時間內無法正常工作的問題。
這個問題的現象基本上是這樣：
當primary和standby之間的網絡出現問題，比如說在測試環境中我們拔掉standby的網線，此時當primary發生日志切換（log switch）的時候，primary將試圖通知standby同樣作歸檔，但是由于網絡不通，就會默認有30秒的timeout，而在這30秒的時間內，primary上的任何dml操作都將被懸停。
至今為止我還沒有找到很好的辦法可以有效地縮短這個timeout時間，雖然按照文檔上說應該可以縮短到最小15秒。即使是15秒，也是無法忍受的，特別是如果dataguard環境搭建在wan上，比如說通過2m的ddn專線，那么出現網絡故障的幾率是比較高的。
如果說將有可能由于dataguard的網絡原因而導致主業務庫的操作懸停，無論對于客戶還是對于我個人而言都是不太容易接受的。
wan上的網絡故障幾率較大，那么如果我們換到lan上，就可以降低這種故障的發生率。由此想到可以利用dataguard中的cascaded redo log destinations功能。今天作了此項測試，效果還是很理想的。
所謂cascaded redo log destinations功能，是指a機器（primary）將redo數據傳遞給b機器（standby），然后b機器再將接收到的redo傳遞給c機器（standby），這種中轉方式在physical standby和logical standby中都可以實現。如果a，b處于同一個lan中，而b，c則通過wan通信，那么即使wan出現網絡問題，也不會影響a將redo傳遞到b，也就不會影響a的業務進行。
大概配置如下：
1。a (primary)的init參數：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.log_archive_dest_2='service=ctsdb.jumper lgwr async=20480 net_timeout=15 max_failure=2 reopen=10'
2。b (standby1)的init參數：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.log_archive_dest_2='service=ctsdb.standby'
*.standby_archive_dest='/oradata/ctsdb/archive'
3。c (standby2)的init參數：
*.log_archive_dest_1='location=/oradata/ctsdb/archive'
*.standby_archive_dest='/oradata/ctsdb/archive'
*.fal_client='ctsdb.standby'
*.fal_server='ctsdb.jumper'
其它的配置文件，比如listener.ora和tnsnames.ora，不再贅述。
在b機器上的alertlog中一些比較有趣的地方：
thu jan 13 12:05:27 2005
rfs: successfully opened standby logfile 4: '/oradata/ctsdb/redo04.log'
thu jan 13 12:05:33 2005
rfs: successfully opened standby logfile 5: '/oradata/ctsdb/redo05.log'
thu jan 13 12:05:38 2005
rfs: successfully opened standby logfile 6: '/oradata/ctsdb/redo06.log'
rfs: successfully opened standby logfile 7: '/oradata/ctsdb/redo07.log'
rfs: no standby redo logfiles of size 6144 blocks available
以前的測試和freelists中的一些郵件列表的討論都表明在dataguard環境中我們最多只能使用到2組standby redolog（一般情況我們只會只用到1組），這是因為oracle對于srl的啟用機制就是從首個srl開始找第一個可以使用的，正常情況下只有在接受下一次redo信息時，redo04.log還沒有被歸檔成功，這時候才會使用redo05.log，而redo05被寫滿以后，redo04還沒有被歸檔結束的情況我們幾乎不可能碰到，所以下一次的redo信息又被寫到redo04中。
而這次測試，由于b和c之間的網絡中斷，導致redo04－redo07這四組srl都被啟用了，并且再接下去rfs報了no standby redo logfiles的錯誤，這個同樣很明顯地表示了如果網絡中斷，在timeout時間內，redo是無法被正常歸檔的。
那么大家可能要問，如果b的4組srl都無法使用了，a繼續傳過來的redo數據是不是也會被阻塞，從而也間接導致了a同樣無法正常繼續業務？
在測試之前，我也同樣擔心這個問題，但是測試表明這種情況沒有出現。原因在于dataguard的機制是，即使a指定了使用lgwr傳遞redo（如本例所示），如果出現b上的srl無法使用的情況，b的rfs進程將把接受到的redo直接寫入本機的archivelog中，當a開始歸檔的時候，b同時歸檔剛才寫入了數據的archivelog（此歸檔的sequence比a上歸檔的sequence大1）。從下面的alertlog中可以確認這點：
arc1: evaluating archive log 6 thread 1 sequence 600
arc1: beginning to archive log 6 thread 1 sequence 600
creating archive destination log_archive_dest_2: 'ctsdb.standby'
creating archive destination log_archive_dest_1: '/oradata/ctsdb/archive/1_600.dbf'
arc1: completed archiving log 6 thread 1 sequence 600
從以上的測試中我們得出一個結論，只要是primary可以跟standby的rfs進程正常通信，那么就不會產生操作被懸停的問題，不管standby到底是使用了srl還是使用了archivelog。
最后，由于這樣的環境添加了額外的機器（機器b），而由于dataguard環境必須要求同構，所以如果整個環境是unix的，那么也許大家要問，這樣豈不是需要再購買一臺小型機，這在budget方面是不是就有些問題了。
確實，需要額外的投入，但是由于b機器只是作中轉redo的作用，所以我們甚至可以不將b置于managed recover模式下，也就是b只負責接受a的redo，再把redo傳送到c，這樣對于b機器的性能要求就可以下降很多，也許一臺普通的sunray工作站就可以滿足要求了。至于是不是確實可以滿足性能需求，我還會有后續的測試。
呵呵，敬請期待。本文來源于網頁設計愛好者web開發社區http://www.html.org.cn收集整理，歡迎訪問。
