轉帖：“http://www.linuxidc.com/Linux/2015-08/121190.htm”
網絡上和官方文檔配置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;