设置 DelayMins 数据库属性延迟重做的应用

使用 DelayMins 可配置数据库属性指定日志应用服务在将重做数据应用到备用数据库之前必须等待的分钟数。
此设置传播到 LOG_ARCHIVE_DEST_n 初始化参数的 DELAY 属性。

DGMGRL> EDIT DATABASE 'london' SET PROPERTY 'DelayMins'=5;

Broker 默认：0（表示应用服务尽快应用重做数据）

在这篇文章中，我们将看到如何监控数据保护的配置性能以及优化 SQL 应用和重做传输以获得最佳性能。

优化 SQL 应用

可以修改 MAX_SERVERS、APPLY_SERVERS 和 PREPARE_SERVERS 参数以控制分配给 SQL 应用的进程数。
由于 SQL Apply 为 READER、BUILDER 和 ANALYZER 角色分配了一个进程，因此需要三个参数之间的关系如下：

APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS – 3

这里，

• APPLY_SERVERS：用于应用更改的 APPLIER 进程数
• MAX_SERVERS：SQL Apply 用来读取和应用重做的进程数
• PREPARE_SERVERS：用于准备更改的 PREPARER 进程数

使用 DBMS_LOGSTDBY.APPLY_SET 过程更改 APPLY_SERVERS、MAX_SERVERS 和 PREPARE_SERVERS 参数。
查询 DBA_LOGSTDBY_PARAMETERS 以查看 SQL 应用参数设置。

注意：有关 DBMS_LOGSTDBY.APPLY_SET 过程的详细信息，请参阅 Oracle 数据库 PL/SQL 包和类型参考 Oracle 数据库 PL/SQL 包和类型参考。

调整APPLIER进程的数量

在更改 APPLIER 进程数之前，请执行以下步骤以确定调整 APPLIER 进程数是否有助于我们获得更大的吞吐量：

1. 通过发出以下查询来确定 APPLIER 进程是否繁忙：

SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;

2. 确保没有空闲的 APPLIER 进程后，通过发出以下查询来确定是否有足够的工作可用于其他 APPLIER 进程：

SELECT NAME, $ VALUE FROM V$LOGSTDBY STATS
WHERE NAME LIKE 'transactions%';

第二个查询返回两个提供累积总数的统计信息：APPLIER 进程准备应用的事务数和已经应用的事务数。
如果“dig的交易”和“应用的交易”之间的差异大于可用 APPLIER 进程数量的两倍，则如果增加 APPLIER 进程的数量，则可能会提高吞吐量。

在增加 APPLIER 进程的数量之前，请考虑以下要求：

APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS – 3

通过设置 MaxConnections 优化重做传输

重做传输机制允许多个归档进程并行传输单个大型重做日志文件，从而使用所有可用带宽。
此行为由 MaxConnections 数据库属性控制。

这种架构提高了重做传输率，并能够更快地将重做传输到备用数据库，以便在主数据库上进行批量批量更新。
由于传输速率的提高，备用数据库站点的数据可用性增加。

通过设置 RedoCompression 属性压缩重做数据

当到远程数据库的通信网络是高延迟、低带宽的 WAN 链接并且传输到备用数据库的重做数据大量时，我们希望最有效地利用网络带宽。
可以在任何远程目标上为所有重做传输方法启用重做传输压缩，以减少网络带宽使用。

可以通过设置 Oracle Data Guard 代理的 RedoCompression 属性来启用或者禁用重做压缩。
该设置传播到 LOG_ARCHIVE_DEST_n 初始化参数的 COMPRESSION 属性。
默认情况下禁用重做压缩。

当我们将数据库添加到 Data Guard 配置时，Data Guard 代理会自动检测是否为正在添加的备用数据库启用或者禁用网络压缩。
属性被相应地设置。

注意：使用此功能需要 Oracle Advanced Compression 选件。

概括

这可以为所有重做传输方法（ASYNC 和 SYNC）启用。

该设置将传播到 LOG ARCHIVE DEST _ __n 初始化参数的 COMPRESSION 属性。

通过查询 V$ARCHIVE_DEST 视图的 COMPRESSION 列来确定是否启用重做压缩。

使用 DGMGRL 启用：

DGMGRL> EDIT DATABASE 'london' SET PROPERTY 'RedoCompression'='ENABLE';

使用 SQL 启用：

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 = 'SERVICE=london SYNC COMPRESSION=ENABLE';

设置 NetTimeout 数据库属性

当我们为 NetTimeout 数据库属性指定一个值时，它会传播到主数据库或者远程同步的 LOG_ARCHIVE_DEST_n 初始化参数的 NET_TIMEOUT 属性。
NET_TIMEOUT 属性使我们能够绕过为主数据库所在的系统建立的默认网络超时间隔。
如果没有 NET_TIMEOUT 属性，主数据库可能会在默认网络超时期限内停滞。
通过为 NET_TIMEOUT 指定一个较小的非零值，我们可以使主数据库在用户指定的超时间隔到期后将目标标记为“失败”。

概括

• 此属性指定日志写入器进程 (LGWR) 等待 Oracle 网络服务响应请求的秒数。
• 经纪人默认值：30
• 该设置传播到发送实例的 LOG_ARCHIVE_DEST_n 初始化参数的 NET_TIMEOUT 属性。

DGMGRL> EDIT DATABASE 'london' SET PROPERTY 'NetTimeout'=20;

