網路上和官方文件配置Data Guard 的步驟已經非常成熟，個人覺得應該逐漸深入，去理解其原理，挖掘其精髓

這篇文章是個人學習總結的筆記，如果寫的有錯的地方，還望大家留言指正

下圖為一個ADG的模型，那麼這篇文章就來研究圖中的箭頭的原理，也就是日誌是如何傳送的

圖中，主庫在執行時會不斷產生redo log，這些日誌會通過網路傳送到備庫，這個傳送動作，可以由ARCH完成，也可以由LGWR完成，選用哪種程序，對資料庫的可用性和DG的保護能力有著很大的區別。

1.使用ARCH程序傳送日誌

主庫不斷的產生redo log，這些日誌被LGWR寫進聯機日誌，當一組聯機日誌被寫滿，會發生日誌切換，並且ARCH會將其歸檔，本地歸檔是LOG_ARCHIVE_DEST_1='LOCATION=/...'這種引數定義，ARCH程序還會通過網路把歸檔日誌傳送給備庫的一個叫做RFS的程序，備庫接受日誌並寫入到歸檔日誌，然後備庫的MRP程序（redo apply）或者LSP程序（SQL apply）在備庫上應用這些日誌，於是資料就同步了。

使用ARCH傳遞的問題也是很明顯的，只有日誌切換作為前提，才能傳送日誌，如果主庫異常停機，聯機日誌丟失，導致無法歸檔，那麼丟失資料是在所難免！

在預設情況下，主庫就是用ARCH程序傳送日誌，不需要特別的設定。

2.使用LGWR程序傳送日誌

LGWR又分為SYNC（同步）和ASYNC（非同步）兩種方式

2.1LGWR程序的SYNC方式

主庫產生redo log要同時寫入到日誌檔案和網路，即LGWR把日誌寫到本地聯機日誌檔案的同時，還發送給本地的LNSN程序（Network Server Process），然後LNSN程序把日誌內容通過網路傳送到備庫。

LGWR必須等待寫入本地聯機日誌和LNSN程序傳送成功，主庫的事物才能提交，這就是實時同步的原理。

備庫的RFS程序把接收到的日誌立刻寫入standby redo log中，所以在備庫上看，最後一個日誌總是IN-MEMORY,這也是我當初疑惑的一個問題，現在終於清晰！

備庫的恢復方式可以是實時恢復，也可以是完成對standby redo log的歸檔後恢復。

另外NET_TIMEOUT引數單位為秒，作用是該段時間網路無響應，LGWR會丟擲錯誤

LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30'

2.2使用LGWR程序的ASYNC方式

使用LGWR SYNC方式也有弱點，如果在傳送給standby db過程中出錯，LGWR會報錯，主庫事物無法完成，

主庫LGWR過分依賴網路狀態，如果網路不能保證365天高速無懸念和不會被挖掘機挖斷光纖，或者對資料同步不苛刻，也可以採用LGWR ASYNC方式。

主庫產生redo log之後，LGWR-->LNSN，但是LGWR只需要成功寫入日誌檔案，事物即可允許提交，不必等待LNSN程序傳送成功。

主庫聯機日誌寫滿後，歸檔，也會觸發備庫的standby redo log歸檔，然後觸發MRP活LSP程序恢復歸檔。

即備庫的恢復方式，只能是完成對standby redo log的歸檔後恢復。

由於LSWR不會等待LNSN，所以無需配置NET_TIMEOUT引數。

1.關於Data Guard日誌接收的總結：

 備庫的RFS程序接收到日誌後，就把日誌寫到standby redo log或者archived log file檔案中。
 而歸檔日誌會被放在什麼位置取決於standby database歸檔路徑的選擇，

 如果配置了standby_archive_dest,則使用這個引數指定的目錄；
 如果配置了log_archive_dest_n，該引數明確定義了VALID_FOR=(STANDBY_LOGFILE,*)，則使用這個引數指定的目錄；
 如果資料庫的COMPATIBLE引數大於等於10，則選取任意一個LOG_ARCHIVE_DEST_n的值；
 如果standby_archive_dest和log_archive_dest_n引數都沒有配置，使用預設的standby_archive_dest引數，這個預設值是$Oracle_HOME/dbs/arch。

2.關於Data Guard日誌應用的總結：

 日誌應用服務，就是在備庫上重演主庫的日誌，從而實現兩個資料庫的資料同步。
 根據備庫重演日誌的方式不同，可分為物理和邏輯兩種型別。

 物理使用的media recovery技術，在資料塊級別進行恢復。這種方式沒有資料型別的限制，可以保證兩個資料庫完全一致。
 而邏輯使用的logminer技術，通過把日誌內容還原成SQL語句，然後SQL引擎執行這些語句。

 根據redo apply發生的時間可以分為2種：
 一種是實時應用，這種方式必須有standby redo log，每當日誌被寫入standby redo log時，就會觸發恢復，
 使用這種方式的好處就在於可以減少資料庫切換的時間，因為切換時間主要用在剩餘日誌的內容恢復上。

 另一種是歸檔時應用，這種方式在主庫發生日誌切換之後，才觸發備庫的歸檔，歸檔完成後再觸發恢復，這也是預設的方式。

 如果是物理備庫，可以使用下面命令啟用real-time
 alter database recover managed standby database using current logfile;

