共计 4913 个字符，预计需要花费 13 分钟才能阅读完成。
本篇内容主要讲解“Oracle RAC LoadBalance 有什么用”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“Oracle RAC LoadBalance 有什么用”吧!
Load Balance 就是把负载平均的分配到集群中的各个节点，从而提高整体的吞吐能力。Oracle10gRAC 提供了两种不同的方法来分散负载：
1. 通过 Connection Balancing，按照某种算法把用户分配到不同的节点。也可认为是纯技术的分散负载。
2. 通过 Service，在应用层上进行分散，也可认为是面象业务的分散负载。
一．Connection Balancing
Connection Balancing 这种负载均衡是在用户连接这个层次进行的，也就是在用户请求建立连接时，根据每个节点的负载决定把连接分配给哪个实例，而一旦连接建立之后，会话的所有操作就都在这个实例上完成，而不会再分派给其他节点了。
ConnectionBalancing 有客户端和服务端两种实现方法。
1.1 客户端均衡（Client-SideLB）
客户端均衡（Client-SideLB）是 Oracle8 使用的方法，配置方法是在客户端的 tnsnames.ora 文件中加入：LOAD_BALANCE=YES 条目。
当客户端发起连接时，会从地址列表中随机的选取一个，在使用随即算法把连接 请求分配到各个实例。
一个 Clint-SideLB 的 TNS 配置文件如下：
RAC=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=rac2-vip)(PORT=1521))
(LOAD_BALANCE=YES)
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=RAC)
)
)
)
注：rac1-vip 需要添加到 hosts 文件中
这种方法缺点很明显，因为在分配连接时没有考虑每个节点的真实负载，最后分配结果不一定是平衡的；并且随即算法需要长时间片，如果在短时间内同时发起多个连接，这些连接有可能都被分配到一个节点上，甚至更坏的情况下，连接可能被分配到故障节点上。因此 Oracle 引入了服务端均衡 (Sevice-SideLB) 方式。
1.2 服务器端均衡（Server-SideLB）
Server-Side LB 是从 Oracle9 引入的。它的实现依赖于 Listener 收集负载信息。
在数据库运行过程中，PMON 后台进程会收集系统的负载信息，然后登记到 Listener 中。最少 1 分钟，最多 10 分钟 PMON 就要做一个信息更新，并且如果节点的负载越高，更新频率就越高，以保证 Listener 能掌握每个节点准确的负载情况。如果 Listener 关闭了，PMON 进程会每隔 1 秒钟检查 Listener 是否重启。除了这个自动的定时的更新任务外，用户也可以使用 alter system register 命令来手工进行这个过程。
这个自动更新动作，可以从 Listener 的日志中看到，比如下面这个 Listener 日志片段很清楚的记录了这些动作。注意，实例启动时 PMON 进程进行的第一次登记过程叫作 Server-register，而后的更新过程叫作 service-update。
[root@rac1log]#pwd
/u01/app/oracle/product/10.2.0/db_1/network/log
[root@rac1log]#more*.log
…..
27-FEB-201002:15:10*service_register*rac1*0
27-FEB-201002:15:11*service_update*rac1*0
27-FEB-201002:15:11*service_update*rac1*0
27-FEB-201002:15:23*service_update*+ASM1*0
27-FEB-201002:15:32*service_update*+ASM1*0
…..
Listener 日志虽然记录了 PMON 进程的注册和更新动作，但是注册的内容却没有体现，要想获得这些内容，可以通过跟踪 10257 时间来获得，这个事件就是跟踪 PMON 活动。
Event= 10257 trace name context forever,levl16
关于 event 的具体使用，参考我的 blog：
http://blog.csdn.net/tianlesoftware/archive/2009/12/13/4977827.aspx
PMON 进程不仅会向本地的 Listener 注册，还可以向其他节点上的 Listener 注册。但到底要想何处注册，是由 Remote_Listeners 和 Local_Listener 两个参数决定。Local_Listener 不用设置，而 Remote_Listener 需要设置，参数值是一个 tnsnames 项。
有了 PMON 的自动注册机制后，集群的每个节点的 Listener 都掌握所有节点的负载情况，当收到客户端连接请求时，就会把连接转给负载最小的节点，这个节点有可能是自己也有可能是其他节点，也就是 Listener 会转发用户的请求。
Listener 的节点选择方法根据用户所请求的连接方式会有所不同：
1). 如果用户请求的是 Delicate 专有连接，Listener 首先选择负载最小的节点，如果多个节点负载相同，则从节点选择负载最小的实例。
2). 如果用户请求的是 ShreServer 共享功能连接，除了做节点负载比较和实例负载比较之外，还要在所选择实例上，选择负载最小的 Dispatcher 进行转发。
Server-Side LB 和 Client-Side LB 不是互斥的，它们可以一起工作，这时用户的连接请求会先从地址列表中随机选取一个地址，然后向该地址的 Listener 发出请求；Listener 接到请求后，根据各节点负载情况挑选出最合适的节点转发连接请求。
1、服务器端的负载均衡需要配置 remote_listener 参数，而该参数的值依赖于 tnsnames.ora 的连接字符串。
2、对于基于服务器端的连接负载均衡，监听器会根据当前节点、实例上的连接负载情况进行转发到空闲的实例
3、转发的依据仅仅是当前节点监听的连接数量的多少，而非当前实例的过度负载
4、从上面的测试可以得出，各个节点的连接并不算均衡，是相对的均衡，因此应结合客户端连接负载协同工作
5、对于当前实例的过度负载的情形，应结合配置 service 方法来实现负载均衡
注意事项：无论在配置 Client-Side LB 还是 Server-side LB 时，都需要从各个节点实例的 listener.ora 文件中删除缺省产生的 SID_LIST_LISTENER_NodeName 条目，这样才能保证 Listener 获得的信息是动态注册的，而不是从文件中读取的静态信息。
1.3 两种 LB 的配置方法
对于 Client-SideLB，需要在客户的 tnsnames 条目中加入 LOAD_BALANCE=YES；
对于 Server-sideLB，需要配置 REMOTE_LISTENER 这个参数。
注意事项：在配置 LB 时，需要从各个节点实例的 listener.ora 文件中删除缺省产生的 SID_LIST_LISTENER_NodeName 条目，这样才能保证 Listener 获得的信息是动态注册的，而不是从文件中读取的静态信息。
我们要删除：
SID_LIST_LISTENER_RAC1=
(SID_LIST=
(SID_DESC=
(SID_NAME=PLSExtProc)
(ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1)
(PROGRAM=extproc)
)
)
仅保留：
LISTENER_RAC1=
(DESCRIPTION_LIST=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521)(IP=FIRST))
(ADDRESS=(PROTOCOL=TCP)(HOST=10.85.10.119)(PORT=1521)(IP=FIRST))
)
)
二. 利用 Service 分散负载
先来分析下 Connection Balancing 方法的不足之处。Oracle 的集群是 共享一切 的架构，所有的节点都共享一份磁盘数据。实例间通过 CacheFusion 机制进行数据同步，所以 RAC 的性能在很大程度上受限于 Cache Fusion 的性能。因此，要提高 RAC 的性能，可以从两方面入手：
1. 提高 Cache Fusion 的能力，这个可以使用更好的互联设备，比如 G 级的 private network，或者使用 Infiniband 等 DRA 技术。
2. 可以尽量减少 CacheFusion 的流量，减少实例间的互相依赖。而 Service 就是后一种思路基础删发展出来的。
在来看一下与 Service 非常类似的 Partition 技术。如果一个表中的数量巨大，Oracle 会建议采用 PartitionTable，把数据按照一定的规律（比如时间）分散到多个物理段上，这样访问数据时就限制在某些局部的 Segment 上。
把 分散数据 的思想进一步提升，在 RAC 环境上，如果能够把数据按照应用进行分离。比如：一个 ERP 应用包括生产，销售，供应链管理多个模块。假设这个数据库采用了 2 个节点的 RAC，在没有进行“分散数据”之前，两个用户都使用销售模块，那么这两个用户就可能被分配到两个节点上，在操作过程中，销售数据就要在 CacheFusion 的作用下，不断在两个字节间传递。如果又来了另外两个生产模块的用户，在两个用户被分配到两个节点上，在操作过程中，生产部分又要在 CacheFusion 的协助下在两个实例间同步。
可见，如果仅有 Connection Balancing 一种机制，表面上看起来用户是被分散到了不同的 Instance 上，似乎负载被分散了。但是这种分散是没有结合每个用户的业务需求下进行的，是一种纯技术手段。这种分散反而可能加重了系统间的负担。
如果换一种思路，假如把销售模块的用户都分配到节点 1 上，生产模块的用户都分配到节点 2 上，再假设这两个模块之间的数据不交叉。这时销售模块的数据都集中在节点 1 上，生产模块的数据都集中在节点 2 上，Cache Fusion 的工作量就会急剧较少，就能从根本上解决了性能问题。
这个思想就是借助 Service 分散负载的基本思想。通过把应用按照功能模块进行划分成 Service，进而把每个 Service 固定在某个 RAC 节点上，从而从根本上体统系统的性能。这种分散负载的方法不是仅靠 DBA 进行配置就能完成的，需要 DBA 和开发人员合作，在了解业务数据特点之后才可能看到效果。
在 RAC 环境下，Service 并不是必须的，但是如果能借助 Service 对应的划分，相信对整个系统性能的提升是有很大好处的。使用 Service 还有另一个好处：可以在数据库内部创建 Service TAF 参数，如果客户通过 Service 连接数据库，客户端的 tnsnames.ora 中就不再需要 FAIL-OVER 的许多设置。只需要添加如下条目即可：
RAC=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=rac2-vip)(PORT=1521))
(LOAD_BALANCE=YES)
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=RAC)
)
)
到此，相信大家对“Oracle RAC LoadBalance 有什么用”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
