best practices for synchronous redo transport - data guard ... · 测试 2：oltp...

同步重做传输最佳实践

Data Guard 和 Active Data Guard

ORACLE 白皮书 | 2 0 1 5 年 3 月


目录引言 1

Data Guard 同步传输概述 2

同步传输性能 3

同步传输增强 4

Oracle Database 11g 第 2 版 4

Oracle Database 12c 5

配置最佳实践 5

将 TCP 套接字缓冲区大小设置为 BDP 的 3 倍 5

配置备用重做日志 7

将 SDU 大小设置为 65535 7

配置充足的资源以获得最佳系统性能 8

使用快速同步 — SYNC NOAFFIRM 8

考虑部署 Exadata 以提高零数据丢失配置中的性能 8

调优 8

了解同步传输如何确保数据完整性 12

评估性能 13

如何评估 Oracle Database 11.2 中同步传输的性能 16

如何评估 Oracle Database 12c 中同步传输的性能 17

诊断长时间日志文件同步等待 18

Data Guard 快速同步 20

总结 21

1 | 同步重做传输最佳实践

引言

通过 Oracle Data Guard 实施 Oracle 最高可用性架构 (MAA) 为避免任务关键型 Oracle 数据库发生单

点故障提供了现有最全面的解决方案。该解决方案能够在远程位置维护生产数据库的一个或多个同步物

理副本，从而以最简单和最经济的方式防止数据丢失和停机。如果生产数据库由于任何原因不能提供服

务，客户端连接可以迅速地（在某些配置中可以透明地）故障切换至某个同步副本以立即恢复服务。

Active Data Guard 扩展了 Data Guard 的基本功能，它支持将报告应用程序、即席查询、数据提取和

快速增量备份分流到生产数据库的只读副本，从而消除高昂的闲置冗余成本。Active Data Guard 完全

专注于实时数据保护和可用性，并且与 Oracle 数据库深度集成，从而避免了存储远程镜像或其他基于

主机的复制解决方案中存在的对数据保护、性能、可用性和复杂性的不利影响。

Data Guard 和 Active Data Guard 是唯一具有 Oracle 感知能力的复制解决方案，能够确保在丝毫不丢

失数据的情况下故障切换至生产数据库的一个已在运行中的同步副本。Active Data Guard 12c 中的新

功能扩展了零数据丢失保护功能，它们使用距生产数据库任意距离的同步副本，同时不会影响生产数据

库性能，也不会增加故障切换操作的复杂性。这可以同时提供 Oracle 数据库高可用性和数据保护，以

防范数据库、集群、站点、区域性或地理性中断。

本文提供在 Data Guard 或 Active Data Guard 配置中使用同步重做传输的 Oracle MAA 最佳实践。本

文面向具备在 Data Guard 和 Active Data Guard 配置环境中使用最高可用性或最大保护模式的工作经

验的数据库管理员。在这些模式下，同步重做传输与 Data Guard 受管恢复进程 (MRP) 相集成，可在

生产数据库发生意外中断时确保零数据丢失。

.


Data Guard 同步传输概述

Data Guard 配置包含一个生产数据库（也称为主数据库），以及最多 30 个直接连接副本（也称为备用数据库）。主数

据库和备用数据库使用 Oracle Net Services 通过 TCP/IP 相互连接。数据库所处的物理位置并不存在限制，只要这些数

据库彼此能够通信即可。最初，通过主数据库的一个备份创建备用数据库。Data Guard 通过传输主数据库重做（每个

Oracle 数据库用于保护事务的信息）并将其应用到备用数据库，来自动同步主数据库及所有备用数据库。

Data Guard 传输服务处理从主数据库到备用数据库传输重做的方方面面。当用户在主数据库中提交事务时，系统会

生成重做记录并将其写入本地联机日志文件。与此同时，Data Guard 传输服务会直接从主数据库日志缓冲区（系统

全局区域中分配的内存）将相同的重做传输到所有备用数据库，在备用数据库处将其写入备用重做日志文件。Data

Guard 传输非常高效，其原因是：

» Data Guard 直接从内存进行传输，不会在主数据库上产生磁盘 I/O 开销。这与许多其他基于主机的复制解决方案

不同，这些方案需要从磁盘读取数据，然后再传输这些更改，因此会增加主数据库上的 I/O 开销。

» Data Guard 只传输数据库重做。这与存储远程镜像形成了鲜明对比，存储远程镜像必须传输每个文件中所有更改

的块，以便保持实时同步。Oracle 测试显示，存储远程镜像最多传输超过 Data Guard 7 倍的网络流量以及 27 倍

的网络 I/O 操作。与存储远程镜像解决方案相比，Data Guard 具有许多优势，有关这些优势的更全面的讨论，请

参阅 Oracle Active Data Guard 与存储远程镜像。1

Data Guard 提供两种传输服务模式：同步和异步。同步重做传输（本文讨论的主题）需要主数据库等待备用数据库

确认已收到重做并写入磁盘（备用重做日志文件），然后再向应用程序发送提交成功通知。同步传输与 Data Guard

应用服务对事务语义的深入理解相结合，可在主数据库突发故障时提供可靠的零数据丢失保护。

Data Guard 还提供三种不同的工作模式以帮助用户在成本、可用性、性能和数据保护之间取得平衡，如表 1 所示。每

种模式定义了当主数据库失去与备用数据库的联系时 Data Guard 配置的行为。三种模式中有两种模式使用同步传输。

表 1：DATA GUARD 保护模式

模式数据丢失风险传输如果未收到备用数据库的确认，则：

最大保护零数据丢失

双重故障保护

同步仅当从备用数据库收到已将事务的重做硬化到磁盘的确认后，才向应用程

序发送提交成功信号。在收到确认之前，生产数据库不会继续执行操作。

最高可用性零数据丢失

单重故障保护

同步

快速同步

远程同步

仅当收到备用数据库的确认后，或超出 NET_TIMEOUT 阈值期限后，才

向应用程序发送提交成功信号，两者取其先。网络中断或备用数据库中断

不会影响生产数据库的可用性。

最高性能可能有极小的数

据丢失风险

异步主数据库从不等待备用数据库的确认，而是直接向应用程序发送提交成功

信号。不能确保零数据丢失。

1 http://www.oracle.com/technetwork/database/availability/dataguardvsstoragemirroring-2082185.pdf

http://www.oracle.com/technetwork/database/availability/dataguardvsstoragemirroring-2082185.pdf

http://www.oracle.com/technetwork/database/availability/dataguardvsstoragemirroring-2082185.pdf


同步传输性能

与基于存储远程镜像的同步解决方案相比，Data Guard 还具有许多性能优势。回忆一下，我们前面讲过 Data

Guard 只传输重做。相反，存储远程镜像必须传输对每个数据块的每个更改，才能保持和 Data Guard 同样的实时

保护。这意味着，存储远程镜像除了传输 Data Guard 要传输的数据量之外，还要传输对以下目标的所有写入：数

据文件、联机日志文件组的其他成员、归档日志文件、控制文件、闪回日志文件等等。因而影响很大。举例来说，

用于写入数据文件的 Oracle 进程称作数据库写入进程 (DBWR)，任何让 DBWR 变慢的因素都可能对数据库性能有

很大的影响。从设计上来说，同步存储远程镜像一定会影响 DBWR，这是因为 DBWR 进行的每次写入都会因镜像

卷之间的往返网络延迟 (RTT) 而延缓。而 Data Guard 从设计上来说绝不会影响主数据库上的 DBWR。

为了确定同步传输对生产数据库的影响，Oracle 进行了大量测试。下面提供了其中两个有代表性的测试的结果。这

里的数据体现的是一般情况下的性能影响，不应由此推断在您的生产负载情况下的预计影响。

