共計 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 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！