Data Guard 4

4 Managing Physical and Snapshot Standby Databases

4.1 Starting Up and Shutting Down a Physical Standby Database

使用STARTUP命令启动physical standby db，会以read-only模式打开。一旦db处于mount或者open状态，那么physical standby db就会从primary db接收redo数据。

如果primary db处于运行状态，那么在关闭physical standby db前，需要在primary db上defer the standby destination and perform a log switch。

4.2 Opening a Physical Standby Database

4.2.1 Real-time query

使用Oracle Active Data Guard的real-time query特性，那么COMPATIBLE参数必须设置为11.0或者更高。

如果数据库实例处于mount状态，并且，Redo Apply是活跃的，那么此时physical standby db实例就不能open，需要先停掉Redo Apply，然后以只读打开实例，最后重新启动Redo Apply。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE OPEN;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

注意，如果在open的实例上，Redo Apply是活跃的，那么其他的实例不需要停止Redo Apply就能够open；如果一个数据库上面有实例是open状态，那么在此数据库上面处于mount状态的实例不能启动Redo Apply。

4.2.1.1 Monitoring Apply Lag in a Real-time Query Environment

在使用real-time query来分担primary db的压力时，需要监控apply lag，看看延迟是否在可接受的范围内。

The current apply lag is the difference, in elapsed time, between when the last applied change became visible on the standby and when that same change was first visible on the primary. This metric is computed to the nearest second.To obtain the apply lag, query the V$DATAGUARD_STATS view. For example:

SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS -

> WHERE name like 'apply lag';

    NAME         VALUE            DATUM_TIME              TIME_COMPUTED

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

apply lag    +00 00:00:00     05/27/2009 08:54:16     05/27/2009 08:54:17

DATUM_TIME是standby db最后收到redo的时间，TIME_COMPUTED是apply lag计算的时间。这两个值之间的差要少于30秒，如果大于的话，那么apply lag metric就是不准确的。

To obtain a histogram that shows the history of apply lag values since the standby instance was last started, query the V$STANDBY_EVENT_HISTOGRAM view. For example:

SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' - 

> AND COUNT > 0;

NAME             TIME       UNIT         COUNT        LAST_TIME_UPDATED

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

apply lag         0        seconds        79681          06/18/2009 10:05:00

apply lag         1        seconds         1006          06/18/2009 10:03:56

apply lag         2        seconds           96          06/18/2009 09:51:06

apply lag         3        seconds            4          06/18/2009 04:12:32

apply lag         4        seconds            1          06/17/2009 11:43:51

apply lag         5        seconds            1          06/17/2009 11:43:52

6 rows selected

To evaluate the apply lag over a time period, take a snapshot of V$STANDBY_EVENT_HISTOGRAM at the beginning of the time period and compare that snapshot with one taken at the end of the time period.

4.2.1.2 Configuring Apply Lag Tolerance in a Real-time Query Environment

STANDBY_MAX_DATA_DELAY是一个会话参数，以秒为单位，用来指定会话最大容忍的apply lag，可以由非管理员用户在real-time query模式下的physical standby db上发布使用。如果STANDBY_MAX_DATA_DELAY是默认值NONE，那么在执行查询时不管是否有apply lag；如果设置为非零值，那么只要apply lag超过设定值，就会报出ORA-3172错误，当设置为0时，查询会保证准确的返回与主库完全一样的值，若有延迟，则也报出ORA-3172。

SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2;

4.2.1.3 Forcing Redo Apply Synchronization in a Real-time Query Environment

Issue the following SQL statement on a physical standby database to ensure that all redo data received from the primary database has been applied to a physical standby database:

SQL> ALTER SESSION SYNC WITH PRIMARY;

This statement will block until all redo data received by the standby database at the time that this command is issued has been applied to the physical standby database. An ORA-3173 error is returned immediately, and synchronization will not occur, if the redo transport status at the standby database is not SYNCHRONIZED or if Redo Apply is not active.

You can ensure that Redo Apply synchronization occurs in specific cases by using the SYS_CONTEXT('USERENV','DATABASE_ROLE') function to create a standby-only trigger (that is, a trigger that is enabled on the primary but that only takes certain actions if it is running on a standby). For example, you could create the following trigger that would execute the ALTER SESSION SYNC WITH PRIMARY statement for a specific user connection at logon:

CREATE TRIGGER adg_logon_sync_trigger

 AFTER LOGON ON user.schema

  begin

    if (SYS_CONTEXT('USERENV', 'DATABASE_ROLE')  IN ('PHYSICAL STANDBY')) then

      execute immediate 'alter session sync with primary';

    end if;

  end;

4.2.1.4 Real-time Query Restrictions

如果将STANDBY_MAX_DATA_DELAY设置为零或者使用了ALTER SESSION SYNC WITH PRIMARY，那么就要受到下面的限制：

STANDBY DB必须通过SYNC传输redo；

在STANDBY上的redo传输状态必须是SYNCHRONIZED，主库必须运行在最大保护或最高可用模式下；

已开启Real-time Apply；

Active Data Guard achieves high performance of real-time queries in an Oracle RAC environment through the use of cache fusion. This allows the Data Guard apply instance and queries to work out of cache and not be slowed down by disk I/O limitations. A consequence of this is that an unexpected failure of the apply instance leaves buffers in inconsistent states across all the open Oracle RAC instances. To ensure data consistency and integrity, Data Guard closes all the other open instances in the Oracle RAC configuration, and brings them to a mounted state. You must manually reopen the instances - at which time the data is automatically made consistent, followed by restarting redo apply on one of the instances. Note that in a Data Guard broker configuration, the instances are automatically reopened and redo apply is automatically restarted on one of the instances.

4.2.1.5 Automatic Repair of Corrupt Data Blocks

如果在访问primary时遇到了坏块，那么就会从physical standby上将对应的好块复制过去，但是要求：1、physical standby是实时查询模式；2、physical standby是实施应用模式.

还要记住以下几点：

无论哪种保护模式，都支持自动修复，然后修复的效率取决于备库应用主库redo的频率；

当执行了自动块修复后，会向数据库alert写日志；

如果不能进行自动快修复，就会返回ORA-1578错误；

如果备库上出现了坏块，那么只要备库进行了如下配置，服务器也会从主库上取到对应的好块去修复备库的坏块：

The LOG_ARCHIVE_CONFIG parameter is configured with a DG_CONFIG list and a LOG_ARCHIVE_DEST_n parameter is configured for the primary database.

or

The FAL_SERVER parameter is configured and its value contains an Oracle Net service name for the primary database.

--这两条都是废话，备库肯定这么配置了。这样的话，无论主库还是备库出现了坏块，Oracle都会尝试自动修复它们。

4.2.1.6 Manual Repair of Corrupt Data Blocks

RMAN的RECOVER BLOCK就是用来手动修复坏块的。这一命令会搜索一些地方去找未损坏的复制块，默认情况下，搜索的其中一个就是处于实时查询模式下的数据库。指定EXCLUDE STANDBY就会从查找源中排除STANDBY。