高可用之4——Data Guard 配置Standby Redo Log

轉載：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，使用者備庫的恢複

('/oracle/u02/ORA10GDG/STANDBYRD01.LOG') size 200M;

Database altered.

('/oracle/u02/ORA10GDG/STANDBYRD02.LOG') size 200M;

('/oracle/u02/ORA10GDG/STANDBYRD03.LOG') size 200M;

('/oracle/u02/ORA10GDG/STANDBYRD04.LOG') size 200M;

2）Primary庫添加四組Standby redo log，用于主備切換

('/oracle/u02/ORA10G/STANDBYRD01.LOG') size 200M;

('/oracle/u02/ORA10G/STANDBYRD02.LOG') size 200M;

('/oracle/u02/ORA10G/STANDBYRD03.LOG') size 200M;

('/oracle/u02/ORA10G/STANDBYRD04.LOG') size 200M;

3.Standby redo log删除方法

4.通過V$STANDBY_LOG視圖驗證standby redo 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.

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 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.