RAC的負載均衡主要是指新會話連線到RAC資料庫時，如何判定這個新的連線要連到哪個節點進行工作。在RAC中，負載均衡分為兩種，一種是基於客戶端連線的，另外一種是基於伺服器端的。
客戶端的負載均衡配置相對簡單，只需要在tnsnames.ora中新增LOAD_BALANCE=ON這麼一個選項即可。比如下面的TNS：

RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(LOAD_BALANCE = ON)

on 和 yes 作用一致。
(FAILOVER = ON)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = rac)
)
)

這樣當客戶端連線RAC資料庫時，會隨機在TNS裡面挑個監聽地址進行連線。在Oracle10g以前，假如有節點宕機或者類似事故時，客戶端可能還是選擇連線到這個節點，這樣會發生較長時間的TCP等待超時。而在10g以後，由於VIP和FAN的引入，這樣的情況可以得到很大程度的改善。客戶端的負載均衡在通常情況下能夠較好地工作，但是由於連線是在客戶端隨機發起的，這樣客戶端並不知道RAC各節點的負荷及連線數情況，有可能負荷大的節點還會源源不斷地增加新的連線，導致RAC節點無法均衡工作。
從Oracle 10g開始，伺服器端的負載均衡可以根據RAC中各節點的負荷及連線數情況，而判定將新的客戶端連線分配到負荷最小的節點上去。RAC中各節點的PMON程序每3秒會將各自節點的負荷（包括LOAD、最大LOAD、CPU使用率）及連線數更新到service_register裡面，然後假如節點的負荷有發生變化，將會通知到監聽程式，由監聽程式再決定新的客戶端連線分配至哪個節點。假如RAC中一個節點的監聽失敗了，PMON每一分鐘會去檢查一次是否已經恢復正常。
伺服器端的監聽配置是在各節點的tnsnames.ora裡面新增一個連線到各個節點監聽的條目，然後再在初始化引數裡面設定remote_listeners這個引數。比如：

LISTENERS_RAC =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
)

ALTER SYSTEM SET REMOTE_LISTENER = LISTENERS_RAC;

這樣伺服器端的LOAD BALANCE便配置完成。
但是有時候由於PMON取節點負荷的延遲，導致客戶端連線可能還是會連線到負荷較大的節點上，這時候便可以在伺服器各節點的listener.ora裡面加入PREFER_LEAST_LOADED_NODE=OFF這麼一行，這樣伺服器端的負載均衡將不再根據節點的負荷來進行分配，而是根據節點的連線數進行分配，達到各個節點連線數比較平衡的效果。
另外一個不得不說的便是並行操作，假如有個會話連線以後要進行並行操作。由於連線時是按負荷或連線數連線，這樣可能連線時各個節點連線數和負荷等比較平衡，但是這個並行會話啟動多個並行程序以後，那麼這個節點的負荷及連線數就會有可能上升得比較快。如果在RAC中開啟了節點並行，那麼有可能會把並行程序分配到多個節點執行以達到負載均衡的效果。
從Oracle 10.2開始，Oracle引入了Load Balance Advisor，對負載均衡有了進一步的改進。結合Service，可以對不同的SERVICE設定不同的負載均衡策略。Load Balance Advisor的配置可以通過DBMS_SERVICE包對SERVICE進行更改而完成。在Load Balance Advisor首先必須設定SERVICE負載均衡的目標，目標分為3種：

GOAL_NONE Disables the load balancing advisory
GOAL_SERVICE_TIME The LBA calculates a weighted moving average of the total elapsed time for completed work plus the bandwidth that’s available to the service to calculate the service goodness. This goal is ideal for services whose workload may change dramatically over a short period of time, e.g. an application that services a “clicks and mortar” store that provides customer self-service through an internet-based shopping web site.
GOAL_THROUGHPUT The LBA calculates a weighted moving average of throughput (i.e. the rate at which work is completed) in addition to the bandwidth available to the service to calculate the service goodness. This goal is best suited for long-duration tasks that are typically queued to run serially, e.g. scheduled jobs that handle large batches of transactions.

另外可以額外設定連線的負載均衡：

CLB_GOAL_SHORT The Load Balancing Advisory will be used for connection load balancing only if it is enabled (i.e. set to other than GOAL_NONE). If the LBA has been disabled, connection load balancing will utilize abridged advice determined by CPU utilization.
CLB_GOAL_LONG Connection load balancing will be determined by first tallying the total number of connections per instance, and then by counting the number of sessions per each service. Oracle recommends using this setting for services whose applications tend to connect for long periods of time (e.g. Oracle Forms). The Load Balancing Advisory can be used in conjunction with this setting as long as the connection pool has been sized to accommodate “gravitation “ within the pool without adding or subtracting connections. Oracle recommends this option as the most efficient design.