RAC 平台特定的入门套件和最佳实践

In this Document

Purpose

Scope

Details

RAC 平台特定的入门套件和最佳实践

RAC 平台通用的负载测试和系统测试计划概述

RACcheck - RAC 配置审核工具

保持 RAC 集群环境稳定当前必须要做的 11 件事

设计注意事项

一般设计注意事项

网络注意事项

存储注意事项（包括 ASM）

Clusterware 和 Grid Infrastructure 配置注意事项

虚拟化注意事项

安装注意事项

补丁安装注意事项

升级注意事项

Clusterware、ASM 和 Grid Infrastructure 升级注意事项

RDBMS 升级注意事项

RAC 的数据库配置注意事项

数据库初始化参数注意事项

性能优化注意事项

数据库网络注意事项

一般数据库注意事项

诊断和故障排除

一般注意事项

Clusterware 和 Grid Infrastructure 诊断

RAC 数据库诊断

应用补丁诊断 (OPatch)

References

 

Applies to:

Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Information in this document applies to any platform.

Purpose

 

 

最佳实践和初学者指南之 Oracle Real Application Clusters (RAC) 系列，主要目标是为了帮助客户快速了解实施、升级与维护 Oracle RAC 系统的通用的以及针对特定平台的最佳实践。Oracle 根据自己的经验及其全球 RAC 客户的反馈编写和维护本文档。

本初学者指南的目的不在于取代 Oracle 文档集，而是作为它的补充。对于本文没有明确解决的任何问题，还应仔细阅读、理解和参考 Oracle 文档，以从中寻找答案。

您的运营团队应仔细审核所有建议，且只有通过了相应的风险评估后方能实施。风险评估只能由具备丰富的系统、应用和企业环境方面知识的人员来执行。

由 于每个客户环境都是独一无二的，因此 Oracle Database 实施（包括 Oracle RAC 实施）的成功源于成功的测试环境。对于本文中的任一建议，在生产环境中加以实施之前，务必要在作为目标生产环境复制品的测试环境中进行充分的测试和验证， 以确保不会产生与所实施建议相关的负面影响。

Scope

本文章适用于所有新的和现有 RAC 实施以及 RAC 升级。

Details

RAC 平台特定的入门套件和最佳实践

本文档重点介绍与平台无关（通用）的 RAC 最佳实践，以下文档则包含了平台特定的具体最佳实践（包括分步安装说明）。

Document 811306.1 RAC and Oracle Clusterware Best Practices and Starter Kit (Linux)
Document 811280.1 RAC and Oracle Clusterware Best Practices and Starter Kit (Solaris)
Document 811271.1 RAC and Oracle Clusterware Best Practices and Starter Kit (Windows)
Document 811293.1 RAC and Oracle Clusterware Best Practices and Starter Kit (AIX)
Document 811303.1 RAC and Oracle Clusterware Best Practices and Starter Kit (HP-UX)

 

RAC 平台通用的负载测试和系统测试计划概述

所有成功实施（特别是关键业务的最大可用性环境）的关键任务是测试。对于 RAC 环境，测试应包含负载生成和故障注入测试。通过负载测试，可衡量系统在负载繁重时的反应，而故障注入测试则有助于确保系统在发生不可避免的硬件和（或）软 件故障时能够按照设计进行反应。下面的文档将介绍执行此重要测试时应遵循的指南。

单击 此处 ，获取可用的 RAC 系统负载测试工具的白皮书
单击 此处 ，获取针对 10gR2 和 11gR1 的平台通用 RAC 系统测试计划概述
单击 此处 ，获取针对 11gR2 的平台通用 RAC 系统测试计划概述

这些文档用于验证您的系统设置和配置，也可以作为练习应对某种故障的处理过程的一种方法。

RACcheck - RAC 配置审核工具

RACcheck 是一款 RAC 配置审核工具，主要用于审核 Real Application Clusters (RAC)、Oracle Clusterware (CRS)、Automatic Storage Management (ASM) 和 Grid Infrastructure 环境中各个重要的配置设置。此实用程序用于验证由 RAC Assurance 开发和支持团队维护的 Oracle Real Application Clusters (RAC) 最佳实践和初学者指南文档系列定义的最佳实践和成功要素。目前，RACcheck 支持 Linux（x86 和 x86_64）、Solais SPARC 和 AIX（使用 bash shell）平台。我们强烈建议在 RACcheck 支持的平台上运行 RAC 的客户使用此工具找出会影响集群稳定性的潜在配置问题。

Document 1268927.1 RACcheck - RAC Configuration Audit Tool

注意： Oracle 会根据全球客户的反馈不断生成和维护最佳实践和成功因素。因此，RACcheck 实用程序会经常根据此信息进行更新。也就是说，建议您在执行审核前先确定自己要使用的 RACcheck 版本。

 

保持 RAC 集群环境稳定当前必须要做的 11 件事

为了积极预防集群因为常见的已知问题出现不稳定的情况，Oracle RAC Proactive Support 团队编写了一个包含会影响 RAC 集群稳定性的最常见的11 个问题的列表。虽然所有这些建议都包含在最佳实践和入门套件系列中，我们还是强烈建议您阅读以下文档，因为我们认为这些文档是非常重要的成功因素。

Document 1344678.1 Top 11 Things to do NOW to Stabilize your RAC Cluster Environment 

 

设计注意事项

以下“设计注意事项”提供与 Infrastructure（平台无关）相关的指南和最佳实践信息，以支持 Oracle RAC 实施。此信息不仅适用于新安装和升级，也能为那些支持现有 RAC 的实施提供有用信息。

一般设计注意事项

• 为简化系统的复杂度和与第三方软件之间的交互，Oracle 建议避免使用第三方集群管理软件，除非实在需要。

• 推荐将 Automatic Storage Management (ASM) 用于数据库存储。有关 ASM 的其他信息，请参见 Document 265633.1.

