最高 可用性 架构 - CSDN › wy › oracle › APP1.pdf · 专门利用 Exadata 的卓越 I/O...
27
Oracle Data Guard ：Oracle 数据库云服务器灾难恢复 Oracle 最高可用性架构白皮书 2011 年 12 月 最高 可用性 架构 Oracle 高可用性最佳实践
Transcript of 最高 可用性 架构 - CSDN › wy › oracle › APP1.pdf · 专门利用 Exadata 的卓越 I/O...
Oracle Data Guard：Oracle
数据库云服务器灾难恢复
Oracle 最高可用性架构白皮书 2011 年 12 月
最高
可用性
架构
Oracle 高可用性最佳实践
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
概述 .......................................................................................................................... 3
Data Guard 和 Exadata ............................................................................................ 2
灾难恢复最佳实践 ..................................................................................................... 3
Data Guard 重做应用 ........................................................................................ 4
备用数据库实例化 ............................................................................................. 4
损坏保护 ........................................................................................................... 5
Exadata 混合列压缩 .......................................................................................... 6
物理网络配置 ............................................................................................................ 8
Data Guard 网络最佳实践 ............................................................................... 10
配置自动客户端故障切换 ................................................................................ 12
减少 ETL 操作期间的开销和重做量 ................................................................ 13
使用 Data Guard 进行计划维护的最佳实践 ............................................................ 14
数据库滚动升级 .............................................................................................. 15
使用备用数据库优先打补丁的 Patch Assurance ............................................. 15
平台迁移和技术更新 ....................................................................................... 16
数据中心迁移 .................................................................................................. 16
使用 Data Guard 克隆测试和开发数据库 ................................................................ 17
在 Exadata 存储上 .......................................................................................... 17
在 Sun ZFS 存储设备上 .................................................................................. 17
在非 Exadata 系统上 ....................................................................................... 18
用于实现最高 ROI 的最佳实践 ................................................................................ 20
用于管理 Data Guard 配置的最佳实践 .................................................................... 22
总结 ........................................................................................................................ 22
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
概述
Oracle 数据库云服务器 (Exadata) 为从扫描密集型数据仓库应用程序到高度并发的 OLTP
应用程序的所有数据库负载提供了最佳解决方案。Exadata 在高度可用、高度安全的环境
中提供超强的性能。
Oracle Data Guard 是最高可用性架构 (MAA) 要求的 Oracle 灾难恢复解决方案，用于保护
驻留在 Exadata 上的任务关键数据库。Data Guard 还用于在任何中断意外影响生产数据
库的情况下维持可用性，并在计划维护期间最大限度地减少停机时间。
Data Guard 包含在 Oracle Database 企业版中，并提供管理、监视和自动化软件来创建和
维护一个或多个同步副本（备用数据库），保护生产数据库（主数据库）免受故障、灾
难、错误和损坏的影响。
Data Guard 与 Oracle 数据库原生集成，可实现最高级别的数据保护。Data Guard 物理备
用数据库支持所有 Oracle 数据类型和特性，其中包括 Exadata 混合列压缩 (EHCC)，还支
持 Exadata 驱动的超大事务量。管理员可以使用手动或自动故障切换快速将备用数据库转
换为生产数据库角色。最后，Data Guard 备用数据库在用于查询、报告、备份、测试或滚
动数据库升级或其他计划维护时提供高投资回报，同时还提供灾难保护。
1
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
2
Data Guard 和 Exadata
Oracle Data Guard1 是适用于 Exadata 的 MAA
2 最佳实践建议，可实现：
灾难恢复 (DR)。Data Guard 可在主站点不可用的情况下防止数据丢失和停机。通过
不间断的 Oracle 验证确保 Data Guard 为 Oracle 数据库提供最佳数据保护。Data
Guard 物理备用数据库透明地支持所有 Oracle 数据类型、数据库特性和应用程序，
并可以满足严苛的 Exadata 性能要求。
高可用性 (HA)。Data Guard 可在单一配置中支持多达 30 个备用数据库。越来越多的
客户都利用了这种灵活性，他们既部署本地 Data Guard 备用数据库以实现 HA，同时
又部署远程 Data Guard 备用数据库以实现 DR。本地 Data Guard 备用数据库与
Exadata 的内部 HA 特性相得益彰，当意外故障或人为错误导致生产数据库不可用
（即使站点的其余部分仍然运行）时可维持可用性。生产数据库和本地备用数据库之
间实现低网络延迟，从而可以轻松地使用同步重做传输，并在需要故障切换的情况下
实现零数据丢失。同样，本地备用数据库与应用程序层非常靠近，还有助于将应用程
序客户端快速重定向到新的主数据库。故障切换到本地备用数据库之后，Data Guard
配置中的远程备用数据库会意识到发生了故障切换，从而自动开始从新的主数据库接
收重做 — 始终维护灾难保护。
数据库滚动升级。当实施 Oracle 补丁集或升级到新的 Oracle 版本时，Data Guard 备
用数据库还可以用于最大限度地减少计划停机时间。可使用数据库滚动升级流程执行
此类升级。从 Oracle Database 11.2.0.2 开始，认证为备用数据库优先补丁的补丁可以
首先在物理备用数据库上实施，进行全面测试，然后在主数据库上实施。Data Guard
备用数据库还可用于测试，尤其是当 Data Guard 快照备用数据库与 Oracle Real
Application Testing 一起使用时。
1 http://www.oracle.com/goto/dataguard
2 http://www.oracle.com/goto/maa
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
3
到 Exadata 存储的特定迁移。Data Guard 是 Oracle 提供的便于以最短停机时间实现
到 Exadata 的初始迁移的几种方法之一。Data Guard 备用数据库还可以用于减少其他
类型的计划维护的停机时间。
分流只读负载。只需备用系统上的小部分 CPU 和内存即可维护同步 Data Guard 备用
数据库。这样，备用系统上剩余了相当大的容量，能够满足其他要求，例如从主数
据库分流只读负载以及进行快速增量备份，从而提高投资回报 (ROI) 并降低 DR 的实
际成本。
通常，无论主和/或备用数据库驻留在 Exadata 上还是其他硬件上，对于 Data Guard 而
言都是透明的。本白皮书将重点介绍一些与同时使用 Data Guard 和 Exadata 尤为相关
的 MAA 最佳实践。
灾难恢复最佳实践
Data Guard 是一个管理、监视和自动化软件基础架构，用于创建和维护一个或多个备
用数据库，保护 Oracle 数据免受故障、灾难、错误和数据损坏的影响。当用户在主数
据库中提交事务时，Oracle 会生成重做记录并将它们写入本地联机日志文件。Data
Guard 传输服务自动将重做副本以同步或异步方式直接从主数据库日志缓冲区传输到
备用数据库，重做副本在备用数据库中写入备用重做日志文件 (SRL)。
备用数据库收到重做之后，根据管理员进行的配置，使用以下方法之一将备用数据库
与主数据库同步：
重做应用（物理备用数据库）使用介质恢复将更改应用于以只读方式打开的备用数
据库 (Active Data Guard)。重做应用逐块维护主数据库的精确副本，从而确保数据始
终受到保护。
SQL 应用（逻辑备用数据库）使用 SQL 应用流程挖掘重做数据，将其转换为 SQL 事
务和数据，然后将事务应用于以读写方式打开的备用数据库。尽管数据的物理组织
和结构可能不同，但逻辑备用数据库与主数据库包含相同的逻辑信息。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
4
Data Guard 重做应用（物理备用数据库）是 Exadata 灾难恢复的 MAA 最佳实践。要配
置重做应用，请按照 Oracle Data Guard 文档3“Oracle 高可用性最佳实践4”以及本白皮
书中所述的其他最佳实践进行操作。
Data Guard 重做应用
重做应用是维护主数据库的单独、同步副本的最简单、最快速、最可靠的方法。物理
备用数据库使用受管恢复流程 (MRP) 应用从其主数据库中接收的重做，受管恢复流程
是每个 Oracle 数据库使用的标准 Oracle 介质恢复的 Data Guard 感知扩展。MRP 控制
Oracle 内核中原生的高度并行的恢复机制。Oracle 实施了多种重做应用性能增强，以便
专门利用 Exadata 的卓越 I/O 特性。Oracle 进行的性能基准测试获得了如下备用数据
库应用速率：对于 OLTP 负载为 290 MB/秒，对于批处理负载为 640 MB/秒（大于 2
TB/小时）。
通常，对于大多数使用默认设置的负载而言，重做应用性能应该足够满足要求。但
是，如果备用数据库无法跟上主数据库的重做生成速率，请参阅用于调优介质恢复的
MAA 最佳实践。5 调优还需要使用 Standby Statspack，请参阅 My Oracle Support 说明
454848.1 以获得详细信息。
备用数据库实例化
创建备用数据库的最简单方法是使用 Oracle Recovery Manager (RMAN)。有两种方案。
第一种方案使用 DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
命令6。活动数据库复制的优点是它不需要源数据库备份，也不需要在目标系统上占用
额外磁盘空间用作临时区域。活动复制将挂载或联机的数据库文件通过网络直接复制
到辅助实例。但是，这种方法有缺点。它将影响网络性能。它还将影响主用主机的性
能，因为源数据库运行
3 http://docs.oracle.com/cd/E11882_01/server.112/e25608/toc.htm
4 http://docs.oracle.com/cd/E11882_01/server.112/e10803/config_dg.htm#CEGEADFC
5 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr1-activedataguard-1-128199.pdf
6 http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/rcmbackp.htm#SBYDB4988
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
5
将文件传输到目标主机所需的流程。内部 MAA 性能测试显示了使用活动复制获得的
以下结果：
2.9 TB/小时的传输速率，使用一个 InfiniBand 和一个 RMAN 会话
0.4 TB/小时的传输速率，使用一个 1 GigE（正在进行 10 GigE 测试）
第二种方案使用基于备份的复制和多个辅助实例。7 针对每个 Oracle 实例使用多个
BACKUP AS COPY 命令和一个 RMAN 会话将可以扩展吞吐量，使其远超过通过活动
复制实现的吞吐量。内部 MAA 性能测试显示了使用这种方法获得的以下结果：
6.1 TB/小时的传输速率，通过两个 InfiniBand 和两个 RMAN 会话
11.7 TB/小时的传输速率，通过四个 InfiniBand 和四个 RMAN 会话
3 TB/小时的传输速率，通过八个 1 GigE 和八个 RMAN 会话（正在进行 10 GigE 测试）
请参阅 My Oracle Support 说明 1206603.1，以获得有关使用多个 BACKUP AS COPY 命
令优化 RMAN 副本的更多信息。
损坏保护
下面是 MAA 最佳实践针对 Data Guard 配置中实现损坏检测、预防和自动修复的关
键参数和数据库特性建议的最佳设置。有关其中每个设置和性能考虑事项的更多信
息，请参阅 My Oracle Support 说明 1302539.1。
在主数据库上
DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKING=FULL
DB_LOST_WRITE_PROTECT=TYPICAL
启用闪回技术以便从通常由人为错误导致的逻辑损坏中进行快速时间点恢复，并在
故障切换之后快速恢复主数据库。
7 http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/rcmbackp.htm#SBYDB4989
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
6
在 Data Guard 物理备用数据库上
DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKING=OFF
DB_LOST_WRITE_PROTECT=TYPICAL
启用闪回技术以便从通常由人为错误导致的逻辑损坏中进行快速时间点恢复，并在
故障切换之后快速恢复主数据库。
使用 Active Data Guard 以启用自动块修复（Data Guard 11.2 及更高版本）。
ASM 冗余
Exadata 的标准 MAA 最佳实践是配置 ASM 高冗余，以便最好地防止数据和存储故障。
ASM 高冗余将在以下情况下维持可用性：双磁盘故障；出现磁盘故障，同时另一个
Exadata 存储单元关闭以进行维护（例如在滚动升级期间）；出现磁盘故障后，冗余磁
盘也出现读取错误（扇区故障）。
但是，ASM 高冗余提供的额外保护级别还会对减少存储容量和增加 I/O 进行权衡。如
果还在单独的 Exadata 系统上部署 Data Guard 备用数据库以进行故障切换，则 MAA
最佳实践允许配置 ASM 常规冗余，作为保护、容量和性能之间的可接受折衷。
Oracle Exadata 硬件辅助恢复数据
Exadata 实施所有 Oracle 硬件辅助恢复数据 (HARD) 规范，从而为 Oracle 块数据结构提
供独一无二的验证。在允许写入物理磁盘之前，在存储级别进行这种 Oracle 感知验
证。HARD 验证与上面列出的参数设置实现的保护相得益彰。HARD 自动在 Exadata
上启用（它需要 DB_BLOCK_CHECKSUM）。HARD 检查透明地处理包括 Oracle ASM 磁盘
重新平衡操作和磁盘故障在内的所有情况。
Exadata 混合列压缩
Data Guard 物理备用数据库提供透明的 Exadata 混合列压缩 (EHCC) 支持。主数据库上
进行 EHCC 压缩的数据以 EHCC 压缩格式复制并应用于备用数据库。Active Data
Guard 只读查询可以访问 Exadata 存储上托管的物理备用数据库上的 EHCC 压缩数据。
同样，如果 Exadata 存储上的物理备用数据库转换为 Data Guard 快照备用数据库，则
应用程序对 EHCC 压缩表具有完全的读写权限。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
7
EHCC 和备用数据库
EHCC 是 Exadata 所独有的一个高级特性。在使用 EHCC 的 Data Guard 配置中，强烈
建议主数据库和所有备用数据库也驻留在 Exadata 上。如果在主数据库上使用 EHCC
而在备用数据库上不使用，则会产生以下问题：
Active Data Guard 无法用于读取非 Exadata 系统上的 EHCC 压缩表。Data Guard 快照
备用数据库也将无法运行。
转换或故障切换到非 Exadata 备用数据库时，需要对 EHCC 压缩表进行解压缩，然
后才能对其访问，从而延长恢复时间，需要过多的磁盘空间，并且性能低于原始主
数据库。
当非 Exadata 系统以主数据库角色运行时，即使在 Exadata 备用数据库（例如原始主
数据库）上启用了 EHCC，也无法使用 EHCC 压缩。最佳情况下，可以针对 Oracle
Advanced Compression 选件获取非 Exadata 系统许可，并且可以使用 OLTP 压缩将数
据复制回 Exadata 系统。
如果环境不允许部署备用 Exadata 系统，则非 Exadata 备用数据库可以用作故障切换目
标 — 受到上述限制，并符合在 My Oracle Support 说明 413484.1 中定义的混合平台 Data
Guard 配置要求。以下各项将适用于非 Exadata 备用数据库：
在挂载模式或只读模式下，Data Guard 将更改以 EHCC 格式应用于备用数据库中的
EHCC 表。
在只读模式下，任何尝试从备用数据库中的 EHCC 表进行选择都将产生以下错误：
ORA-64307: hybrid columnar compression is only supported in
tablespaces residing on Exadata storage
要访问或修改 EHCC 表中的数据，您必须故障切换到备用数据库，并使用“alter
table move”对 EHCC 表进行解压缩。在 alter table move 操作期间，将锁定表。
SQL> recover managed standby database finish;
SQL> alter database commit to switchover to primary;
SQL> alter database open;
SQL> alter table <table_name> move <nocompress>;
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
8
注意：您还可以在非 Exadata 存储上使用以下压缩选项转换 EHCC 表：基本表压缩
<compress/compress basic> 或 OLTP 压缩 <compress for oltp>。OLTP
压缩需要 Oracle Advanced Compression 选件许可。
故障切换之后，您将无法轻松地恢复原始主数据库。通常，修复故障主数据库并挂
载数据库之后，使用闪回数据库将其闪回到备用数据库变成新的主数据库之前的
SCN。然后，Data Guard 可以使用发生故障切换之后由新的主数据库生成的重做来重
新同步此数据库。此用例的复杂之处在于通过 alter table <table_name>
move nocompress; 操作获得的重做也将对 Exadata 系统上的压缩表进行解压缩。
当后续转换将原始主数据库返回到主数据库角色时，需要将数据转换或重新加载为
EHCC 格式以完成将主数据库返回到其原始状态的流程。
物理网络配置
在 Exadata 上配置备用数据库时，有两种方案：共享网络接口（常规配置）或 Data
Guard 的专用网络接口。
共享网络接口
备用数据库可以使用 Oracle RAC VIP 接口或专用接口。在典型配置中，客户端连接使
用的网络接口与 Data Guard 用于在主数据库和备用数据库之间传输重做的网络接口相
同。图 1 提供了一个示例配置；客户端连接和 Data Guard 重做传输使用 Exadata 系统
的 NET1 (eth1) 千兆以太网接口。请注意，建议使用通道绑定以便在通道发生故障的情
况下实现 HA。额外的通道仅提供 HA，使用通道绑定不会实现可伸缩性。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
9
Database server
Database server
Database server Infin
iBa
nd
结构
Database server
Database server
Database server
Infin
iBa
nd 结
构
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
网络密钥
客户端访问和
Data Guard 传输
InfiniBand
NET3 NET2 NET1 NET0 ILOM BOND0
数据库服务器
NET3 NET2 NET1 NET0 ILOM BOND0
数据库服务器
NET0 ILOM BOND0
存储服务器
NET0 ILOM BOND0
存储服务器
主站点 灾难恢复站点
图 1：DATA GUARD 网络配置
Data Guard 重做传输的专用网络接口
如果您发现单个网络接口无法在不影响主数据库性能或重做传输保持同步能力的情况
下处理客户端和 Data Guard 网络流量，请考虑配置专用网络接口来隔离 Data Guard 流
量。图 2 中显示了使用千兆以太网接口的示例配置。请参阅 My Oracle Support 说明
960510.1 以获得详细信息。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
10
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Database server
Infin
iBa
nd 结
构
Infin
iBa
nd 结
构
Database server
Database server
Database server
Database server
Database server
Database server
网络密钥
客户端访问
DG 传输
InfiniBand
NET3 NET2 NET1 NET0 ILOM BOND0
数据库服务器
NET3 NET2 NET1 NET0 ILOM BOND0
数据库服务器
NET0 ILOM BOND0
存储服务器
NET0 ILOM BOND0
存储服务器
主站点 灾难恢复站点
图 2：将 DATA GUARD 重做传输与客户端访问相隔离
Data Guard 网络最佳实践
针对任何 Data Guard 配置建议的标准 Data Guard 网络最佳实践也适用于 Exadata。请参
阅 Oracle 高可用性最佳实践8 文档，以获得更多详细信息。
带宽需求
主系统和备用系统之间必须具有足够的网络带宽，以便 Data Guard 传输由主数据库生
成的重做量。网络带宽不足将导致传输延迟，增加数据丢失的风险，从而对恢复点目
标 (RPO) 产生不良影响。如果无法购买足够的带宽，则您可以使用 Oracle Advanced
8 http://docs.oracle.com/cd/E11882_01/server.112/e10803/config_dg.htm#CEGHIEIE
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
11
Compression选件以压缩格式传输重做9。这可以显著降低带宽需求，具体取决于负载和
数据压缩程度。请参阅 Data Guard 11g 第 2 版文档，以获得有关启用重做传输压缩的
信息。10 请参阅 My Oracle Support 说明 729551.1，以获得有关针对 Data Guard 11g 第 1
版启用重做传输压缩的信息。
网络调优
对先前发布的 Data Guard 最佳实践进行了一个更改，在这里非常有必要加以重点介
绍。先前的建议是将 TCP 发送/接收缓冲区大小设置为 3 x BDP（带宽时延积 = 网络带
宽 x 往返网络延迟）。
自 Oracle Database 11g 起，MAA 最佳实践将 TCP 发送/接收缓冲区大小设置为 3 x BDP
或 10 MB，取其中较大者。必须进行此设置，以便从针对 Data Guard 11g 重做传输实
施的新流协议中获得最大利益。
同步重做传输 — 零数据丢失 RPO
对于具有零数据丢失 RPO 的应用程序，建议使用最高可用性保护模式下的 Data Guard
同步重做传输。同步传输 (SYNC) 使主数据库最多等待 NET_TIMEOUT 秒以便备用数据
库确认当前事务的重做已安全写入磁盘，然后确认到应用程序的提交成功。如果超过
NET_TIMEOUT 秒，则 Data Guard 将停止尝试同步发送，直到主数据库能够与备用数据
库重新建立连接。
Data Guard 11g 第 2 版同步传输将重做与主数据库上的本地联机日志文件 I/O 并行传输
到远程备用数据库（先前版本写入联机日志文件，然后通过串行操作传送）。假设主
系统和备用系统上的磁盘 I/O 性能类似，则对主数据库性能的影响将取决于主数据库
和备用数据库之间的网络往返 (RTT) 所需的时间。
如果主数据库和备用数据库之间的往返网络延迟 (RTT) 小于 5 毫秒，则始终建议将使
用 SYNC 实现的最高可用性作为理想的数据保护。如果应用程序对 SYNC 延迟的影响
不敏感，则较高的 RTT 延迟仍可接受。当部署最高可用性保护模式时，始终建议进行
性能测试。
9 http://www.oracle.com/us/products/database/options/advanced-compression/index.html
10 http://download.oracle.com/docs/cd/E11882_01/server.112/e10700/log_arch_dest_param.htm#SBYDB4902
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
12
异步重做传输 — 几乎没有数据丢失
如果没有零数据丢失要求，或者 RTT 延迟对性能的影响太大而不能使用最高可用性，
则建议使用最高性能保护模式下的 Data Guard 异步重做传输。异步重做传输 (ASYNC)
允许主数据库确认向应用程序提交成功，而无需等待确认备用数据库已收到重做。最
高性能可避免任何对主数据库响应时间的影响。
Data Guard 11g ASYNC 重做传输对主数据库性能也几乎没有任何影响。这是因为直接从
主数据库日志缓冲区传送重做，而不是采用从联机重做日志文件 (ORL) 进行传送的
Data Guard 10g 实践。为了通过此增强实现最大利益，请务必为日志缓冲区分配足够的
内存，以避免 Data Guard 必须从 ORL 中读取（例如，当由主数据库生成的重做量很
大，以致于在 Data Guard 传送重做之前回收日志缓冲区时）。请参阅 My Oracle Support
说明 951152.1，以获得有关如何配置最佳日志缓冲区大小的详细信息。如果 ASYNC 流
程必须转换为从 ORL 中读取，则会自动进行转换而不中断重做传输。同样，保持一致
之后，它将自动转换回从日志缓冲区中读取。
配置自动客户端故障切换
部分站点故障
部分站点故障是指主数据库已变得不可用，但主站点中的应用程序层保持完好无损。
如果具有本地 Data Guard 备用数据库，则为了维持可用性，只需在 Data Guard 故障切
换之后将应用程序层重定向到新的主数据库。当具有远程 Data Guard 备用数据库时，
如果在发生数据库故障切换之后，依然运行的应用程序层可以提供可接受的性能，也
可以进行这种重定向。快速应用程序通知 (FAN) 将结束已连接的客户端的 TCP 超时状
态，透明应用程序故障切换（OCI 客户端）或快速连接故障切换（JDBC 客户端）自动
将客户端故障切换到新的主数据库上运行的数据库服务。请参阅技术白皮书“高可用
性 Oracle 数据库的客户端故障切换最佳实践：Oracle Database 11g 第 2 版”，以获得更
多详细信息11。
11 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
13
整个站点故障
整个站点故障导致应用程序层和数据库层都不可用。为了维持可用性，必须将用户重
定向到托管冗余应用程序层和同步 Data Guard 备用数据库的辅助站点。MAA 最佳实践
是在备用站点中维护一个正在运行的应用程序层，以避免启动时间并加快故障切换。
使用 WAN 流量管理器执行 DNS 故障切换（手动或自动），以便在 Data Guard 故障切
换将备用数据库转换为主生产数据库角色时，将用户重定向到备用站点中的应用程序
层。请参阅 Oracle 数据库高可用性最佳实践文档，以获得有关自动执行整个站点故障
切换的信息。12
减少 ETL 操作期间的开销和重做量
对于具有大量加载操作的数据仓库应用程序，许多使用 Exadata 的客户都会这样做。通
常，在提取、转换和加载 (ETL) 操作期间会执行大量处理，其中将中间结果临时存储
在数据库中，然后将最终结果加载到永久表中。通常不需要保护中间结果。如果作业
失败，则在更正问题之后重新提交作业。
Data Guard 配置的标准最佳实践是在数据库级别启用 FORCE LOGGING (ALTER DATABASE
FORCE LOGGING;)，以确保所有事务都受到保护。但是，如果将主数据库置于强制日志
记录模式以进行 ETL 操作，则会导致 Data Guard 保护不需要保护的中间结果，从而产
生不必要的数据库开销和额外的处理。
MAA 最佳实践要求将不需要由备用数据库保护的数据分离到它们自己的表空间中。此
类数据包括：
临时加载产生的数据
临时转换产生的数据
12 http://download.oracle.com/docs/cd/B19306_01/server.102/b25159/outage.htm#BABHCAIA
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
14
任何非关键数据
要减少不必要的重做生成，请执行以下操作：
针对您明确希望保护的所有表空间指定 FORCE LOGGING（ALTER TABLESPACE
<name> FORCE LOGGING;）
针对那些不需要保护的表空间指定 NO FORCE LOGGING（ALTER TABLESPACE
<name> NO FORCE LOGGING;）。
在数据库级别禁用强制日志记录 (ALTER DATABASE NO FORCE LOGGING;)，否则
数据库级别设置将覆盖表空间设置。
上述操作完成之后，重做日志记录将按如下方式运行：
针对无日志记录表空间中的对象执行的显式无日志记录操作将不会生成常规重做
（对于无日志记录操作，总是生成少量重做，以便发出已执行无日志记录操作的
信号）。
对无日志记录表空间中的对象执行的其他所有操作将生成常规重做。
对强制日志记录表空间中的对象执行的操作始终生成常规重做。
注意：在表空间级别设置 NO FORCE LOGGING 时一定谨慎，以避免意外的无日志记录
操作。因为数据库级别设置已删除，所以添加到数据库中的新表空间将默认允许无日
志记录操作。您必须根据需要，对所有新的表空间启用或禁用强制日志记录。
如果在备用数据库中需要空间，则使用 ALTER DATABASE DATAFILE OFFLINE DROP 语
句从恢复中删除并排除非日志记录的数据文件。
上面的过程对常规 Data Guard 操作或 Data Guard 角色转换没有任何影响。角色转换之
后，需要进行最低限度的维护以便在新的主数据库上的无日志记录表空间中重新创建
对象（如果需要）。
使用 Data Guard 进行计划维护的最佳实践
在 Exadata 系统上执行特定类型的计划维护时，可以使用 Data Guard 物理备用数据库
减少停机时间和降低风险。常用方法是以滚动方式执行维护，首先在备用数据库上实
施更改，对更改进行测试，然后将生产数据库从主数据库转换到备用数据库。唯一的
停机时间是转换数据库角色以及将客户端连接指向新的主数据库所需的时间。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
15
此类维护的示例包括：
数据库滚动升级
可以使用 Data Guard 物理备用数据库升级到新的 Oracle Database 补丁集和主要版本，
或者更改数据库的逻辑结构，方法是使用率先在 Oracle Database 11g 第 1 版中引入的临
时逻辑数据库滚动升级流程。此流程如下：
从物理备用数据库开始
临时将物理备用数据库转换为逻辑备用数据库（SQL 应用）。请注意，这不会更改
备用数据库的 DBID；众所周知，转换只是升级期间的临时操作。
执行将备用数据库升级到新的 Oracle 补丁集或主要版本的标准流程，然后允许 Data
Guard 重新同步备用数据库和主数据库。当主数据库和备用数据库以不同的版本运行
时，使用 SQL 应用保持同步。执行测试以验证成功进行升级。完成之后，执行转换
以将备用数据库转换为主数据库角色。 .
然后闪回原始主数据库（闪回到其物理备用数据库转换为逻辑数据库的时间点）。
它挂载在新的 Oracle 主目录中，并变成新的主数据库的物理备用数据库。不需要另
外的目录升级，因为已通过重做应用，使用由新的主数据库生成的重做升级和重新
同步数据库（从数据库临时转换为逻辑备用数据库的 SCN 开始）。
Oracle 提供了 MAA 最佳实践13 以及一个可自动执行此流程大部分的脚本，此脚本可通
过 My Oracle Support 说明 949322.1 从 Oracle 支持下载。
使用备用数据库优先打补丁的 Patch Assurance
通过备用数据库优先补丁应用，物理备用数据库可以使用重做应用来支持主数据库及
其物理备用数据库之间的不同软件版本，以便以滚动方式应用和验证 Oracle 补丁（如
果为“备用数据库优先”补丁，则不需要使用 SQL 应用临时将备用数据库转换为逻辑
数据库）。
可用于备用数据库优先打补丁的补丁包括：
13 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-upgrades-made-easy-131972.pdf
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
16
Oracle Exadata 捆绑补丁
Oracle Exadata Storage Server 软件补丁
补丁集更新 (PSU)
重要补丁更新 (CPU)
个别补丁集 (PSE)
对于适用于 Oracle Database 企业版第 2 版 (11.2) 11.2.0.1 及更高版本的认证软件补
丁，支持备用数据库优先补丁应用。请参阅 My Oracle Support 说明 1265700.1 以获得
更多信息，参阅每个补丁的 README 文件以确定目标补丁是否认证为备用数据库优
先补丁。
平台迁移和技术更新
从原有系统迁移到 Exadata 时，有多种方案。请参阅 Exadata 迁移的 MAA 最佳实践14，
以确定用于在应用程序服务级别、属性和性能之间实现最佳折衷的最好战略。最佳实
践白皮书中所述的几种方案都使用 Data Guard 备用数据库进行迁移。
请参阅 My Oracle Support 说明 413484.1，以获得有关 Data Guard 配置中支持的异构主/
备用平台组合的信息。
在技术更新期间使用 Data Guard 备用数据库最大限度地减少计划停机时间的一个示例
是从运行 Oracle Database 11g 第 1 版的 HP Oracle 数据库云服务器升级到运行 Oracle
Database 11g 第 2 版的 SUN Oracle 数据库云服务器。执行 Oracle Database 升级和彻底更
换硬件平台时，总停机时间不到 5 分钟。有关详细信息，请参阅 My Oracle Support 说
明 1055938.1。
数据中心迁移
在新的数据中心中创建 Data Guard 备用数据库，然后进行转换。
14 http://www.oracle.com/technetwork/database/features/availability/xmigration-11-133466.pdf
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
17
使用 Data Guard 克隆测试和开发数据库
克隆用于测试和开发的数据库对于支持生产环境至关重要。需要定期刷新这些数据
库，以便它们准确地反映主数据库。在具有 Exadata 的 Data Guard 配置中创建克隆数
据库时，有几种方案。
在 Exadata 存储上
用于部署测试和开发数据库的 Exadata 所在环境最好与生产环境保持一直。可以使用
RMAN 通过 RMAN DUPLICATE 命令一次性创建克隆数据库。15 或者，可以使用 Data
Guard 快照备用数据库创建可轻松刷新的克隆数据库16。
通过 Data Guard 快照备用数据库，物理备用数据库可以以读写方式打开，以用于测试
或任何需要生产数据读写副本的活动。快照备用数据库持续接收由主数据库生成的更
新，但不应用这些更新。当快照备用数据库转换回物理备用数据库时，自动将这些更
新应用于备用数据库（当快照备用数据库以读写方式打开时对其进行的更新将丢
弃）。Data Guard 快照备用数据库也是对 Oracle Real Application Testing 的完美补充。17
在 Sun ZFS 存储设备上
如果 Exadata 上的存储容量不足以克隆生产数据库，则可以在 Sun ZFS 存储设备
(ZFSSA) 上创建第二个备用数据库并将其添加到现有 Data Guard 配置中。与驻留在
Exadata 存储上用于故障切换的第一个备用数据库不同，第二个备用数据库由 ZFSSA
用作源以便快速创建和维护多个可节省空间的生产数据库副本，从而支持开发和测试
活动。
ZFSSA 支持无限的快照功能。快照是文件系统的只读时间点副本。它即时创建，最初
不分配空间。对基文件系统进行更改时，将分配块（写入时复制）。快照可以手动启
动，也可以按计划以特定间隔自动执行。
15 http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmdupdb.htm#i1008564
16 http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/manage_ps.htm#SBYDB4801
17 http://www.oracle.com/technetwork/database/features/manageability/index.html
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
18
可以直接访问快照数据以进行任何备份。对快照块的任何读取均由基文件系统的块提
供。当基文件系统发生更改时，快照现在引用旧块，文件系统引用新的已更改块。
ZFSSA 还支持无限数量的克隆。克隆是即时创建的可读写快照副本。可通过单个快
照创建一个或多个克隆。可以对克隆执行所有常规操作，其中包括通过克隆拍摄快
照。克隆通常用于测试、开发、QA 和备份环境中。与快照类似，创建克隆时，不分
配空间。对克隆的读取由基文件系统的块提供。仅当在克隆中更改块时，才分配已
更改的块。
自从发布了相应的 Oracle Database 11.2.0.3 补丁，ZFSSA 已能够支持 EHCC。ZFSSA 不
具有原生 Exadata 存储的性能优势，但它是用于备份、快照和克隆的经济高效的目标。
请参阅 MAA 最佳实践白皮书“使用 Oracle Sun ZFS 存储设备和 Oracle Data Guard 克隆
数据库”18。
在非 Exadata 系统上
但是，当迁移到 Exadata 时存在这样的情况：其中用户希望使用以前托管生产数据库的
原有系统进行开发和测试。如本白皮书的 EHCC 部分中所述，当 Exadata 主数据库使
用 EHCC 压缩数据而测试和开发数据库位于非 Exadata 硬件上时，会带来挑战。有三
种使用 Data Guard 的解决方案可以应对这种挑战。
方案 1：非 Exadata 系统上的快照备用数据库
此方案使用以读写方式打开的 Data Guard 快照备用数据库作为开发或测试数据库，或
者创建其他开发或测试数据库的种子。此流程首先在非 Exadata 硬件上为 Exadata 主数
据库创建物理备用数据库。在挂载模式或只读模式下，受管恢复流程将更改应用于
EHCC 表。
在只读模式下，任何尝试从表中进行选择的操作都将产生以下错误：
18 http://www.oracle.com/technetwork/database/features/availability/maa-db-clone-szfssa-172997.pdf
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
19
ORA-64307: hybrid columnar compression is only supported in
tablespaces residing on Exadata storage
要访问或修改 EHCC 表，请将物理备用数据库转换为快照备用数据库19。请注意，
在 alter table move 操作期间，将锁定表。
SQL> alter database convert to snapshot standby;
SQL> alter database open;
SQL> alter table <table_name> move <nocompress>;
注意：您还可以在非 Exadata 存储上使用以下压缩选项转换 EHCC 表：基本表压缩
<compress/compress basic> 或 OLTP 压缩 <compress for oltp>。OLTP
压缩需要 Oracle Advanced Compression 选件许可。
对 EHCC 表进行解压缩之后，您可以关闭并复制快照备用数据库以创建测试或开发
数据库的种子。完成复制流程之后，将快照备用数据库转换回物理备用数据库。当
快照备用数据库转换回物理备用数据库时，在上面步骤中进行解压缩的 EHCC 表将
返回到 EHCC 压缩格式，受管恢复将继续更新备用数据库。使用以下命令将快照备
用数据库转换回物理备用数据库：
SQL> alter database convert to physical standby;
注意：快照备用数据库使用有保证的恢复点转换回物理备用数据库。必须为备用数据库
的快速恢复区分配足够的空间，以容纳将在 alter table move 过程中生成的闪回日志。
方案 2：非 Exadata 系统上的逻辑备用数据库
此方案首先在非 Exadata 硬件上为 Exadata 主数据库创建物理备用数据库，这与方案 1
相同。然后，使用“Data Guard 概念和管理指南”中所述的步骤将物理备用数据库转
换为逻辑备用数据库20。
19 http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/manage_ps.htm#SBYDB4801
20 http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/create_ls.htm#g105412
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
20
SQL 应用将维护和更新 EHCC 表和数据。任何尝试访问数据的操作都将导致上述错误
(ORA-64307)
要访问或更新 EHCC 数据，您必须首先使用“alter table move”进行解压缩。请
注意，在 alter table move 操作期间，将锁定表。
SQL> alter database stop logical standby apply;
SQL> alter table <table_name> move <nocompress>;
SQL> alter database start logical standby apply;
注意：您还可以在非 Exadata 存储上使用以下压缩选项转换 EHCC 表：基本表压缩
<compress/compress basic> 或 OLTP 压缩 <compress for oltp>。OLTP
压缩需要 Oracle Advanced Compression 选件许可。
对 EHCC 表进行解压缩之后，您可以关闭逻辑备用数据库并使用它创建测试或开发
数据库的种子。当您重新启动逻辑备用数据库时，SQL 应用将持续维护对主数据库
中的表的更新，自动对 EHCC 重做进行解压缩并将其转换为备用数据库中所需的压
缩格式（无、BASIC 或 OLTP）。当您需要刷新测试或开发数据库时，只需重复关闭
逻辑备用数据库并刷新开发/测试数据库的流程。
用于实现最高 ROI 的最佳实践
将 Data Guard 备用数据库在处于备用数据库角色时用于生产目的，以便最大限度地提
高投资回报。
只需备用系统上的小部分 CPU 和内存即可维护同步 Data Guard 备用数据库。这样，备
用系统上剩余相当可观的容量以满足其他要求，从而提高 ROI 并有效降低 DR 成本。
MAA 最佳实践建议通过以下方法有效使用备用系统。
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
21
使用 Active Data Guard 将只读负载分流到活动备用数据库以提高主数据库性能，同
时还提供 HA/DR。必须注意的是，对 Active Data Guard 备用数据库执行的只读查询
与对主数据库执行的查询具有相同的读取一致性保证 — 其他物理复制解决方案都无
法提供此级别的读取一致性。（Active Data Guard 是 Oracle Database 企业版的选件许
可。）有关 Active Data Guard 的更多详细信息，请参阅技术白皮书“Active Data
Guard 11g 最佳实践”21。
针对 Oracle 数据库所执行的任何只读访问负载都可以分流到 Active Data Guard 备用数
据库。一些 Oracle 管理软件和报表工具还支持将分流用于报表。这些管理软件和报
表工具包括：
▪ E-Business Suite 报表 (OracleReports)，自 E-Business Suite 第 12.1.3 版或更高版本起22
▪ Peoplesoft PeopleTools 8.5123
▪ Oracle Business Intelligence Enterprise Edition Server24
▪ Oracle TopLink 管理软件25
使用备用数据库从主数据库分流备份。使用 Active Data Guard 通过 RMAN 块更改跟
踪从主数据库分流快速增量备份。
使用单个 Exadata 系统作为“备用数据库中心”，其中此系统用作共享资源，托管位
于两个或多个数据中心的主数据库的多个备用数据库。此整合战略以不同站点间极
少同时发生多个故障为前提，降低了 DR 成本。
在主站点和 DR 站点中的 Exadata 系统上部署生产数据库，因此将所有数据中心都转
换为主站点。在此配置中，每个站点都为部署在其他站点中的主数据库托管备用数
据库，从而提高系统利用率，同时降低单个站点故障的整体影响。除了负载平衡优
势之外，此战略将确保所有站点在故障切换时都真正能够运行生产数据库，前提是
站点通常全年都用作生产站点。尽管可能有一些限制阻止了轻松采用此战略，但回
报相当可观。
21 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr1-activedataguard-1-128199.pdf
22 http://blogs.oracle.com/stevenChan/2011/01/adg_ebs12.html
23 http://download.oracle.com/docs/cd/E18083_01/pt851pbr0/eng/psbooks/tadm/book.htm?File=tadm/htm/tadm13.htm#H4064
24 http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-biee-activedataguard-1-131999.pdf
25 http://www.oracle.com/technetwork/database/features/availability/maa-tech-wp-toplinkwithadg-130077.pdf
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
22
用于管理 Data Guard 配置的最佳实践
Oracle Enterprise Manager Grid Control 使用 Data Guard Broker26 的底层服务来简化 Data
Guard 配置的创建和管理。可使用向导轻松实例化备用数据库。只需鼠标单击即可调用
数据库转换和故障切换操作，或者如果您愿意，则可以配置自动故障切换（Data Guard
快速启动故障切换）。Enterprise Manager 在一个称为 HA 控制台的窗口中整合关键 Data
Guard 度量（例如应用延迟、传输延迟、重做速率和配置状态）的报表。Grid Control 还
对它监视的 Data Guard 量度进行历史趋势分析 — 例如，最近 24 小时或最近 5 天度量的
性能情况等。此外，通过 Enterprise Manager，可以设置通知警报，这样，如果度量超过
了配置的阈值，管理员就会收到通知。
Data Guard Broker 是一个分布式管理框架，它包含在 Data Guard 中，是 Enterprise
Manager Grid Control 所需的。管理员（如果愿意）还可以使用代理的命令行界面
(DGMGRL) 直接与代理交互。
总结
Data Guard 重做应用是最简单、最快速、最可靠的解决方案，用于维护 Oracle 数据库
的单独、同步物理副本，从而实现 HA/DR。
Data Guard：
支持高可用性（通过零数据丢失和/或自动故障切换）和灾难恢复。
提供独一无二的数据保护和可用性，是唯一能够支持 Exadata 驱动的超大事务量的
DR 技术。
26 http://www.oracle.com/pls/db112/to_toc?pathname=server.112/e17023/toc.htm
Oracle 白皮书 — Oracle Data Guard：Oracle 数据库云服务器灾难恢复
23
是真正现成的 Oracle 数据库解决方案。Data Guard 重做应用是唯一的 Oracle 感知 DR
技术，原生支持所有 Oracle 数据类型、数据库特性和负载。
是用于最大限度地减少计划停机时间的工具，并可以用于迁移到 Exadata，以滚动方
式执行数据库升级。
与 Exadata 一起使用时，具有很少需要考虑的特殊事项。升级到此高性能平台时，您
可以直接利用以往的 Data Guard 知识和经验。
提供多种部署方案，其中包括 Active Data Guard，以便在备用系统处于备用数据库角
色时加以高效地使用，从而实现高投资回报。
Data Guard 是最高可用性架构 (MAA) 要求的 Oracle HA/DR 解决方案，用于保护驻留
在 Exadata 上的任务关键数据库。
甲骨文（中国）软件系统有限公司
北京远洋光华中心办公室
地址：北京市朝阳区景华南街5号远洋光华中心C座21层
邮编：100020
电话：(86.10) 6535-6688
传真：(86.10) 6515-1015
北京上地6号办公室
地址：北京市海淀区上地信息产业基地，上地西路8号，上地六号大厦D座702室
邮编：100085
电话：(86.10) 8278-7300
传真：(86.10) 8278-7373
上海分公司
地址：上海市黄浦区天津路155号名人商业大厦12层
邮编：200021
电话：(86.21) 2302-3000
传真：(86.21) 6340-6055
广州分公司
地址：广州市天河区珠江新城华夏路8号合景国际金融广场18楼
邮编：510623
电话：(86.20) 8513-2000
传真：(86.20) 8513-2380
成都分公司（川信大厦办公室）
地址：成都市人民南路二段18号四川川信大厦20层A&D座
邮编：610016
电话：(86.28) 8619-7200
传真：(86.28) 8619-9573
成都分公司（高新国际广场办公室）
地址：成都市高新区天韵路150号高新国际广场D座四楼18-19，22-25单元
邮编：610041
电话：(86.28) 8530-8600
传真：(86.28) 8530-8699
大连分公司
地址：大连软件园东路23号大连软件园国际信息服务中心2号楼五层502号A区
邮编：116023
电话：(86.411) 8465-6000
传真：(86.411) 8465-6499
济南分公司
地址：济南市泺源大街150号，中信广场11层1113单元
邮编：250011
电话：(86.531) 8518-1122
传真：(86.531) 8518-1133
沈阳分公司
地址：沈阳市沈河区青年大街219号，华新国际大厦17层D单元
邮编：110016
电话：(86.24) 2396 1175
传真：(86.24) 2396 1033
南京分公司
地址：南京市玄武区洪武北路55号，置地广场19层1911室
邮编：210028
电话：(86.25) 8476-5228
传真：(86.25) 8476-5226
杭州分公司
地址：杭州市西湖区杭大路15号，嘉华国际商务中心702室
邮编：310007
电话：(86.571) 8717-5300
传真：(86.571) 8717-5299
西安分公司
地址：西安市高新区科技二路72号，零壹广场主楼1401室
邮编：710075
电话：(86.29) 8833-9800
传真：(86.29) 8833-9829
福州分公司
地址：福州市五四路158号，环球广场1601室
邮编：350003
电话：(86.591) 8801-0338
传真：(86.591) 8801-0330
重庆分公司
地址：重庆市渝中区邹容路68号，大都会商厦1611室
邮编：400010
电话：(86.23) 6370-8898
传真：(86.23) 6370-8700
深圳分公司
地址：深圳市南山区高新南一道飞亚达大厦16层
邮编：518057
电话：(86.755) 8396-5000
传真：(86.755) 8601-3837
甲骨文软件研究开发中心（北京）有限公司
地址：北京市海淀区中关村软件园孵化器2号楼A座一层
邮编：100094
电话：(86.10) 8278-6000
传真：(86.10) 8282-6455
深圳分公司
地址：深圳市南山区高新南一道德赛科技大厦8层0801-0803单元
邮编：518057
电话：(86.755) 8660-7100
传真：(86.755) 2167-1299
甲骨文亚洲研发中心-上海
地址：上海市杨浦区淞沪路290号创智天地10号楼512-516单元
邮编：200433
电话：(86.21) 6095-2500
传真：(86.21) 6095-2555
Oracle Data Guard：Oracle 数据库云服务器灾难恢复
作者：Joseph Meeks, Larry Carpenter, Michael Smith
特约作者：MAA team
2011 年 12 月
公司网址：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（简体中文）
版权© 2011 归 Oracle 公司所有。未经允许，不得以任何
形式和手段复制和使用。
本文的宗旨只是提供相关信息，其内容如有变动，恕不另行
通知。Oracle 公司对本文内容的准确性不提供任何保证，
也不做任何口头或法律形式的其他保证或条件，包括关于适
销性或符合特定用途的所有默示保证和条件。本公司特别声
明对本文档不承担任何义务，而且本文档也不能构成任何直
接或间接的合同责任。未经 Oracle 公司事先书面许可，严
禁将此文档为了任何目的，以任何形式或手段(无论是电子
的还是机械的)进行复制或传播。
Oracle 是 Oracle 公司和/或其分公司的注册商标。其他名
字均可能是各相应公司的商标。
