Oracle 11g R2 RAC 高可用連線特性 – SCAN 詳解

阿新 • • 發佈：2022-05-02

許春植（Luocs）

（阿里巴巴高階資料庫管理員,7年以上資料庫運維管理經驗，擅長MySQL、Oracle及MongoDB資料庫，目前主要研究並建設MongoDB一套完整的運維體系）

編輯手記：感謝許春植授權獨家轉載其精華文章，也歡迎讀者朋友向我們投稿，本文是對Oracle SCAN特性的一些介紹和總結，編輯時略有節略。

Oracle 從11g 開始推出的 SCAN 特性在 Oracle RAC 高可用連線裡佔據著非常重要的地位，也是以後的重點推進方向。

說在前頭：文章中核心內容來自官方，當然也參考了部分前輩們整理的資料，再加以自己的理解和測試整理出的文章。

SCAN 概念

什麼叫 SCAN，SCAN (Single Client Access Name) 是 Oracle 從11g R2 開始推出的，客戶端可以通過 SCAN 特性負載均衡地連線到 RAC 資料庫

。SCAN 提供一個域名來訪問 RAC，域名可以解析 1個到 3個 SCAN IP，我們可以通過 DNS 或者 GNS 來解析實現。其中 DNS 大家都很熟悉，這裡不多說。GNS (Grid Naming Service) 則是 Oracle 11g R2 的新功能，可以通過 DHCP 服務為節點和 SCAN 分配 VIP 和 SCAN IP。另外還有個優點是，對於新加入叢集的節點，它會自動分配 VIP 地址，更新叢集資源，客戶端依然通過 SCAN 特性負載均衡地連線到新增叢集節點上。

除了 DNS 和 GNS 解析方法外，SCAN 也可以使用 hosts 檔案來解析，但用過的人都知道，此方法不僅在安裝 RAC 的時候產生問題（RAC 安裝的時候的確會報錯），後期使用也是存在問題的，比如 SCAN 域名只能定義一個 SCAN IP。所以這種方法也是 Oracle 不推薦使用的。但儘管如此，我見過很多生產上依然這樣使用，也就是廢棄了11g 的新特性 SCAN，而是依然採用 VIP 連線方式。

SCAN 最明顯的優點就是，當叢集中新增加了節點或者刪除了節點，不需要額外維護客戶端。

很多概念

在 RAC 部署的時候，我們都會接觸到很多關於地址的概念，以下簡要介紹一下。

PUBLIC IP : 這是我們網絡卡上配置的真實 IP 地址，我們稱為公共 IP，這個 IP 的存在關係到下面介紹的 VIP 能不能正確漂在其所在網絡卡上。注意，Public IP 是不提供給客戶端去連線配置的，這並不是說通過 PUBLIC IP 無法連線例項，而是它會存在節點伺服器宕機的時候所有向它請求的客戶端都會有等待現象並且最後得到超時資訊的缺點。

PRIVATE IP : 稱為私網 IP（私有 IP），它是用於心跳同步的，也就是保證兩臺伺服器資料同步。說到私網 IP，我簡單說下 Oracle 另一個高可用性連線特性 – HAIP。其實 Cache Fusion 會消耗節點伺服器很大的私網資源，另外，私網間無法通訊還會引起 Brain Split(腦裂)，以前為解決這種問題，可以採用網絡卡 bonding 技術，而 Oracle 在 11g R2 的時候 HAIP 技術來實現，HAIP - Highly Available Virtual IP 用於節點間的私網通訊，支援同時使用多個網路連線來滿足網絡卡間的負載均衡，並且還提高了 Cache Fusion 資源通訊能力。

VIP : RAC 的每個節點都需要有一個虛擬 IP，這就是 VIP。VIP 需要和 PUBLIC IP 同一個子網，它們是由 GI 的 Clusterware 來管理的。VIP 在其節點伺服器發生故障的時候會自動漂移到另外正常的節點伺服器上，如果 RAC 是多個節點執行的，那具體漂移到哪個活動的節點將由 Clusterware 決定。VIP 發生漂移現象之後，其當前的節點伺服器 LOCAL LISTENER 是不會監聽它的請求的，所以有客戶端向這個 VIP 傳送請求時，Clusterware 的 FAN 會通知客戶端向別的 VIP 傳送請求，客戶端收到通知後通過 Failover 機制把請求重新發送到 ADDRESS 列表中的其他 VIP 上。雖然有這種較複雜的過程，但始終對客戶端是透明進行的，而且這個過程完成時間非常短暫，客戶端也就幾乎感受不到有節點宕機。等故障節點恢復正常，漂移的 VIP 也回到此節點上，繼續提供服務。