• 检查产品支持矩阵，以确保产品、版本和平台组合的可支持性，或了解在某些组合中需要额外完成的所有特定步骤，请参见 Document 337737.1

• 与磁盘供应商联系，确认节点数、OS 版本、RAC 版本、CRS 版本、网络结构和补丁是否经过认证，因为有些存储/San 供应商可能要求针对特定的节点数进行专门认证。

• 计划并记录容量要求。与服务器供应商合作，制定详细的容量计划和系统配置，但请注意：使用正常的容量计划流程估计运行工作负载所需的 CPU 数。随着 CPU 数量的增加，SMP 和 RAC 集群的成本会同步增加。如果 CPU 数量较少，通常是 SMP 的伸缩性较好；如果 CPU 数量较多，RAC 集群的伸缩性通常要比 SMP 好。标准同步成本：5-20%。

• 消除架构中的所有单一故障点。示例包括（但不限于）：集群私网冗余（NIC 绑定等）、存储的多路存取路径、使用 2 个或多个 HBA 或发起程序和多路径软件、磁盘镜像/RAID。其他详细信息请见后文描述。

• 使用经过证实的最大可用性策略。RAC 是最大可用性整体架构中的一个组件。查看 Oracle 的最大可用性架构蓝图，网址：http://www.oracle.com/technetwork/database/features/availability/maa-096107.html.

• 使用系统测试计划帮助制定意外停机的计划并将其付诸实践，这个步骤非常重要。本文档附有“系统测试计划概述”示例，可指导您进行系统测试，以便为潜在的计划外故障做准备。

• 强烈建议用于生产的RAC 实例不与 DEV、TEST、QA 或 TRAINING 实例共享一个节点。这些额外的实例通常会给生产环境带来意外的性能改变。同时，强烈建议测试环境尽可能地接近生产环境的镜像。

• 如能为 RAC 项目实施制定分步计划，那将会非常有帮助。下面的 OTN 文章中包含了示例项目概述： http://www.oracle.com/technetwork/articles/haskins-rac-project-guide-099429.html

网络注意事项

• 根据 RFC952 - DoD 主机列表说明，在主机名或域名中不使用下划线。这条规则也适用于 Net（网络）、Host（主机）、Gateway（网关）或 Domain（域）名。

• VIP 和 SCAN VIP 应与公网在同一个子网上。有关其他信息，请参见 Understanding SCAN VIP white paper.

• 默认网关必须与 VIP（包括 SCAN VIP）在同一个子网上，以防止出现 VIP 启动/停止/故障转移问题。在 11gR2 中，OUI 会检测出并报告此问题，如果忽略检查，此问题将导致无法启动 VIP，从而导致安装自身也出现故障。

• 建议通过 DNS，按round-robin方式将 SCAN 名称（11gR2 和更高版本）至少解析为 3 个 IP 地址，无论集群大小如何。有关其他信息，请参见 Understanding SCAN VIP white paper.

• 为避免名称解析出现问题，请确保 HOSTS 文件和 DNS 中提供了 VIP 与公共主机名。SCAN 不得位于 HOSTS 文件中，因为 HOSTS 文件只能显示 1:1 主机到 IP 的映射。

• 网络接口必须在所有节点上使用相同的名称（如 eth1 -> eth1 支持 VIP，eth2 -> eth2 支持专用私网网络）。

• 网络接口卡 (NIC) 名称中不得包含 "." 。

• 私网使用 Jumbo Frames 是提高 Cache Fusion 操作性能的最佳实践。请参考 Document 341788.1

• 对私网使用non-routable的网络地址；A 类：10.0.0.0 到 10.255.255.255，B 类：172.16.0.0 到 172.31.255.255，C 类：192.168.0.0 到 192.168.255.255。有关其他信息，请参考 RFC1918  和 Document 338924.1

• 请确保根据速度、双工等正确配置网络接口。可用于监视和测试网络的各种工具有：ethtool、iperf、netperf、spray 和 tcp。请参考 Document 563566.1.
• 为避免公网或私网出现单一故障点，Oracle 强烈建议在每个集群节点上配置公共网络接口卡 (Network Interface Card, NIC) 和私网 NIC 的冗余集。请参考 Document 787420.1。   从 11.2.0.2 开始，Oracle Grid Infrastructure 可为私网（不是公网）提供冗余和负载均衡，对于 11.2.0.2（必须使用 11.2.0.2 Database），这是 NIC 冗余的首选方法。更多信息，请参考 Document 1210883.1。
  
  
  注意：  如果使用 11.2.0.2 Redundant Interconnect/HAIP 功能，目前要求所有私网要在不同的子网上。如果全部接口在同一个子网上，且从路由表的第一个 NIC 中拔出电缆，则将发生GI stacks重启或节点重启的情况。有关此要求的技术说明，请参见 Document 1481481.1 。
   
• 如果希望对发现硬件的可预测性更强，请将 HBA 和 NIC 卡插入 Grid 中每台服务器上的同一对应插槽中。
   
• 私网连接需要使用交换机，或冗余交换机（不支持交叉线直连）。
   
• 由于在交换机上部署私有网络（甚至在使用 VLAN 时）可能会使私网链路在大型 IP 网络拓扑中遭遇拥堵并变得不稳定，因此强烈建议为私网使用专用冗余交换机。如果在 VLAN 上部署私网，则在 VLAN 和non-routable的子网之间应该有一个 1:1 映射，并且 VLAN 不应该跨越多个 VLAN（已标记）或多个交换机。此环境中的部署问题包括在大型 IP 网络拓扑更改时的“Spanning Tree ”环、可能导致数据包洪流的不对称路由以及缺乏对 VLAN/端口的细粒度监视。请参考 Bug 9761210。
   
