如何使用实时查询访问物理备库上的数据-之路教程

配置主备库零延迟

某些应用程序对任何延迟都零容忍。
对备用数据库的查询必须返回与在主数据库上执行的查询相同的结果。
通过将 STANDBY_MAX_DATA_DELAY 设置为 0，我们可以确保在备用数据库上查询数据的应用程序看到已在主数据库上提交的所有数据。

查询不会执行，直到备用数据库上的查询 SCN 的值与发出查询时主数据库上的当前 SCN 的值相等。
为了支持零延迟，主数据库必须在最大可用性或者最大保护模式下运行。
本类稍后将讨论保护模式。

为重做传输模式指定 SYNC。
必须启用实时查询作为配置零延迟的准备工作。

如何使用实时查询访问物理备库上的数据

优点：临时撤销和序列

在 Oracle Database 12c 第 1 版 (12.1) 之前，无法为 Active Data Guard 使用全局临时表和序列限制了一些以读取为主的应用程序从主数据库卸载到备用数据库。

对 Active Data Guard 的新临时撤消和序列支持提供了许多好处。
现在可以将另外的报告工作负载迁移到备用系统，以减少系统资源的总体开销。
由于临时撤消减少了生成的重做量，因此减少了需要传送到备用数据库系统的重做量，从而提高了网络性能。
重做的减少还意味着写入备用重做日志和备用重做日志的本地归档更少的重做。
因此，在主备数据库系统以及两个系统之间的网络上实现了性能改进。

示例：使用 AFTER LOGON 触发器设置 STANDBY_MAX_DATA_DELAY

下面的示例显示了一个 AFTER LOGON 触发器，用于根据数据库角色设置 STANDBY_MAX_DATA_DELAY 的值。

CREATE OR REPLACE TRIGGER sla_logon_trigger
  AFTER LOGON
  ON APP.SCHEMA
BEGIN
  IF (SYS_CONTEXT('USERENV', 'DATABASE_ROLE')
      IN ('PHYSICAL STANDBY'))
  THEN execute immediate
    'alter session set standby_max_data_delay=5';
  ENDIF;
END;

禁用实时查询

要禁用实时查询，我们必须关闭备用数据库实例并在 MOUNT 模式下重新启动它。

关闭备用数据库实例。

SQL> SHUTDOWN IMMEDIATE;

2、以MOUNT方式重启备库实例。

SQL> STARTUP MOUNT;

3、重启Redo Apply服务（实时应用）。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

检查备用机的打开模式

我们可以使用 V$DATABASE 的 OPEN_MODE 列来检查物理备用数据库的打开模式。
如果物理备用数据库为了以只读模式打开数据库而停止重做应用，则 OPEN_MODE 列将指示“只读”。

以只读模式打开的物理备用数据库：

SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
-------------------
READ ONLY

一个以实时查询方式打开的物理备库：

SQL> SELECT open mode FROM V$DATABASE; _
OPEN_MODE
-------------------
READ ONLY WITH APPLY

数据库以只读方式打开后，可以使用以下命令重新启动重做应用以启用 Active Data Guard 实时查询模式：

SQL> alter database recover managed standby database disconnect;

在打开的只读物理备用数据库上启动重做应用后，OPEN_MODE 列将指示“READ ONLY WITH APPLY”。

为同步创建登录后触发器

当我们使用备用数据库进行报告并希望确保报告具有最新数据时，这种类型的触发器非常有用。
仅备用 AFTER LOGON 触发器执行 ALTER SESSION SYNC WITH PRIMARY 命令以强制等待主数据库和备用数据库之间的同步。
在主数据库上创建和启用备用触发器，然后成为传播到备用数据库的重做的一部分。
但是，触发器逻辑仅用于在数据库角色设置为“物理备用”时执行某些操作。

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;

监控应用滞后：V$STANDBY 事件直方图

V$STANDBY_EVENT_HISTOGRAM 是备用数据库上可用的新视图。
此视图显示物理备用数据库上应用滞后的直方图。

使用直方图关注应用滞后超过所需水平的时间段。
确定这些时间段内滞后的原因，并采取措施解决过度滞后。
要评估一段时间内的应用延迟，请在该时间段开始时拍摄 V$STANDBY_EVENT_HISTOGRAM 的快照，并将该快照与该时间段结束时拍摄的快照进行比较。

SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM
2> 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

应用滞后的每个不同值都有自己的桶。
当物理备用数据库对其数据延迟进行采样时，存储桶中的计数会增加。

强制重做应用同步

