之前，原本已經嘗試過配置oracle實例的邏輯和物理standby結構，並且做個一些role交換操作，可是由於昨天學習rman的部分命令時沒留意，誤刪掉了primary DB上的所有歸檔日誌，因爲原來是在maximum protection模式下，standby DB上還存在archivel gap，結果之前搭建的standby實驗環境徹底掛了，primary DB也自動停了。我只好把primary DB在nomount模式下改爲maximum performance模式，並將控制standby redo log傳輸的log_archive_dest_state_n設置爲defer，才把primary DB啓動起來。現在，除了重建standby，還沒找到其他的彌補方法，看來對data guard的理解還是停留在照貓畫虎的操作上，根本米有理解它的原理啊。所以重新來過，從基礎開始好了。
首先，data guard的主要原理主要是primary DB將所有操作產生的redo log 傳輸到standby DB上，在由standby DB對此進行應用的。從而產生一個一致的standby DB。在data guard中，存在兩類SYNC和ASYNC，下面分別描述兩類的工作方法，從而進一步認識它的原理。
下圖是SYNC模式的流程圖。
1、當user 發出 commit命令後，將產生一條 redo record （也稱作redo entry）放入SGA中的 redo buffer 中，後臺進程LGWR將讀取此redo record，將其寫入online redo log file。並等待從LNS進程傳來的確認信息。
2、LNS（Log Network Server） 進程同樣從redo log buffer讀取redo record，並將其通過Oracle Net Services傳輸給standby DB。在standby DB上的RFS後臺進程將接收到的redo record寫入standby database中。
3、當RFS確定寫入所有的redo record到磁盤後，向primary DB的LNS發送確認信息。當LGWR收到LNS轉發的確認信息後，才返回commit成功的消息給user。
接下來來看ASYNC：類似於SYNC，只是primary DB上的LGWR可以不必等待LNS的確認信息，而且LNS可以讀取online redo log中的redo record。對於ASYNC，就可以考慮使用壓縮方式傳輸redo record，從而節省帶寬，但是這會使CPU的利用升高。此外，如果LNS在讀取online redo log中記錄時剛好遇到online switch，則可能造成standby的archivelog gap。LNS的不同步記錄，在提高性能的同時也可能會產生數據的丟失。
對於redo log的gap的處理，oracle的data guard有自己的自動處理方法。log file gap主要出現在primary DB上不斷有事務被提交，同時，LNS可能由於網絡或是standby DB的問題，不能及時同步造成的。此時，primary DB會繼續運行，循環使用redo logs，並進行歸檔。Data Guard會在primary DB上使用一個ARCH進程不斷的ping standby
DB。當與standby DB可以進行通信時，ARCH的ping進程會通過RFS查詢standby的控制文件，獲得上一次完成log同步的SCN從而確定從哪一個歸檔log開始進行同步，從而填補gap。當完成這一步，會自動過度到從當前的日誌文件中同步。具體的流程圖如下：
對於物理standby來說，它應用接受到的redo record是按下圖的方式的：
redo apply維持一個standby database是通過精確的物理塊來進行primary DB的備份的。RFS進程從primary DB接收到redo record，並將其寫入standby redo log（後面將被簡稱爲SRL）。redo apply通過介質恢復，將SRL中的redo record讀入內存中，介質恢復協調器（MRP0）管理恢復session，iang具有相同SCN的redo進行合併（這多是在RAC環境中），並分析redo映射到不同的 apply 進程。不同的 apply 進程讀取映射的數據塊，並將其寫入相應改變的數據塊。redo apply 會自動設置與cpu數目相等的 apply 進程。
對於使用 sql apply 的邏輯standby，其具體使用 redo 如下圖
SQL apply使用的是邏輯 standby 進程進行協調應用相應的redo log中的改變。sql apply進程讀取SRL，並將其轉化爲邏輯的記錄改變，並建立SQL事務，並應用這些SQL到standby DB上。顯然相對於redo apply，sql apply 更耗費cpu、io和內存等資源。