每个应用程序都对同步复制有不同的容忍度。应用程序的并发性、会话数量、事务大小（以字节计）、会话提交频

度，以及日志切换频度，这些方面存在的差异导致性能影响会随应用程序不同而不同，即使在往返网络延迟

(RTT)、带宽和日志文件写入 I/O 性能全都相同的情况下也是如此。总体来说，Oracle 发现，同样是采用同步传

输，但是当往返网络延迟小于 5 毫秒时，相比于延迟超过 5 毫秒的情形，客户取得成功的概率更高。对于同步复制

对您的实际负载的影响，在您得出任何明确的结论之前，我们建议您始终要进行先期测试。

测试 1：OLTP 负载，少量插入

Swingbench 是一个公共域负载生成器2，用于模拟以 30MB/秒速度产生重做的 OLTP 负载。测试结果表明，在 1

毫秒 RTT 的情况下性能影响为 3%，在 5 毫秒 RTT 的情况下性能影响为 5%（参见图 1）。

图 1：同步传输对少量插入 OLTP 负载的性能影响

2 http://dominicgiles.com/swingbench.html

http://dominicgiles.com/swingbench.html


测试 1 中的 Swingbench 负载具有以下特点：

» 随机 DML，1 毫秒思考时间，400 位用户，每秒 6000 以上的事务，30MB/秒高峰重做速率

» 少量插入：5K 重做大小，120 次逻辑读取，每事务 30 个块更改

» 测试执行三次：一次未使用 Data Guard 执行的测试，两次在往返网络延迟分别为 1 和 5 毫秒的情况下使用 Data

Guard 执行的测试

» Exadata 2 节点 RAC 数据库，Oracle 11.2.0.4，Exadata 智能闪存日志，写回闪存缓存

测试 2：OLTP 负载，大量插入第二个测试使用同样的系统和数据库配置，该测试描绘了当平均事务大小增加到 440K 并且重做吞吐量相应地增加时

对 OLTP 负载的性能影响。RTT 在 1 毫秒以下、2 毫秒、5 毫秒时的性能影响分别为 1%、7% 和 12%（参见图 2）。

图 2：同步传输对大量插入 OLTP 负载的性能影响

测试 2 中的 Swingbench 负载具有以下特点：

» 大量插入 OLTP 负载：每秒 180 以上的事务，83MB/秒高峰重做速率，随机表

» 事务特点：440K 重做大小，6000 次逻辑读取，每事务 2100 个块更改

» 首先未使用 Data Guard 执行基准测试，然后使用 Data Guard 分别在 RTT 网络延迟为 1、2 和 5 毫秒的情况下

执行测试

同步传输增强

同步传输技术随着一系列的 Oracle 数据库版本而发展。对于 Data Guard 和 Active Data Guard 来说，同步传输的

技术细节及相关的 Oracle MAA 最佳实践是相同的。本文描述的全部 Data Guard 最佳实践同样适用于 Active Data

Guard。

Oracle Database 11g 第 2 版

Data Guard 11g 第 2 版能够在 LGWR 将重做写入主数据库上的本地联机日志文件时并行地将重做传输至远程备用数


据库，这缩短了同步复制需要的总往返时间，从而降低了同步传输对性能的影响。与之前的 Data Guard 版本相

比，这是一项改进，在以前的版本中，同步传输要等待本地日志文件写入完成才会向远程备用数据库传输重做。由

于总往返时间缩短，同步零数据丢失配置下的主数据库和备用数据库之间可以相距更远的距离。或者，在低延迟网

络中，这可以让 SYNC 复制对主数据库性能的影响降至近乎为零。Oracle Database 12c 使用的是同样的架构。

Oracle Database 12c

Oracle Database 12c 中的 Data Guard 快速同步 (SYNC NOAFFIRM) 为提高同步零数据丢失配置的性能提供了一

种简单的方法。快速同步允许备用数据库在内存中收到重做时立即向主数据库确认，无需等待磁盘 I/O 将重做写入

到备用数据库重做日志文件中。这种做法进一步缩短了主数据库和备用数据库之间的总往返时间，从而降低了同步

传输对主数据库性能的影响。快速同步可能会引入非常小的数据丢失风险，这种风险仅限于备用数据库 I/O 完成

前，主数据库和备用数据库同时受到故障影响的情况。不过该时间间隔非常短暂（双方的故障必须在几毫秒的时间

内相继发生），并且这种情形太过极端，因此发生的可能性非常低。快速同步包含在 Data Guard 12c 中（不需要

Active Data Guard 许可）。管理员必须显式地启用快速同步，否则 Data Guard 12c 同步重做传输默认情况下和

Data Guard 11g (SYNC AFFIRM) 的行为相同。

Active Data Guard 12c 中引入了一个新的功能，称作远程同步。Active Data Guard 远程同步甚至在主数据库和备

用数据库相距成百上千英里时仍能提供零数据丢失保护，同时能够降低甚至消除通过广域网进行同步通信对生产数

据库造成的影响。当与 Oracle Advanced Compression 结合使用时，远程同步支持主机外重做传输压缩，从而节省

带宽，同时不会在生产系统上产生开销。远程同步不在本文讨论范围之内，有关该功能的更多信息和最佳实践，请

参见 Oracle Active Data Guard 远程同步 — 任意距离的零数据丢失保护 3。

配置最佳实践

以下 MAA 最佳实践旨在让您在配置 Data Guard 同步重做传输以实现对生产数据库的零数据丢失保护时最大程度

降低您的配置对性能的影响。

将 TCP 套接字缓冲区大小设置为 BDP 的 3 倍

为了获得最佳网络吞吐量，建议将 TCP 发送和接收套接字缓冲区大小最低设置为等于主系统和备用系统之间网络

链路的带宽时延积 (BDP)。如果设置的值高于 BDP，还可能获得渐进式改进。例如，当 TCP 发送和接收套接字缓

冲区设置增加到 BDP 的 3 倍时，模拟高延迟、高带宽网络的 MAA 测试继续获得了吞吐量上的少量渐进式增长。

BDP 是网络带宽和延迟的乘积。可以使用 Oracle Net 参数 RECV_BUF_SIZE 和 SEND_BUF_SIZE 对套接字缓冲

区大小进行设置，这样套接字缓冲区大小设置只会影响 Oracle TCP 连接。操作系统可能对套接字缓冲区大小施加

了限制，因此为了让 Oracle 可以使用更大的值，必须对这些限制进行调整。例如，Linux 操作系统使用

net.core.rmem_max 和 net.core.wmem_max 参数来限制套接字缓冲区大小，因此必须将这两个参数分别设置为大

于 RECV_BUF_SIZE 和 SEND_BUF_SIZE。

3 http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf

http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf

http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf


例如，如果带宽为 622 Mb，延迟为 30 毫秒，那么您可以像下面这样计算 RECV_BUF_SIZE 和 SEND_BUF_SIZE

参数的最小大小：

带宽时延积 (BDP) = 带宽 x 延迟

BDP = 622,000,000（带宽）/ 8 x 0.030（延迟）= 2,332,500 字节。对于本例，最佳发送和接收套接字缓冲区大小的计算如下所示：

套接字缓冲区大小 = 3 x BDP

= 2,332,500 (BDP) x 3

= 6,997,500 字节

套接字缓冲区大小可以在操作系统一级设置，也可以在 Oracle Net 一级设置。由于套接字缓冲区大小要求可能变得

相当大（具体取决于网络条件），我们建议在 Oracle Net 一级进行设置，以便一般的 TCP 会话，如 telnet，不会

占用额外的内存。请注意，某些操作系统有一些参数用于设置所有发送和接收套接字缓冲区的最大大小。您须确保

