使RAC环境稳定运行的首要三件事nbsp;nbsp;…

本文主要是介绍使RAC环境稳定运行的首要三件事nbsp;nbsp;…，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

使RAC环境稳定运行的首要三件事

By Allen Gao on 六月 15, 2012

from ：https://blogs.oracle.com/Database4CN/entry/使rac环境稳定运行的首要三件事

确保您的核心数据库基础架构实现高可用性和可扩展性在很多时候是一个复杂的任务。然而，在世界范围内每天有成千上万的Oracle RAC系统都能够成功完成这个复杂的任务。而保证在扩展您的系统同时，又能够最大化系统正常运行时间的一个关键，就是应用确保RAC系统稳定运行的最佳实践，这些最佳实践已经经过时间的验证并且在很多系统上都被成功应用。在这篇文章中，将会讨论3个所有RAC系统都应该遵守的最佳实践。

本文内容主要基于MOS 文章"Top 11 Things to do NOW
to Stabilize your RAC Cluster Environment”（DOC ID 1344678.1）。然而，在这里，我们将只介绍3件最重要和最关键的事情，使您的群集环境更加稳定。虽然许多这些概念和最佳实践不是新的，事实上，许多概念和最佳实践已经被介绍了多年，但是，根据技术支持所解决的问题统计，我们发现由于没有遵守最佳实践而导致的问题数量，仍然是一个惊人的数字。因此，这篇文章的目的是阐明这些基本的最佳实践的作用，以尽可能的避免RAC DBA的痛苦。

了解补丁集更新 (PSU)策略,尽快应用最新发布的PSU。

这是名单上的第一个主题，也是最关键的。Oracle每季度发布的补丁集更新（PSU）。这些PSU中包含了少数关键修复。至关重要的是，这些PSU应该定期在您的环境中应用。每个季度更新PSU补丁是极力推荐的，但如果您的系统不能每个季度更新PSU，您应该争取至少每6个月更新一次。这样做会大大降低您命中常见BUG的可能性，而且如果问题确实出现，也将大大缩短解决问题的时间。根据最近的统计，在过去9个月中，新建的RAC和集群（Cluster）BUG，低于7％的新BUG需要修正代码，其中近三分之一为已知BUG的重复问题。这些问题本来是可以通过应用当前的PSU避免的。对于RAC的客户，PSU有几个关键的优势：

PSU可以仅打在Grid Infrastructure（GI）home，而无须在同一时间应用到RDBMS home。如果需要的话，只要GI home首先打了PSU，可以在其它home上单独应用，缩短了维护时间。由于GI不会直接影响您的应用程序，许多客户发现，相比RDBMS PSU，GI PSU需要较少的测试。由于GI home可以独立应用PSU，所以也可以早于RDBMS更新PSU。
RAC环境中的PSU可以通过rolling的方式安装 –这种方式同时适用于GI和 RDBMS。这意味着只要通过适当的测试和计划，应用PSU不需要停机时间，这对于高可用性环境是至关重要的。

如果您的版本不在最新的PSU，我们建议尽快制定计划纠正，并努力保持在当前的PSU。底线是，投入在RAC环境上的规划定期检测和应用PSU的时间，会通过避免问题而节省大量的问题解决时间。

关于PSU的更多信息, 请参考下面的MOS文章：

NOTE 854428.1 Intro to
Patch Set Updates (PSU)
NOTE 1082394.1 11.2.0.X Grid Infrastructure PSU Known
Issues
NOTE 756671.1 Oracle
Recommended Patches -- Oracle Database
NOTE 161549.1 Oracle
Database, Networking and Grid Agent Patches for Microsoft Platforms
NOTE 810394.1 RAC and
Oracle Clusterware Best Practices and Starter Kit

11gR2之前版本的集群，将Diagwait设置为13。

在2012年，接近45％的服务请求是关于11gR2之前版本的集群，虽然设置diagwait为13已经做为RAC最佳实践之一实行了多年,但是由于diagwait值没有被正确设置而引起的问题，仍然是一个惊人的数字。从本质上讲， diagwait值在RAC环境中控制着两件关键的事情：

