2. Data Guard 架構

Oracle Data Guard 運行的流程大致上可以歸納如下:

Primary 產生交易 🡪 傳送交易日誌到 Standby 🡪 Standby Apply 交易日誌

每個流程都有相對應的 Process 來處理:

• Primary 產生交易 :

  當資料庫產生交易 (DML) 行為並進行 commit ，此時交易紀錄便會透過 LGWR 寫入到 Redo Log ，當一個 Redo Log 寫滿產生 switch 的動作之後，便會由 ARCn 產生 Archive Log 。在 Data Guard 架構之下，除了將交易寫入到本地 Redo Log 之外，同時也會將此筆交易傳送到 Standby 端，以往傳送的方式可以選擇用 LGWR 或者是 ARCn 來傳送，而從 Oracle 11gR2 之後，便只能使用 LGWR 這個 Process 來傳送交易日誌，傳送的即時性可以選擇 Sync 或者是 Async 模式， Sync 模式是在交易 commit 之後， LGWR 同時寫入本地 Redo Log 以及傳送日誌到 LNSn 這個 Process ； Async 模式則是 LGWR 主要先寫入到本地 Redo Log ，寫完之後再由 Redo Log 將日誌傳送到 LNSn ， Async 的好處是這種設定完全不會影響到 Primary 交易的進行，而 Sync 模式則是要完全等到 LGWR 寫完 Redo 與傳送 LNSn ，此筆交易才會完成，有可能會影響到交易的效能。 LNSn (Network Server Process) 是一個中繼的 Process ，專門負責將交易日誌進行網路傳輸到 Standby 端，這一個 Process 是從 Oracle 10g 才開始有的，過往沒有 LNSn 時，都時直接由 LGWR 直接進行網路傳輸將日誌傳送到 Standby 端，此時若網路效能不好或者是 Standby 端無法到達，那麼 LGWR 便無法成功的傳輸日誌到 Standby 端，此時 Primary 的交易就無法完成，不過有了 LNSn 之後， LGWR 只負責將交易日誌送達 LNSn ，之後網路的傳輸就跟 LGWR 沒關係了， LNSn 最大的好處就是確保 Data Guard 架構下的 Redo Log 傳輸不會影響到正常交易的進行。

• 傳送交易日誌到 Standby 端 :

  Primary 端由 LNSn 這個 Process 接收交易日誌並且負責傳送，到了 Standby 端則是由 RFS (Remote File Server) 這個 Process 負責接收交易日誌，在 RFS 接收之後，便會把這筆交易紀錄寫入 Standby Redo Log ，當一個 Standby Redo Log 寫滿產生 switch 時， 便會由 Standby 端本地的 ARCn 產生 Archive Log ，如果 Standby 端沒有建立 Standby Redo Log ，此時會由 RFS 直接產出 Archive Log 。如果 Standby 端的交易日誌與 Primary 端有 Gap ，例如 Primary 的交易日誌序號已經到 100 ，而 Standby 端只接收到 50 號，此時 Standby 端會經由 FAL (Fetch Archive Log) 這個 Process 向 Primary 發出請求，把中間缺少的 archive log 再重新傳送過來。

• Standby Apply 交易日誌 :

  當交易日誌傳送到 Standby 端之後， Physical Standby 透過 MRP (Managed Recovery Process) 、 Logical Standby 透過 LSP (Logical Standby Process) 來 Apply 交易日誌， Standby 端可以選擇從 Standby Redo Log 來 Apply (這邊稱為 Real-Time Apply) ，或者是從 Archive Log 來 Apply ，在啟動 MRP 時使用 using current logfile 則表示用 Real-Time Apply:

SQL> alter database recover managed standby database disconnect from session;      (使用 archive log 進行 apply) SQL> alter database recover managed standby database using current logfile disconnect from session;      (使用 Real-Time Apply)

從 Oracle 12.2 開始， Real-Time Apply 已經是預設模式，不用再特別使用 using current logfile 。

Data Guard 的流程並不複雜，但每個 Process 所扮演的腳色都非常重要，只有熟悉這些架構，在發生問題時才能夠盡快找到是哪一個環節出了狀況。