二、LB
LoadBalance就是把负载均衡分配到集群的各个节点，从而提高总体的吞吐能力。Oracle 10g
RAC提供了两种手段来实现负载，其一是通过Connection Balancing。依照某种算法把用户分配到不同的节点。其二是通过service。在应用层面上进行分散。
Connection Balancing
Connection Balancing这样的负载均衡是在用户连接这个层次上进行的。也就是在用户请求建立连接时。依据每一个的负载决定把连接分配到哪个实例上。而一旦建立连接之后，会话的全部操作就都在这个实力上完毕，而不会再分配给其它实例。
client均衡（Client-Side LB）
client均衡（Client-Side LB）是oracle 8i使用的方法。配置方法是在client的tnsnames.ora文件里增加LOAD_BALANCE=YES条目。当client发起连接时，会从地址列表中随机选取一个，再使用随机算法吧连接请求分散到各个实例。
一个Client-Side LB的TNS配置实比例如以下：
TAF_SERVER =
(DESCRIPTION =
(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))
(ADDRESS= (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = taf_server)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)
这样的方法的缺点非常明显。由于在分配连接时没有考虑每一个节点的真是负载，最后分配结果不一定是平衡的。而且随机算法须要长时间片。假设在短时间内同一时候发起多个连接，这些连接有可能都被分配到一个节点上；甚至更坏的情况下，连接可能会被分配到故障节点上。因此Oracle又引入了server端（Server-Side LB）方式。
总结：client均衡的最大缺点就是不能依据各个实例的真实负载来分散用户连接
server端均衡（Server-Side）
server端负载均衡的实现依赖于listener（监听）手机的负载信息。在数据库执行过程中，PMON后台进程会手机系统的负载信息，然后登记到Listener中。最少一分钟，最多十分钟PMON就要做一次信息更新。而且假设节点的负载越高，更新频率就越高，以保证Listener可以掌握每一个节点准确的负载情况。假设Listener关闭，PMON进程会每隔1妙检查Listener是否重新启动，除了这个自己主动的、定时的更新任务外，用户也可以有用altersystem
register命令来手工进行这个过程。
这个自己主动更新动作能够从listener的日志中看到。
注意：实例启动时PMON进程进行的第一次登记过程叫做Server-Rgister，而后的更新过程叫做service-update；
TNSLSNR for Linux: Version 10.2.0.5.0 - Productionon 03-JUN-2014 11:51:54
Copyright (c) 1991, 2010, Oracle. All rights reserved.
System parameter file is/u01/oracle/10.2.0/db_1/network/admin/listener.ora
Log messages written to/u01/oracle/10.2.0/db_1/network/log/listener.log
Trace information written to/u01/oracle/10.2.0/db_1/network/trace/listener.trc
Trace level is currently 0
Started with pid=25371
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=felix1)(PORT=1521)))
Listener completed notification to CRS on start
TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT[* SID] * RETURN CODE
03-JUN-2014 11:51:54 *(CONNECT_DATA=(CID=(PROGRAM=)(HOST=felix1)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=LISTENER)(VERSION=169870592))* status * 0
03-JUN-2014 11:52:15 * service_register * felix2 *0
03-JUN-2014 11:52:15 * service_register * felix1 *0
03-JUN-2014 11:52:15 * service_update * felix1 * 0
03-JUN-2014 11:52:15 * service_register * +ASM1 *0
Listener日志尽管记录了PMON进程的注冊和更新动作。可是注冊的内容却没有体现，要想获得这些内容，能够通过各种1025事件来获得，这个时间是跟中PMON活动的。
SQL> alter session set events ‘10257 trace namecontext forever,level 16‘;
Session altered.
SQL>
获取跟踪文件：
CREATE OR REPLACE FUNCTION get_trace return varchar is
Resultvarchar2(4000);
begin
dbms_output.enable(1000000);
begin
for x in(SELECT d.VALUE
||‘/‘
||LOWER (RTRIM (i.INSTANCE, CHR (0)))
||‘_ora_‘
||p.spid
||‘.trc‘
trace_file_name
FROM (SELECT p.spid
FROM v$mystat m, v$session s,v$process p
WHERE m.statistic# = 1 AND s.SID= m.SID AND p.addr = s.paddr) p,
(SELECT t.INSTANCE
FROM v$thread t, v$parameter v
WHERE v.NAME = ‘thread‘
AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,
(SELECT VALUE
FROM v$parameter
WHERE NAME = ‘user_dump_dest‘)d) loop
Result:= Result || x.trace_file_name;
End loop;
End;
return(substr(Result, 1, 4000));
end get_trace;
select get_trace from dual;
GET_TRACE
--------------------------------------------------------------------------------
/u01/oracle/admin/felix/udump/felix1_ora_27465.trc
PMON进程不仅回忆本地的Listener注冊。还能够向其它节点的listener注冊。但究竟要向何处注冊，是由remote_listener和local_listener这两个參数决定。Local_Listener不用设置，而remote须要设置。參数值是一个tnsnames项。
SQL> show parameter listener
NAME TYPE VALUE
------------------------------------ -----------------------------------------
local_listener string LISTENER_FELIX1
remote_listener string LISTENERS_FELIX
SQL>
Tnsnames.ora中相应的LISTENERS_FELIX的内容例如以下：
LISTENERS_FELIX =
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))
(ADDRESS= (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521))
)
有了PMON的自己主动注冊机制后。集群的每一个节点的Listener都掌握全部节点的负载状态，当收到client的连接请求时，就会把连接转给负载最小的节点，这个节点有可能是自己也可能是其它节点，也就是Listener会转发用户连接的请求listener的节点选择方法依据用户所请求的连接方式会有所不同：
a． 假设用户请求的是Dedicate专有连接，Listener首先选择负载最小的节点，假设多个节点负载同样。则从中选择负载最小的实例；
b． 假设用户请求的是shared server共享连接，除了做节点负载比較和实例负载比較之外，还要在所选实例上，选择最小的Dispatcher进行转发。
两种LB的配置方法：
对于client-Side LB。须要在客户的tnsnames条目中增加LOAD_BALANCE=YES。对于Server-Side LB,须要配置REMOTE_LISTENER这个參数。
在配置LB时有一点须要注意：须要从各个实例的listener文件里却掉缺省的SID_LIST_LISTENER_NAME条目，这样才干保证Listener获得的信息都是动态注冊的。而不是从文件里读出的静态信息。
改动前：
[[email protected] admin]$ cat listener.ora
# listener.ora.felix2 Network Configuration File:/u01/oracle/10.2.0/db_1/network/admin/listener.ora.felix2
# Generated by Oracle configuration tools.
LISTENER_FELIX2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521)(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.102)(PORT = 1521)(IP =FIRST))
)
)
----------------------------------------
SID_LIST_LISTENER_FELIX2 =
(SID_LIST=
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/oracle/10.2.0/db_1)
(PROGRAM = extproc)
)
)
[[email protected] admin]$
改动后配置例如以下：
[[email protected] admin]$ catlistener.ora
# listener.ora.felix2 Network Configuration File:/u01/oracle/10.2.0/db_1/network/admin/listener.ora.felix2
# Generated by Oracle configuration tools.
LISTENER_FELIX2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521)(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.102)(PORT = 1521)(IP =FIRST))
)
)
[[email protected] admin]$
利用service分散负载
Connection Balancing方法的不足之处，Oracle的集群时“共享一切“的架构，全部节点都共享一份磁盘数据。
实例间通过cachefusion机制进行数据同步，所以RAC的性能在非常大程度上受限于cache fusion的性能。因此。要提高RAC的性能能够从双方面入手，一方面提高cache fusion的能力。这能够通过更好的互联设备，比方G级的Private network。或者使用Infiniband等DRA技术；还有一方面，能够尽量降低cache
fusion的流量，降低实例间的相互依赖。
而service就是后一种思路基础上发展出来的。
先看一下与service很相似的Partition技术。假设一个表中的数据量巨大。Oralce会建议採用了Partition Table，把数据依照一定的规律分散到多个物理段（Segment）中，这样訪问数据时就限制在某些个局部的Segment上。
把“分散数据“思想机一部提升，在RAC环境中。假设可以把数据依照顾用进行分离。考虑以下这个场景：一个ERP应用包含生产、销售、供应链管理多个模块。
假设这个数据库採用了2节点的RAC在没有进行“数据分散”之前，两个用户都使用销售模块。那么这两个用户就可能被分配到两个节点上，在操作过程中，销售数据就要在cache fusion的作用下。不断在两个节点间传递，假设有来了另外两个生产模块的用户，这两个用户又被分配到两个节点上。在操作的过程中，生产部分的数据又要在Cache
fusion的协助下在两个实力之间同步。
可见。假设仅有connectionbalance一种机制。表面上看起来用户是被分配到了不同的实例上，似乎负载被分散了。可是这样的分散是没有结合每一个用户的业务需求进行的。是一种纯技术手段（因此能够把它叫做纯技术手段分散）。
如果换一种解决思想，假如把销售模块的用户都分配到节点1上，生产模块的用户都分配到节点2上，在如果这两个模块之间的数据交叉不多，这是销售模块的数据都集中在节点1上。生产库模块的数据都集中在节点2上，cachefusion的工作量就会急剧降低，这就从根本上攻克了性能的问题。
这个思想是借助于service分散负载的基本思想。
通过把应用依照功能模块进行划分成Service，进而把每一个service固定在某些RAC节点上，从而从根本上提供系统的性能。这样的分散负载的方法不是仅靠DBA进行配置就能完毕的，须要DBA和开发者合作，在了解业务数据特点之后才干看到效果。
在RAC环境下。Service并非必须的，可是假设借助service相应用的划分，相信对整个系统性能的提升是大有裨益的。
使用service还有另外一个优点：能够在数据库内部创建Service的TAF參数，假设在client通过service连接数据库。clienttnsnames.ora中就不再须要FAIL-OVER的很多设置。
假设使用service方法，client配置须要使用service_name条目，比如以下的红字部分:
TAF_SERVER =
(DESCRIPTION =
(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))
(ADDRESS= (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = taf_server)
)
)
具体探究參考《大话RAC》张晓明 p238~242，讲的特别好！
。！。