有两个新的术语需要学习：
无数据丢失模式： 用来保证所有提交事务的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