SCAN VIP : SCAN VIP 就是我在剛開始常說的 SCAN IP，也就是由 DNS 或者 GNS、hosts 解析出來的 IP 地址。上面也說過，SCAN VIP 最多能有三個，它們迴圈地被客戶端所請求到。這裡大家可能會存在這樣的問題，SCAN VIP 只有三個，那 RAC 是四節點或更多的節點情況怎麼辦？存在這種問題的原因歸咎於對 SCAN VIP 的瞭解不足。其實，SCAN VIP 數量和節點數是沒有任何關係的，SCAN VIP 會落到哪個節點上都是隨機的。

GNS VIP : GNS VIP 同 SCAN VIP，也是 Oracle 從 11g R2 開始提供的。GNS VIP 是提供 GNS 服務的 IP 地址，它繫結到某個節點的 PUBLIC IP 所在網絡卡上，當節點出現故障，GNS 資源會自動切換到其他正常的節點繼續提供 GNS 解析服務。如果我們不使用 GNS 解析方法，那麼也不會存在 GNS VIP。

LOCAL LISTENER : 本地監聽器，RAC 的每個節點上都會有獨立的本地監聽器，它會監聽該節點的 Public IP 和 VIP，而每個節點的例項在啟動的時候也向本地監聽器進行註冊，當然它也會向 SCAN 監聽器註冊，當 VIP 或者 PUBLIC IP(這種情況比較少見)有連線請求的時候，本地監聽器就接受處理並和本地例項建立連線。如果某個節點故障，其上面的 VIP 會進行漂移，但本地監聽器並不會產生漂移。

SCAN LISTENER : SCAN 監聽器，它是實現 SCAN 負載均衡的原理所在。如果 RAC 上有三個 SCAN VIP，那麼 SCAN 監聽器也有三個，它們各自監聽 SCAN VIP 的連線請求。SCAN 監聽器跟著 SCAN VIP 隨機分配到節點伺服器上，如果某個節點發生故障，執行在此節點上的 SCAN VIP 會進行漂移，這時候 SCAN 監聽器也跟著漂移到正常的節點上，繼續為 SCAN VIP 監聽連線請求，當 PMON 程序下次動態更新例項資訊到該 SCAN 監聽器之後，它又重新接受客戶端的連線。這和 VIP 產生漂移的時候是有所區別的。

兩個引數

LOCAL_LISTENER : 這是 Oracle 的引數，這個引數控制著本地監聽器的註冊，因為本地監聽器的工作機制關係，通過本地監聽器的資料庫連線請求只會連線到本地節點的例項上。

REMOTE_LISTENER : 同 LOCAL_LISTENER 是 Oracle 的引數，通過這個設定，任何例項都會向 SCAN 監聽器註冊，所以 SCAN 監聽器能夠負載均衡地分發連線請求到節點本地監聽器上，也就是連線到其本地節點上例項上。

SCAN 解析與配置

SCAN 是在安裝 GI(Grid Infrastructure) 時配置的，作為 Clusterware 資源被管理。忽略 hosts 解析之後，有兩種方式配置和解析 SCAN: DNS 和 GNS(Grid Naming Service)。

這裡重點說一下 DNS 解析 SCAN 方式 使用 DNS 解析 SCAN 的時候，DNS 伺服器會採用 rr(round-robin) 的方式迴圈解析為它準備的3個 IP 地址，與 Oracle 11g R2 的客戶端配合使不同的客戶端能夠連線到不同的 SCAN Listener 上，這相當於是 Oracle 10g 中配置的客戶端負載均衡（通過 LOAD_BALANCE=yes 配置）。

下面看一下客戶端通過 SCAN 連線到資料庫的過程，首先由 DNS 伺服器解析 SCAN 名稱，DNS 伺服器返回 SCAN 對應的3個 IP 地址的列表，客戶端會選擇使用其中一個 SCAN VIP 地址作為連線地址，將命名方法解析後的連線資訊傳送到 SCAN VIP 對應的 SCAN Listener 上，SCAN Listener 通過負載均衡機制再把請求轉發給比較空閒的伺服器上的本地監聽器，由本地監聽器完成例項與客戶端之間的連線。

使用 SCAN 連線資料庫例項，整個過程實現了客戶端的 Failover(Oracle 10g R2 是通過 FAILOVER=on 來配置)，DNS 伺服器返回的是一個 SCAN VIP 列表，客戶端會選擇其中一個連線到 RAC，如果這個 IP 地址不能正常訪問，客戶端會選擇另一個 IP 地址繼續連線，直到所有的地址都不能正常連線，才返回錯誤給客戶端，整個過程對客戶端程式來說依然是透明的。

