转载：http://blog.itpub.net/35489/viewspace-672422
Data Guard在最大保护和最高可用性模式下，Standby数据库必须配置standby redo log，通过下面的实
验展示创建的原则和过程。
1.原则
1).standby redo log的文件大小与primary 数据库online redo log 文件大小相同
2).standby redo log日志文件组的个数依照下面的原则进行计算
Standby redo log组数公式>=(每个instance日志组个数+1)*instance个数
例如在我的环境中，只有一个节点，这个节点有三组redo，所以
Standby redo log组数公式>=(3+1)*1 == 4
所以需要创建4组Standby redo log
3).每一日志组为了安全起见，可以包含多个成员文件
2.配置过程，正常情况下仅需要在Standby端进行配置，考虑到主备切换，在primary端亦进行配置
1）Standby库添加四组Standby redo log，用户备库的恢复
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10GDG/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10GDG/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10GDG/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10GDG/STANDBYRD04.LOG') size 200M;
Database altered.
2）Primary库添加四组Standby redo log，用于主备切换
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10G/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10G/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10G/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10G/STANDBYRD04.LOG') size 200M;
Database altered.
3.Standby redo log删除方法
sys@ora10g> alter database drop standby logfile group 4;
sys@ora10g> alter database drop standby logfile group 5;
sys@ora10g> alter database drop standby logfile group 6;
sys@ora10g> alter database drop standby logfile group 7;
4.通过V$STANDBY_LOG视图验证standby redo log文件组是否成功创建
sys@ora10g> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
6 0 0 YES UNASSIGNED
7 0 0 YES UNASSIGNED
Question: In Data Guard, why do we need standby redo log files? Should the the primary redo log files be enough?
Answer: A standby redo log resides on the standby database site. The standby redo log file is similar to an online redo log, except that a standby redo log is used to store redo data that has been received from a primary database.
Oracle Data Guard used to have the onerous（严重的） problem of loosing the last redo log. If the primary instanced crashed, the "current" redo log (as written by the LGWR process) would need to be flushed (with a log switch) before the most recent changes could be applied to the standby database. If you could not flush the current redo, data could be lost forever.
Also see these important notes on LNS log transport waits.
Standby Redo Logs
In Oracle 10g and beyond we see an exciting new approach to Data Guard management whereby we write the current redo log to a "standby redo log", allowing complete recovery in cases of catastrophic（灾难性的） instance failure.
Note: The standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby database. This means that the standby redo log has more current information than the log apply mechanism because it took a "shortcut" and was written to the standby, bypassing the traditional archiving and FTP to the standby database.
The Oracle documentation notes three Data Guard Protection Modes. The Maximum protection mode offers redo synchronization:
Maximum Protection?This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode ensures no-data-loss.
Maximum Availability?This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
Maximum Performance?This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database and there is little effect on primary database performance.
Asynchronous redo transmission
We see more about the standby redo log mode in the 10g r2 docs where a new feature called "Asynchronous Redo Transmission" uses a new background process called LNSn:
Asynchronous redo transmission using the log writer process (LGWR ASYNC) has been improved to reduce the performance impact on the primary database. During asynchronous redo transmission, the network server (LNSn) process transmits redo data out of the online redo log files on the primary database and no longer interacts directly with the log writer process.
This change in behavior allows the log writer process to write redo data to the current online redo log file and continue processing the next request without waiting for inter-process communication or network I/O to complete.
