Oracle Standby 以及其中的引數解釋 (zt)

有兩個新的術語需要學習：
無資料丟失模式： 用來保證所有提交事務的100%恢復。這就意味著LGWR（而不是ARCH）現在對傳送對備用伺服器重做流是很可靠的。
無資料分歧：在保證主資料庫及備用資料庫必須能夠同步方面增強了安全性，這個和無資料丟失模式一樣重要。這就意味著，假如重做日誌不能從主資料庫傳送到從資料庫，那麼沒有重做日誌將會允許產生。事實上，主資料庫將被關掉以防止這一點。
一個重要的構架變化就是對備用聯機重做日誌組的明顯需求.這些在備用資料庫節點必須被配置，而且在主節點必須支援新的資料庫替換特性。如下例：
用命令列增加新的備用重做日誌組:
alter database add standby logfile
group 1 '/u01/oradata/SID1/SID1_gl.rdo' size 80M;

Oracle備用伺服器現在能夠執行在4種資料保護模式下：
Guaranteed Protection
(無資料丟失模式、無資料分岐） 可能是最嚴格的模式。主節點的LGWR同步傳送重做流到備用節點。備用節點必須在主節點事務被提交之前表示或確認事務接收。假如LGWR不能傳送，主節點將關閉。效能影響將很嚴重.
log_archive_dest_n='service=standby1 LGWR SYNC AFFIRM'
除此之外，下列命令在主節點也必須被解決，以區別於例項保護模式。
alter database set standby database [un]protected;
Instand Protection
(無資料丟失模式） 除了資料分岐被禁止外，它基本和上一模式相同。假如與備用節點的連結斷開，那麼主要的操作將繼續，並且因此將產生分歧。效能影響將很嚴重.
直到連線被重建且同步時，才可以轉換到備用節點。
log_archive_dest_n='service=standby1 LGWR SYNC AFFIRM'
快速保護
(無資料丟失模式） 主節點的LGWR 非同步地傳送重做日誌流到備用節點。事務會被接收，而不需要等待與備用節點協調一致(無確認）。效能影響不會很嚴重
log_archive_dest_n='service=standby1 LGWR NOSYNC NOAFFIRM'
延遲保護 ARCH以和oracle8i一樣傳送歸檔日誌檔案到備用節點。

正確地說，最後一種模式，即延遲保護模式是一種備用備用資料庫操作的老方式。因為ARCH依賴於已經包含有提交事務的傳送日誌檔案，它不能保證沒有資料的丟失。

資料交換：
在主節點（主節點變成新的備用節點）

- 關閉資料庫 (normal or immediate)
- 檢查所有歸檔日誌已經被傳送到備用節點。
- alter database commit to switchover to physical standby;
- 關閉資料庫(normal or immediate)
- 以nomount 模式啟動
- alter dababase mount standby database;
在備用節點:
- alter database commit to switchover to physical standby;
- shutdown normal;
- startup;

在新的備用節點(以前的主資料庫)
- recover managed standby database parallel n;
- recover managed standby database [disconnect from session];
注意：新的選項'disconnect from session' 能夠產生一個MPR程式來管理恢復。這個版本控制退出到sql*plus(sql*plus已經啟動恢復)

以下是原文
Oracle9i Standby Database (DataGuard) Print This Page

--------------------------------------------------------------------------------

Standby Server (now called Oracle DataGuard)

Significant improvements made to warm standby. A new background process DMON monitors the primary and standby databases and can be configured either by OEM using the new DataGuard Manager tool or through the command line using the new DGMGRL utility. DMON processes run on both primary and standby servers.

There are 2 new terms of reference to learn:

'No data loss mode' is the ability to guarantee recovery of 100% of all committed transactions. This generally means that LGWR, not ARCH is now responsible for transferring the redo stream to the standby server(s).

'No data divergence' is essentially the same as no data loss mode with the added security of guaranteeing that primary and standby databases must be able to be kept in synch. That means that if redo logs cannot be transmitted from Primary to Secondary, then no more redo is allowed to be generated. In fact the primary will be shutdown to prevent this.



One important architecture change is that of the now obvious requirement for standby online redo log groups. These should be configured on the standby node but also on the primary node to support the new database switchover feature (described below). Add new standby redo log groups with the command:

alter database add standby logfile group 1 '/u01/oradata/SID1/SID1_g1.rdo' size 80M;



Oracle standby server can now run in 4 data protection modes as follows:

Guaranteed Protection
(no data loss mode)
(no data divergence) The strictest mode possible. Primary node's LGWR transmits the redo stream synchronously to the standby nodes. Standby node must acknowledge, or affirm receipt of the transaction before it can be committed on Primary. The primary node will shutdown if LGWR cannot transmit. Performance penalties are severe.
log_archive_dest_n = 'service=standby1 LGWR SYNC AFFIRM'

In addtion, the following command is required to be issued on Primary to differentiate this mode from Instant Protection Mode:

alter database set standby database [un]protected;



Instant Protection
(no data loss mode) Behaves exactly the same as Guaranteed Protection with the exception that data divergence is permitted. ie. primary operation can continue and will therefore diverge if the links to the standbys are broken. Performance penalties are still severe.
Switchover to standby is not permitted until contact is re-established and synchronised.

log_archive_dest_n = 'service=standby1 LGWR SYNC AFFIRM'



Rapid Protection
(no data loss mode) Primary node's LGWR transmits the redo stream asynchronously to the standby nodes. No need to wait for acknowledgement from standby node that the transaction has been received (noaffirm). Performance penalties are not so severe.
log_archive_dest_n = 'service=standby1 LGWR NOSYNC NOAFFIRM'



Delayed Protection ARCH transmits archived redo logs to standby node(s) in the same way as it did in Oracle8i.


The last mode there, delayed protection is exactly how the old form of standby database behaved. It cannot guarantee no data loss because ARCH is responsible for transmitting redo logs that already contain committed transactions.



Database switchover

On Primary (primary becomes new standby):

shutdown database normal (not abort)

Check all archive logs have been transmitted to standby node(s)

Check that the primary's online redo logs are intact

alter database commit to switchover to physical standby;

shutdown normal;

startup nomount;

alter database mount standby database;


On Standby (standby becomes new primary)

alter database commit to switchover to physical standby;

shutdown normal;

startup;


On new Standby (previously the primary):

recover managed standby database parallel n;

recover managed standby database [disconnect from session];


Note the new options 'disconnect from session' which spawns an MPR process to managed the recovery. This releases control back to the SQL*Plus session in which the recovery was started.



Automatic Archive Gap Resolution

Set the following init.ora parameters on all standby nodes:

fal_client = standby_n
fal_server = primary

FAL stands for Fetch Archive Log. Each standby server will spawn a background process on the primary node responsible for checking and plugging gaps in archive log sequences by transmitting the relevant files. Monitor this operation by using the new dictionary view V$ARCHIVE_GAP.



Adding a delay to redo application on the standby site

log_archive_dest_n = 'service=sby1 DELAY 30'

Delay time specified in minutes. The default is NODELAY.

http://www.delphibbs.com/keylife/iblog_show.asp?xid=1016