对这些值进行相应地调整，以便让 Oracle Net 可以使用更大的套接字缓冲区大小。

利用 Oracle Net，您可以在 sqlnet.ora 中使用以下参数全局性地设置所有连接的发送和接收套接字缓冲区大小：

RECV_BUF_SIZE=6997500

SEND_BUF_SIZE=6997500

如果您只想对 Data Guard 传输的相关连接使用更大的缓冲区大小，那么我们建议您在传输使用的 Oracle Net 别名

中以及在备用主机的监听器中配置 RECV_BUF_SIZE 和 SEND_BUF_SIZE。下面给出一个示例，其中发送和接收

套接字缓冲区大小作为特定连接描述符的 description 属性进行设置：

standby =

(DESCRIPTION=

(SEND_BUF_SIZE=6997500)

(RECV_BUF_SIZE=6997500)

(ADDRESS=(PROTOCOL=tcp)

(HOST=stby_host)(PORT=1521))

(CONNECT_DATA=

(SERVICE_NAME=standby)))

对于 Data Guard 配置中的所有数据库，套接字缓冲区大小必须设置为相同的值。在备用端即接收端，可以在

sqlnet.ora 或 listener.ora 文件中完成此设置。在 listener.ora 文件中，您可以对特定协议地址或 description 指定缓

冲区空间参数。

LISTENER =

(DESCRIPTION=

(ADDRESS=(PROTOCOL=tcp)

(HOST=stby_host)(PORT=1521)


(SEND_BUF_SIZE=9375000)

(RECV_BUF_SIZE=9375000)))

配置备用重做日志

联机重做日志和备用重做日志使用的重做日志大小应该等于 4GB 或者大于等于高峰重做速率/分钟 x 20 分钟。要得

到高峰重做速率，请查看高峰负载时段（如批处理、季末或年末处理时段）的 AWR 报告。特别重要的是，要使用

高峰负载而不是平均负载，因为平均负载可能掩盖高峰重做速率，从而导致提供的网络带宽不足。利用表 2 的对应

关系，您可以迅速通过重做速率确定建议的最小重做日志大小：

表 2：建议的重做日志大小

从 EM 或 AWR 报告得到的高峰重做速率建议的重做日志组大小

<= 5 MB/秒 4 GB

<= 25 MB/秒 16 GB

<= 50 MB/秒 32 GB

> 50 MB/秒 64 GB

在设置合适的联机重做日志大小后，您需要创建同样大小的备用重做日志。备用重做日志组只包含单个成员对于性

能来说十分重要。此外，对于每个重做日志线程（与一个 Oracle RAC 数据库实例相关的线程），备用重做日志的

数量 = 重做日志组的数量 + 1。

有了这个额外的备用重做日志，备用数据库就不会出现等待备用重做日志的情况。例如，如果主数据库有两个实例

（线程），每个线程有三个联机日志组，那么您应在主数据库和每个备用数据库上预先配置 8 个备用重做日志。此

外，如果主数据库或备用数据库不是对称的 RAC 集群（例如，主数据库是 8 节点的 Oracle RAC 集群，备用数据

库是 2 节点的 Oracle RAC 集群），主数据库与备用数据库仍应具有相同数量的备用重做日志（取决于配置中最大

的集群）并且所有线程都应体现出来。备用重做日志必须总是与主数据库上的联机重做日志具有完全相同的大小。

请务必将包含单个成员的备用重做日志组置于最快的可用磁盘组中。其目的是提供与主数据库上日志文件 I/O 最佳

性能相当的备用日志文件写入速度。

将 SDU 大小设置为 65535

在 Oracle Net Services 中，可以通过调整 Oracle Net 会话数据单元 (SDU) 设置的大小来控制数据传输。Oracle 测

试表明，将 SDU 设置为其最大值 65535 可以提高 SYNC 传输的性能。您可以使用本地命名配置文件

(TNSNAMES.ORA) 和监听器配置文件 (LISTENER.ORA) 中的 SDU 参数来对单个连接设置 SDU，您也可以使用

SQLNET.ORA 文件中的配置文件参数 DEFAULT_SDU_SIZE 来对所有 Oracle Net 连接设置 SDU。


请注意，ASYNC 传输使用新的流协议并且将 SDU 大小设置为高于默认值不会提高异步配置的性能。

配置充足的资源以获得最佳系统性能

充足的资源，特别是主数据库和备用数据库上的日志文件 I/O 资源以及主系统位置与备用系统位置之间的网络带宽

资源，对于同步 Data Guard 配置的性能至关重要。尽管 Oracle Database 12c 中的快速同步将会消除备用数据库

上慢速 I/O 对生产数据库性能的影响，但是为了获得最好的结果，仍然需要为主数据库日志文件写入提供足够好的

I/O 性能，并且为传输重做流量提供充足的网络带宽。

使用快速同步 — SYNC NOAFFIRM

使用快速同步 (SYNC NOAFFIRM) 时，所有等待远程 RFS 写入的会话将在写入提交后（而不是写入完成后）立即

执行后续操作。这减少了总体 SYNC 远程写入等待事件，从而提供了最佳的性能。

考虑部署 Exadata 以提高零数据丢失配置中的性能

Exadata 包含的一些特性使其成为部署 SYNC 配置的最佳系统。

» 智能闪存日志：Exadata 智能闪存缓存实施了一个可以缩短日志写入 I/O 延迟的特殊算法，称作 Exadata 智能闪

存日志。用户事务提交时间或关键更新执行时间对日志写入延迟非常敏感。智能闪存日志利用 Exadata 存储中的

闪存缓存和 Exadata 磁盘控制器中的高速 RAM 内存大幅减少了日志写入延迟，避免了包括基于闪存的存储解决

方案在内的所有存储解决方案经常发生的延迟高峰。Exadata 智能闪存日志算法是 Exadata 独有的算法，这些算

法提高了主数据库和备用数据库的日志写入速度。

» 网络：Exadata 计算节点提供多个 1GigE 和 10GigE 网络适配器，这些适配器预先配置为高可用性模式并提供充

足的带宽以支持高传输速率。

» 存储性能：Exadata 是一个现代化的架构，内含可横向扩展的行业标准数据库服务器，可横向扩展的智能存储服

务器，先进的 PCI 闪存存储服务器以及一个连接所有服务器和存储的内部极速 InfiniBand 结构。Exadata 采用的

独特的软件算法在存储、基于 PCI 的闪存和 InfiniBand 网络中实现了数据库智能，因此，与其他平台相比，能以

更低的成本提供更高的性能和容量。

调优

Data Guard 的性能直接取决于主系统和备用系统、连接这些系统的网络以及 IO 子系统的性能。了解 Data Guard 配置

的拓扑及其与 Data Guard 性能的相关性有助于消除常常被人们误认为是 Data Guard 架构弱点的基础架构弱点。

配置先决条件 Data Guard 架构十分简洁高效，不过和所有应用程序一样，为了获得令人满意的性能，需要满足一些合理的先决条件：

主数据库

» 提供充足的 CPU 容量以便 LGWR 能够高效地通知前台。

» 提供充足的 I/O 带宽，以便本地日志写入在高峰速率期间仍能保持低 I/O 延迟。

» 提供的网络接口应能处理高峰重做速率下的流量及其上承载的任何其他网络活动。


» 收集主系统 AWR、ASH 和 OSwatcher 数据以用于调优和故障排除。

网络：

» 主数据库和备用数据库之间的往返网络延迟 (RTT) 不能过长，以至于对主数据库的影响达到了使主数据库违背性

能 SLA 要求的程度。这意味着对主数据库和备用数据库之间的距离存在着实际限制，因为往返延迟将随距离的

