在近期的第七屆資料技術嘉年華上，雲和恩墨技術專家曾令軍做了“RAC效能優化實戰”為主題的演講，分享了從硬體架構、系統與引數配置、應用設計以及工作負載管理這四個層面，剖析在RAC效能優化的過程中，應當注意的問題以及可以借鑑的經驗和思路。我們再次分享出來，希望對各位有所指導借鑑。

RAC硬體架構

“千尺之臺，始於壘土”，硬體架構是決定RAC環境執行效能最基礎的部分。下面是一個比較簡單的RAC架構拓撲圖，一個儲存、兩臺主機、三條網路，構成了一套RAC環境。

使用者通過業務網發起一個查詢請求，資料庫會判斷要請求的資料塊在兩個節點的記憶體(buffer cache)中是否存在，如果存在，這些資料塊就通過私網複製傳遞到需要的節點上，如果沒有，再從儲存讀取到記憶體。在這個過程中，私網負責資料塊傳遞及鎖控制方面的通訊，而儲存，除了要響應資料請求，還要負責儲存資料和記錄日誌。所以，共享儲存和私有網路被認為是RAC系統的核心和靈魂

換句話說，如果這兩部分元件的效能有問題，對RAC環境的影響也是最大的。

既然這兩部分元件在RAC環境中如此重要，在做基礎硬體選型及規劃的時候，需要基於業務系統的規劃要求，瞭解硬體環境是否能夠滿足業務的發展需要，把好效能優化的第一關。

在RAC環境中，儲存層面最關注的指標包括I/O吞吐量、IOPS、I/O延時；而私有網路層面最關注的是頻寬和網路延時。這裡順便介紹兩個工具：Orion和Netperf，可以很好地滿足這兩部分元件的測試需求。

在規劃重要系統的硬體架構時，需要考慮RAC環境的一些特殊要求，尤其是效能負載特別高的系統。以下是在RAC硬體架構層面的一些實踐經驗，供大家參考：

雙公網、雙私網、多儲存鏈路。公網（業務網）建議每個主機使用兩塊網絡卡做網絡卡繫結；私網配置兩塊網絡卡，安裝的時候都選上，叢集就會為它們配置HAIP；儲存要使用多條儲存鏈路，並安裝多路徑軟體。這樣做的好處，一是消除單點故障，另外有些配置還能夠起到負載均衡的作用。

萬兆頻寬是為了應對私網流量大的壓力，減輕網路頻寬出現瓶頸的問題。使用共享的交換機，一個是對於壓力大的系統，頻寬可能互相爭用或限制，另外由於HAIP是虛擬地址，如果用VLAN，還可能可能遇到IP與閘道器地址衝突的問題。所以，重要系統的私網最好能使用單獨交換機。

ASM技術在11G已經非常成熟，不但效能好，對於磁碟的管理維護也特別方便。如果有條件的話，建議使用normal的冗餘方式，這樣做的好處，一個是資料多一份備份，另外就是ASM有一些特效能夠提升讀寫效率，例如11G的優先讀取失敗組，12C的均勻讀取失敗組。

磁碟大小相同有利於磁碟的容量管理和磁碟組中資料的rebalance效能，11G的資料庫軟體還不支援大於2T的磁碟。

把不同的檔案放在不同的磁碟組，可以起到I/O分流的作用，但這個設計不僅僅是出於讀寫效能的考慮，也是基於資料安全的考慮，如果資料和歸檔放在同一個磁碟組，萬一這個磁碟組有問題，不但資料檔案讀不出來，使用備份恢復的時候，連歸檔日誌也讀不出來，那就會產生資料丟失的風險。

關於這點最近剛好遇到一個案例，這套系統提交特別頻繁，log file sync等待事件很嚴重。由於是效能測試階段，所以針對性地做了很多測試，redo日誌放在底層做raid5的儲存盤上效能是最差的，而放在raid10上是最好的。因為提交特別頻繁的系統，寫redo日誌都是小I/O操作，對儲存的iops效能要求特別高。raid5的iops效能是最差的，ssd盤iops效能雖然很高，但是它的資料塊擦寫的方式，存在寫峰值的問題。大多數情況下log write效能都很好，當峰值一出現，就會出現很多個使用者會話併發等待lgwr寫操作的完成，進而產生被成倍數放大的log file sync等待。所以我們建議對於效能要求特別高的聯機業務系統，redo日誌要放在普通的機械磁碟的raid10磁陣上。另外，這是一個存在爭議的問題，可能某些高階全快閃記憶體儲存上並不存在寫峰值的問題，因此如果是特別重要、壓力特別大的系統，測試過程是不可或缺的。

