二、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獲得的信息都是動態注冊的。而不是從文件里讀出的靜態信息。
改動前：
[oracle@felix2 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)
)
)
[oracle@felix2 admin]$
改動后配置例如以下：
[oracle@felix2 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))
)
)
[oracle@felix2 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，講的特別好！
。！。