Oracle RAC具备高可用性（High Availablity）和负载均衡（Load Balance）的特性。
其中高可用性的基础就是Failover（故障转移），它主要的功能是集群中任何一个节点的故障都不会影响用户的使用，连接到故障节点的用户会被自动转移到其他正常的节点上，对于用户而言，是感觉不到这种切换的。
Oracle 10g RAC的Failover主要分为以下三种：
其中Client-Side Connection time Failover和TAF（Transparent Application Failover）都是基于客户端配置的Failover。Service-Side TAF是基于服务器端的Failover。
基于客户端连接的Failover，主要是通过在客户端的tnsnames.ora中配置多个节点的地址来实现。当用户发起连接请求时，会从连接地址表中的第一个开始尝试连接，如果连接失败，则继续尝试连接地址表中的下一个地址，直到连接成功或则遍历完所有的地址。
特点：
1、 配置简单
2、 只能在连接的时刻起作用，也就是说，这种方式只在客户端发起连接的时候才会去判断节点是否有问题，如果有问题，则会尝试下一个地址。但是一旦连接建立后，节点出现问题就不会处理，这样的结果就是抛出连接错误，客户端直接断开，然后需要重新建立连接
说明：
如果使用这种方式连接，服务端的listener.ora文件中不能设置global_name
示例：
注意：
这里的orlrac1-vip和orlrac2-vip最好是设置成具体的IP地址，而不是hostname。
如果要在客户端的tnsnames.ora中使用orlrac1-vip和orlrac2-vip，就必须在/etc/hosts文件中，配置orlrac1-vip和orlrac2-vip的IP地址。
由于目前大部分应用系统都采用配置连接池的方式来访问数据库，都是在启动的时候就建立了若干个长连接，便于在应用程序的整个生命周期中重用这些连接。
在这种情况下，基于Client-Side Connection time Failover方式的Failover就对程序高可用性方面没有太大的作用。
在这种情况下，oracle推出了Transparent Application Failover这种新的机制。在数据库连接建立以后，如果某个实例发生了故障，那么连接到这个故障实例的连接会自动地迁移到其他可用的实例上。整个这个过程对于应用程序来讲是透明的，不需要其他用户介入，但是未提交的事务还是会回滚。
配置方法：需要在客户端的tnsnames.ora配置Failover_mode配置项
该配置项有以下的5个子项目需要配置。
1、 Method
定义用户什么时候创建到实例的连接，有两个可选项
Basic：在有节点故障时才创建到其他实例的连接
Preconnect：在最初建立连接时就同时建立了到所有实例的连接，当发生故障时，就立刻可以切换到其他链路上去。
Basic方式建立的连接开销较小，但是在Failover的时候会产生延迟，Preconnect方式就恰好相反
2、 Type
定义发生故障时，对完成的SQL如何处理。有三个选项
Select：如果使用这种方式，Oracle net会跟踪事务期间的所有select语句，并跟踪每一个与当前select相关的游标已返回了多少行数据给客户端。即如果一个select查询一共要返回1000条数据，在返回500条的时候出现故障，此时oracle net会自动建立一个新的连接到其他正常的节点上，并继续返回剩下的500条数据。
Session：使用这种方式，所有select的查询相关结果会在建立新的连接后丢失，需要重新发起SQL后再返回所有的数据，虽然会自动重新连接，但是需要重新发起SQL
None：默认方式，没有failover的动作
Select方式，oracle必须为每个session保存更多的内容，包括游标，用户上下文信息等，所以一般使用于OLAP类型的数据库。Session方式则多适用于OLTP数据库。
3、 Retries：表示重试的次数，默认为5次
4、 Delay：表示重试的间隔时间，默认为1秒
5、 Backup：指定不同的net service作为备用的连接。在使用Preconnect方式创建连接时，使用该选项。
示例：
Service-Side TAF是基于服务器端的TAF，与之前两种基于客户端的TAF相比较，如果有调整，前者只需要在服务器端进行修改即可，而后者需要再每个客户端进行修改，既低效又容易出问题。
从配置上讲，Service-Side多了一个Instance Role的概念，所谓的Instance Role，就是当多个实例都参与到一个Service时，可以优先使用哪一个实例。Instance Role包含了两种可选的角色：
Preferred：首先实例，优先选择这个角色的实例提供服务
Available：后备实例，在Preferred角色的instance不能使用的时候，会转到available的instance上
配置Service-Side TAF的方法：
1、 DBCA
2、 Srvctl
3、 Dbms_services包
当DBCA配置Service时，dbca会自动更新OCR，启动Service，当删除Service时，会停止Service，并更新OCR。
当使用srvctl工具配置时，只会更新OCR中的配置，不会更新数据字典和监听中的信息，还需要使用dbms_services包来更新数据字典、手动更改监听配置文件。为了方便，推荐使用DBCA的方式来进行创建。
注意：
无论是使用dbca 工具还是使用srvctl 命令来配置service，都无法配置TAF的TYPE,DELAY,RETRIES 三个属性，必须使用dbms_service包来修改这些属性
使用DBCA配置：
节点1作为Preferred、节点2作为Available，采用Basic的Policy
如果没有其他操作的话，选择”No”
这两个为多出的服务
其中高可用性的基础就是Failover（故障转移），它主要的功能是集群中任何一个节点的故障都不会影响用户的使用，连接到故障节点的用户会被自动转移到其他正常的节点上，对于用户而言，是感觉不到这种切换的。
Oracle 10g RAC的Failover主要分为以下三种：
- Client-Side Connection time Failover
- TAF（Transparent Application Failover）
- Service-Side TAF
其中Client-Side Connection time Failover和TAF（Transparent Application Failover）都是基于客户端配置的Failover。Service-Side TAF是基于服务器端的Failover。
一、Client-side Connection time Failover
基于客户端连接的Failover，主要是通过在客户端的tnsnames.ora中配置多个节点的地址来实现。当用户发起连接请求时，会从连接地址表中的第一个开始尝试连接，如果连接失败，则继续尝试连接地址表中的下一个地址，直到连接成功或则遍历完所有的地址。
特点：
1、 配置简单
2、 只能在连接的时刻起作用，也就是说，这种方式只在客户端发起连接的时候才会去判断节点是否有问题，如果有问题，则会尝试下一个地址。但是一旦连接建立后，节点出现问题就不会处理，这样的结果就是抛出连接错误，客户端直接断开，然后需要重新建立连接
说明：
如果使用这种方式连接，服务端的listener.ora文件中不能设置global_name
示例：
ORCLDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orlrac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = orlrac2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcldb)
)
)
注意：
这里的orlrac1-vip和orlrac2-vip最好是设置成具体的IP地址，而不是hostname。
如果要在客户端的tnsnames.ora中使用orlrac1-vip和orlrac2-vip，就必须在/etc/hosts文件中，配置orlrac1-vip和orlrac2-vip的IP地址。
二、TAF（Transparent Application Failover）
由于目前大部分应用系统都采用配置连接池的方式来访问数据库，都是在启动的时候就建立了若干个长连接，便于在应用程序的整个生命周期中重用这些连接。
在这种情况下，基于Client-Side Connection time Failover方式的Failover就对程序高可用性方面没有太大的作用。
在这种情况下，oracle推出了Transparent Application Failover这种新的机制。在数据库连接建立以后，如果某个实例发生了故障，那么连接到这个故障实例的连接会自动地迁移到其他可用的实例上。整个这个过程对于应用程序来讲是透明的，不需要其他用户介入，但是未提交的事务还是会回滚。
配置方法：需要在客户端的tnsnames.ora配置Failover_mode配置项
该配置项有以下的5个子项目需要配置。
1、 Method
定义用户什么时候创建到实例的连接，有两个可选项
Basic：在有节点故障时才创建到其他实例的连接
Preconnect：在最初建立连接时就同时建立了到所有实例的连接，当发生故障时，就立刻可以切换到其他链路上去。
Basic方式建立的连接开销较小，但是在Failover的时候会产生延迟，Preconnect方式就恰好相反
2、 Type
定义发生故障时，对完成的SQL如何处理。有三个选项
Select：如果使用这种方式，Oracle net会跟踪事务期间的所有select语句，并跟踪每一个与当前select相关的游标已返回了多少行数据给客户端。即如果一个select查询一共要返回1000条数据，在返回500条的时候出现故障，此时oracle net会自动建立一个新的连接到其他正常的节点上，并继续返回剩下的500条数据。
Session：使用这种方式，所有select的查询相关结果会在建立新的连接后丢失，需要重新发起SQL后再返回所有的数据，虽然会自动重新连接，但是需要重新发起SQL
None：默认方式，没有failover的动作
Select方式，oracle必须为每个session保存更多的内容，包括游标，用户上下文信息等，所以一般使用于OLAP类型的数据库。Session方式则多适用于OLTP数据库。
3、 Retries：表示重试的次数，默认为5次
4、 Delay：表示重试的间隔时间，默认为1秒
5、 Backup：指定不同的net service作为备用的连接。在使用Preconnect方式创建连接时，使用该选项。
示例：
orcldb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orlrac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = orlrac2-vip)(PORT = 1521))
(LOAD_BALANCE=YES)
(CONNECT_DATA=
(SERVER = DEDICATED)
(SERVICE_NAME = orcldb)
(FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=180)
(DELAY=5)
)
)
)
三、Service-Side TAF
Service-Side TAF是基于服务器端的TAF，与之前两种基于客户端的TAF相比较，如果有调整，前者只需要在服务器端进行修改即可，而后者需要再每个客户端进行修改，既低效又容易出问题。
从配置上讲，Service-Side多了一个Instance Role的概念，所谓的Instance Role，就是当多个实例都参与到一个Service时，可以优先使用哪一个实例。Instance Role包含了两种可选的角色：
Preferred：首先实例，优先选择这个角色的实例提供服务
Available：后备实例，在Preferred角色的instance不能使用的时候，会转到available的instance上
配置Service-Side TAF的方法：
1、 DBCA
2、 Srvctl
3、 Dbms_services包
当DBCA配置Service时，dbca会自动更新OCR，启动Service，当删除Service时，会停止Service，并更新OCR。
当使用srvctl工具配置时，只会更新OCR中的配置，不会更新数据字典和监听中的信息，还需要使用dbms_services包来更新数据字典、手动更改监听配置文件。为了方便，推荐使用DBCA的方式来进行创建。
注意：
无论是使用dbca 工具还是使用srvctl 命令来配置service，都无法配置TAF的TYPE,DELAY,RETRIES 三个属性，必须使用dbms_service包来修改这些属性
使用DBCA配置：
节点1作为Preferred、节点2作为Available，采用Basic的Policy
如果没有其他操作的话，选择”No”
这两个为多出的服务
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
