这一部分我们在RAC上应用的高可用设计的层面上，讨论一些Oracle数据库的特性。我们同时也会指出，什么地方可用性会被限制，比如打补丁和重要的数据库升级。然后我们将视线转移到站点间的可用性，讨论Data Guard(灾备)和Oracle Streams(信息共享与复制)。RAC解决方案不是孤立的，很多组件扮演一个角色、很多技术被利用来搭建一个健壮的、高可用的、可扩展的应用。

可用性 

很多用户选择RAC解决方案，因为他们需要他们的应用对客户持续可用，且可以容忍一些类型的故障而不会中断服务。在这个应用多层、面向网络的时代，可用性和应用的可扩展性事保证用户基础的关键。调查发现，如果用户在浏览器访问一个web页面，如果在大约十秒钟以内不能完全出现结果，那么他们会很烦躁，常常会离开很少还会回来。

会损害系统的可用性的中断从根本上分为两类：计划和非计划。Oracle技术提供了大量互补的技术，可以避免几乎所有类型的中断。下面两个表分别列出非计划中断的挽救措施和避免中断的技术。

       当设计和实施这样的安装，每个单独的节点需要在发生节点故障时承担所有的负载。或者在这样的情况下，通知用户只进行必要的操作来使工作量降低。单独的RAC节点的处理能力可能会随着时间而降低，那时候会有更大的问题，因此这些安装必须能承受大于全部工作量的负载。

       在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会接管剩下的工作(增加/删除节点)。所有需要而当前没有的组件都会自动创建。

您可能感兴趣的文章: