虽然在Oracle的立场上，总是建议客户能够更好地规划自己的应用，在有其它负载平衡方法的时候，尽量不要依赖于Oracle的Load Balance方法，但是往往在给客户配置完Oracle RAC数据库以后，客户都会要求要测试负载平衡（Load Balance）和TAF（Transparent Application Failover），并且将这两个测试作为RAC是否安装成功的标准。

这是一件很无奈的事情，像把旁枝末节看作了主要功能，甚至有些买椟还珠的感觉，但是毕竟这是客户，更了解Oracle Load Balance（后文用LB表示），才可以更好满足客户需求。

本文不牵涉TAF（可以参看老熊关于TAF的系列文章PartI，PartII，PartIII），如何在Oracle10g之后版本中在服务器端service层面设置TAF，可以参看Metalink Note: 404644.1。

对于LB，在Oracle10g之前有Client端和Server端两种，在Oracle10g之后又推出了Server端Service层面的LB配置，本文也不涉及Service层面的LB。

在Oracle9i,10g,11g版本中都适用的LB配置分为以下两种。

(1) Client Side Connect Time Load Balance
(2) Server Side Listener Connection Load Balance （此处的Listener用以跟10g之后的Server Side Service Load Balance区分开）

1. Client Side Connect Time Load Balance
既然是Client端的LB，那么也就是不需要在数据库服务器端配置任何参数，完全由客户端机器上的tnsnames.ora文件中对于TNS的配置来决定，实际上也就是LOAD_BALANCE参数。

看一个例子，下面这样的TNS配置就是启用了客户端的LB。

CLIENT_LOADBALANCE =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521))
      (LOAD_BALANCE = yes)
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = rac_lb)
    )
  )

(LOAD_BALANCE = yes)指示SQLNet随机选择ADDRESS_LIST列表中的任意一个监听，将客户端请求发送到此监听上，通过这种方法来实现负载平衡。如果(LOAD_BALANCE = no)那么将会按照ADDRESS_LIST列表中的顺序选择监听，只要这个监听能够正常连接那么就使用该监听。

因此在某些负载平衡的解决方案中会使用(LOAD_BALANCE = no)但是在多个客户端或者应用服务器端配置顺序不同的ADDRESS_LIST，以此来实现人为的负载平衡。

如果在TNS配置时使用的是ADDRESS_LIST语法，那么必须显示设置LOAD_BALANCE = yes，默认值LOAD_BALANCE = no。

2. Server Side Listener Connection Load Balance
要实现server side load balance要求监听能够知道在整个RAC环境中的各节点负载情况，节点负载情况是由PMON进程来定期更新的，而要让PMON进程能够通知其它节点自己节点的负载情况则需要设置数据库初始化参数REMOTE_LISTENER。

在RAC数据库服务器端的每个节点上的tnsnames.ora文件中设置如下的TNS名称。

LISTENERS_RAC =
(DESCRIPTION =  
 (ADDRESS_LIST =   
  (ADDRESS = (PROTOCOL = TCP)(HOST=node1-vip)(PORT = 1521))   
  (ADDRESS = (PROTOCOL = TCP)(HOST=node2-vip)(PORT = 1521))   
 )  
) 

然后设置REMOTE_LISTENER参数值为LISTENERS_RAC。

sql> alter system set REMOTE_LISTENER='LISTENERS_RAC' scope=both;

当某个实例的监听收到客户端连接请求，将会统筹考虑RAC环境中各个节点的负载情况，然后将该连接传递到具有最小负载的节点的最小负载实例上。

在10gR2版本之后，节点和实例的负载计算通过lbscore来完成，而lbscore则由两个动态值决定：”goodness” 和 “delta”，这两个值均由PMON来定期更新，计算公式如下：
Lbscore = Goodness (Received from PMON update)
Delta = New Delta (Received from PMON update)
在PMON定期更新的间隔，如果有新连接进入，那么lbscore的计算公式是：
Lbscore = Lbscore(previous) + Listener Delta

可以通过添加监听的trace（TRACE_LEVEL_LISTENER = 16）来获取lbscore的产生情况，更详细的文档请参看Metalink Note: 263599.1。

关于Failover，多说两句，其实Failover也有两种。
一种是Client-side Failover。细分为Client-side Connect Time Failover，由客户端TNS配置的(failover=on)参数控制，或者Client-side TAF，由客户端TNS配置中的failover_mode参数控制。
另外一种是Server-side Failover。通常跟Server-side Service LB同时配置，通过modify service来完成。