增加而增加。人们常常向 Oracle 提出这样的问题：最多可以支持多长的延迟，或者，是否有一种公式可用来预

测对性能的影响。遗憾地是，不同的应用程序对网络延迟的容忍度不同。应用程序的并发性、会话数量、事务大

小（以字节计）、会话提交频度，以及日志切换频度，这些方面存在的差异可能导致性能影响会随应用程序不同

而不同，即使在往返网络延迟、带宽和日志文件写入 I/O 性能全都相同的情况下也是如此。总体来说，Oracle 发

现，同样是采用同步重做传输，但是当往返网络延迟小于 5 毫秒时，相比于延迟超过 5 毫秒的情形，客户取得成

功的概率更高。

» 提供充足的网络带宽以支持高峰重做速率（稳定状态及当解析差异时）以及共享同一网络的任何其他网络活动。

请注意，您的点对点网络带宽将受到网段、交换机、路由器、接口及最低网络带宽的限制。如果您的网络路由器

有 90% 都支持 10 GigE，而您的现有交换机或网络接口只支持 1 GigE，则您的最大网络带宽只有 1 GigE。

» 应收集 Netstat 和/或任何网络监视统计信息。

注意：网络响应不一致和网络带宽不足是遇到的最多的网络问题。

备用数据库

» 提供充足的 CPU 容量以便 RFS（备用数据库中接收重做的 Data Guard 进程）能够高效地写入备用重做日志。

» 提供充足的 I/O 带宽以便本地日志写入在高峰速率期间仍能保持低延迟 I/O。

» 提供一个网络接口，该接口既能接收高峰重做速率下的流量又能处理其上承载的任何其他网络活动。

» 应收集 standby statspack、ASH 和 OSwatcher 数据。

注意：由于 I/O 带宽不足导致备用日志写入延迟过长，这是备用数据库遇到的最多的问题。使用 Oracle 12c 中的

Data Guard 快速同步或者使用 Exadata 都可以减轻这一问题。

监视系统资源下面提供有关如何在主/备用系统主机上监视系统资源的信息。监视 CPU 您可以使用 uptime、mpstat、sar、dstat 和 top 实用程序来监视 CPU 使用情况。如果一些进程执行工作时占用了

系统的全部 CPU 内核，则其他进程只能等待，直到某个 CPU 内核或线程空闲下来或者调度程序将某个 CPU 调换

为执行其他进程的代码。如果有过多的进程过于频繁地处于排队状态，这可能表示系统存在某种性能瓶颈。

mpstat -P ALL 和 sar -u -P ALL 命令可以显示每个 CPU 内核的 CPU 使用统计信息及所有 CPU 内核的平均统计信息。


%idle 值显示命令执行时某个 CPU 不运行系统代码或进程代码的时间百分比。如果所有 CPU 内核大多数时候

的 %idle 值都接近 0%，则系统上当前运行的负载正在受到 CPU 的限制。运行系统代码花费的时间百分比

（%system 或 %sys）通常不应超过 30%，尤其是 %idle 接近 0% 的情况下。

平均系统负载表示一段时间中 CPU 内核上正在运行的、等待运行的，或者等待磁盘 I/O 操作完成的进程的平均数

量。在繁忙的系统上，uptime 或 sar -q 命令报告的平均负载不应超过 CPU 内核数量的两倍。如果平均负载长时间

超过 CPU 内核数量的四倍，则系统处于过载状态。

除了平均负载 (ldavg-*)，sar -q 命令还报告当前等待运行的进程数量（运行队列的大小，即 runq-sz）和进程总数

量 (plist_sz)。runq-sz 值也指示了 CPU 的饱和度。

首先确定在用户和应用程序没有遇到系统响应问题的常规负载情况下系统的平均负载，然后观察渐渐出现的与此基

准的偏差。平均负载显著升高可能意味着出现了严重的性能问题。

监视内存使用 sar -r 命令报告内存使用统计信息，包括 %memused，该值表示正在使用的物理内存的百分比。

» sar -B 报告内存分页统计信息，包括 pgscank/s 和 pgscand/s，前者表示 kswapd 守护程序每秒扫描的内存页面

数，后者表示每秒直接扫描的内存页面数。

» sar -W 报告页面交换统计信息，包括 pswpin/s 和 pswpout/s，分别表示每秒换入和换出的页面数。

如果 %memused 接近 100% 且扫描速率持续超过每秒 200 个页面，则系统处于内存不足状态。

一旦系统用光了实际或物理内存并开始使用交换空间，其性能就会急剧恶化。如果用光了交换空间，您的程序甚至

整个操作系统都可能崩溃。如果 free 或 top 指示只有很少的交换空间仍然可用，这也指示内存所剩不多。

dmesg 命令的输出可能包含对引导时检测到的物理内存方面的任何问题的通知。

监视 I/O：

iostat 命令用于监视块 I/O 设备加载，其方法是观察这些设备相对于平均数据传输速率的活动时间。您可以使用此

信息调整系统配置，以在各个磁盘和主机适配器之间平衡分配 I/O 加载。

iostat -x 报告一秒间隔的块 I/O 活动的扩展统计信息，包括 %util 和 avgqu-sz，前者表示处理到某个设备的 I/O 请

求所花费的 CPU 时间百分比，后者表示向该设备发出的 I/O 请求的平均队列长度。如果 %util 接近 100% 或者

avgqu-sz 大于 1，则将出现设备饱和，需要通过增添磁盘或存储来增加存储 I/O 带宽。

您也可以使用 sar -d 命令报告块 I/O 活动，包括 %util 和 avgqu-sz 的值。 iotop 实用程序可以帮助您确定过高的磁盘 I/O 是由哪些进程造成的。iotop 有一个类似于 top 的用户界面。在用户

界面的上面部分，iotop 显示总磁盘输入和输出使用情况（以每秒字节数计）。在下面部分，iotop 显示每个进程的

I/O 信息，包括磁盘输入输出使用情况（以每秒字节数计）、磁盘页面交换或 I/O 等待花费的时间百分比，以及命

令名称。使用左右箭头键可更改排序字段，按 A 键可在每秒字节数和总字节数之间切换 I/O 单元，按 O 键可在显示

所有进程和只显示正在执行 I/O 的进程之间切换。


监视网络：

ip -s link 命令显示所有网络设备的网络统计信息和错误，包括发送 (TX) 和接收 (RX) 的字节数。丢失字段和溢出字

段指示网络接口饱和度。

ss -s 命令显示每个协议的汇总统计信息。

要监视某个接口的当前传输速率，请使用 sar –n DEV 命令。

评估数据库等待事件

一旦您验证任何系统或网络资源均不存在瓶颈后，就可以评估数据库等待事件了。为了完成这项工作，在主数据库

上要使用 AWR 报告，而在备用数据库上则要使用 standby statspack 报告（请参见 My Oracle Support 说明

454848.1，了解有关 Standby Statspack 的完整详细信息）。表 3 说明了 Oracle Database 11.2 中 Data Guard 特

有的等待事件。

表 3：与 DATA GUARD 11.2 有关的等待事件

事件名称说明

ARCH wait on ATTACH 监视所有 archiver 进程生成一个新 RFS 连接花费的时间。

ARCH wait on SENDREQ 监视所有 archiver 进程将归档日志写入本地磁盘及远程目标花费的时间。

ARCH wait on DETACH 监视所有 archiver 进程删除一个新 RFS 连接花费的时间。

LNS wait on ATTACH 监视所有 LNS 进程生成一个新 RFS 连接花费的时间。

LNS wait on SENDREQ 监视所有 LNS 进程将接收的重做写入磁盘以及打开和关闭远程归档重做日志花费的时间。

LNS wait on DETACH 监视所有 LNS 进程删除一个 RFS 连接花费的时间。

