資料庫Standby中的幾個概念 - LGWR, ARCH,ASYNC,SYNC,AFFIRM

一 . 雙機熱備

　 從廣義上講，雙機熱備（雙機容錯）就是對於重要的服務，使用兩臺伺服器，互相備份，共同執行同一服務。當一臺伺服器出現故障時，可以由另一臺伺服器承擔服務任務，從而在不需要人工干預的情況下，自動保證系統能持續提供服務　 雙機熱備由備用的伺服器解決了在主伺服器故障時服務不中斷的問題。但在實際應用中，可能會出現多臺伺服器的情況，即伺服器叢集　 雙機熱備一般情況下需要有共享的儲存裝置。但某些情況下也可以使用兩臺獨立的伺服器　 實現雙機熱備，需要透過專業的叢集軟體或雙機軟體

　 從狹義上講，雙機熱備特指基於active/standby方式的伺服器熱備。伺服器資料包括資料庫資料同時往兩臺或多臺伺服器寫，或者使用一個共享的儲存裝置。在同一時間內只有一臺伺服器執行。當其中執行著的一臺伺服器出現故障無法啟動時，另一臺備份伺服器會透過雙機軟體的診測（一般是透過心跳診斷）將standby機器啟用，保證應用在短時間內完全恢復正常使用 .

所以，像VCS (VERITAS Cluster Manager)等軟體實現的Oracle Cluster Server 以及Oracle Standby ,Oracle RAC(Real Application Cluster),高階複製(Advanced Replication), Streams 等技術都能認為是雙機熱備。

二． Physical Standby ，Logical Standby (物理Standby及邏輯Standby)

Physical standby直接從主庫接受archived log，然後直接做基於block的物理恢復（更新或調整變化的block），所以physical standby在物理檔案一級完全都等同於主庫。 physical standby 恢復只是底層的block apply, OS層面的工作, 資料庫SCHEMA，包括索引都是一樣的。它是直接應用REDO或歸檔實現同步的 。不會涉及temp ,undo 等。 物理STANDBY可能的模式：只讀模式（OPEN READONLY）和恢復模式（MANANGED RECOVERY）。

在邏輯STANDBY中，邏輯資訊是相同的，但物理組織和資料結構可以不同，它和主庫保持同步的方法是將接收的REDO轉換成SQL語句，然後在STANDBY上執行SQL語句（SQL Apply）。邏輯STANDBY除災難恢復外還有其它用途，比如用於使用者進行查詢和報表。

在9i R2之前，data guard的伺服器只能執行在read only或者recover 模式， 一個physical standby database 在物理上完全等同主庫，當physical standby database正在做恢復的時候，不能開啟用作其他用途。 而logical standby database只是在logical上等同需要恢復的schema， 所以在恢復的時候，可以同時開啟做report(做查詢動作)，也可以使用者和主庫不一樣的 資料物件等等，極大了提高了備用庫的利用率。

三． Dataguard

都是Standby 。 在Oracle 9i之前稱為Standby，9i或之後的Standby被改名為Data guard 。不過功能上也有了很多的改進和區別 。

四． Standby下LGWR / ARCH 傳輸

檢視資料庫保護模式：

SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;

1. 最大效能(maximize performance): 這是data guard預設的保護模式。primay上的事務commit前不需要從standby上收到反饋資訊（主資料庫的提交操作不等待STANDBY），該模式在primary故障時可能丟失資料，但standby對primary的效能影響最小。 可以使用LGWR ASYNC 或者ARCH 兩種傳輸模式。

ARCH 傳輸模式： Primary DB上的online redo log 寫滿或其他條件引起redo log寫歸檔的時候，redo log 生成的archived log file寫到本地歸檔目錄的同時，寫入了Standby歸檔目錄。只是Primary db上的online redo log 切換不必等Standby上的寫歸檔動作結束。

2. 最大可用(maximize availability): 在正常情況下，最大可用模式和最大保護模式一樣；在standby不可用時，最大可用模式會自動降低成最大效能模式，所以standby故障不會導致primay不可用。在問題糾正之後，Standby和主資料庫進行再同步，至少有一個standby可用的情況下，即使primary down機，也能保證不丟失資料。(不過當問題修復，再同步之前有必要FAILOVER,那麼有些資料可能會丟失)。最大可用性模式Standby必須配置Standby Redo log ， Oracle推薦最大可用模式使用LGWR ASYNC （非同步）模式傳輸。

採用最大可用的data guard 模式，主庫往備庫傳遞線上日誌(online redo log)資訊，線上日誌資訊寫入備用庫的standby redo log,這些standby redo log歸檔後，備用庫應用歸檔日誌。

LGWR還分為LGWR ASYNC(非同步)和LGWR SYNC(同步)兩種。

	最大保護	最大可用	最大效能
程式	LGWR	LGWR	LGWR或ARCH
網路傳輸模式	SYNC	SYNC	LGWR時設定ASYNC
磁碟寫操作	AFFIRM	AFFIRM	NOAFFIRM
備用日誌	YES	物理備用需要	LGWR和物理備用時需要
備用庫型別	物理Standby	物理或邏輯	物理或邏輯

最大保護(maximize protection): 最高階別的保護模式。primay上的事務在commit前必須確認redo已經傳遞到至少一個standby上，如果所有standby不可用，則primary會掛起。該模式能保證零資料丟失。 對於最大保護和最高可用性模式，Standby資料庫必須配置standby redo log，並且oracle推薦所有資料庫都使用LGWR ASYNC模式傳輸。

 

LGWR ASYNC: ------------

Asynchronously archiving with the LGWR process in
conjunction with SSH port forwarding showed the following characteristics when
compared to the baseline: - Significant reduction in network traffic -
Slight increase in primary database throughput - Minimal increase in cpu usage
When using LGWR to remotely archive in ASYNC mode, the LGWR process does not
wait for each network I/O to complete before proceeding. This behavior. is made
possible by the use of an intermediate process, known as a LGWR network server
process (LNS), that performs the actual network I/O and waits for each network
I/O to complete. Each LNS has a user configurable buffer that is used to
accept outbound redo data from the LGWR. This is configured by specifying the
size in 512 byte blocks on the ASYNC attribute in the archivelog destination
parameter. For example ASYNC=2048 indicates a 1Mb buffer. As long as the
LNS process is able to empty this buffer faster than the LGWR can fill it, the
LGWR will never stall. If the LNS cannot keep up, then the buffer will become
full and the LGWR will stall until either sufficient buffer space is freed up
by a successful network transmission or a timeout occurs. Reducing network
traffic in a network with high round trip times (RTT) reduces network server
timeouts due to buffer full conditions, thus reducing the impact to the
primary database throughput. ASYNC can improve the primary database throughput
due to the fact that by compressing the redo traffic, the transfer (in 1 MB
chunks) is quicker and thus the ASYNC buffer doesn't reach full capacity as
often, thereby avoiding the wait that can occur when the buffer is full.