系統與引數配置

系統與引數配置分為三個層次（從底向上）：作業系統配置、Grid和RDBMS軟體配置、資料庫引數配置。

作業系統配置

作業系統配置層面，有如下兩點建議：

• 使用推薦的作業系統版本、安裝補丁程式
  
• 配置系統引數、網路引數、非同步IO引數、VMO引數、記憶體大頁
  

在安裝配置作業系統時，針對不同的作業系統，建議按照官方的指引文件進行配置，以減少遇到各種效能問題或BUG的風險。

Oracle Database (RDBMS) on Unix AIX,HP-UX, Linux, Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) (文件 ID 169706.1)

MOS上的這個配置指引文件，列舉了各種作業系統平臺上，安裝資料庫之前要注意的配置事項，有很高的參考價值。

下面通過兩個案例說明配置合適的系統引數的重要性：

vmo -p -o minperm%=5 -o maxperm%=10 -o maxclient%=10 -o strict_maxclient=1 -o strict_maxperm=1 -o lru_file_repage=0 -o v_pinshm=1

這是針對AIX系統VMO引數的一個配置，在AIX系統中，記憶體分為計算型記憶體和非計算型記憶體兩部分，對於資料庫伺服器來說，主要使用的是計算型記憶體。而對於非計算型記憶體，在AIX中程序呼叫檔案進入記憶體，即便該程序結束釋放了所佔用的記憶體，系統也並不立即將該使用過的記憶體段重新整理為“fre”狀態，而是將其標註為檔案頁no-comp的方式存放於記憶體中，如果應用程式重複呼叫到該檔案就可以直接從記憶體中讀取資料。但這樣非計算型記憶體的使用量就會越來越高，空閒頁越來越少，當計算型記憶體需要申請更多的記憶體空間時，就有可能出現因為記憶體重新整理或分配導致嚴重的效能問題，甚至會出現節點驅逐。因此對於資料庫伺服器來說，建議將maxperm%這個引數設成一個較小的值，通常為20%以下，用來限制非計算型記憶體的最大使用量。

RHEL6.6:IPC Send timeout/node eviction etc with high packet reassbemles failure(DOC ID 2008933.1)

這個案例是由於作業系統引數配置不合理導致的一個BUG，從標題可以看出，問題是由於大量的包重組失敗引起了節點驅逐。網絡卡之間傳遞資料時，會根據MTU（Maximum Transmission Unit）的尺寸，大的UDP資料包可能被分片，並在多個幀中傳送。這些零散的資料包需要在接收節點上重新組合。分片的報文需要在指定時間內完成重組，已經收到但由於空間不足（例如reassembly buffer）沒有進行重組的資料分片會被直接丟棄。

LINUX環境中存在兩個引數：

net.ipv4.ipfrag_low_thresh：用於IP分片匯聚的最小記憶體用量

net.ipv4.ipfrag_high_thresh：用於IP分片匯聚的最大記憶體用量

這兩個引數指定的記憶體空間，用於網路包的分片和重組，這部分記憶體空間一旦用盡，分片處理程式將丟棄網路包的分片，出現包重組失敗的問題。在redhat6.6之前的版本中，這兩個引數為最小值6M、最大值8M。而在redhat6.6版本中，這兩個引數被改成了最小值3M、最大值4M，當私網流量較大時，很可能引起包重組失敗率過高，而導致資料庫層面的IPC通訊超時。超時持續300秒，就會觸發節點驅逐，這也是一個較為嚴重的問題。

作業系統作為RAC執行的基礎軟體環境，不管是作業系統版本還是作業系統的引數配置，對於資料庫來說，都是至關重要的。因此，在做作業系統的使用規劃和安裝配置時，一方面要遵循官方的指導建議；另一方面也要廣泛查閱相關的資料文件，避免遇到這些影響系統穩定執行的潛在風險。

作業系統配置

資料庫軟體配置層面，有如下三點建議：

穩定的版本通常是小版本號比較高的版本，例如10.2.0.4、10.2.0.5、11.2.0.4

grid軟體的PSU可以比Rdbms軟體更高，但建議讓他們保持相同的版本上執行

通常oracle每個季度會發佈一個PSU版本，這些PSU中包含了對於資料庫穩定性或安全性影響較大的問題的修復補丁，打上這些PSU，就可以避免遇到這些問題。所以，對於特別重要的系統，要制定PSU的更新策略，另外，還需要關注PSU上最新的one off patch的更新資訊。同樣，通過一個案例來說明資料庫軟體及補丁更新的重要性。

11gR2/Aix - Dedicated Server Processes Have Large USLA Heap Segment Compared To Older Versions (文件 ID 1260095.1)