LGWR wait on LNS 监视日志写入进程 (LGWR) 等待接收来自 LNS 进程的消息花费的时间。

LNS wait on LGWR 监视 LNS 进程等待接收来自日志写入进程 (LGWR) 的消息花费的时间。

LGWR-LNS wait on channel 监视日志写入进程 (LGWR) 或 LNS 进程等待接收消息花费的时间。

12.1.0.1 及之后的所有数据库版本用表 4 中列出的以下事件取代了 Oracle 11.2 中的等待事件。


表 4：与 ORACLE DATABAS E 12C 及更新版本中的 DATA GUARD 有关的等待事件

事件名称说明

ARCH Remote Write ARCn 后台进程暂停以等待网络写入操作完成花费的时间（以厘秒计）。

ASYNC Remote Write 异步流 RFSWRITE 操作花费的时间（以厘秒计）。这包括搁置的接收和流网络提交时间。该时间

按 TTnn（重做传输备用进程）后台进程累计得到。

Redo Transport Attach 针对任何网络进程执行 Connect、Logon 和 RFSATTACH 花费的时间（以厘秒计）。

Redo Transport Close ARCn、NSSn 和 TTnn 进程执行 RFSCLOSE 和 RFSRGSTR 操作花费的时间（以厘秒计）。

Redo Transport Detach 针对任何网络进程执行 RFSDETACH 和 Disconnect 花费的时间（以厘秒计）。

Redo Transport Open ARCn、NSSn 和 TTnn 后台进程执行 RFSCREAT 和 RFSANNCE 操作花费的时间（以厘秒计）。

Redo Transport Ping ARCn 后台进程执行 RFSPING 操作花费的时间（以厘秒计）。

Redo Transport Slave Shutdown LGWR 执行 NSSn 和 TTnn 进程关闭和终止花费的时间（以厘秒计）。

Redo Transport Slave Startup LGWR 执行 NSSn 和 TTnn 进程启动和初始化花费的时间（以厘秒计）。

Redo Writer Remote Sync

Complete LGWR 收到通过网络写入远程目标任务已完成消息花费的时间（以厘秒计）。

Redo Writer Remote Sync Notify LGWR 发出通过网络写入远程目标指令花费的时间（以厘秒计）。

Remote SYNC Ping LGWR 和 NSSn 后台进程执行同步 PING 操作花费的时间（以厘秒计）。

SYNC Remote Write LGWR 执行 SYNC RFSWRITE 操作花费的时间。

了解同步传输如何确保数据完整性

以下算法确保 Data Guard 同步配置中的数据一致性：

» 主数据库上的 LGWR 重做写入和 Data Guard NSS 网络重做写入完全相同。

» 备用数据库上的 Data Guard 受管恢复进程 (MRP) 只有在重做写入主数据库联机重做日志后才能应用重做，除非

是处于 Data Guard 故障切换操作过程中（主数据库已中断）。除了同步传输重做，NSS 和 LGWR 还会交换有关

安全重做块边界的信息，该边界限制了备用恢复可以在其备用重做日志中应用的范围。当备用系统收到重做，但

主系统尚未确认已将该重做提交给自己的联机重做日志时，这可以阻止备用系统应用该重做。

可能的故障情况包括：

» 如果主数据库的 LGWR 不能写入联机重做日志，则 LGWR 和实例将会崩溃。实例或崩溃恢复将恢复到联机重做

日志中最近提交的事务并回滚任何未提交的事务。当前日志将会完成并归档。

» 在备用数据库上，我们以正确的值完成部分备用重做日志，以使其大小与对应的联机重做日志相等。如果 SRL 中

丢失了任何重做块，我们传输这些块而不是重传整个重做日志。

» 如果主数据库崩溃导致自动或手动零数据丢失故障切换，则 Data Guard 故障切换操作的一部分将执行“最终恢复”

并读取和恢复当前的备用重做日志。一旦恢复完成了对 SRL 中所有重做的应用，新的主数据库立即启动，并归档


新完成的日志组。所有新的及现有的备用数据库将删除其联机重做日志中的任何重做，闪回到一致的 SCN，并且

只应用来自新主数据库的归档。于是，Data Guard 环境再次恢复了与（新）主数据库的同步。

评估性能

在评估同步传输环境中的性能时，需要知道各种等待事件彼此之间的关系。启用同步传输带来的影响将随应用程序

而不同。为了搞清楚其中的原因，我们来看看下面的过程，该过程描述了发出提交时 LGWR 执行的工作：

1) 前台进程向 LGWR 通知提交，此时日志文件同步 (log file sync) 开始。如果有并发提交请求处于排队状态，

LGWR 将对所有待办提交请求一起进行批处理，从而导致一连串重做。

2) LGWR 等待 CPU 3) LGWR 启动重做写入，此时重做写入时间 (redo write time) 开始 4) 对于 RAC，LGWR 向其他实例广播当前的写入 5) 在进行预处理后，如果存在同步备用数据库，LGWR 启动远程写入，此时同步远程写入 (SYNC remote write) 开始 6) LGWR 发出本地写入指令（日志文件并行写入 (log file parallel write)） 7) 如果存在同步备用数据库，LGWR 等待远程写入完成 8) 在检查 I/O 状态后，LGWR 结束重做写入时间/同步远程写入 (redo write time / SYNC remote write) 9) 对于 RAC，LGWR 等待广播确认消息 10) LGWR 更新磁盘上 SCN 11) LGWR 通知前台进程 12) 前台进程等待 CPU 13) 前台进程结束日志文件同步 (log file sync)

我们建议使用以下方法来评估性能：对于批处理负载，最重要的因素是监视所用时间，因为大多数这类进程必须在固定的时段内完成。这类操作的数据

库负载与常规 OLTP 负载非常不同，例如，其写入的大小可能大得多，因此，使用日志文件同步平均值不能准确地

了解情况或进行比较。

对于 OLTP 负载，我们建议（通过 AWR）监视每秒事务量并通过 AWR 报告监视重做速率（每秒重做大小）。从

中您可以清楚地了解应用程序的吞吐量以及启用同步传输对应用程序的影响。

如何评估启用同步传输的影响：人们往往认为，在评估启用同步传输的影响时首先要查看的位置是主数据库上的日志文件同步等待事件。假如启用

同步传输之前和之后的平均日志文件同步等待时间分别是 3 毫秒和 6 毫秒，那么，人们会想当然地认为同步传输对

性能的影响达到了 100%。然而，Oracle 不建议使用日志文件同步等待时间来衡量同步传输的影响，这是因为这些

平均值可能具有很大的欺骗性，同步传输对响应时间和吞吐量的实际影响可能远远低于该事件暗示的影响。


当某个用户会话进行提交时，LGWR 将会经历以下过程：获取 CPU，提交 I/O，等待该 I/O 完成，重新获取 CPU

以通知前台进程其提交已完成。这整个时段都包含在 ‘log file sync’ 等待事件中。当 LGWR 执行其工作时，大多数情

况下会有其他会话进行提交，这些会话必须等待 LGWR 完成工作之后再处理它们的提交。处于等待状态的会话的大

小和数量取决于应用程序具有的会话数量及这些会话进行提交的频度。我们通常将这种批量产生的提交称作应用程

序的并发度。

例如，我们假设执行日志写入（日志文件并行写入）一般要花 0.5 毫秒，为提交提供服务（日志文件同步）一般要

花 1 毫秒，并且每个提交平均有 100 个等待服务的会话。如果存储层出现异常，一个提交的日志写入 I/O 花了 20

毫秒才完成，则可能有多达 2,000 个会话等待日志文件同步，而原本只有 1 个因日志文件并行写入引起的长时等

待。大量会话等待一个长时间的异常可能让日志文件同步平均值严重失真。

