公司現(xiàn)在越來越重視數(shù)據(jù)的災備，部署了大量的Data Guard和Oracle GoldenGate。核心系統(tǒng)的數(shù)據(jù)非常重要，大boss的要求很簡單就是數(shù)據(jù)零丟失。

仔細衡量Data Guard的三種保護模式，在最大可用和最大保護之間展開了激烈的討論。下面從技術層面看看這兩種保護模式的特點和區(qū)別。

[[190001]] 

零數(shù)據(jù)丟失：

在DataGuard中同步傳輸SYNC(synchronous transport)又稱為零數(shù)據(jù)丟失。因為要等到確認事務恢復所需要的redo數(shù)據(jù)已經(jīng)被寫入備用數(shù)據(jù)庫的磁盤上(StandbyLogFile)，才允許LGWR認可提交操作成功。

最高可用：

ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;  

這個模式最強調(diào)可用性，其次強調(diào)零數(shù)據(jù)損失保護。該模式使用SYNC(同步)方式傳輸redo數(shù)據(jù)，因此從備用數(shù)據(jù)庫收到“redo數(shù)據(jù)已經(jīng)寫入磁盤”確認消息所需的時間會影響主庫的性能。但是在主庫出現(xiàn)故障時，通常可以百分百保護數(shù)據(jù)。

然而網(wǎng)絡故障或者備用數(shù)據(jù)庫出現(xiàn)故障，將無法向備用數(shù)據(jù)庫傳輸redo，而主庫仍能繼續(xù)接收新事物。 配置最高可用時，其最長等待秒數(shù)有NET_TIMEOUT的值決定(默認30秒)，此后將放棄備用目標，即使仍然無法與備用數(shù)據(jù)庫通信，也允許主數(shù)據(jù)庫繼續(xù)進行處理。當連接重新建立后，主庫將強制切換一次日志，關閉current redo log，防止在間隔再同步過程中redo傳輸進一步滯后。僅當在自動重新同步進程尚未完成前，主庫又一次出現(xiàn)故障時才可能丟失數(shù)據(jù)。

最高保護：

ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION; 

采用SYNC同步redo數(shù)據(jù)傳輸模式，直到收到配置中至少一個備用數(shù)據(jù)庫的確認消息(恢復事務所需的數(shù)據(jù)已經(jīng)可靠第保存在磁盤上)，主數(shù)據(jù)庫才確認提交。與最高可用不同的是，它不再考慮NET_TIMEOUT參數(shù)。如果主數(shù)據(jù)庫未能從SYNC備用數(shù)據(jù)庫收到確認消息，主數(shù)據(jù)庫將停下來并最終終止，防止出現(xiàn)未保護提交的情形。

最高性能：

就是快在ASYNC，異步傳輸模式上。LGWR進程不必等待LNS的確認消息。該種方法不再考慮范圍之內(nèi)。

最高可用vs最大保護

最大可用顧名思義是以可用為第一目標，安全性會為了可用性自動降級。它的阿基里斯之踵就是在NET_TIMEOUT超時后，主庫會繼續(xù)處理事務，等到當前redo寫滿，開始進入歸檔模式時才會再次嘗試連接備用數(shù)據(jù)庫。這個期間主庫與備庫的數(shù)據(jù)時不一致的，出現(xiàn)災難場景failover后回丟失數(shù)據(jù)。

可是最大保護呢，這個反對呼聲也非常高，就是擔心網(wǎng)絡問題或是備庫問題導致無法及時給主庫的LGWR反饋信息，使主庫掛掉。

解決方案：  

其實滿足boss的零數(shù)據(jù)丟失，可以采用最大保護模式。為主庫創(chuàng)建2個或3個最大保護模式的同城災備，一個備庫在同機房不同機柜，其它的備庫在不同的機房(可能相隔幾公里)。當主庫發(fā)起一個事物提交動作，LGWR進程將redo log buffer中的內(nèi)容寫入redo log file同時LNS進程將該redo log buffer中的信息發(fā)送給備用數(shù)據(jù)庫。這時只要有一個最大保護模式的備用數(shù)據(jù)庫成功收到該數(shù)據(jù)并寫入standby log file中就會給主庫的LGWR進程反饋成功，主庫會繼續(xù)處理事務。并不需要所有的備用數(shù)據(jù)庫都向它反饋。 從某個角度來看該方法更像是解決備用數(shù)據(jù)庫的“單點故障”。當然只有一臺備用數(shù)據(jù)庫，并且采用了最大保護模式還是有影響主庫的可能性。