需要注意的是，使用 SCAN 連線到資料庫，不再需要客戶端能解析節點的 PUBLIC IP 和 VIP，只需要客戶端能夠通過 DNS 伺服器正常解析 SCAN 就可以了。負載均衡工作交給伺服器端的 SCAN 實現。

至於 GNS 解析 SCAN，因為目前 GNS 服務存在不穩定的情況，也很少有企業將其投入到生產環境使用，而且其工作原理也較為複雜，所以在這裡並不深入說明。

例項的動態註冊

上面已經介紹了 LOCAL_LISTENER 和 REMOTE_LISTENER 兩個和動態註冊有關的引數，那我們看看它們在資料庫中的表現形式：

本地監聽器註冊是由例項的 LOCAL_LISTENER 引數所控制的：

LOCAL_LISTENER 設定為向本地VIP地址進行註冊，由於本地監聽器是在本地的 PUBLIC IP 和 VIP 上監聽，所以向 VIP 監聽註冊就能保證成功向本地監聽器註冊。

檢視本地監聽器的狀態：

– 這裡注意：檢視本地監聽器資訊的時候每個節點只能看到其上執行的例項。

SCAN 監聽器的註冊是由 REMOTE_LISTENER 引數控制的，任何例項都會向所有的 SCAN 監聽器註冊：

SQL> show parameter remote_listener

NAME TYPE VALUE ———————————— ———————- —————————— remote_listener string pos-cluster-scan:1521

下面是 LISTENER_SCAN1 的一個狀態資訊，當然你也可以檢視 LISTENER_SCAN2和 LISTENER_SCAN3 的狀態。

由於任何例項啟動都會向所有的 SCAN 監聽器動態註冊，從 LISTENER_SCAN1 的 SCAN 監聽器執行狀態來看，SERVICE pos 包括了所有的例項名稱。 SCAN 監聽器是實時瞭解所有例項的執行情況的，因此它能夠準確地將連線重定向到空閒伺服器的本地監聽器上。

下面我們通過日誌檢視例項的動態註冊與動態更新

1）本地監聽器動態註冊日誌：
[grid@pos2 ~]$ cd $ORACLE_BASE/diag/tnslsnr/pos2/listener/alert
[grid@pos2 alert]$ grep service_register log_1.xml | head -3
 <txt>18-JUN-2012 13:58:23 * service_register * LsnrAgt * 0
 <txt>18-JUN-2012 13:58:30 * service_register * +ASM2 * 0
 <txt>18-JUN-2012 15:54:15 * service_register * pos2 * 0
-- 之所以選擇log_1.xml歷史檔案是因為發現我的log.xml裡基本都是更新日誌，沒有註冊日誌。

2）本地監聽器動態更新日誌：
[grid@pos2 alert]$ grep service_update log.xml | head -3
 <txt>16-OCT-2012 16:07:09 * service_update * pos2 * 0
 <txt>16-OCT-2012 16:07:33 * service_update * pos2 * 0
 <txt>16-OCT-2012 16:08:03 * service_update * pos2 * 0

3）SCAN監聽器動態註冊日誌：
[grid@rac1 ~]$ cd $ORACLE_BASE/diag/tnslsnr/rac1/listener_scan2/alert/
[grid@rac1 ~]$ grep service_register log.xml | head -3
 <txt>13-AUG-2012 05:25:00 * service_register * LsnrAgt * 0
 <txt>13-AUG-2012 20:29:07 * service_register * luocs1 * 0
 <txt>13-AUG-2012 20:58:05 * service_register * luocs1 * 0
-- 這是我另一套測試RAC環境。

4）SCAN監聽器動態更新日誌：
[grid@rac1 ~]$ grep service_update log.xml | head -3
 <txt>13-AUG-2012 20:29:19 * service_update * luocs1 * 0
 <txt>13-AUG-2012 20:30:19 * service_update * luocs1 * 0
 <txt>13-AUG-2012 20:30:46 * service_update * luocs1 * 0

注意，如果你的 RAC 是通過 hosts 解析了 SCAN 域名的，那麼系統裡就找不到上面的 SCAN 監聽器日誌的路徑。

例項的動態註冊和動態更新過程是由例項的 PMON 程序完成的，正是因為 SCAN 監聽器能夠實時瞭解例項的負載情況，所以 SCAN 監聽器能夠負載均衡地將連線請求轉發給合適例項的本地監聽器來處理。