表 5 显示了 v$event_histogram 中对特定时段内日志文件同步等待事件的输出结果。

表 5：V$EVENT_HIS TOGRAM 中的日志文件同步等待事件

毫秒等待数量总等待百分比

1 17610 21.83%

2 43670 54.14%

4 8394 10.41%

8 4072 5.05%

16 4344 5.39%

32 2109 2.61%

64 460 0.57%

128 6 0.01%

输出结果表明，92% 的日志文件同步等待时间小于 8 毫秒，大多数小于 4 毫秒 (86%)。大于 8 毫秒的等待，即我们

称作异常的等待，总共只占 8%，但是因这些异常而处于等待状态的会话存在一定的数量（由于提交批处理），因而

造成了平均值失真。这种失真让使用日志文件同步平均等待时间作为评估同步传输影响的指标具有误导性。

造成异常的原因对于同步传输，主系统或备用系统上出现的任何 I/O 中断，或者突发的网络延迟高峰，都可能导致大量日志文件同

步异常。在备用系统的 I/O 子系统不如主系统的情况下，我们常常会看到这种现象。客户常常会在备用系统上托管

多个数据库，如开发和测试数据库，这可能让 I/O 响应速度变慢。因此，需要使用前文所述的 iostat 对 I/O 进行监

视，以确定磁盘是否即将达到最大 IOPS，因为这会影响同步传输写入性能。

造成异常的最大的原因之一可能是频繁的日志切换。想想当主系统进行日志切换时备用系统发生了什么。


1. 备用系统上的 RFS 必须结束对备用重做日志标头的更新 2. RFS 于是切换到一个新的备用重做日志并进行其他标头更新 3. 切换日志会在备用系统上强制执行完全检查点操作。这会导致缓冲区缓存中所有更新的缓冲区写入到磁盘中，从

而引发写入 I/O 高峰。在备用数据库与主数据库的存储子系统具有不同的性能的非对称配置下，这会导致更高的

I/O 延迟。

4. 之前的备用重做日志必须归档，这增加了读取和写入 I/O。图 3 中的图表是使用含大量插入的负载（每秒产生约 30MB 流量）创建的。该图表显示包含日志切换的时段的每次

远程写入的时间（以毫秒计），从中可以看出每次日志切换时出现的远程写入时间的增加。

图 3：日志切换对远程消息时间的影响

启用同步传输对其他方面的影响启用同步传输后，提交处理过程除了要进行常规本地写入外，还比以往多了一项工作，即要进行远程写入（RFS 写

入到备用重做日志）（除非使用 Oracle Database 12c 中的快速同步）。该远程写入可以让提交处理时间延长，具

体取决于网络延迟和远程 I/O 带宽。由于提交处理要花费更长的时间，这意味着将有更多的会话等待 LGWR 完成其

工作后开始处理它们的提交请求，也就是说应用程序并发度有所增加。通过分析数据库统计信息和等待事件可以观

察到这种应用程序并发度增加的现象。我们来看看表 6 中的示例。


表 6：同步传输的影响 — 增加应用程序并发度

同步

传输

重做

速率

网络

延迟

AWR 中

的 TPS

平均日志

文件同步

时间

（毫秒）

平均日

志文件

并行写

入时间

（毫秒）

RFS 随

机 I/O

平均同步

远程写入

时间

（毫秒）

重做写入

大小 (kb)

重做写入

次数

未启用 25MB 0 5,514.94 0.74 0.47 不适用不适用 10.58 2,246,356

启用 25MB 0 5,280.20 2.6 .51 .65 .95 20.50 989,791

影响 0 - -4% +251% +8.5% 不适用不适用 +93.8% -55.9%

从上面的示例中我们可以看到，启用同步传输后，重做写入次数减少，但是每次重做写入的大小增加了。由于重做

写入大小增加，我们可以预计执行 I/O（无论本地还是远程）花费的时间将会增加。我们可以预计‘日志文件同步’等

待时间也会更长，这是因为每次等待期间系统要执行更多的工作。不过，在应用程序一级对事务速度和事务响应时间

的影响可能变化很小，这是因为启用同步传输后，系统在每次提交处理过程中会为更多的会话提供服务。这就是为什

么需要在应用程序一级衡量同步传输的影响，而不是完全依靠数据库等待事件的原因所在，下面我们将详细讨论这一

点。此示例也很好地说明了为何日志文件同步等待事件对于实际应用程序影响来说是一个非常具有误导性的指标。

如何评估 Oracle Database 11.2 中同步传输的性能

要评估性能，我们建议计算本地重做写入延迟用时、平均每次写入的重做写入大小，以及总重做写入延迟。您可以使

用以下等待事件来执行计算：

» 本地日志写入延迟 = ‘日志文件并行写入’

» 平均每次写入的重做写入大小 = ‘重做大小’ / ‘重做写入次数’

» 总重做写入延迟（本地和远程） = ‘重做写入时间’ / ‘重做写入次数’ * 10

» 前台进程感到的平均提交延迟 = ‘日志文件同步’

» 每秒事务数

» 重做速率

表 7 提供的统计信息来自 Oracle 11.2 数据库中的 AWR 报告。我们对一个网络延迟为 1 毫秒的本地备用系统启用了

同步传输，目的是通过与未启用同步传输时的基准性能进行比较以得出同步传输的性能影响：

表 7：评估 ORACLE DATABAS E 11.2 的同步传输性能

指标基准 — 无同步传输同步传输影响

重做速率（K/秒） 3,689 3,670 无变化

日志文件同步 0.43 2.45 +469%

日志文件并行写入 0.30 0.30 无变化

TPS 438 429 -2.1%

总写入延迟 0.42 1.87 +345%

总重做大小 3,418,477,080 3,450,849,356 +0.9%

重做写入次数 426,201 396,199 -7.0%

重做写入大小 8,020 8,709 +8.6%


从上述示例中我们看到，启用同步传输对每秒总事务量的影响在应用程序看来是 2%，数据库重做速率下降不到

1%。我们还看到，重做写入次数减少，但重做写入大小增加。这是因为并发度，即任何一个提交或重做写入所服务

的会话数量增加。写入备用系统平均用时 1.87 毫秒，而本地写入平均用时不到 0.5 毫秒。这意味着在远程写入的

1.87 毫秒中，有 1 毫秒的时间花费在网络上，剩下大约 0.87 毫秒用于完成到备用重做日志的 I/O 写入。

如何评估 Oracle Database 12c 中同步传输的性能

要评估性能，我们建议计算本地重做写入延迟用时、平均每次写入的重做写入大小，以及总重做写入延迟您可以使

用以下等待事件来执行计算：

» 本地重做写入延迟 = ‘日志文件并行写入’

» 远程写入延迟 = ‘同步远程写入’

» 平均每次写入的重做写入大小 = ‘重做大小’ / ‘重做写入次数’

» 前台进程感到的平均提交延迟 = ‘日志文件同步’

表 8 提供的统计信息来自 Oracle 12c 数据库中的 AWR 报告。我们对一个网络延迟为 1 毫秒的本地备用系统启用了

同步传输，目的是通过与未启用同步传输时的基准性能进行比较以得出同步传输的性能影响。

表 8：评估 ORACLE DATABAS E 12C 的同步传输性能


重做速率（MB/秒） 25 25 无变化

日志文件同步 0.68 4.60 +576%

日志文件并行写入 0.57 0.62 +8.8%

TPS 7,814.92 6224.03 -20.3%

RFS 随机 I/O 不适用 2.89 不适用

平均同步远程写入时间

（毫秒）不适用 3.45 不适用

重做写入次数 2,312,366 897,751 -61,2%

重做写入大小 (kb) 10.58 20.50 +93.8%