注意：在最大保护模式下运行时，请记住指定一个合理的值。
如果没有其他处于正确模式的备用数据库可供主数据库实例联系，则错误的网络故障检测可能会导致主实例关闭。

优化重做传输服务

使用以下技术优化重做传输：

• 使用多个归档进程优化异步重做传输
• 压缩重做数据

以下各节提供了有关这些技术的信息。

延迟重做的应用

我们可以延迟对备用数据库应用更改，从而防止用户错误和损坏。
我们可以防止将损坏或者错误的数据应用到备用数据库。
应用过程还会重新验证日志记录以防止应用日志损坏。

例如，如果从主数据库中意外删除了一个关键表，我们可以通过延迟在备用数据库中应用更改来防止此操作影响备用数据库。

在最大保护或者最大可用性模式下运行时，即使延迟应用生效，Data Guard 也能确保零数据丢失。
如果我们为启用了实时应用的目标定义延迟，则该延迟将被忽略。

注意：我们可以使用闪回数据库作为应用延迟配置选项的替代方案。
使用闪回数据库是 Oracle 最佳实践。

使用 Enterprise Manager Cloud Control 监控配置性能

“性能概览”页面上的图形图表：

• 重做生成率：显示主数据库上的重做生成率（以 KB 每秒为单位）。
• 应用速率：显示备用数据库上的应用速率（以每秒 KB 为单位）。 “活动时应用率”统计数据表示最近三个日志文件的平均实际应用率。
• 滞后时间：显示传输滞后和应用滞后。传输延迟是备用数据库上尚不可用的大约重做量（以秒为单位）。应用滞后是备用数据库落后于主数据库的大约秒数

在 Performance Overview 页面上，我们可以调用测试应用程序以在主数据库上生成工作负载。
这提供了一种在主数据库在负载下运行时查看性能指标的方法。

使用企业管理器延迟重做应用

• 在 Data Guard 页面上，选择备用数据库并单击 Edit。
• 在“编辑备用数据库属性”页面上，单击“备用角色属性”。
• 在应用延迟字段中输入延迟值（以分钟为单位）
• 单击应用。

调整 PREPARER 进程的数量

在极少数情况下，我们可能需要调整 PREPARER 进程的数量。
在增加 PREPARER 进程的数量之前，请验证以下条件是否为真：

• 所有 PREPARER 进程都处于忙碌状态。
• 准备应用的事务数少于可用的 APPLIER 进程数。
• 有空闲的 APPLIER 进程。

执行以下查询以验证上述条件：

1、判断是否所有PREPARER进程都忙：

SELECT COUNT(*) A SELECT COUNT(*) AS IDLE_PREPARER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'PREPARER' and status_code = 16166;

2、判断准备申请的事务数是否小于APPLIER进程数：

SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'transactions%';
SELECT COUNT(*) AS APPLIER_COUNT
FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';

3、判断是否有空闲的APPLIER进程：

SELECT COUNT(*) AS IDLE_APPLIER
FROM V$LOGSTDBY PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;

在增加 PREPARER 进程的数量之前，请考虑以下要求：

APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS – 3

在增加 PREPARE_SERVERS 的值之前，我们可能需要增加 MAX_SERVERS 的值。
使用 DBMS_LOGSTDBY.APPLY_SET 过程增加 MAX_SERVERS 和 PREPARE_SERVERS 的值，如以下示例所示：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);

设置 ReopenSecs 数据库属性

当我们为 ReopenSecs 数据库属性指定一个值时，它会传播到发送实例的 LOG_ARCHIVE_DEST_n 初始化参数的 REOPEN 属性。
发送实例可以是主数据库实例或者远程同步实例。

LOG_ARCHIVE_DEST_n 参数的 REOPEN 属性指定传送重做的进程应再次尝试访问以前失败的目标之前的最小秒数。

REOPEN 适用于所有错误，而不仅仅是连接失败。
这些错误包括（但不限于）网络故障、磁盘错误和配额异常。

概括

• 此属性指定存档程序进程尝试访问以前失败的目标之前的最小秒数。
• 经纪人默认值：300
• 为备用数据库或者远程同步实例设置。
• 该设置传播到 LOG_ARCHIVE_DEST_n 初始化参数的 REOPEN 属性
  发送实例。

DGMGRL> EDIT DATABASE 'london' SET PROPERTY 'ReopenSecs'=600;

设置 MaxConnections 数据库属性

为 MaxConnections 数据库属性指定值时，它会传播到主数据库或者远程同步实例的 LOG_ARCHIVE_DEST_n 初始化参数的 MAX_CONNECTIONS 属性。
LOG_ARCHIVE_DEST_n 的 MAX_CONNECTIONS 属性用于设置用于将归档重做日志文件传输到远程目标的并行连接数。
MAX_CONNECTIONS 属性默认为 1，表示为数据的通信和传输建立了单个连接。
MAX_CONNECTIONS 的最大值为 20。

DGMGRL> EDIT DATABASE 'london' SET PROPERTY 'MaxConnections'= 15;

注意：我们必须将LOG_ARCHIVE_MAX_PROCESSES 初始化参数设置为大于或者等于MAX_CONNECTIONS 的值才能达到所需的并行连接数如果并行连接的值。
如果 MAX CONNECTIONS MAX_CONNECTIONS 属性的值超过 LOG_ARCHIVE_MAX_PROCESSES 的值，Data Guard 将使用可用的归档程序进程。