這裡談到負載均衡，那麼就說下負載均衡中的優先順序

共享伺服器配置中：

低負載節點
低負載例項
例項相關的低負載排程器

專用伺服器配置中：

低負載節點
低負載例項

SCAN 相容性配置

介紹 SCAN 差不多了，這裡還有個相容性問題不能不說。要完美實現 SCAN 功能特性，其實對客戶端的要求也是存在的。下面看下不同版本和 SCAN 之間的相容性。

編號	客戶端軟體版本	伺服器端軟體版本	SCAN 特性的使用
1	11g R2	11g R2	能夠充分使用 SCAN 的特性
2	早於11g R2 版本	11g R2	不能充分感受到 SCAN 特性
3	11g R2	早於11g R2 版本	在伺服器端沒有 SCAN 的概念
4	早於11g R2 版本	早於11g R2 版本	在伺服器端沒有 SCAN 的概念

這裡稍微詳細說一下第2種情況，如果客戶端低於11g R2 的版本，在 DNS 解析的3個 VIP 地址中，可能只能固定地使用第一個 SCAN VIP 連線資料庫；如果該 SCAN VIP 對應的監聽器出現故障，那麼整個連線將會失敗，客戶端也會收到到錯誤資訊。

那針對相容性問題我們拿出各種客戶端配置方法

1）客戶端和伺服器端軟體版本都是11g R2的時候
Tnsnames.ora
RACSCAN =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = luocs-cluster-scan.grid.luocs.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
             (SERVICE_NAME = luocs10g)
    )
  )

2）客戶端是早於11g R2的版本，伺服器端是11g R2的時候
RACSCAN =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (LOAD_BALANCE=on)
      (FAILOVER=on)
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.193)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.194)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.195)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = luocs10g)
    )
  )

為了確保在早於11g R版本的客戶端負載均衡和失敗切換，我們需要在tnsnames.ora中新增3個SCAN VIP。

3）傳統的RAC客戶端配置方法
先從客戶端正常地解析伺服器所有節點的主機名稱和相應的VIP名稱，
最好和服務端/etc/hosts一致。當然，我們不解析名稱的情況下還可以使用VIP地址，比如：

LUOCSRAC =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.193)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.194)(PORT = 1521))
      (LOAD_BALANCE = yes)
      (FAILOVER = on)
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = luocs)
    )
  )

本地客戶端hosts解析之後，使用名稱：
LUOCSRAC =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.luocs.com)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.luocs.com)(PORT = 1521))
      (LOAD_BALANCE = yes)
      (FAILOVER = on)
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = luocs)
    )
  )

注意：傳統的客戶端配置方法其實還有多種，這個在這裡不細說。

4）JDBC字串配置
早期版本：
jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.luocs.com)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.luocs.com)(PORT = 1521))(LOAD_BALANCE = yes)(FAILOVER = on))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = luocs)))

11g R2：
jdbc:oracle:thin@luocs-cluster-scan:1521/luocs

注意：JDBC 是不支援 TAF 的，所以通過 JDBC 連線無法實現 Failover，那有沒有解決方法，我們可以使用應用的連線池來實現，也就是當連線的時候發現某些連線有故障，那自動切換到正常例項的連線。

最後我貼一下 SCAN 配置資訊的檢查方法和 DNS、GNS 方式 SCAN 解析例項。

首先 SCAN 配置資訊的檢查：

DNS 方式配置 SCAN：

然後我們在安裝 GI 的時候使用 scan.luocs.com 即可，當然要不選擇 Configure GNS。

GNS方式配置SCAN：

然後我們在安裝GI的時候使用SCAN Name填寫：rac-cluster-scan.gns-server.rac.com，選擇Configure GNS，GNS Sub Domain填寫gns-server.rac.com，GNS VIP Address填寫192.168.77.95。其中SCAN Name的填寫有講究的，就是再不包含域名的情況下前面的字元不能超過15個，另外192.168.77.95就是GNS VIP。

近期文章

刪繁就簡-雲和恩墨的一道面試題解析

用SQL解一道數學題：Gauss和Poincare

新年賀禮：雲和恩墨大講堂期刊發行

2015 Oracle 十大熱門文章精選

Oracle 12c ASM 防火防盜新特性揭祕

DBA入門之路：學習與進階之經驗談

DBA入門之路：關於日常工作的建議

三十八載，Oracle伴我同行—記我的成長之路

從Approx_Count_Distinct到M7的CPU整合

診斷工具與方法：從OS到資料庫

Cloud時代DBA的DevOps最佳實踐 - SQL 稽核