从上述示例中我们看到，在启用同步传输之后，平均日志文件同步等待时间显著增加。在本地写入大体上保持不变

的情况下，日志文件同步等待时间增加的最大的原因是增加了同步远程写入。对于同步远程写入，我们知道网络延

迟为零，因此重点在于对备用重做日志的远程写入，该远程写入平均用时为 2.89 毫秒。在主系统和备用系统使用同

样的硬件因而远程写入应与本地写入所用时间一致的情况下，这是一个明显的危险信号。

从上面的示例中可以判断出，备用重做日志 (SRL) 具有多个成员，并且它们存放在性能较慢的磁盘组中。在减少为

单个成员并存放到一个快速磁盘组后，我们重新进行了测试，该测试产生的结果如表 9 所示。


表 9：将 SRL 减少为单个成员并存放在快速磁盘组后同步传输的性能


重做速率（MB/秒） 25 25 无变化

日志文件同步 0.67 1.60 +139%

日志文件并行写入 0.51 0.63 +23.5%

TPS 7714.36 7458.08 -3.3%

RFS 随机 I/O 不适用 .89 不适用

平均同步远程写入时间

（毫秒）不适用 1.45 不适用

重做写入次数 2,364,388 996,532 -57.9%

重做写入大小 (kb) 10.61 20.32 +91.5%

由于备用系统上的 I/O 速度提高，总日志文件同步等待时间得以减少，从而提高了每秒应用程序事务率。

诊断长时间日志文件同步等待

在发生长时间的日志写入时，系统会将类似以下的一条消息写入主数据库上的 LGWR 跟踪文件：

Warning:log write elapsed time 163ms, size 18KB

默认情况下，Oracle 只会对长于 500 毫秒的长时间日志写入操作输出警告消息。您可以使用以下带下划线的参数来

降低这类消息的输出阈值：

_long_log_write_warning_threshold=<some number of milliseconds>

利用上述警告的相关时间戳，您可以通过跟踪重做发送和接收来诊断出备用系统是否是引起长时间日志写入的根本原

因。可以设置以下跟踪：

» 在主系统和备用系统上设置事件 16410（动态）：alter system set 16410 trace name context forever, level 16

» 在备用系统上，通过查询 v$managed_standby 来确定 RFS 的 pid 并设置事件 10046，level 12。

在进行了上述跟踪设置后，您可以通过跟踪消息 id 来跟踪每个远程日志写入花费的时间。例如，对于每个远程日志

写入，输出以下消息并在该消息下面放置发送时间戳：

Client sending SQLNET request data [kpurcs] oper='Write' flag=67111042 thrd=1

seq=1584 msgid=117468

*** 2014-12-02 08:46:34.598 5837 krsu.c

在备用系统端，我们可以通过寻找上面标识的相同 msgid 来查看对远程日志写入的接收：

... Server received SQLNET data [krsr_rfs_dsp] oper='Write' flag=67111042 thrd=1

seq=1584 msgid=117468

*** 2014-12-02 08:46:34.598 826 krsr.c


一旦 RFS 完成了到 SRL 的写入，RFS 将向主系统返回一条确认消息，如以下消息所示：

... Server finished processing SQLNET data [krsr_rfs_dsp] oper='Write' flag=67111042

thrd=1 seq=1584 msgid=117468

*** 2014-12-02 08:46:34.761 1459 krsr.c

在主系统上，您可以看到 NSS 从 RFS 接收该确认消息，可以看到以下消息及其上方显示的时间戳：

*** 2014-12-02 08:46:34.761 6058 krsu.c

... Client received SQLNET call [kpurcs] response oper='Write' flag=67111042 thrd=1

seq=1584 msgid=117468

示例

下面给出一个跟踪示例，并说明如何分析一个用时 163 毫秒的长时间日志写入：

从 NSS 跟踪文件中我们可以看出，163 毫秒几乎全部花在了网络上或 RFS 中：


seq=1584 msgid=117468

*** 2014-12-02 08:46:34.598 5837 krsu.c

*** 2014-12-02 08:46:34.761 6058 krsu.c


seq=1584 msgid=117468

在 RFS 上启用事件 16410 和 10046 后，我们看到上述 msgid 的以下消息：


seq=1584 msgid=117468

*** 2014-12-02 08:46:34.598 826 krsr.c

WAIT #0:nam='RFS random i/o' ela= 298 p1=0 p2=0 p3=2147483647 obj#=-1

tim=1417535194598944

WAIT #0:nam='RFS write' ela= 162381 p1=0 p2=0 p3=0 obj#=-1 tim=1417535194761203



*** 2014-12-02 08:46:34.761 1459 krsr.c


可以看出，上面 RFS 写入所花时间占据了几乎全部 163 毫秒。下一个示例显示出一个 138 毫秒的长时间日志写入花在网络上的时间：

从 NSS 跟踪文件中我们可以看出，138 毫秒几乎全部花在了网络上或 RFS 中：


seq=1311 msgid=124705

*** 2014-12-02 08:46:49.879 5837 krsu.c

*** 2014-12-02 08:46:50.017 6058 krsu.c


seq=1311 msgid=124705

在 RFS 端我们看到，直到几乎过去了 170 毫秒后才收到了该 msgid：


seq=1311 msgid=124705

*** 2014-12-02 08:46:50.016 826 krsr.c

WAIT #0:nam='RFS random i/o' ela= 360 p1=0 p2=0 p3=2147483647 obj#=-1

tim=1417535210017013

WAIT #0:nam='RFS write' ela= 246 p1=0 p2=0 p3=0 obj#=-1 tim=1417535210017052



*** 2014-12-02 08:46:50.017 1459 krsr.c

Data Guard 快速同步

快速同步是 Oracle Database 12c 提供的一项新的 Data Guard 功能。快速同步支持使用目标参数 NOAFFIRM，该

参数指定备用数据库无需等待重做写入备用重做日志文件完成即可确认重做接收。通过使用快速同步，可从总往返

时间中去除远程 I/O 时间，因此可缩短 SYNC 配置下应用程序的响应时间。该功能还可防止备用数据库 I/O 性能的

波动和异常影响应用程序的响应时间。利用快速同步，用户实际上可以延长主数据库与任何 Data Guard 同步目标

之间的距离，从而提供更强的地理保护。

Oracle 在 Exadata 上执行的性能测试表明，配置快速同步后主数据库吞吐量提高了 4%。有些矛盾的是，使用

Exadata 智能闪存日志的 Exadata 系统上的快速 I/O 表现出的性能优势不太明显。而在 I/O 速度较慢的系统上部署

的生产数据库却表现出较大的性能优势。例如，在采用 NAS 存储的商用 x86 系统中部署的虚拟机上使用 Oracle 数

据库进行的性能测试中，通过使用快速同步，主数据库吞吐量提高了 12%（见图 4）。这是因为在虚拟机示例中磁

盘 I/O 在总往返时间中占有更大比例。


图 4：性能比较：FASTSYNC 与 SYNC

总结

在发生数据库、集群和站点中断以及自然灾难事件和其他可能影响广泛地理区域的事件时，Data Guard 和 Active Data

Guard 同步重做传输能够为您提供零数据丢失保护。同步传输与快速数据库故障切换（由管理员手动启动或使用 Data

Guard 快速启动故障切换启动4）结合使用，是 Oracle 唯一能同时提供零数据库丢失保护、灾难恢复和高可用性的复

制解决方案。本质上来说，任何同步复制解决方案都会影响生产数据库的性能。然而，Data Guard 与 Oracle 数据库

独特的集成以及本文描述的 MAA 最佳实践相结合，可以同时为您提供最佳的数据保护和最佳的性能。