如果是邏輯備庫，可以使用下面命令啟用real-time
 alter database start logical standby apply immediate;

檢視是否使用了real-time
 select recovery_mode from v$archive_dest_status;

3.關於Data Guard環境中的重要程序的總結：

 主庫：
LGWR：在主庫上，這個程序負責吧redo buffer中的內容寫入online redo log。

LNS（logwriter network service）：LNS程序讀取日誌，並通過網路傳送給備庫，這個程序的目的是為了給LGWR減輕負擔，LGWR程序不用再參與到網路日誌的傳送中。

ARCH：歸檔程序，在主庫中可有30個歸檔程序，其中有一個是專門負責本地歸檔的，不參與Gap Resolution,
而其他的arch程序都可以進行Gap Resolution。

 備庫
RFS（remote file server）：這個程序負責接收網路上傳來的redo日誌，並把這些日誌寫到standby redo log檔案中。

ARCH：同樣是歸檔程序，只是在備庫上，需要歸檔的是standby redo log檔案的內容。

MRP（magaged recovery process）：這個程序負責協調介質恢復管理工作，整個物理備庫就是建立在介質恢復技術上的。

PR0x（Parallel Recover Process）：這是進行具體恢復工作的程序，如果是real-time apply模式下，這些程序會從standby redo log檔案中讀日誌；而在其他模式下，是從歸檔日誌中讀取日誌然後再進行日誌應用。

LSP（logical standby process）：這個程序在logical standby中才有，功能和物理備庫的MRP程序類似，負責協調SQL APPLY過程。

1.關於standby redo log的理解
Data Guard在備庫中，建議配置一種額外的日誌檔案，叫做standby redo log（SRL），和傳統的online redo log（ORL）相比，SRL有著特殊的要求和作用。兩者的關係可以從下面的幾點來對比：
1.SRL和ORL兩種檔案是完全相同的，只是兩者發揮的作用和場景不同。
2.SRL只在備庫上起作用，（雖然主庫也可以配置SRL），但是當資料庫處於主庫角色的時候，SRL是不活動的，只有經過了角色切換，變成了備庫角色時，SRL日誌才會變成活動的。
3.對於處於備庫角色的資料庫來說，ORL不是必須的，也不會起作用，（在很多時候，備庫雖然顯示有ORL，但是並沒有真正的作業系統檔案存在，只有當角色切換，變成主庫角色時，才真正在作業系統上建立ORL檔案）！
4.對於處於備庫角色的資料庫來說，他從主庫接收到的日誌可以記錄在SRL檔案中，也可以記錄在歸檔日誌檔案中，具體寫在哪個檔案中取決於具體配置，但是不會寫在ORL中。
5.SRL必須和ORL大小完全一致，否則SRL也不會被用到。其次，從數量上，應該按照每個例項或日誌執行緒N+1的數量關係來配置，例如2個例項的RAC，如果每個例項3組日誌，則SRL應該是（3+1）*2=8組。

 是否使用SRL，關鍵區別在於RFS把接收到的日誌，是寫在歸檔日誌裡，還是寫在SRL裡。
 使用SRL可以帶來2大好處：
1.效能
 如果不使用SRL，則備庫的RFS會把接收到的日誌記錄到歸檔日誌檔案中，每當主庫做日誌切換時，才會觸發備庫對當前歸檔日誌的歸檔操作，因此他必須等待備庫的RFS程序建立並且初始化下一個歸檔日誌檔案，用來容納以後傳遞的REDO內容。因此這個過程會影響主庫日誌的切換進度，當然對於非同步傳送來說不影響主庫效能，但是仍然會導致備庫日誌落後的情況。
 然而使用了SRL，因為SRL預先建好，因此日誌切換時，無需額外的檔案初始化工作，因此效能要更好一些。

2.支援Real-Time Apply（RTA）
 前面介紹了實時同步，備庫最後一個日誌總是IN-MEMORY狀態。

2.關於Data Guard保護模式的學習和總結
 資料保護模式是指備庫和主庫之間資料同步程度。
Data Guard允許定義3種資料庫保護模式，分別是最大保護、最大可用、最大效能模式。
 這3種模式的區別在於，當主庫發生故障時，備庫的資料會和主庫有多大的差距。

