Oracle数据库教程：RAC 11.2 体系结构

这一部分我们在RAC上应用的高可用设计的层面上，讨论一些Oracle数据库的特性。我们同时也会指出，什么地方可用性会被限制，比如打

这一部分我们在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系统