• 如果在 VLAN 上部署集群私网，请查看 Oracle RAC and Clusterware Interconnect Virtual Local Area Networks (VLANs) 白皮书中的注意事项。
   
• 考虑对有高流量要求的工作负载的私网使用 Infiniband。Infiniband 还可以通过降低延迟来提高性能。实施 Infiniband 后，可以使用 RDS 协议进一步降低延迟。请参见 Document 751343.1 了解详细信息。
   
• 请注意，RAC 目前尚不支持 IPv6 寻址。有关详细信息，请参见 Oracle Database IPv6 State of Direction white paper （Oracle Database IPv6 发展方向白皮书）。

• 对于Grid Infrastructure版本 11.2.0.2，私网必须在子网 230.0.1.0支持多播传输（multicast）。Oracle Grid Infrastructure 11.2.0.2 的 Patch: 9974223  （包含在 GI PSU 11.2.0.2.1 和更高版本中）对私网上的 224.0.0.251 多播地址启用了多播功能。必须允许这两个地址中的其中一个所对应的私网使用多播（假设已应用补丁程序）。Document 1212703.1 中提供了测试多播功能的其他信息和程序。

存储注意事项（包括 ASM）

• 对使用两个或多个 HBA 或 Initiator 的存储阵列，多路径软件通过这些HBA 实现对这些阵列的多路径存取。如果可能，请使用伪设备（多路径 I/O）作为 ASM 的 diskstring。比如：EMC PowerPath、Veritas DMP、Sun Traffic Manager、Hitachi HDLM、IBM SDDPC、Linux 2.6 Device Mapper。这对 I/O 的负载均衡和故障转移非常有用。请参考 Document 294869.1 和  Multipathing Best Practices white paper（多路径最佳实践白皮书）。

• RAC 与 NFS 一起使用时，请确保对 NFS 磁盘使用正确的 mount 选项。Document 359515.1 中详细介绍了针对各个平台的 mount 选项。

• ASM 是存储 Oracle Database 目前和未来的发展方向。也就是说，强烈建议在 RAC 环境中使用 ASM（而不是使用其它的集群文件系统），这是最佳实践。使用 Oracle RAC 标准版时，数据文件存储需要使用 ASM。

• 遵守 ASM 最佳实践。请参考： Document 265633.1 ASM Technical Best Practices.   虽然未明确说明，但是本文中列出的这些最佳实践也适用于 11gR2。11gR2 ASM 最佳实践也记录在了 Oracle Automatic Storage Management Administrator's Guide11g Release 2 (11.2).

• 建议保持 ASM 磁盘组不超过两个，一个用于存储数据文件，一个用于闪回区（flash recovery area），而且每个磁盘组位于不同的物理磁盘。RAID 存储阵列 LUN 可作为 ASM 磁盘，以最小化 OS 中显示的 LUN 个数。

• 每个 ASM 磁盘组上最少要有四个大小和性能相同的 LUN（每个 LUN在不同的RAID 组），以确保性能最优。

• 使用高端存储阵列时使用外部冗余磁盘组。高端存储阵列一般提供硬件 RAID 保护。不使用硬件 RAID 或需要使用基于主机的卷管理功能（如跨存储系统镜像）时，则使用 Oracle ASM 镜像冗余。在地理位置上分离的两站点间镜像（扩展的集群）时，可以在配置中使用 Oracle ASM 镜像。

• 对于 10g，增大 ASM 实例 SGA 参数大小分配的默认值：
  
  SHARED_POOL_SIZE=128M - 另外，当系统中的磁盘组数量大于5个时，每新增一个磁盘组，增加 SHARED_POOL_SIZE 500KB。
  LARGE_POOL=12M
  DB_CACHE_SIZE=64M
  PROCESSES=150
• 在 11g 中，默认对 ASM 实例启用 Automatic Memory Management (AMM)，即使没有设置 MEMORY_TARGET 参数。大多数环境使用 MEMORY_TARGET 的默认值都是可以的。如果在您的 ASM 实例中遇到 ORA-4031 错误，可能需要调整 AMM 设置。请参考 Document 1370925.1 (ASM Instances Are Reporting ORA-04031 Errors)，了解如何正确设置以避免共享池耗尽。