這個案例是在11.2.0.3上的一個BUG，在專有連線模式下出現的程序消耗記憶體量過多的問題。在專有連線模式下，資料庫會為每個使用者連線分配一個使用者服務程序，正常情況這個程序初始的記憶體消耗量為3.5M左右，但遇到這個BUG時，每個程序初始的記憶體消耗量為10M左右。這樣就會造成資料庫伺服器出現記憶體消耗過高的問題，而主機記憶體不足時，就會引發一系列的問題。解決這個問題辦法就是打補丁或者升級資料庫版本。這個例子也說明，有時候我們收到使用者系統變慢的通知，在資料庫中並不能發現什麼效能問題，問題的真正原因很可能是由於主機層面的資源限制引起。

談到PSU升級和打補丁的問題，不得不提到兩個坑，希望能夠給大家提供參考，少走一些彎路：

jar命令解壓問題：

PSU的補丁包是.zip檔案，在解壓這些檔案時，通常使用unzip命令。而在AIX環境中，unzip並不是預設配置在path路徑中的，有時候為了偷懶，可能會想到做jar命令來進行解壓。unzip和jar命令解壓最大的區別在於檔案的許可權，使用unzip解壓出來的檔案與zip包中檔案原有的許可權是一致的，而使用jar命令解壓出來的檔案取決於環境變數umask的設定。所以預設情況下，jar命令解壓出來的檔案許可權就是660，這意味著PSU補丁包中所有檔案的可執行檔案全部丟失。當打完PSU啟動叢集時，就會遇到叢集無法啟動的現象。

online patch的問題：

在很多online patch的Readme檔案中，通常會有一個說明：該patch是可以線上應用的，但強烈建議在可停機維護的時間，將它打成普通的補丁模式（如果是online patch，在opatch lsinventory的結果列表中，會有“online”字樣的標記）。在我們打補丁的時候往往會忽略這個說明，因為以前並沒有遇到過如果沒有這樣做，會出現什麼情況。而在前段時間處理的一個案例，就恰好命中了這個問題。現象是在變更時間段，資料庫重啟後，應用一連上來，即使這時並沒有什麼業務發生，伺服器的CPU使用率接近100%。看上去是一個非常嚴重的效能問題，但後來在排查的過程中，無意中發現補丁列表中有一個online patch，把它回滾掉，然後再以普通的模式apply，CPU使用率又恢復正常。

資料庫引數配置

在RAC環境中，有三個資料庫引數是需要注意的：

parallel_force_local--建議設定為true，用於控制需要開並行守護程序的會話只能在該會話當前所在例項上開啟並行守護程序。因為並行程序所操作的資料很可能非常接近，如果在多個例項同時執行，很可能產生大量的私網間的資料塊傳遞和例項間資源爭用。

gcs_server_processes--用於控制LMS程序的數量。在某些特殊環境中，RAC兩個節點的CPU數量可能不一致，而CPU核數，決定了LMS程序初始化的數量，lms數量不一樣在高負載時會產生嚴重的效能問題，在此種情況下，需要手工設定gcs_server_processes引數，使RAC資料庫所有節點的lms程序數相同。

DRM（dynamic remastering）特性--建議關閉。在RAC環境中，資料塊資源有一個主節點，為了提升本地節點的命中率，DRM特性可以動態調整資料塊資源的主節點，哪個節點上對該資源請求的次數最多，就讓它做了該資料塊的主節點。但在調整主節點的過程中，有可能出現超時，使系統性能不穩定、嚴重的時候使資料庫掛起。

 read、deferred_segment_creation、delayed failed logins、undo_autot
另外，單例項資料庫的引數優化在RAC環境同樣適用。這裡例舉一些引數或特性：
parallel_max_server 、 adaptive_cursor_sharing、cardinality feedback、
serial direct pathune 、audit_trail 、adaptive_log_file_sync

很多特性都是11G的新特性，但是遇到問題的也往往是這些新功能、自適應或自動調整功能。以密碼延遲驗證為例，做一個說明。密碼延遲驗證是為了防止密碼暴力破解所做的一個應對措施，先看兩個趨勢圖：

單個連線密碼錯誤時資料庫響應時間的變化：

併發連線密碼錯誤時資料庫響應時間的變化

從上圖可以看出，密碼延時驗證的功能，是當連續出現（超過三次）錯誤密碼連線請求的時候，有規律地將密碼驗證返回的時間變長。

問題在於，由於這個響應時間變慢，如果錯誤密碼請求發起的過於頻繁，那麼在資料庫中就會出現兩個問題：

• 資料庫連線數快速累積，直到超出process最大數量，影響所有使用者建立新連線；
  