1.最大保護模式 Maximum Protection
顧名思義，這是最高的資料保護級別，這個模式的規則是即便犧牲主庫的可用性，也要保證不出現資料丟失！
 這個級別保證備庫和主庫的資料是完全同步的，即使主庫突然夯機，在備庫上也不會出現任何資料丟失。

 這種方式要求備庫必須配置SRL，而主庫必須使用LGWR、SYNC、AFFIRM方式歸檔到備庫，並且用命令定義為最大保護模式。
 在這種模式下，主庫上的每個事務的REDO日誌必須在和本地和備庫上都寫入日誌檔案後才允許提交。如果不能寫入到備庫，
 主庫就會自動關閉以方式資料丟失。但也不是立刻shutdown abort，而是不再生成任何REDO，並且不斷地嘗試連線備庫，
 這個嘗試大約最多會有10分鐘，因為這一段時間內LGWR不再生成任何REDO，因此整個資料庫表現為掛起。

 在這種模式下，至少要有一個備庫是正常的，主庫才能正常開啟，否則主庫都無法開啟。

 如果主庫是RAC環境，如果一個例項和備庫之間網路發生了問題，那麼在最大保護模式下，這個例項是crash，繼而觸發其他例項的crash recovery，
 完成這個recovery之後，Data Guard會忽略這個例項，而主庫其他例項也能繼續處理業務，併發送日誌進行同步。除非所有例項連線備庫都出現了問題，
 才會出現所有例項crash，最終導致整個資料庫的crash。

2.最大可用模式 Maximum Availability
這是另外一種能實現零資料丟失的資料保護方案。這種模式需要至少有一個備庫是通過SYNC和AFFIRM方式傳送資料，並且要使用SRL檔案才行。
 在這種模式下，主庫傳送redo日誌、並等待備庫確認，備庫收到redo日誌，記錄到SRL中，並返回確認給主庫，這時，主庫上的事務才能結束。
 這是和最大保護模式一樣的地方。因此，網路狀態、備庫的狀態都會影響主庫的事務效能。等待確認的時間用一個引數NET_TIMEOUT定義。
 如果主庫在該段時間（預設30秒）沒有收到任何反饋資訊，這個備庫就會被標記成failed，LGWR會繼續寫日誌，但是會忽略掉這個failed的備庫。
 如果在NET_TIMEOUT內收到了standby failed的訊息，LGWR和LNS還會繼續嘗試重新連線，直到最終放棄這個備庫為止。

 一旦備庫被認為是failed，那麼主庫就會強制進行一次日誌切換，以明確的標識出發生failed的時間點，也就是達到零資料丟失的時間點，
 而在這以後產生的redo日誌就不再向備庫傳送了。

 在這以後的時刻，Data Guard的保護模式就降到了Unprotected了，如果是一主多備環境，會有其他備庫保持同步。一致到解決了日誌Gap，
 主庫才會繼續傳送REDO，Data Guard才會恢復到Maximum Availability模式。

 在RAC環境下，如果一個例項認為備庫是failed，則自動觸發的日誌切換會導致所有的例項都停止傳送REDO，即便其他例項能夠連線到備庫。
 接下來，例項的ARCH程序還繼續利用ping機制檢測到備庫的連通性，一旦恢復連線，則所有的例項會自動去解決gap，
 接著所有的例項會進行日誌切換，以啟動LNS程序，繼續傳送REDO。

 這種模式只是儘量避免資料丟失，也並不能保證資料完全一致。這種模式要求備庫必須配置SRL，而主庫必須使用LGWR、SYNC、AFFIRM方式歸檔。

3.最大效能模式 Maximum Performance
這個模式是預設的模式，它更加側重對主庫可用性不造成任何影響，即“在不影響主庫效能的情況下，儘可能少的資料丟失。”

主庫上的事務的REDO日誌只要寫到本地日誌檔案就可以提交，不必等待到備庫傳遞完成。主庫的REDO可以非同步傳送到備庫。
 備庫的任何故障，以及兩者之間的網路故障都不會影響主庫的活動，即便網路出現問題，主庫也只不過暫時停止REDO傳送，
 並等待ARCH程序通過PING機制發現連線恢復之後，繼續重傳。

 這種模式可以使用LGWR ASYNC或者ARCH實現，備庫也不要求使用SRL。

 如果主庫是RAC，並且工作在最大效能模式下，如果只是RAC的某個例項和備庫的日誌傳遞發生故障，那麼也只有該例項的日誌傳遞被中止。
 而其他例項的日誌傳遞仍然繼續。發生中斷的例項上的ARCH程序會不斷地通過ping機制來檢查連通性，一旦發現連線恢復，這個例項上的gap會自動傳送給備庫，
 但是LGWR程序卻並不會立即啟動LNS程序去傳送當前的redo資料，而是直到下一次日誌切換時，LGWR才會啟動LNS，開始傳遞REDO資料。

3.定義資料保護模式
 保護模式是針對主庫進行設定的，這個設定是告訴主庫必須要遵守的規則。對備庫沒有作用。
 資料保護模式在定義資料保護級別的同時，捎帶著也同時定義了兩個重要資訊：

 主庫如何向備庫傳送redo；
 當備庫發生故障或網路出現故障，主庫應該怎麼做。

 以下命令都是在主庫下執行：
ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;
 ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
 ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;

切換模式的過程，先嚐試能夠在open狀態下切換，不能的話，就在mount下切換。
shutdown immeidate
 startup
 alter database set standby to maximize availability;
 alter database open;
 select protection_mode,protection_level from v$database;