TAF详解

Client-Side TAF

Client-Side TAF 的配置很简单,只需要在客户端的tnsnames.ora中添加FAILOVER_MODE配置项。这个条目有4个子项目需要定义。

METHOD

用户定义何时创建到其实例的连接,有BASIC 和 PRECONNECT 两种可选值。

  • BASIC: 是指在感知到节点故障时才创建到其他实例的连接。
  • PRECONNECT: 是在最初建立连接时就同时建立到所有实例的连接,当发生故障时,立刻就可以切换到其他链路上。

两种方法比较: BASIC方式在Failover时会有时间延迟,PRECONNECT方式虽然没有时间延迟,但是建立多个冗余连接会消耗更多资源,两者就是是用时间换资源和用资源换时间的区别。

TYPE

用于定义发生故障时对完成的SQL 语句如何处理,其中有2种类型:session 和select.

这2种方式对于未提交的事务都会自动回滚,区别在于对select 语句的处理,对于select,用户正在执行的select语句会被转移到新的实例上,在新的节点上继续返回后续结果集,而已经返回的记录集则抛弃。

假设用户正在节点1上执行查询,整个结果集共有100条记录,现在已从节点1上返回10条记录,这时节点1宕机,用户连接被转移到节点2上,如果是session模式,则需要重新执行查询语句;如果是select方式,会从节点2上继续返回剩下的90天记录,而已经从节点1返回的10条记录不会重复返回给用户,对于用户而言,感受不到这种切换。

显然为了实现select 方式,Oracle 必须为每个session保存更多的内容,包括游标,用户上下文等,需要更多的资源也是用资源换时间的方案。

DELAY 和 RETRIES

这2个参数分别代表重试间隔时间和重试次数。

Service-Side TAF

Service-SideTAF 可以看作是TAF的一种变种,首先Service-SideTAF也是TAF,所有TAF的特点它都有,其次这种TAF是在服务器上配置的,而不像TAF是在客户端配置的。

Client-Side TAF 是在客户端修改tnsnames.ora 文件来配置的,如果有很多客户端使用这个数据库,那么每次微笑调整都需要把所有的计算机更改一遍,既低效又容易出错。而Service-Side TAF 通过结合Service,在数据库里保存FAIL_MODE的配置,把所有的TAF配置保存在数据字典中,从而省去了客户端的配置工作,现在客户端的TNS文件就不需要任何TAF的配置选项了。

从配置参数而言,Service-Side TAF和TAF 相比多了一个Instance Role(实例角色)的概念。 所谓的实例角色,就是当有多个Instance 参与一个Service时,可以配置优先使用哪一个Instance为用户提供服务。用户共有两种可选角色。

  • PREFERRED:首选实例,会优先选择拥有这个角色的实例提供服务。
  • AVAILABLE: 后备实例,用户连接会优先连接PREFFERRED的Instance,当PREFERRED的Instance不可用时,才会被转到AVAILBALE的Instance上。

要使用Server-Side TAF必须配置Service。 Service 可以在创建数据库时创建,也可以在创建数据库之后修改,既可以使用dbca 配置向导,也可以用命令行的方式配置。

TAF详解TAF详解 Ray-Song 发布了6 篇原创文章 · 获赞 0 · 访问量 50 私信 关注
上一篇:R语言统计入门第二章R语言环境——2.2作图系统


下一篇:动态更新-算法模版合集