• 資料庫中出現大量的library cache lock等待事件，影響本使用者的登入，即使密碼是正確的。

應用設計

應用設計的問題在單例項資料庫中會引發效能問題，而在RAC環境中，設計上的小問題造成的影響有可能會非常嚴重。

區域性插入操作

在非常多的應用系統中，會存在這樣的設計：業務表中存在一個主鍵，例如id號，沒有真正的業務含義，使用sequence插入序列值。主鍵是有索引的、序列是有序增長的。每次表中有資料插入時，序列都會產生一個最大值，並在索引的最右邊的葉子塊增加一行記錄。同時，整個索引的最大值變化了，索引中分支塊、根塊都會同步更新。如果在RAC的兩個節點中，發生在表上的插入會話並行量增多，最右邊塊的競爭就會急劇增加。由於要更新索引塊中的資料，使用者會話需要不斷獲取和釋放全域性快取鎖，而導致嚴重的gc buffer busy acquire和gc buffer busy等待事件。由於熱點塊總是發生在索引樹的最右邊，也把這個問題稱為：右邊索引增長競爭。

針對這個問題的優化策略有三種：

1. 將索引建成雜湊分割槽索引。通過雜湊分割槽，一個索引會產生多個索引樹，競爭被分散到多個索引分割槽的最右邊。
   
2. 將該資料表改造成雜湊分割槽表，索引為本地分割槽索引
   
3. 將索引建成反向鍵索引。列的值被反向儲存在索引塊中，索引的插入值被分散到不同的葉塊上。
   

同時，要注意上述優化策略帶來的負面影響，例如反向鍵索引不支援範圍查詢。

大量的truncate和drop

在某些業務系統中會有這樣的設計，為了臨時存放某些計算結果或查詢結果，建立一箇中間表，用完之後又把它truncate或drop掉。但開發設計人員沒有意識到，這種建立和刪除表的DDL操作，在RAC環境中，會觸發多種等待佇列，包括所有例項記憶體緩衝區的物件佇列掃描（GCS）、觸發檢查點事件的等待、所有關聯物件釋放解析鎖的等待（GES）。而在多數情況下，這些應用場景都是可以被oracle的全域性臨時表替代的，只是開發人員不具備這方面的知識。由於全域性臨時表基於會話獨立，且會話結束後，資料即被丟棄，因此不再需要額外的DDL操作，從根本上避免了這類問題。

Sequence快取

在RAC環境中，序列的值被快取在所有例項中，序列快取的預設值是20，對於繁忙的系統來說，這個快取值是不夠的，當產生序列請求等待的時候，在資料庫中往往會出現row cache lock等待事件。同樣的道理，當應用設計人員將序列的屬性改成“order、nocache”時，被頻繁訪問的序列會產生很大的效能影響。每次訪問序列都要更新seq$表，如果很多會話同時要求訪問序列，那麼行快取鎖等待就會變得非常嚴重。

因此，對於sequence的使用要注意：

1. 如果序列的併發訪問量較高，且業務層面沒有不跳號、不斷號的需求，則可以為該序列設定一個較大的快取值，例如1000以上。
   
2. 如果序列一定要order、nocache，則可以考慮是否根據業務邏輯將這個序列拆分為多個序列，減少競爭。
   

當然還有很多的應用設計問題會造成RAC效能緩慢，例如：應用系統提交過於頻繁、系統中存在大事務長事務、存在大表的全表掃描、過多的並行操作、索引設計不合理等等，在此不一一說明。

工作負載管理

分析應用關聯性，實現業務分割，在RAC效能優化中也是一種覺見的手段，而且往往是非常有效的手段。藉助於資料庫的服務管理，應用程式的工作負載可以被關聯、分配。上圖中以銀行業務的垂直分割為例，希望能為大家提供思路上的參考。早期的銀行核心業務系統，集合了存款業務和貸款業務，而這兩種業務的耦合度非常低，它們使用不同的業務表，完全具備分割的基礎。那麼，我們可以在資料庫層面建立兩個服務，service1用於存款業務的連線配置，service2用於貸款業務的連線配置。在服務的建立過程中，指定TAP的引數配置，例如service1以節點1為主用節點，以節點2為備用節點。正常情況下，service1只在節點1上執行，當節點1發生故障的時候，該服務會自動切換到節點2繼續接收使用者請求。在完成業務分割，最大限度地減少例項間資料傳遞和爭用的同時，又充分利用了RAC環境的高可用性。

構建一套效能優越的ORACLE RAC資料庫是一門藝術，而在RAC環境中遇到效能問題，不斷地調整優化，更需要多方面的專業知識和精心設計。