我们可以执行 ALTER SESSION SYNC WITH PRIMARY 命令以确保备用数据库在执行时与主数据库完全同步。
此命令的使用特别适用于报告环境。

ALTER SESSION SYNC WITH PRIMARY 在执行时对备用数据库执行阻塞等待。
此命令会导致应用程序被阻塞，直到执行此命令时备用数据库与主数据库同步。

当 ALTER SESSION 命令将控制权返回给会话时，会话可以继续处理查询，而无需等待备用数据库上的重做应用。
如果重做应用未处于活动状态或者在备用数据库与主数据库同步之前被取消，则会返回 ORA-3173 Standby may not be synced with primary 错误。

示例：透明地将写入重定向到主数据库

考虑如下所述的应用程序：

应用程序作为用户 U 执行，读取 U.R 表并写入 U.W 表。
应用程序在主数据库上执行时以用户 U 身份连接。
用户 S 使用 S.R 同义词访问 U.R，使用 S.W 同义词访问 U.W。

在备用数据库上创建一个 AFTER LOGON 触发器：

CREATE TRIGGER adg_logon_switch_schema_trigger
  AFTER LOGON ON u.schema
  BEGIN
    IF (SYS CONTEXT('USERENV' 'DATABASE ROLE') IF (SYS_CONTEXT('USERENV','DATABASE_ROLE')
        IN ('PHYSICAL STANDBY'))
    THEN
      execute immediate
        'alter session set current_schema = S';
    END IF;
  END;

AFTER LOGON 触发器是在备用数据库上为另一个用户 R 创建的。
当应用程序在备用数据库上执行时，它作为 U 用户连接。
AFTER LOGON 触发器触发并透明地切换到 S 模式。
R 上的所有读取都作为对备用数据库上的 U.R 表的读取执行。
对 W 的所有读取和写入都作为对 U.W@primary 的读取和写入执行。

Active Data Guard：临时表上的 DML

不允许在只读数据库上生成重做。
当数据操作语言 (DML) 操作对全局临时表进行更改时，更改本身不会生成重做，因为它只是一个临时表。
但是，为更改生成的撤消会反过来生成重做。
在 Oracle Database 12c 第 1 版 (12.1) 之前，无法在只读的 Active Data Guard 备用数据库上使用全局临时表。

但是，在 Oracle Database 12c 第 1 版 (12.1) 中，临时撤消功能允许将全局临时表的更改撤消存储在临时表空间而不是撤消表空间中。
存储在临时表空间中的撤消不会生成重做，因此可以对全局临时表进行无重做更改。
这允许对 Oracle Active Data Guard 备用数据库上的全局临时表和 Oracle Active Data Guard 备用数据库的全局临时表进行 DML 操作。

要在主数据库上启用临时撤消，请使用 TEMP_UNDO_ENABLED 初始化参数。
在 Active Data Guard 备用数据库上，默认情况下始终启用临时撤消，因此 TEMP_UNDO_ENABLED 参数无效。

TEMP_UNDO_ENABLED = false | true

临时撤消功能要求将数据库初始化参数 COMPATIBLE 设置为 12.0.0 或者更高版本。
Active Data Guard 实例上的临时撤消功能不支持临时二进制和字符大对象。

启用实时查询

如果重做应用在该数据库的已安装实例上处于活动状态，则无法打开物理备用数据库实例。
为了启用实时查询：

停止重做应用过程：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2.打开数据库进行只读访问：

SQL> ALTER DATABASE OPEN READ ONLY;

使用实时选项重新启动重做应用，该选项现在是 Oracle Database 12c 第 1 版的默认模式：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

COMPATIBLE 数据库初始化参数必须设置为 11.0 或者更高版本才能使用 Oracle Active Data Guard 选项的实时查询功能。

注意：使用 Oracle Data Guard broker 时不需要停止 Redo Apply；使用 Oracle Data Guard broker 时，启用实时查询时不需要停止 Redo Apply 并重新启动 Redo Apply。
实时查询与实时应用不同，后者在上一课中有介绍。
实时应用允许恢复机制在将重做写入备用重做日志的同时从备用重做日志中读取。
在正常的物理备用操作模式下，数据库仅处于挂载模式并且不允许对用户表进行任何查询，即使启用了实时应用。
使用 Oracle Active Data Guard 的实时查询扩展了实时应用，允许打开数据库并对其执行查询，允许打开数据库并对其执行查询。

https://onitroad.com 更多教程

使用登录后触发器设置 STANDBY_MAX_DATA_DELAY

创建一个可识别数据库角色并使用 DATABASE_ROLE（USERENV 上下文中的新属性）的 AFTER LOGON 触发器。
SQL 和 PL/SQL 客户端可以使用 SYS_CONTEXT 函数以编程方式检索数据库角色。
它还应该使我们能够编写特定于角色的触发器。

它应该设置 STANDBY_MAX_DATA_DELAY 当应用程序登录到启用实时查询时间查询的备用数据库的真实登录时，并允许在不更改应用程序源代码的情况下配置最大数据延迟。

当数据库是在实时查询模式下运行的物理备用数据库时，我们可以创建一个 AFTER LOGON 触发器来设置 STANDBY_MAX_DATA_DELAY 会话参数。
在 Oracle Database 12c 第 1 版 (12.1) 中，USERENV 上下文的 DATABASE_ROLE 属性使我们能够确定数据库的角色。
SQL 和 PL/SQL 客户端可以使用 SYS_CONTEXT 函数检索此信息。
这使我们能够编写基于数据库角色执行某些操作的触发器。

Active Data Guard：支持全局序列

要使用 Active Data Guard 支持以读取为主的应用程序，我们可能必须使用具有全局临时表的序列。
在 Active Data Guard 环境中，主数据库使用默认 CACHE 和 NOORDER 选项创建的序列也可以从备用数据库访问。
当备用数据库第一次访问这样的序列时，它请求主数据库分配一个序列号范围。
该范围基于创建序列时指定的缓存大小和其他序列属性。
然后主数据库通过调整数据字典中相应的序列条目将这些序列号分配给请求的备用数据库。
当备用数据库使用了该范围内的所有号码时，它会请求另一个号码范围。

由于备用数据库对一系列序列的请求涉及到主数据库的往返，因此在为 Active Data Guard 备用数据库创建序列时，请确保为 CACHE 关键字指定足够大的值。
否则，性能可能会受到影响。
此外，终端备用数据库应该有一个已定义的 LOG_ARCHIVE_DEST_n 参数，该参数指向主数据库。

Oracle Active Data Guard

无论在何处使用 Data Guard 进行实时数据保护和可用性，Oracle Active Data Guard 都可以提高性能、可用性、数据保护和投资回报。
Oracle Active Data Guard 备用数据库可用于卸载主数据库的报告、即席查询、数据提取和备份，使其成为将生产系统上的交互式用户和关键业务任务与长时间运行的操作。
Oracle Active Data Guard 在与主数据库同步的同时提供对物理备用数据库的只读访问，从而实现报告和生产数据之间的最小延迟。
与其他复制方法不同，Active Data Guard 使用起来非常简单，透明地支持所有数据类型，并提供非常高的性能和报告数据库的完全读取一致性。
Oracle Active Data Guard 自动修复主数据库或者备用数据库上的物理损坏，从而提高可用性并始终保持数据保护。

Oracle Active Data Guard 12c 减少了 Oracle 数据库升级和其他数据库维护的停机时间，同时避免了容易出错的手动过程。
Oracle Active Data Guard 12c 远程同步支持跨任何距离的零数据丢失灾难保护 (DR)，而不会影响数据库性能。
Oracle Active Data Guard 12c 还包括全局数据服务，将自动服务故障转移和工作负载管理的概念扩展到全球分布式系统，以及应用程序连续性，以在不使用 Oracle Real Application Cluster 的 Data Guard 配置中提供动态事务的透明故障转移（Oracle RAC）。

了解 Active Data Guard 配置中的滞后

Active Data Guard 可以通过将只读工作负载卸载到物理备用数据库来提高性能。
但是，由于硬件和网络问题，备用数据库上的数据可能滞后于主数据库上的数据。
如果备用数据库没有能力在收到重做时尽快应用重做，则备用数据库可能并不总是与主数据库保持同步。
有限的带宽可能会阻止主数据库在重做生成时尽快传送，尤其是在工作负载高峰期。

Oracle Database 12c 第 1 版 (12.1) 包含使我们能够确定滞后时间并采取适当措施的特性。
我们可以通过配置应用滞后的最大值来建立数据陈旧的容限级别。
如果滞后在可接受的容限范围内，则将查询结果返回给应用程序；否则，将导致错误。

如果我们确定我们希望应用程序接收查询结果，而不管数据是否“陈旧”，我们可以通过 V$DATAGUARD_STATS 视图监控应用延迟，然后在延迟不可接受时采取适当的措施。

备用查询数据的允许陈旧性

我们可以通过使用 STANDBY_MAX_DATA_DELAY 会话参数来配置限制。
使用此会话参数指定在主数据库上提交更改和可以在活动备用数据库上查询这些相同更改之间允许经过的时间量（以秒为单位）的限制。

ALTER SESSION SET STANDBY_MAX_DATA_DELAY = {INTEGER|NONE}

如果无法满足指定的限制，则会向查询返回错误，如下所示：

ORA-3172 STANDBY_MAX_DATA_DELAY has been exceeded

这保证了如果应用延迟超过服务水平协议，查询将不会收到“陈旧的结果”。
此外，还会向备用数据库警报日志写入一条警告消息。
SYS 用户将忽略此设置。

默认值为 NONE，这表示将执行发出到物理备用数据库的查询，而不管该数据库上的应用延迟如何。

支持以读取为主的应用程序

主要为只读但需要有限读写数据库访问权限的报告应用程序被称为“以读取为主”的应用程序。
如果写入被重定向到主数据库或者本地数据库，则 Active Data Guard 使备用数据库能够支持主要读取应用程序的只读部分。

以读取为主的应用程序主要是只读应用程序，但需要有限的读写数据库访问权限。
如果写入被重定向到主数据库或者本地数据库，则 Active Data Guard 支持只读应用程序的只读部分。
读写工作负载的重定向不需要更改应用程序代码。
写入可以透明地重定向到主数据库如果应用程序符合以下条件，写入可以透明地重定向到主数据库：
修改后的对象不得由架构名称限定。
SQL 命令必须直接从客户端发出，而不是在存储过程中发出。

Active Data Guard：支持会话序列。

会话序列是一种特殊类型的序列，专门设计用于具有会话可见性的全局临时表。
与现有的常规序列（为了比较，称为“全局”序列）不同，会话序列仅在会话内返回唯一范围的序列号，而不是跨会话返回。
会话序列不是持久的。
如果会话消失，会话期间访问的会话序列的状态也会消失。

会话序列支持在定义序列时指定的大多数序列属性。
但是，CACHE/NOCACHE 和 ORDER/NOORDER 选项与它们无关并被忽略。
会话序列必须由读写数据库创建，但它们可以在任何读写或者只读数据库（临时打开为只读或者备用数据库的常规数据库）上访问。

创建会话序列：

SQL> CREATE SEQUENCE ... SESSION;

监控应用延迟：V$DATAGUARD_STATS

应用滞后是衡量备用数据库落后于主数据库的程度，原因是传播和应用重做到备用数据库的延迟。
当前应用延迟是上次应用更改在备用服务器上可见与同一更改在主服务器上首次可见之间的经过时间差。
该指标计算到最接近的秒。

应用滞后指标是使用定期从主数据库接收的数据计算的。
DATUM_TIME 列包含备用数据库上次接收此数据的时间戳。
TIME_COMPUTED 列包含计算应用滞后指标时采用的时间戳。
这些列中的值之间的差异应小于 30 秒如果差异大于此值，则列应小于 30 秒。
如果差异大于此值，则应用滞后指标可能不准确。

SQL> SELECT name, value, datum_time, time_computed
2> FROM v$dataguard_stats
3> WHERE name like 3> WHERE name like 'apply lag apply lag ;'
NAME        VALUE          DATUM_TIME             TIME_COMPUTED
---------   -------------  --------------------   -------------------
apply lag   +00 00:00:00   27-MAY-2009 08:54:16   27-MAY-2009 08:54:17

使用实时查询

使用 Oracle Active Data Guard，我们可以使用物理备用数据库进行查询，同时将重做应用于物理备用数据库。
此功能使我们能够使用物理备用数据库进行灾难恢复，并在正常操作期间从主数据库卸载工作。
物理备用数据库处于只读模式，因此不会创建另外的索引或者物化视图来支持报告活动。

注意：如果我们需要创建另外的结构（例如索引和物化视图），我们可以创建一个逻辑备用数据库。

此外，此功能在配置如下时为 OLTP 工作负载提供了松散耦合的读/写集群机制：

主数据库：所有更新流量的接收者
几个可读的备用数据库：用于分配查询工作负载

仅当所有文件都恢复到相同的系统更改号 (SCN) 时，才能以只读模式打开物理备用数据库。
否则，打开失败。

日期：2020-09-17 00:11:49 来源：oir作者：oir

←如何将数据文件移动到物理备用数据库上的不同位置

Oracle如何查看归档重做日志的信息？→