【翻译自mos文章】Standby Redo Logs (SRL)的用途，益处与限制

时间：2016-02-07 02:25:06 阅读：275 评论：0 收藏：0 [点我收藏+]

标签：

Standby Redo Logs (SRL)的用途，益处与限制

来源于：
Usage, Benefits and Limitations of Standby Redo Logs (SRL) (文档 ID 219344.1)

目的：
本文显示了Standby Redo Logs (SRL)的用途，益处与限制，适用于 Oracle 9i/10g/11g中带有SRL的dataguard环境。

范围：
所有DBA以及希望实施9i/10g/11g (9.x-11.x) DataGuard的人

1. Standby Redo Logs (SRL) ---是什么？在什么时候使用SRL？
从Oracle 9i开始，你有机会为Online Redo Log Groups添加Standby Redo Logs (SRL) Groups。
这些Standby Redo Logs (SRL) 存储了从DG主库接收的信息。
在failover的情况下，有Standby Redo Logs比没有Standby Redo Logs会减少数据损失（data loss）

在Oracle9i时，仅仅Physical standby支持SRL，从10g开始，Physical standby 和 Logical standby均支持SRL。

SRL的最大优势是:主库上每个写入到online redologs的 entry 都会被传输到备库，同时被写入到SRL中。
因此，在备库上减少了数据损失的可能性。

从10g 开始，可以在Physical standby 和 Logical standby 上使用实时应用（Real-Time Apply）
使用Real-Time Apply时，来自SRL的redo被应用到standby database中，在不使用Real-Time Apply时，redo apply一直在等待直到归档日志被建立。
因此，Real-Time Apply 需要SRL.

2. 我该怎么建立SRL？
SRL是额外的Redo Log Groups。如果你在standby database上查询v$logfile，输出类似如下：

   SQL> select * from v$logfile;

   GROUP# STATUS  TYPE    MEMBER
   ------ ------- ------- ------------------------------------
        1          ONLINE C:\ORACLE\ORADATA\STANDBY\REDO01.LOG
        2          ONLINE C:\ORACLE\ORADATA\STANDBY\REDO02.LOG
        3          ONLINE C:\ORACLE\ORADATA\STANDBY\REDO03.LOG

在备库上添加SRL之前，确认一下 the number of maximum Logfile Groups and Logfile Members
如果你没有记住这些值，可以在 CREATE CONTROLFILE的脚本中看到。用下面的命令来得到 CREATE CONTROLFILE脚本：

   SQL> alter database backup controlfile to trace;

上面的命令会在UDUMP目录下建立一个trc文件。

注意下面相关的entry：

    MAXLOGFILES   8
    MAXLOGMEMBERS 3

在这个例子中，你最多可以建立8个logfile groups，每个groups最多可以包括3个member。

现在，我们可以给standby databae添加SRL（当然，standby databaes必须处于mount状态）

   SQL> alter database add standby logfile group 4 ('C:\ORACLE\ORADATA\STANDBY\STBY04.LOG') SIZE 5M;

你可以为一个group添加member：

   SQL> alter database add standby logfile member 'C:\ORACLE\ORADATA\STANDBY\STBY14.LOG' to group 4;

请记住：如果RFS进程写入数据到SRL，SRL的文件大小必须等于主库上的当前的online redo log 的大小。

3. SRL的限制。
在Oracle 9i/10g的DG环境中，standby database上的RFS进程收到来自于Primary database的data，并写入这些data到Disk（要么是SRL，要么是 Archived Redo Logs）

如果你考试使用SRL，你必须确保：这些SRL与online redo log有相同的大小。
如果你有不同大小的online redo log，你不得不建立相关的SRL.
如果SRL与online redo log 不同，RFS进程不会附加到SRL上。
It is recommended to have at least one more of Standby Redo Log Group as you have of Online Redo Log Groups per Thread and Size.

SRL 被填充的内容与在主库上online redo log被写入的内容相同。
因此，只有LGWR进程能提供这个信息给备库上的RFS进程，因此，只有当主库的LOG_ARCHIVE_DEST_n 参数设置LGWR为传输者时，SRL才起作用。
从10.2.0开始，arch进程可以写入到SRL中。

The RFS-Process always tries to allocate the next available Standby RedoLog,
so it is possible that you encounter a Switch between only two Standby RedoLogs,
although you created lots more of them. There‘s no rota defined here like in Online RedoLogs. This is reported in Bug 2722195.

从10.2.0开始，arch进程可以写入到SRL中。

4.使用SRL时，Log Apply Service的不同。
在不使用SRL的情况下，当归档日志完成时，RFS进程创建了归档日志。该归档日志由MRP（Managed Recovery Process）进程应用到备库上。
一个打开的(不是完全写入的)归档日志不能在备库上应用，因而不能在failover情况下使用，这会导致一定的data loss

如果你使用了SRL，RFS进程会往SRL里写入，并且当日志切换时，备库的归档器进程会把SRL归档到归档日志，同时，MRP进程应用这些信息到备库。
在failover时，你将会访问这些已经被写入SRL的信息，因此，这些信息不回丢失。

从10g开始，你可以使用针对 Physical Standby and Logical Standby Apply 来使用Real-Time Apply。
When using Real-Time Apply we directly apply Redo Data from Standby RedoLogs.
如果不使用SRL，Real-Time Apply不能应用部分填充的归档日志来应用redo，因此，对 Real-Time Apply而言，SRL是被强制要求的。

注意：在12c中，默认的MRP会变为 Real-Time Apply 模式。

Default Standby recovery in REAL time apply.
SQL>alter database recover managed standby database disconnect;
To Start MRP in non real time apply mode use,(in 12c)
SQL>alter database recover managed standby database using archived logfile disconnect;

5. Standby RedoLogs and the Data Guard Broker
---------------------------------------------

If there is an active Data Guard Broker Configuration on this Data Guard Environment the following Error can be raised in the Data Guard Broker Configuration if the setup Transport Method (LogXptMode) is ‘SYNC‘ or ‘ASYNC‘
and there are no Standby RedoLogs configured:

Warning: ORA-16809: multiple warnings detected for the database

In the corresponding DRC.LOG-Files and the Database Status you can find:

ORA-16789: standby redo logs not configured

-> So please add corresponding Standby RedoLogs to the Standby Database. As per default the Data Guard Broker tries to start Log Apply Services in Real-Time Apply Mode which is not possible without Standby RedoLogs.Note that starting with Oracle 11g ARCH Log Transport Method is deprecated.