模板
教程
環境
性能
功能
管理
DataGuard - 利用Cascaded Redo Log Destinations避免WAN穩定性問題
最近一直頭疼于DataGuard環境中萬一 網絡 失敗將導致的Primary庫短時間內無法正常工作的問題。 這個問題的現象基本上是這樣： 當Primary和Standby之間的網絡出現問題，比如說在 測試環境 中我們拔掉Standby的網線，此時當Primary發生日志切換（Log Switch）
最近一直頭疼于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: Suclearcase/" target="_blank" >ccessfully 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工作站就可以滿足要求了。至于是不是確實可以滿足性能需求，我還會有后續的測試。
呵呵，敬請期待。