默认情况下，集群守护进程OPROCD的超时值为1秒和0.5秒的时间差，这意味着，如果OPROCD不能在 1.5秒内返回，系统会被重启。设置diagwait为推荐值13会将OPROCD的默认超时时差增加到10秒（ diagwait - CSS重启时间[默认为3秒]），从而防止大量由于OPROCD没有在定义的时间内返回而导致的'假'的节点重启。对于繁忙的系统，1.5秒的默认值太小了。长期推荐的办法是将OPROCD超时提高到一个更为合理的值11秒（1秒休眠时间+10秒时间差）。
当节点驱逐/重启事件发生时，增加diagwait，我们更可能在重新启动之前将日志信息刷新到磁盘，因此，缩短寻找问题根本原因时间。

从11g第2版（11.2.0.1和更高版本）开始，这一变化不再是必要的。然而，对于之前的版本，这个改变必须在一个完整的停机时间进行，而且这个值不能通过补丁修正。因此，必须安排停机时间手动修改。鉴于已知通过设置diagwait解决的问题的数量，申请停机时间来修改它是值得的投入。请注意，因为这个值存储在Oracle集群注册表（OCR），如果您的确需要重建OCR或从一个之前的备份恢复，您可能需要重新设置diagwai。检查当前值可以通过以下简单的命令：

# $CLUSTERWARE_HOME\bin\crsctl get css diagwait

关于更多DIAGWAIT的信息,请参考下面的MOS文章:

NOTE
567730.1 Changes in Oracle Clusterware on Linux with the 10.2.0.4
Patchset
NOTE
559365.1 Using Diagwait as a diagnostic to get more information for
diagnosing Oracle Clusterware Node evictions
NOTE
810394.1 RAC and Oracle Clusterware Best Practices and Starter Kit

应用OS Watcher Black Box（OSWbb）或 Cluster Health Monitor（CHM）

虽然您可能不认为OS监控可以作为一种预防性的工具，但是，它实际上是。OS Watcher Black Box（OSWbb）（原名OS Watcher）和Cluster Health Monitor（CHM）的目的是收集有关OS的信息，帮助DBA和系统管理员识别集群问题的原因。如果不能直接预防问题发生，那么在问题第一次出现的时候，有更多的数据进行分析，就可以增加防止同样问题在未来再次发生的可能性。如果OS的指标被密切监测，您有可能在问题即将发生前，在它对您的环境造成实际影响之前发现问题。

OSWbb是一个非常轻量级的，但非常有效的，定期搜集OS统计信息的工具。除了非常轻便，与标准的OS监控工具相比OSWbb的好处是双重的：

默认情况下，它每30秒搜集一次信息。许多OS监控工具使用更大的时间间隔（例如5分钟）收集信息。在解决节点驱逐或实例驱逐问题时，每1分钟或5分钟搜集数据与实际所需要的时间间隔差距太大了。以30秒甚至更短的间隔，Oracle技术支持更有可能了解在问题期间OS的行为。对于节点重启的问题，Oracle技术支持建议OSWbb每20秒收集一次信息。
OSWbb的第二个关键优势是它可以很容易的被Oracle技术支持分析。当然您可以自由的使用其它OS监控工具，但是，您可能需要借助第三方供应商解释这些信息。由于缺乏对Oracle集群的基本理解，这样做会减慢问题解决的进程，甚至可能将问题导向错误的解决方向。

从版本11.2.0.3开始，在所有的平台（HP-UX除外）上，Oracle GI包含了新的监测工具，Cluster Health Monitor (CHM)。CHM也是轻量级的，收集数据比OSW更加频繁，然而，数据保留时间比OSW短。因此，这两个工具是互补的。

Oracle技术支持强烈建议所有的集群环境都安装OSWbb和/或CHM，并确保能够正常运行，旨在对群集的运作提供额外的信息和深入了解，从而提高稳定性。至于OSWbb，请确保该工具安装在每个RAC节点，并且在系统重新启动后仍然能够自动启动（请参阅NOTE 580513.1“How To Start
OS Watcher Black Box Every System Boot”获得更多信息）。