4 http://docs.oracle.com/database/121/DGBKR/sofo.htm#i1027843

http://docs.oracle.com/database/121/DGBKR/sofo.htm#i1027843



甲骨文（中国）软件系统有限公司

北京远洋光华中心办公室

地址：北京市朝阳区景华南街5号远洋光华中心C座21层

邮编：100020

电话：(86.10) 6535-6688

传真：(86.10) 6515-1015

北京汉威办公室

地址：北京市朝阳区光华路7号汉威大厦10层1003-1005单元

邮编：100004

电话：(86.10) 6535-6688

传真：(86.10) 6561-3235

北京甲骨文大厦

地址：北京市海淀区中关村软件园24号楼甲骨文大厦

邮编：100193

电话：(86.10) 6106-6000

传真：(86.10) 6106-5000

北京国际软件大厦办公室

地址：北京市海淀区中关村软件园9号楼国际软件大厦二区308单元

邮编：100193

电话：(86.10) 8279-8400

传真：(86.10) 8279-8686

北京孵化器办公室

地址：北京市海淀区中关村软件园孵化器2号楼A座一层

邮编：100193

电话：(86.10) 8278-6000

传真：(86.10) 8282-6401

上海名人商业大厦办公室

地址：上海市黄浦区天津路155号名人商业大厦12层

邮编：200001

电话：(86.21) 2302-3000

传真：(86.21) 6340-6055

上海腾飞浦汇大厦办公室

地址：上海市黄浦区福州路318号腾飞浦汇大厦508-509室

邮编：200001

电话：(86.21) 2302-3000

传真：(86.21) 6391-2366

上海创智天地10号楼办公室

地址：上海市杨浦区凇沪路290号创智天地10号楼512-516单元

邮编：200433

电话：(86.21) 6095-2500

传真：(86.21) 6107-5108

上海创智天地11号楼办公室

地址：上海市杨浦区淞沪路303号创智天地科教广场3期11号楼7楼

邮编：200433

电话：(86.21) 6072-6200

传真：(86.21) 6082-1960

上海新思大厦办公室

地址：上海市漕河泾开发区宜山路926号新思大厦11层

邮编：200233

电话：(86.21) 6057-9100

传真：(86.21) 6083-5350

广州国际金融广场办公室

地址：广州市天河区珠江新城华夏路8号合景国际金融广场18楼

邮编：510623

电话：(86.20) 8513-2000

传真：(86.20) 8513-2380

成都中海国际中心办公室

地址：成都市高新区交子大道177号中海国际中心7楼B座02-06单元

邮编：610041

电话：(86.28) 8530-8600

传真：(86.28) 8530-8699

深圳飞亚达科技大厦办公室

地址：深圳市南山区高新南一道飞亚达科技大厦16层

邮编：518057

电话：(86.755) 8396-5000

传真：(86.591) 8601-3837

深圳德赛科技大厦办公室

地址：深圳市南山区高新南一道德赛科技大厦8层0801-0803单元

邮编：518057

电话：(86.755) 8660-7100

传真：(86.755) 2167-1299

大连办公室

地址：大连软件园东路23号大连软件园15号楼502

邮编：116023

电话：(86.411) 8465-6000

传真：(86.755) 8465-6499

苏州办公室

地址：苏州工业园区星湖街328号苏州国际科技园5期11幢1001室

邮编：215123

电话：(86.512) 8666-5000

传真：(86.512) 8187-7838

沈阳办公室

地址：沈阳市和平区青年大街390号皇朝万鑫国际大厦A座39层3901&3911室

邮编：110003

电话：(86.24) 8393-8700

传真：(86.24) 2353-0585

济南办公室

地址：济南市泺源大街150号中信广场11层1113单元

邮编：250011

电话：(86.531) 6861-1900

传真：(86.531) 8518-1133

南京办公室

地址：南京市玄武区洪武北路55号置地广场19层1911室

邮编：210018

电话：(86.25) 8579-7500

传真：(86.25) 8476-5226

西安办公室

地址：西安市高新区科技二路72号西安软件园零壹广场主楼1401室

邮编：710075

电话：(86.29) 8834-3400

传真：(86.25) 8833-9829

重庆办公室

地址：重庆市渝中区邹容路68号大都会商厦1611室

邮编：400010

电话：(86.23) 6037-5600

传真：(86.23) 6370-8700

杭州办公室

地址：杭州市西湖区杭大路15号嘉华国际商务中心810&811室

邮编：310007

电话：(86.571) 8168-3600

传真：(86.571) 8717-5299

福州办公室

地址：福州市五四路158号环球广场1601室

邮编：350003

电话：(86.591) 8621-5050

传真：(86.591) 8801-0330

南昌办公室

地址：江西省南昌市西湖区沿江中大道258号

皇冠商务广场10楼1009室

邮编：330025

电话：(86.791) 8612-1000

传真：(86.791) 8657-7693

呼和浩特办公室

地址：内蒙古自治区呼和浩特市新城区迎宾北路7号

大唐金座19层北侧1902-1904室

邮编：010051

电话：(86.471) 3941-600

传真：(86.471) 5100-535

郑州办公室

地址：河南省郑州市中原区中原中路220号

裕达国际贸易中心A座2015室

邮编：450007

电话：(86.371) 6755-9500

传真：(86.371) 6797-2085

武汉办公室

地址：武汉市江岸区中山大道1628号

武汉天地企业中心5号大厦23层2301单元

邮编：430010

电话：(86.27) 8221-2168

传真：(86.27) 8221-2168

长沙办公室

地址：长沙市芙蓉区韶山北路159号通程国际大酒店1311-1313室

邮编：410011

电话：(86.731) 8977-4100

传真：(86.731) 8425-9601

石家庄办公室

地址：石家庄市中山东路303号石家庄世贸广场酒店14层1402室

邮编：050011

电话：(86.311) 6670-8080

传真：(86.311) 8667-0618

昆明办公室

地址：昆明市三市街六号柏联广场写字楼11层1103A室

邮编：650021

电话：(86.871) 6402-4600

传真：(86.871) 6361-4946

合肥办公室

地址：安徽省合肥市蜀山区政务新区怀宁路1639号平安大厦18层1801室

邮编：230022

电话：(86.551) 6595-8200

传真：(86.551) 6371-3182

广西办公室

地址：广西省南宁市青秀区民族大道136-2号华润大厦B座2302室

邮编：530028

电话：(86.771) 391-8400

传真：(86.771) 577-5500


Data Guard 和 Active Data Guard

2015 年 3 月

作者：Andy Steinorth, Michael Smith

参与编著：Joe Meeks, Lawrence To

公司网址：http://www.oracle.com（英文）

中文网址：http://www.oracle.com/cn（简体中文）

销售中心：800-810-0161

售后服务热线：800-810-0366

培训服务热线：800-810-9931

欢迎访问：

http://www.oracle.com（英文）

http://www.oracle.com/cn（简体中文）

版权© 2014 归 Oracle 公司所有。未经允许，不得以任何

形式和手段复制和使用。

本文的宗旨只是提供相关信息，其内容如有变动，恕不另

行通知。Oracle 公司对本文内容的准确性不提供任何保证，

也不做任何口头或法律形式的其他保证或条件，包括关于

适销性或符合特定用途的所有默示保证和条件。本公司特

别声明对本文档不承担任何义务，而且本文档也不能构成

任何直接或间接的合同责任。未经 Oracle 公司事先书面许

可，严禁将此文档为了任何目的，以任何形式或手段(无论

是电子的还是机械的)进行复制或传播。

Oracle 是 Oracle 公司和/或其分公司的注册商标。其他名

字均可能是各相应公司的商标。

best practices for synchronous redo transport - data guard ... · 测试 2：oltp...

Documents