Rac的高可用技术基础是failover，也就是集群的任何一个节点崩溃后连接可以到另外的节点而不影响应用。
连接的故障节点的连接会被自动转移到新的健康节点。
Failover主要体现有三种：
Client-connect time
failover
TAF
Service-sid TAF
其中的client-connect time failover主要是用于客户端的连接中的配置了多个连接地址，会先尝试连接第一个地址，当无法连接时然后尝试连接第二个地址，client-connect time failover只在连接建立failover，连接后就不会在做failover。对于现今比较流行的中间件连接池机制并不适用（连接池会在连接数据库后建立一系列的连接缓存在连接池内，后续的应用程序会重用这些连接来减少频繁连接数据库造成的资源消耗）
TAF也就是transaction application failover是在连接期间一直可以提供failover，当节点出现故障时会自动转移到健康的节点上，该tns文件中的需要填写failover_type提供select和session，其中主要是对于select语句的处理方式不同。
例如在a节点上查询100条记录，已经查询出了10条，如果是select则当a节点出现故障后可以直接在b节点上查询剩下的90多条，而session则需要在b节点上重新查询100条记录。可以看出oracle的很多知识都是利用资源和时间的转换，select虽然不需要再次执行重复的查询而由于保存了相应的cursor 用户的上下文需要消耗更多的资源！
Failover_method取值有basic和freconnect，其中的basic是在感知节点故障时才会建立新的连接，而freconnect则是在连接初就建立了冗余的连接。
[oracle@rac101
admin]$ cat tnsnames.ora
# tnsnames.ora
Network Configuration File:
/db/oracle10grac/product/10.2.0/db/network/admin/tnsnames.ora
# Generated by
Oracle configuration tools.
LISTENERS_BENGUO =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.12)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.13)(PORT = 1521))
)
BENGUO =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.12)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.13)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = benguo)
)
)
---client-connect
time failover
BGSERVER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.12)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST =
192.168.0.13)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = bgserver)
(FAILOVER_MODE=
(TYPE=SELECT)
(METHOD=BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)
---TAF的tnsname.ora配置
[oracle@rac101
admin]$ sqlplus cobra/cobra@bgserver
SQL*Plus: Release
10.2.0.1.0 - Production on Tue Jul 17 16:15:46 2012
Copyright (c) 1982,
2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g
Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the
Partitioning, Real Application Clusters, OLAP and Data Mining options
SQL> select
instance_name from v$instance;
INSTANCE_NAME
----------------
benguo1
SQL> select spid
from v$process where addr in (select paddr from v$session where sid in (select
userenv('sid') from dual));
SPID
------------
24049
然后在os上kill掉该会话的进程
[root@rac101 ~]#
kill -9 24049
刚开始会断开然后可以继续连接到实例中
SQL> select
instance_name from v$instance;
select
instance_name from v$instance
*
ERROR at line 1:
ORA-03113:
end-of-file on communication channel
SQL> select
instance_name from v$instance;
INSTANCE_NAME
----------------
benguo1
SQL> select
failover_type,failover_method from v$session where sid in (select
userenv('sid') from dual);
FAILOVER_TYPE
FAILOVER_M
-------------
----------
SELECT BASIC
而如果用benguo这个server则不提供连接后的高可用转移。
SQL> conn
cobra/cobra@benguo
Connected.
SQL> select
failover_type,failover_method from v$session where sid in (select
userenv('sid') from dual);
FAILOVER_TYPE
FAILOVER_M
-------------
----------
NONE NONE
在os上kill掉该进程后oracle不提供ha转移
[root@rac102 ~]#
kill -9 16248
SQL> select spid
from v$process where addr in (select paddr from v$session where sid in (select
userenv('sid') from dual));
SPID
------------------------
16248
SQL> select
instance_name from v$instance;
select
instance_name from v$instance
*
ERROR at line 1:
ORA-03113:
end-of-file on communication channel
SQL> select
instance_name from v$instance;
ERROR:
ORA-03114: not
connected to ORACLE
负载均衡：
再来看看rac的loadbalance，rac的负载均衡也就是在连接平均分配到不同的节点上，平衡各节点的资源消耗，主要是通过单纯的算法负载均衡和面向业务的负载均衡。
客户端如何通过监听连接服务器端：
客户端是如何连接到服务器的数据库，客户端通过tns文件（中间件下可以直接通过驱动程序）的数据库服务器端的IP发送连接到server side，然后查看其相应的端口上面是否有监听程序，然后通过其监听程序来查看是否有数据库服务注册到监听程序中，最后核对用户名和密码是否正确等。这个是专有服务器建立连接的方式，共享服务器方式有所不同不在这里论述。（个人理解仅供参考）
算法均衡：
算法均衡中又分为client和server，client是oracle 8i推出的，主要是在客户端的tns文件中随机算法抽取一个节点进行连接，这种算法也比较消耗时间而且也不能反应服务器端的负载信息。
Server是oracle 9i推出的，其负载均衡是利用pmon进程每1到10分钟定期收集系统的负载到本地listen和其他节点listen中，系统负载越高pmon收集的频繁也越高，client发出请求到listen后，listen根据本地实例和远程实例的负载把连接请求转接给负载相对低的节点，本地pmon到注册更新负载信息到其他节点的listen需要配置remote_listen参数。Client和server可以结合使用来对连接进行负载均衡。
Service分离应用均衡：
还有一种负载均衡是利用service也就是分离应用的办法来平衡连接到不同实例上，rac是作为一个高可用和减轻负载的扩展性方案，而并不是作为绝对提高性能的，很多情况下instance间cache
fusion会成为系统的瓶颈，gc current request 和enq sequence等一系列热点现象会严重降低rac的性能。
记得一年前就看过oracle说过大表需要做分区，平均热点请求，这个热点请求不仅仅是data block，；例如索引 hwm 等系列的enq contention都可能在拆分思想上做文章，同样的service也是利用拆分应用的思想来使各节点使用的不同的service，也就是用不同的data
block，而节点间不存在交互或者很少，也就能很大程度的减少gc 等一系列等待事件造成的系统瓶颈！
推荐一本书：
算算自己真正接触rac也快一段事件，已经有一个多月了，多rac的整体了解已经有了一个大体的清晰思路，这里也推荐一本书<<大话集群 高可用
备份和恢复>>,潜心翻看一定会颇有收获！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/25362835/viewspace-1058838/ ，如需转载，请注明出处，否则将追究法律责任。