• 在 11g 环境中，如果多个数据库共享同一个 ASM 实例，可能需要修改 ASM processes 参数。根据经验法则，ASM 的最佳进程数为 150 个，可用于确定合适值的公式为：
  
  ASM processes = 50 x (<max # instances on db node> + <1 for first 10>) + 10 x (<subsequent instances after 10>)
• 磁盘做RAID条带化的尺寸 需要选择大小为 2 的幂且小于或等于 Oracle ASM Allocation Unit 的值。

• 如果 ASM 磁盘组中的 LUN 大于 2TB，则可能会发生 ORA-15196（ASM 块损坏）。修复这个问题后，如果指定的磁盘大于 2TB，将发生 ORA-15099。无论是否存在 asmlib 这个问题都会发生。绕过问题的方法：不要向磁盘组中添加大于 2 TB 的磁盘。请参考 Document 6453944.8

• 在某些平台上，警告日志中可能会重复出现关于 AIO 限制的警告：
  "WARNING:Oracle process running out of OS kernel I/O resources." 解决这个问题需要应用 Patch 6687381，（许多平台上都有）。此问题会影响 10.2.0.3、10.2.0.4 和 11.1.0.6。版本11.1.0.7 中已修正此问题。请参考 Document 6687381.8

• 在将 ASM 从 10.2 版升级到 11.1 或 11.2 版期间，会发生 Bug 5100163 (possible metadata corruption) ；在执行 ASM 升级前，仅当 ASM 磁盘组的 AU > 1 MB 时才会发生此 bug。对于在 11.1 或 11.2 版上直接创建的新磁盘组，不会遇到此 bug。
  • 为了防止发生 Bug 5100163，My Oracle Support 上已生成了相关的公告。请参考： Document 1145365.1 Alert: Querying v$asm_file Gives ORA-15196 After ASM Was Upgraded From 10gR2 To 11gR2。总之，您可能要运行“alter diskgroup <DG_NAME> check all repair”以验证和修复所有升级后的磁盘组。

Clusterware 和 Grid Infrastructure 配置注意事项

• 对于 11gR2 之前的版本，建议将 Voting Disks 存储在 裸设备或块设备（取决于 OS 和 Oracle 版本）上，并使用 Oracle 提供的冗余，而不用考虑底层存储配置。建议使用两个 OCR。Voting Disks 的数量应保持为奇数，且最小数量为 3。之所以建议 Voting Disks 为奇数，是因为如果所有 Voting Disks 丢失 1/2 或更多，将导致节点从集群中被驱逐，或导致节点将自己驱逐出集群。

• 在 Grid Infrastructure 11gR2 中，已弃用 裸设备和块设备，建议使用 ASM 存储 OCR 和Voting Disks。在 11gR2 和更高版本中，将 OCR 和 Voting Disks 存储在 ASM 中时，建议保持 ASM 磁盘组不超过 2 个（请参见“ASM 最佳实践”）。这意味着 OCR 和 Voting Disks 将与数据库相关文件一起存储。如果要对磁盘组使用外部冗余（请参见“ASM 注意事项”了解有关磁盘组冗余的详细信息），这意味着您将使用 1 个 Voting Disk 和 1 个 OCR。
  • 如果用户要在 11gR2 和更高版本中对 OCR 和 Voting Disks 使用 Oracle 提供的冗余，可以单独创建（第三个）ASM 磁盘组，这个磁盘组至少含有 3 个Failure Groups（总计 3 个磁盘）。此配置将提供 3 个 Voting Disks （每个Failure Group 一个）和 1 个 OCR，其中OCR的冗余是通过该磁盘组（在 ASM 中镜像）的冗余实现的。构成此冗余度为正常的磁盘组的 3 个磁盘的最小尺寸为 1GB。

• 在 11.2.0.2 中，Oracle Grid Infrastructure 可为私有网络（不是公共网络）提供冗余和负载均衡，对于 11.2.0.2 版本的GI（必须使用 11.2.0.2 Database），这是 NIC 冗余的首选方法。更多信息，请参考 Document 1210883.1.

• 对于版本 10gR2 和 11gR1，所有平台上的最佳实践都是将 CSS diagwait 参数设置为 13，以便在出现节点驱逐时提供转储诊断信息的时间。如果 Oracle Support 没有明确说明，建议 diagwait 的值不要超过 13。在 Oracle Clusterware 11g Release 2 中，将不再要求进行此设置。有关 diagwait 的更多详细信息，请参考 Document 559365.1 for more details on diagwait.
   
• 不要设置 ORA_CRS_HOME 环境变量（在所有平台上）。设置此变量将使各个 Oracle 组件出现问题，而且 CRS 程序完全不需要此变量，因为它们都有包装脚本。

虚拟化注意事项

• 具有特定平台、版本和补丁程序要求的特定虚拟化技术（如 Oracle VM）支持 Oracle Clusterware、Grid Infrastructure 和 RAC。在虚拟化的环境中部署 RAC 时，很重要的一点是要满足 RAC 虚拟化矩阵 中列出的支持要求，以确保成功实施受支持的部署。

安装注意事项

• 建议在安装 Oracle RAC 软件时使用本地文件系统，以允许使用滚动补丁升级，并避免出现单一故障点和其他故障。其它有关信息，请参见 Oracle Real Application Clusters Environment 白皮书。请注意，不支持将 11gR2 Grid Infrastructure 安装到集群文件系统上，请参见 Oracle Grid Infrastructure Installation Guide 11g Release 2 (11.2) for Linux 的 2.5.4 部分。
• 使用 cluvfy（集群验证实用程序）检查集群先决条件。在安装 Oracle 软件前，以及安装期间的所有阶段使用 cluvfy。安装 11gR2 之前的版本时，务必下载最新版本的 cluvfy OTN。 Document 339939.1 和 Document 316817.1 中包含了有关本主题的更多相关信息。

• 在执行 11gR2 之前的安装时，建议在执行任何 RDBMS 或 ASM 主目录安装前应用补丁程序将 Clusterware 主目录升级到所需的级别。例如，在安装 10.2.0.1 RDBMS 前，先安装 Clusterware 10.2.0.1 并使用补丁程序升级到 10.2.0.4。

• 在 11gR2 之前的环境中，出于维护和可用性的考虑（如独立补丁程序和升级），将 ASM安装到单独的ORACLE_HOME 。为轻松升级到 11gR2，ASM 软件所有者应与 Clusterware 软件所有者相同。

• 从 11gR2 开始，所有补丁程序集都是可完全安装的版本。例如，要安装 11.2.0.2（11gR2 Patchset 1），可直接安装 11.2.0.2，无需先安装 11.2.0.1 再应用补丁程序升级到 11.2.0.2。对于 11gR2 Grid Infrastructure，所有补丁程序集升级都是 out-of-place 的。对于 11gR2 RDBMS，您可以执行 out-of-place 或 in-place升级，但建议使用 out-of-place 升级方法。更多信息，请参考 Document 1189783.1.

• 如果安装 Oracle Clusterware的用户属于多个操作系统用户组，安装程序将在集群的所有节点上安装Oracle Clusterware，并将软件的组所有权设置为安装用户的当前活动组或主要组所有。因此，确保文件 /etc/group 中列出的第一个组是当前活动组，或使用以下命令行选项调用 Oracle Clusterware 安装，以强制安装程序在对所有文件设置组所有权时使用正确的组：runInstaller s_usergroup=current_active_group （Bug 4433140）

补丁安装注意事项

本部分旨在为新实施和现有实施制定积极的修补策略。对于新实施，强烈建议您在开始测试时，对您的平台应用最新的可用 Patchset 和适用的 Patch Set Update (PSU)。如果由于内部延迟或第三方应用认证或由于其他限制导致无法使用最新版本的 RDBMS，则仍建议 CRS 主目录和 ASM（或 Grid Infrastructure）主目录的 patch级别比 RDBMS 主目录高。作为最佳实践（有一些例外，请参见下面参考部分中的文档），Oracle Support 建议遵循以下说明：

• Clusterware（或 Grid Infrastructure）的补丁程序级别或版本必须高于或等同于 RDBMS 主目录的补丁程序级别或版本（比较到版本号的第四位）。对于 11.2 之前的版本，Clusterware 的补丁程序级别或版本必须高于或等同于 ASM 和 RDBMS 主目录的补丁程序级别或版本（比较到版本号的第四位）。

• 在应用补丁前，使用 opatch 检查ASM 或 Clusterware 主目录文件系统上的可用空间，并使用 Document 550522.1 估计需要多少空间，以及如果应用补丁期间出现文件系统被填满的情况时该如何处理。
  

• Document 557934.1 提供了在 11gR2 之前的版本中给 Oracle Clusterware 应用补丁的基本概述，并介绍了 Oracle Clusterware 的组件是如何通过应用补丁获得更新的。
  

• 如果要通过补丁程序将 Grid Infrastructure 从 11.2.0.1 升级到 11.2.0.2，请务必参考  Document 1312225.1 - "Things to Consider Before Upgrading to Grid Infrastructure 11.2.0.2" be reviewed。本文档介绍了所有必须遵守的先决条件和过程，以确保成功升级到 11.2.0.2。

• 制定积极的修补策略，对最新的已知问题防患于未然。应用最新的Patch Set Update（请参见 Document 850471.1中的介绍），并了解最新的推荐补丁（请参见 Document 756671.1中的介绍）。制定定期（如按季度）维护窗口的计划，以应用最新推荐的 PSU 和补丁程序。
  
  

升级注意事项

本部分实际上分为 2 个子部分。第一部分介绍 Clusterware、ASM 和 Grid Infrastructure 升级，第二部分介绍 RDBMS 升级。

Clusterware、ASM 和 Grid Infrastructure 升级注意事项

• 从 Oracle Clusterware 和 Oracle ASM 到 Grid Infrastructure 的升级应始终是 out-of-place 的。在 11g release 2 (11.2) 中，无法以 in-place 的方式将 Oracle Clusterware 和 Oracle ASM 升级。

• 如果现有 Oracle Clusterware 主目录是共享主目录，请注意，您可以对 Oracle Grid Infrastructure 使用非共享主目录。

• 在开始升级 Grid Infrastructure 或升级到 Grid Infrastructure 前，务必参考以下文档（取决于目标版本）：
  
  Document 1312225.1 - Things to Consider Before Upgrading to Grid Infrastructure 11.2.0.2
  Document 1363369.1 - Things to Consider Before Upgrading to 11.2.0.3 Grid Infrastructure/ASM

  下面列出了上述文档的一些要点（详细信息请参考文档）：

• 验证现有 Clusterware 和 ASM（或 Grid Infrastructure）配置是否正常
• 确保将所有必须的补丁程序应用于升级前的 Clusterware/ASM/Grid Infrastructure 主目录，例如：
  • 如果要从 GI 11.2.0.1 升级到 11.2.0.2，在尝试升级前，必须将 Patch 9706490 应用于 GI 11.2.0.1 主目录。
• 如要升级到 11.2.0.2，请验证集群私网上的多播功能。
• 在执行 rootupgrade.sh（或 root.sh）前，将 11.2.0.2 升级到最新的 GI PSU，详细说明请参考 Document 1312225.1。

• 如要升级到 11.2.0.3，请使用 RACcheck 的升级准备情况评估功能帮助执行升级前要求计划和升级后验证。有关其他详细信息，请参考  Document 1457357.1 RACcheck 11.2.0.3 Upgrade Readiness Assessment for additional details。
• 要将 10gR2 Clusterware 升级到 11g，根据 Oracle Upgrade Guide 11gR1  http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/upgrade.htm#BABCEGBC 所述，最低必须从版本 10.2.0.3 开始，11gR2 GI 平台特定的文档中也介绍了类似的内容。该文档介绍了以下内容：
  
  
  注意： Oracle 新添加了先决条件检查操作，以确保 Oracle Clusterware 10.2.0.x 版本为 10.2.0.3（或更高版）后，才能尝试将其升级到 Oracle Clusterware 11g release 1 (11.1)。如果此检查失败，系统将指导您将 Oracle Clusterware 补丁程序集 10.2.0.3.0 或更高版应用于现有版本，然后才能进行升级。所有其他升级路径和新的安装不会受这些先决条件检查操作的影响。

• 如果可能，可以对 Oracle Clusterware (CRS) 使用滚动升级，请参考 Document 338706.1。如需详细的升级帮助，请参考与您的版本对应的“升级指南”：  Document 466181.1 10g Upgrade Companion 和 Document 601807.1 Oracle 11gR1 Upgrade Companion。 对于 11gR2，Clusterware 自身的升级是滚动升级（所有节点上的旧版本的程序必须处于运行状态）；对于 ASM 11.1 和更高版本，ASM 升级也是滚动升级。ASM 11.1 之前的版本不是滚动升级。

• 如果计划在 11gR2 Grid Infrastrucutre 环境中运行 11gR2 之前的数据库，请查看 Document 948456.1 : Pre 11.2 Database Issues in 11gR2 Grid Infrastructure Environment。

• 对于 11.2.0.2 之前的数据库，11.2.0.2 HAIP 功能将不提供 NIC 冗余或负载均衡，如果计划在 11.2.0.2 Grid Infrastructure 上运行 11.2.0.2 之前的数据库，必须使用第三方 NIC 冗余解决方案，与 11.2.0.2 之前版本中的操作相同。

RDBMS 升级注意事项

• 请您务必查看与您的目标版本对应的“升级指南”：
  
  Oracle 11gR2 Upgrade Companion Document 785351.1
  Oracle 11gR1 Upgrade Companion Document 601807.1
• 查看与您的目标版本对应的“数据库升级指南”：
  
  Oracle Database Upgrade Guide 11g Release 2 (11.2)
  Oracle Database Upgrade Guide 11g Release 1 (11.1)
• 升级到 11gR2 时，务必查看 Best Practices for Upgrading to Oracle Database 11g Release 2 （升级到 Oracle Database 11g Release 2 的最佳实践）。
• 如要升级到 11.2.0.3，请使用 RACcheck 的升级准备情况评估功能帮助执行升级前要求计划和升级后验证。有关其他详细信息，请参见 Document 1457357.1 RACcheck 11.2.0.3 Upgrade Readiness Assessment for additional details.

• 如果在决定使用哪种方法将数据库升级到 11gR2 时需要帮助，请查看 Upgrade Methods for Upgrading to Oracle Database 11g Release 2 （升级到 Oracle Database 11g Release 2 的升级方法）白皮书。

• 在将 Oracle Database 10g 升级到 11g 时，请查看：
  http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-management-11gr2-133099.pdf

• 对于希望在升级数据库时将停机时间缩到最短的用户，可以考虑使用 logical standby 做过渡，请参考 Document 949322.1 : Oracle11g Data Guard: Database Rolling Upgrade Shell Script。

RAC 的数据库配置注意事项

数据库初始化参数注意事项

• 设置 PRE_PAGE_SGA=false。如果设置为 true，将大大增加建立数据库连接所需的时间。如果客户端投诉与数据库的连接太慢，则考虑将此参数设置为 false，因为这样做可以避免在进程启动时映射整个 SGA，从而节省连接时间。

• 确保监控活动并行服务器进程的数量并计算要应用于 PARALLEL_MIN_SERVERS 的平均值。可通过以下操作完成：

Select * from v$pq_syssstat;
Then: Get/save the value for row "Servers Highwater"

• 根据您的硬件情况优化 PARALLEL_MAX_SERVERS的值。最开始可以使用 (2 * ( 2 个线程 ) *(CPU_COUNT)) = 4 x CPU 计算，然后使用测试数据对更高的值重复测试。

• 考虑设置 FAST_START_PARALLEL_ROLLBACK。此参数可确定将有多少个进程用于事务 恢复（在 redo 应用后执行）。为了确保在出现计划外故障后仍能获得高效的工作负载，优化事务恢复显得非常重要。只要系统不大量占用 CPU，最佳实践是将此参数设置为值“HIGH”。这会导致 Oracle 使用四倍于 CPU 个数 (4 X cpu_count) 的并行进程进行事务恢复。此参数的默认值是“LOW”，或两倍的 CPU 计数 (2 X cpu_count)。

• 将 FAST_START_MTTR_TARGET 设置为非零值（以秒为单位）。崩溃恢复将在此要求的时间范围内完成。

• 在 10g 和 11g 数据库中，不应再设置初始化参数 ACTIVE_INSTANCE_COUNT。这是因为 RACG 层不会考虑此参数。作为替代，您应该创建具有一个首选实例的服务。

• 对于 11gR2 之前的版本，将 PARALLEL_EXECUTION_MESSAGE_SIZE 从默认值（通常为 2048）增加到 8192。对于基于数据仓库的系统（通过 PQ 传输大量数据），可以将其设置的更高。在版本 11gR2 中，PARALLEL_EXECUTION_MESSAGE_SIZE 的默认值是 16K，经证明，该值在大多数情况下都能够满足要求。

• 设置 OPTIMIZER_DYNAMIC_SAMPLING = 1 或确保您的数据库对象都收集了统计信息，因为 10g 动态采样在执行 SQL 语句期间可以生成额外的 CR 缓冲区。

• 对于所有版本在Oracle 10.2.0.3 到 11.0.6.0之间的数据库，LMON 进程可能会挂起，并且 Instance Manager Recovery (IMR) 无法驱逐挂起的实例。11.1.0.7 中已修正此问题。在 10gR2 中，可通过 bug 5259835 修复此问题。此增强已包含在 10.2.0.4.1 和更高版本的 PSU 中，在某些平台上作为 10.2.0.3 和 10.2.0.5 都有的one-off补丁程序。对于 11.1.0.6.0，需要进行以下设置：
  
  _lm_rcvr_hang_check_frequency = 20
  _lm_rcvr_hang_allow_time = 70
  _lm_rcvr_hang_kill = true

性能优化注意事项

• 在所有数据库系统中，不管是 RAC 还是单实例，最突出的性能改进往往都是通过使用传统应用程序优化技术实现的。在 RAC 数据库中，这些技术的优势尤为显著。

• 移除选择性不好的索引。在 RAC 环境中，对于频繁需要做插入操作的表，选择性不好的索引的数据块会频繁在不同节点间传输，从而导致节点之间的块争用。

• 为了避免“checkpoint not complete”情况和频繁的日志切换影响性能，建议至少为每个线程创建 3 个 redo（重做）日志组，并且 redo 日志的大小应允许每 15 - 30 分钟发生一次日志切换。请参见 Document 147468.1 了解详细信息。

• 使用自动段空间管理 (Automatic Segment Space Management, ASSM)。ASSM 表空间可自动完成 freelist 管理，并且不需要（也不能）为在这些表空间中创建的各个表和索引指定 PCTUSED、FREELISTS 和 FREELIST GROUPS 存储参数。请参见 Document 180608.1 了解其他详细信息。

• 增加 Insert 密集型应用的序列缓存，可以改进由序列产生的索引值的实例关联性。增加应用程序使用的序列和某些系统序列的缓存可获得更高的性能。使用约 10,000 或更大的缓存值。另外，虽然使用 NOORDER 属性最有效，但它并不能保证以请求顺序生成序列号（实际上这是默认设置）。
  
  注意： 此建议不适用于 OLAP S$ 对象。如果重组这些对象，则 OLAP AW（包含所有多维数据）将损坏，因为它们严格依赖于值的顺序。

• SYS.AUDSES$ 序列的默认设置是 20，这对于可从多个节点同时登录的 RAC 系统来说过低。请参考 Document 395314.1。 10.2.0.3 和更高版本中已修正此问题。

• 将 AWR 数据的保留期从 7 天增加到至少一个业务周期。使用 awrinfo.sql 脚本来计算需要存储在 AWR 中的信息量，然后进行相应的设置。

• 对在 RAC 环境中设置缓冲区缓存大小的建议与单节点相似，适用相同的优化程序。尽管实际内存要求取决于应用的工作负载，但一般建议是大约增加 10% 的缓冲区缓存以适应扩展要求（例如：1 个节点 - 1000 个用户，2 个节点 - 2000 个用户）。

• 优化 DataGuard 以避免出现与集群相关的等待。不正确的 DataGuard 设置可使 LOG FILE SYNC WAIT 和 GLOBAL CACHE LOG FLUSH TIME 变得较高。参考： http://www.oracle.com/technetwork/database/features /availability/maa-wp-10gr2-dataguardnetworkbestpr-134557.pdf and http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-recoverybestpractices-131010.pdf

数据库网络注意事项

• 正确配置 Oracle Net Services 负载均衡以分发连接。负载均衡应该与 Workload Management 结合使用以提供最高可用性。工作负载服务的 CLB_GOAL 属性应根据应用要求进行相应的配置。不同工作负载可能会有不同的负载均衡目标。请为每个服务使用 CLB_GOAL 单独配置每个工作负载。

• 对于 11.2 之前的 listener，请确保 IPC 项存在，且此项列在所有 RAC  listener 的 listener.ora 地址列表的第一个。否则，可能会对 VIP 在公网接口出现故障时进行故障转移所用的时长产生不利影响。请查看 Document 403743.1 了解详细信息。

• 对于 11.2 之前的实施，建议从 ASM 主目录（假设ASM在单独的ORACLE_HOME下运行）运行 listener。这样即可在带有 listener的一个节点上注册多个数据库，且无需绑定到特定数据库主目录。

• 对于 11gR2，默认情况下将从 Grid Infrastructure 主目录运行 listener。最佳实践是不修改此配置。

• 对于 11gR2 环境，不应为 Grid Infrastructure 环境设置 TNS_ADMIN 环境变量，因为它会导致 oraagent 无法维护 listener配置文件。TNS_ADMIN 也可能会影响 Clusterware 启动、停止和监控 listener 的能力。

• 强烈建议为 11.2 数据库使用 SCAN（用于 11.2 客户端连接），因为这样可以简化客户端连接，且在集群添加和（或）删除节点时无需修改数据库连接字符串。SCAN 也可以按照 Document 1058646.1 与 11.2 之前的客户端集成。有关 SCAN 的更多信息，请参见 Document 887522.1.

• 应该为listener配置 remote listener进行交叉注册以支持工作负载重定向和负载均衡，从而允许在 RAC 集群中分发服务连接请求。通过此配置，每个 listener都会知道是哪个实例在处理特定服务以及当前给定的数据库实例上有多少负载。这让客户端可以在 listener之间对要在服务级别进行管理的工作负载进行连接请求的负载均衡。请参见 Document 728787.1 - How to Set Up Cross-Registration in RAC.

• 在 11gR2 之前，LOCAL_LISTENER 参数应该指向正在运行特定数据库实例的本地系统 listener的 VIP地址。对于 11gR2，LOCAL_LISTENER 参数应设置为其默认值，以允许 oraagent 根据 OCR 中存储的 listener配置正确设置参数。

• 一般而言，每个 RAC 节点（不包括 SCAN）仅需要一个 listener为给定集群上运行的所有数据库处理连接。如果需要或要求在每个集群节点上使用多个 listener，则务必在 OCR 上注册这些额外的 listener，以确保这些额外 listener的 HA 和正确管理。

• 建议创建额外数据库服务以处理应用程序连接，而使用默认数据库服务用于管理用途。这样，管理员除了能够轻松控制哪些应用程序连接到哪些实例，同时 还可以灵活地实现诸如服务器端 TAF、FAN、FCF 和运行时连接负载均衡等功能。有关这些服务的更多信息，请参见“Oracle Real Application Clusters Administration and Deployment Guide 11g Release 2 (11.2)（Oracle Real Application Clusters 管理和部署指南 11g Release 2 (11.2)）”中的 Chapter 5。

• 利用面向连接的可用性功能，例如透明应用故障转移 (Transparent Application Failover, TAF)、快速应用通知 (Fast Application Notification, FAN)、快速连接故障转移 (Fast Connection Failover, FCF)、运行时连接负载均衡 (Runtime Connection Load Balancing, RCLB)。有关更多详细信息，请参见 Automatic Workload Management with Oracle Real Application Clusters （Oracle Real Application Clusters 自动工作负载管理）白皮书。
• 使用安全传输类 (Class of Secure Transport, OST) 限制实例注册，从而防止数据库向 listener进行未授权注册。这样可以避免 Oracle 安全警告 CVE-2012-1675 中发布的问题。有关实施 COST  listener注册的说明，可以在 Document 1340831.1 中找到。

一般数据库注意事项

• 在 10gR2 和更高版本中，LMS 进程应该在实时调度类中运行。在某些情况下，我们注意到该操作由于 oradism 可执行文件（存储在 $ORACLE_HOME/bin 目录中）的所有权和权限不正确而被阻止。有关它的更多详细信息，请参见 Document 602419.1。

• 在给定集群节点上运行的数据库实例数量应受到限制，以便节点上的实时 LMS 进程总数不会超过建议的 CPU 数量 – 1。所有这些实时进程都可能使给定集群节点超载，从而导致性能不佳和实例/节点驱逐。对于 LMS 进程数量（gcs_server_processes 参数），如果没有 Oracle Support 的指导，不应修改其默认值。请参见 Document 558185.1 了解详细信息。

• 对于 11gR2（默认情况下禁用 NUMA）之前的版本，除非明确要求并已经过测试，请确保禁用 NUMA（Non Uniform Memory Architecture）功能，因为根据报告显示，启用 NUMA 后会出现问题。请参考 Document 759565.1 了解详细信息。

• 阅读并遵循 XA 和 RAC 的最佳实践指南，以避免XA 事务被拆分到多个RAC 实例的问题。请参考： http://www.oracle.com/technetwork/database/enterprise-edition/bestpracticesforxaandrac-128676.pdf 和 http://www.oracle.com/technetwork/database/clustering/overview/distributed-transactions-and-xa-163941.pdf

• 从运行数据库的 RDBMS 主目录中使用 SRVCTL 注册并管理数据库资源。资源注册必须由拥有 RDBMS 软件的 OS 用户执行。

诊断和故障排除

一般注意事项

• 查看 Document 166650.1 Working Effectively with Global Customer Support。它将帮您了解作为 Oracle Support 客户可用的支持流程、程序和资源。

• 主动安装并运行 OSWATCHER (OSW) 以获得 OS 资源使用情况。OSW 是用于收集操作系统和网络信息，以帮助诊断性能问题的 UNIX shell 脚本集合，这些脚本被设计为连续运行并将这些指标保存到归档目录的 ASCII 文件。保存的归档数据量和收集频率基于用户在启动 OSW 时设置的参数。强烈建议始终在集群所有节点上安装并连续运行 OSW。请参考 Document 301137.1。 请确保为每个节点使用单独的目录以存储 OSW 输出。在 RAC 环境中使用 OSWatcher 时，每个节点必须将其输出文件写入到单独的归档目录。不支持将所有节点的输出放到同一个目录下，因为这样将导致 OSWg 工具崩溃。可以放到共享存储上，但每个节点都需要一个单独的归档目录。

• 在Windows、Solaris 和 Linux 平台上，可以使用 Cluster Health Monitor (CHM) 来跟踪 OS 资源消耗并在整个集群范围内收集和分析数据。对于 Linux 和 Solaris，会随 Grid Infrastructure 11.2.0.2 自动安装 CHM。对于 Windows 和 Linux，可以 单独下载 （如果未运行 11.2.0.2 GI）。如果您正在 Solaris 或 Linux 上运行 11.2.0.2 GI，您不能安装单独下载的 CHM。有关 CHM 的更多信息，请参见 Document 1328466.1。

• 使用集群 deinstall 工具来移除 CRS 安装（如果需要）。clusterdeconfig 工具将移除并取消与 Oracle Clusterware 或 Oracle RAC 数据库安装关联的所有软件和共享文件的配置。clusterdeconfig 工具将移除集群中所有节点中的软件和共享文件。请参考 http://www.oracle.com/technology/products/database/clustering/index.html

Clusterware 和 Grid Infrastructure 诊断

• 在向 Oracle Support 发出与 Clusterware/Grid Infrastructure 问题相关的 SR 时，建议按照 Document 330358.1 中所述，上传 diagcollection 实用程序的输出。如果这是节点驱逐相关问题，还应该上传 OSWatcher 或 CHM 数据（请参见上文的 OSWatcher 和（或）CHM 信息）。在创建 SR 时提供此数据可以减少 SR 的周转时间。有关 Grid Infrastructure 和 Clusterware 问题的诊断收集的其他信息，请参见：
  Data Gathering for Troubleshooting CRS Issues Document 289690.1

• 在解决Clusterware 和 Grid Infrastructure问题时，以下文档通常非常重要：
  
  RAC: Frequently Asked Questions Document 220970.1
  11gR2 Clusterware and Grid Home - What You Need to Know Document 1053147.1
  Troubleshooting 11.2 Clusterware Node Evictions (Reboots) Document 1050693.1
  Troubleshooting 10g and 11.1 Clusterware Reboots Document 265769.1
  Data Gathering for Troubleshooting CRS Issues Document 289690.1
  
  注意： 有关更多信息，请参见 Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure Document 1096952.1 .

RAC 数据库诊断

• 在向 Oracle Support 发出与 RAC 数据库问题相关的 SR 时，请务必查看 Document 289690.1 ，以确保在创建 SR 时收集并提供正确的诊断信息。预先提供这些信息可以减少 SR 的周转时间。

• 在解决 RAC 相关的数据库问题时，以下文档通常非常重要：
  
  RAC: Frequently Asked Questions Document 220970.1
  GC Lost Blocks Diagnostics Document 563566.1
  Troubleshoot ORA-29740 errors in a RAC Environment Document 219361.1
  11g How to Unpack a Package in to ADR Document 745960.1
  11g Quick Steps to Package and Send Critical Error Diagnostic Information to Support Document 443529.1
  Data Gathering for Troubleshooting RAC Issues Document 289690.1
  
  注意：有关更多信息，请参见 Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure Document 1096952.1 .

应用补丁诊断 (OPatch)

• 在解决 OPatch 相关的数据库问题时，以下文档通常非常重要：
  
  Top OPATCH/PATCH Questions/Issues in Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environment Document 1339140.1
  
  注意： 有关 OPatch 的更多信息，请参见 Master Note for OPatch Document 293369.1