【DATAGUARD】Dataguard遠端同步配置最佳實踐

Oracle12.2之後，Dataguard推出了一個新的功能，Far sync Instance， 也就是 該例項不存放資料檔案，只負責把相關線上日誌資料或者歸檔資料同步到其他dg備端上，起到一箇中轉站的作用。具體可參考其他文章。 如本博文章： http://blog.itpub.net/29487349/viewspace-2792878/

下面的文章是轉自mos，供有興趣的小哥翻閱。

遠端同步例項相關技術可參考: 

遠同步例項的行為與為同步傳輸配置的任何其他資料保護/活動資料保護歸檔目標一樣。這意味著關於影響往返網路延遲的光速的物理定律沒有以任何方式改變；主資料庫效能仍將受到主資料庫和遠同步例項之間的網路往返時間的影響。但是，透過將遠同步例項放置在距離主資料庫較遠的metro距離，並允許遠同步例項處理與數百或數千英里遠的遠端備用裝置的所有通訊，實現了實現遠距離零資料丟失的靈活選項。這使所有情況下都能實現零資料丟失故障切換，但影響廣泛地理區域的災難除外，該災難會同時導致主同步例項和遠同步例項中斷。很少有必要的配置最佳實踐。大多數與適用於任何同步重做傳輸目標的相同。它們如下所示：

 

»主資料庫和遠端同步例項之間的網路必須滿足 :

• Have  round trip  latency low enough so that  the impact to  response time and throughput of the primary  database do es  not exceed business requirements .  The degree of impact  is very application specific and wil l  require testing to validate.  In general, experience shows that there is a higher likelihood of success if the  round - trip latency is less than 5ms, though there are successful deployments at higher  latencies.
• Provide enough bandwidth between the primary database and far sync instance to accommodate peak redo  volumes  in addition to any other  traffic sharing the network. Redo  transport  compression can be used to  reduce network bandwidth requirements .
• Ideally there are redundant network links that will also tolerate network component failure.

 

»標準資料保護網路最佳實踐，例如TCP傳送和接收緩衝區大小的適當設定等於頻寬延遲乘積的三倍。有關更多資訊，請參閱資料保護網路傳輸的MAA實踐。 ( )

 

»遠同步例項的備用重做日誌（SRL）應放置在具有足夠IOPS（每秒寫入數）容量的儲存器上，以在峰值活動期間超過主資料庫上LGWR程式的I/O of，以及其他活動的任何IOPS。這是一個重要的考慮因素。例如 :

• If the Far Sync instance has  lesser performing disks  than the primary it  may  not be able to forward  redo  to  remote destinations as fast  as it is received  and a n archive log  gap can  form.
• In the case of redo gap resolution scenarios due to planned maintenance on the standby or network outages  for example, there will be additional IO requests for gap resolution  on top of  redo  from current  transactions .
• Lesser performing disks at the Far Sync instance will delay acknowledgement to the primary database,  increasing the total round - trip time between primary and standby and impacting application response time.  This impact can be eliminated by u sing Fast Sync between the primary and the Far Sync instance  .

 

»根據標準MAA最佳實踐，遠端同步例項的備用重做日誌（SRL）的重做日誌組數量應與主伺服器上的相同，每個執行緒的重做日誌組數量應為+1。 .

»備用遠同步的SRL應在使用前手動清除，以便在啟用備用遠同步時實現最快的返回同步傳輸和零資料丟失保護。

»效能測試表明，小型遠同步例項SGA不會影響遠同步例項或主資料庫的效能。MAA建議配置遠同步功能所需的最小SGA。

»使用例項限制()以實現儘可能最小的SGA。在測試期間減少CPU_計數對遠同步例項的效能沒有影響。

»MAA測試確定，在Linux上CPU_計數為1的300MB SGA 300足以進行遠同步。（CPU_計數為1 SGA_目標為300M）

» 將遠同步例項上的RMAN archivelog刪除策略配置為“傳送到備用”或“在備用時應用”，以自動管理遠同步例項上的磁碟空間。如果主或備用例項有適當的備份計劃，則無需備份遠同步例項上的archivelog。

»為主資料庫和備用資料庫配置遠同步例項，以便在角色轉換後保持零資料丟失保護。部署在備用資料庫城域距離內的遠同步例項處於空閒狀態，直到備用資料庫成為主資料庫

• Note that  in  a  Data Guard Broker configuration a  switchover (planned role tr ansition) cannot occur while in  Maximum Availability unless the  protection mode  can be enforced from the targe t standby site.  If the standby  does not have its own Far Sync instance it will have to be configured to ship ASYNC to the original primar y  after roles are reversed. T his will prevent a switchover from occurring unless the pro tection mode for the  primary database is first dropped from Maximum Availability to Maximum Performance. 
  

»快速同步是Data Guard 12c的一項新功能，與4%到12%的同步相比，它提高了主資料庫效能，具體取決於網路延遲和遠同步例項硬體的I/O速度

»如果滿足CPU、I/O和網路要求，將遠同步例項放置在虛擬機器上不會產生與物理硬體配置不同的效能

原文參考： Far Sync Configuration Best Practices (Doc ID 2678239.1)