Oracle数据库教程：RAC 11.2 体系结构
Oracle数据库教程：RAC 11.2 体系结构
这一部分我们在RAC上应用的高可用设计的层面上，讨论一些Oracle数据库的特性。我们同时也会指出，什么地方可用性会被限制，比如打补丁和重要的数据库升级。然后我们将视线转移到站点间的可用性，讨论Data Guard(灾备)和Oracle Streams(信息共享与复制)。RAC解决方案不是孤立的，很多组件扮演一个角色、很多技术被利用来搭建一个健壮的、高可用的、可扩展的应用。
可用性
很多用户选择RAC解决方案，因为他们需要他们的应用对客户持续可用，且可以容忍一些类型的故障而不会中断服务。在这个应用多层、面向网络的时代，可用性和应用的可扩展性事保证用户基础的关键。调查发现，如果用户在浏览器访问一个web页面，如果在大约十秒钟以内不能完全出现结果，那么他们会很烦躁，常常会离开很少还会回来。
会损害系统的可用性的中断从根本上分为两类：计划和非计划。Oracle技术提供了大量互补的技术，可以避免几乎所有类型的中断。下面两个表分别列出非计划中断的挽救措施和避免中断的技术。
节点数的决策
很多RAC系统都只有两个节点。你可以常常在英国的Oracle用户会议的举手投票中得到这样的结果。这样的系统常常用在类似active/passive集群中，RAC完全为了高可用而部署。 适当的节点数的讨论不应该局限在在线生产系统。在用户适应RAC以前，他们很可能在类似展示和质量保证的生产前环境中考虑过节点数量，也可以用作容灾方案。由于很多原因，有一个与生产环境一样的生产前的环境是很有益处的，否则你可能会在代码发布以后经历不愉快的体验。你可以在一个与生产环境完全一样的拷贝中进行测试——如果你的数据与生产环境不同步；所有的测试都有可能出错。一个非生产的RAC集群是必要的，用来在生产库里应用补丁前先在非生产库里测试，以避免非计划中断或Oracle程序文件的损坏。 如果没有多余的硬件或预算来创建一个用来测试RAC系统，你可以在一个服务器上创建一个虚拟的RAC系统。Oracle VM是一个免费的虚拟机管理软件。 灾难恢复(DR)站点的性能应该与生产站点相同；当发生危机需要启用DR站点时的最后一件事，是确保DR站点能承载工作量。将老的生产环境回收来作为DR是不推荐的。
双节点RAC集群
两节点的RAC有一些优势：首先，购买许可的成本比较低；第二，只有两个节点可以使全局缓存转移得到简化，因为不会出现三向的通讯。标准版RAC的许可条件看起来不允许超过2个装备了新型处理器的节点，因此你的拓扑不如企业版的灵活。
当设计和实施这样的安装，每个单独的节点需要在发生节点故障时承担所有的负载。或者在这样的情况下，通知用户只进行必要的操作来使工作量降低。单独的RAC节点的处理能力可能会随着时间而降低，那时候会有更大的问题，因此这些安装必须能承受大于全部工作量的负载。
Oracle RAC One Node
在Oracle 11.2中，引入了一种介于RAC和active/passive中间的混合RAC，它叫做RAC One Node。当你需要扩展到完全的RAC时，这种转换将比较简单。RAC One Node的主要目的之一是允许计划停机，例如，运行中的数据库实例可以使用omotion工具移动到另一台主机上而对应用没什么影响，然后可以在原先运行实例的主机中进行维护操作。与RAC系统不同，它只有一个实例来为用户连接服务；不过，它还是需要以RAC数据库的方式创建。
这个实例注册在Oracle Grid Infrastructure、元数据仓库和集群高可用框架中。通过这种方法，RDBMS实例可以从Grid Infrastructure提供的高可用选项中获益，也就是故障检测和保护、在线滚动打补丁和在线滚动升级。
RAC One Node发布的第一个版本是在11.2.0.1，只能用在Linux系统中。它不支持Data Guard，在默认的安装中也不可用。对RAC One Node感兴趣的用户必须下载My Oracle Support补丁9004119。其他平台的管理员想使用的话需要等待第一个补丁集的发布。用户指南还提示RAC One Node将不支持第三方集群软件，比如Veritas Storage Foundation for RAC或者HP Serviceguard。一旦RAC数据库在一个节点上创建，一些工具将作为上面提到的补丁的一部分安装，允许用户将系统转换成RAC One Node数据库。这个转换通过raconeinit命令来进行，当它执行完毕后，你会发现数据库实例被重命名为instanceName_1。
就像上面提到的，一个新的工具叫omotion允许用户将一个RAC One Node实例转移到集群中的另一个节点上。当需要对节点做一个计划维护，或者你的集群节点用完了所有资源，容纳不下数据库的时候，移动实例会很有用途。为了减轻应用上对用户的影响，需要使用TAF或FCF。如果不使用的话，正在执行的事务会在某个用户可定义窗口中完成；然后，接下来用户连接将会被断开，并出现ORA-3113"End of line on communication channel"错误。这个错误是由宽限期后开始的数据库实例的关闭导致的。
如果需要将一个RAC One Node转变为"full" RAC，另一个工具racone2rac可以用来简化这个过程。只需要从一个文本菜单中选择你的RAC One Node数据库，然后让这个工具将其转换为RAC数据库。转换的结果看起来与使用policy-managed数据库的结果类似。policy-managed数据库是11.2中引入的新特性，标志了传统RAC数据库的一个转变，以前数据库管理员需要负责管理RAC数据库的所有方面，比如初始化参数、在线redo线程和其他结构上的改变。通过policy-managed数据库，DBA只需要定义数据库节点的数量，Oracle会接管剩下的工作(增加/删除节点)。所有需要而当前没有的组件都会自动创建。
多节点RAC系统
当单个节点发生故障时，多节点的系统比双节点集群更容易支撑所有的工作量。一个正确设计的RAC系统应该有足够的冗余来保证应用可以继续运行，产生尽量小的中断。因此很多企业采用了超过2个节点的RAC。在这种情况下，设计一个n节点的集群时，这个集群应该在只有n-1节点工作时支持全部的工作量。这意味着集群中有一个节点可以作为冗余，这个冗余的节点也不需要处于闲置状态。比如，它可以用来做备份和报告；唯一的要求是，它能在短时间内为集群提供它的处理能力。 从Oracle 10.1开始，当确定当前集群的节点数不足以支持工作量时，可以在线添加节点到集群中。在Oracle 11.2中，引入了网格即插即用和策略管理的数据库使这个过程得到了改进和简化。
在线维护和打补丁
不管一个新的系统在上线前经过了多么仔细的测试，它迟早需要打补丁。这有多个原因，通常主要原因如下：一个内部错误导致应用不可用；当前使用的版本马上要不被支持。例如，Oracle在2010年不再主要支持10g r2（但Oracle将服务免费延长一年），这可能会是将数据库升级到下一个版本的原因；一个关键的安全补丁需要应用；合同要求履行预定的维护工作。 打补丁会对可用性产生影响，虽然Oracle通过在线打补丁和滚动补丁应用机制改进了这种状况。Oracle中补丁应用的主要工具是opatch。但是，关键的版本审计不能通过opatch来执行，你需要使用OUI来来达到这个目的。 （有一点很重要，在高可用系统中，不要为了打补丁而打补丁。） 所有的补丁应用都是有风险的，不管你事先做了多少测试。几乎所有的DBA都可以讲述一个因为应用补丁导致的错误。打补丁同时意味着在一个节点中修改二进制文件时，需要提供这个节点的停机时间。 在Oracle数据库领域里，有一些不同种类的补丁，下表做一个介绍：
|
评论暂时关闭