RAC 11.2 体系结构（二）
Failover的相关讨论
当设计一个机遇RAC的应用的时候，开发人员和设计人员需要面对一个事实就是：即使是最好的硬件也不是100%可靠的。使用RAC可以降低实例故障带来的影响，但在应用端上需要做一些额外的措施来屏蔽故障对应用带来的影响。
但是，并不是所有的应用都支持RAC。商业的、现成的包常常不支持RAC。在这些情况下，一个active/passive集群或RAC One Node系统是一个合适的替代方案。
供应商提供的支持RAC的应用或内部开发的应用可以使用不同的高可用技术来屏蔽实例故障。这些技术包括TAF(Transparent Application Failover)和FCF(Fst Connection Failover)。
应用经常是在单实例Oracle中开发的，这不是一个问题，因为应用照样可以工作在RAC中。但把failover支持添加到内部开发或源代码可用的应用中汇更加容易。当设计一个新的应用时，故障切换应该一开始就要考虑，因为重新设计再引入这个特征的成本可能会很大。
透明应用切换(TAF)
TAF允许数据库连接在一个节点发生故障时，使用OCI库来故障切换到另一个存活的节点中。使用JDBC thin driver的应用不能从这个特性中得到好处，因为该驱动不使用OCI。TAF是一个客户端的特性：当发生节点故障时，将发送一个通知给客户端上的触发动作。
切换模式
TAF可以配置在两个模式下工作，或者可以禁用。如果把失效也算作一个模式的话，TAF可以有下面三个选项：Session failover、Select failover、None(默认)。
session failover模式可能是最常见的情况，因为它不需要任何代码上的变动来实现。所有需要做的就是在tnsnames.ora文件中配置一个适当的本地命名定义或将TAF策略关联到数据库服务中。TAF会在一个节点发生故障时自动使用相同的连接串来重新连接用户会话。
select failover模式允许客户端在连接重新建立后从打开的游标中集训获取记录。本质上，TAF会重新执行相同的查询，然后丢弃已经返回给用户的那部分记录，来实现故障切换的透明。会有一些轻微的开销，因为Oracle需要对已经传输的数据进行追踪。
如果你显式指定了none作为failover类型，不会做任何故障切换。指定none而不是省略FAILOVER_MODE参数的唯一理由，就是要显式地禁用TAF。
故障发生时任何执行DML而发生的改变都不能通过TAF来恢复，在这种情况下，未提交的事务在会话重建后将被回滚。
除了节点故障以外，TAF还能与Data Guard、active/passive集群一起配置，在Data Guard环境中能提供一个故障切换能力。
Failover Methods
指定了failover mode后，用户可以进一步定义一个方法来确切地指定TAF如何重建在其他实例上的连接。failover method可以在failover type外单独定义，failover method决定failover如何工作，可用的选项有：Basic、Preconnect。
和名称一样，basic选项让客户端只有在节点故障以后才会重建一个新的连接。这可能会导致存活的节点上会收到大量新的连接请求。在双节点RAC的情况下，在所有用户连接都重建完以前，可能会导致性能问题。如果你准备使用这种方法，应该在设计阶段就对可能的性能问题进行测试。
preconnect选项配置要稍微更麻烦一些。当你指定了preconnect参数，客户端将在备份实例上预连接一个会话来加速会话的切换。你要记住这些预建立的连接会增加集群的会话数量。另外，你需要定义这些备份连接。
快速连接切换(FCF)和快速应用通知(FAN)
- Java数据库连接驱动(JDBC)
- Oracle Universal Connection Pool(UCP)
- 使用OCI的客户端
- Oracle Data Providers for .Net