Oracle RAC 建設過程中各個層面關鍵點和最佳化項總結

原題：Oracle RAC建設過程中必須要知和要做的事情   作者：趙海，某城商行系統架構師，專注並擅長銀行資料中心解決方案規劃及設計。

資料庫建設過程中缺少可以遵循的實踐標準，知識點和經驗點散落四處難以快速形成邏輯性強的參照標準，面對專案令人無從下手。本文是基於資料建設的規劃、實施以及配置最佳化等階段對大量文獻的總結提煉，以及從專案的實踐出發，對資料庫建設過程中各個層面應該注意的事項進行的總結。優質長文，建議先收藏後看。

1.背景描述

資料庫建設是每一個企業資料中心建設過程中非常重要的一個環節，直接關係到業務連續性和穩定性。但是我們在資料庫建設過程當中卻很少有可以遵循的實踐標準。當我們面對整個建設專案的規劃設計和配置最佳化的時候，又覺得無從下手。散落在官方網站上的一些知識點和經驗點無法讓我們快速形成一個具有很強邏輯性的參照標準。本文希望透過以下篇幅的總結和分析，從各個層面給予實踐標準，為日後從事資料庫建設的專案提供一個參考思路。

2.儲存規劃設計的關鍵點 2.1 OCR/VOTE磁碟的合理規劃事項

什麼是OCR/VOTE磁碟，它在叢集中是什麼樣的角色呢？

ORACLE RAC ASM管理模式下，磁碟組通常有三個（+DATA，+FRA，+OCR），在OCR磁碟組當中所有的磁碟中儲存的資料包括兩部分，一部分是Vote File，另外一部分就是OCR（Oracle Cluster Registry）。Vote File是用來記錄叢集節點的磁碟心跳資訊，而OCR是儲存叢集配置資訊的資料。Vote File，以整個檔案的方式儲存在OCR磁碟上，不做任何條帶。下圖是其資訊記錄的一個說明：

以上是一個三節點的ORACLE RAC叢集的Vote FIle的一個示意矩陣，每一行是一個節點的寫入的資訊，例如第一行，Instance1分別把其對叢集中的三個成員（1、2、3）進行私網檢測的結果寫入到仲裁檔案當中，Instance2、Instance3同樣把其檢測結果寫入仲裁檔案，最終組成了三個節點的仲裁矩陣。當私網發生故障而從網路上導致叢集分割為幾個孤島子集的時候，叢集是透過這個檔案的資訊來判斷最後存活的節點。具體演算法有兩個非常重要的規則：

1. 保障隔離後的叢集子集中節點數目最多的子集存活。

2. 當隔離後的叢集子集獲得的仲裁票數相等時，保障例項號小者存活。

對於Vote File本身的數目來講，Oracle又有一個非常重要的規則：叢集節點獲得的Vote File數目小於N/2+1時，節點就會被叢集驅逐出叢集，N是Vote File的總數目。也就是說叢集中所有節點獲得的Vote File數目必須要大於等於N/2+1。

根據以上結果來看，對於VOTE磁碟組的規劃，首先偶數個仲裁磁碟必然會造成一個浪費。那麼我們就沒有必要選擇偶數仲裁磁碟。然後我們再考慮磁碟組磁碟的容錯能力，為了保障我們至少有1份磁碟容錯能力，我們的仲裁磁碟至少是3塊兒。也就是說對於OCR磁碟組的規劃來講，至少保障其內有三個容錯組，每一個容錯組裡面一塊兒仲裁磁碟。

對於OCR來講，它屬於叢集的資源註冊資訊，是叢集執行的前提條件。所以一定要保障它的高可用性。由於它屬於配置資料，那麼一定會遵循ORACLE ASM的磁碟冗餘策略（External、Normal、High）。也就是說OCR在OCR磁碟組裡面可以擁有1份、2份、3份映象。每份映象的資料條帶會落在一個獨立的容錯組裡。

綜上所述，對於OCR磁碟組的規劃，為了保障仲裁盤的至少一份的容錯能力以及OCR資料的高冗餘策略，我們應該至少將磁碟組內規劃為3個磁碟，每一個磁碟落在一個獨立的容錯組。磁碟大小建議為1GB以上（雖然OCR Device = 300M左右）。

2.2 儲存外部冗餘架構設計

首先一定要用多路徑軟體對Lun進行路徑管理，並且保障鏈路切換策略為負載均衡模式。對於鏈路的數目來講最佳為8條鏈路。而且需要保證這8條鏈路在光纖口、光纖卡、接入交換機、核心交換機、儲存控制器5個層面上的冗餘。例如2張雙口光纖卡，每個光纖卡透過各自接入交換機連線到不同的兩個核心交換機上，核心交換機又分別與兩個儲存控制器的前埠相連線。在光纖交換機的zone配置裡，每一個主機光纖口wwn和儲存的一個前埠wwn配置在一個zone裡面，埠比例為1:2，總共有8個zone。用示意圖的方式表示如下：

2.3 NFS架構的儲存配置引數

Orace RAC的ASM磁碟可以是網路儲存架構實現的Lun，當然我們也可以利用檔案系統或者裸盤作為資料庫的儲存資源。但是在掛載NFS卷的時候，有若干引數是值得我們注意的。

1）Hard/soft：當應用程式傳送一個請求，Hard情況下，客戶端遇到錯誤不會立即通知應用，而是在後臺進行重試直到正常，這會導致應用程式的阻塞；Soft情況下，客戶端會立刻通知應用導致應用掛起。從這個意義上來講，Soft對應用的響應速度會比Hard好，但是如果網路不穩，那麼Soft有可能導致應用資料被損壞。這也是Oracle建議將這個引數設定為Hard的理由。

2）Rsize/Wsize:客戶端從伺服器端讀寫檔案的最大數目（byte）/每次請求。如果該引數不做設定的話，那麼它是透過客戶端和伺服器端的協商完成的。一般建議設定為固定的32768。

3）Timeo: 建議為600（60秒）。

4）Intr/nointr: 是否允許接受檔案操作的中斷訊號，一般而言設定為nointr。

5）Noac/ac: ac情況下，客戶端會快取檔案屬性資訊，從而提高客戶端的讀效能。Noac情況下，客戶端不會快取檔案屬性資訊，任何情況下的讀都是NFS檔案系統上檔案的實時版本資訊。Ac情況下，客戶端會定期掃描Server端的檔案實時資訊，其他時候都是讀取自己快取的資訊。NFS卷作為資料庫的儲存磁碟，只需要實時反映檔案的真實版本資訊即可，不需要客戶端再去做快取，資料庫有自己的快取機制。因此一般情況下Oracle建議將這個引數設定為Noac。

當然這些引數，根據不同的作業系統特點是會有一些差異。表2.3是摘自Oracle官方釋出的NFS儲存最佳實踐參數列當中的一部分，可以提供通用參考。

2.4 ASM磁碟組規劃

（1）磁碟組相關

除了OCR磁碟組之外，一般建議建立磁碟組不超過2個，一個是存放資料的資料磁碟組（+DATA），另外一個是存放日誌的閃回區磁碟組(+FRA)。假設我們選擇磁碟組的冗餘策略為Normal，那麼建議磁碟數目為偶數個並且至少為4個相同大小相同效能配置，一方面考慮到冗餘為2份，另外一方面保障Failure Group裡面數目的條帶化分佈，可以保障磁碟組的讀寫效能。如果是其他冗餘策略，那麼按照同樣的思路去選擇磁碟組的數目。另外Lun的大小不能超過2T（容易引起ORA-15196、ORA-15099問題）。

（2）磁碟分配單元及檔案條帶

AU是ASM Disk Group磁碟空間分配單元。Strip實際上是檔案層面的條帶，準確說法應該是檔案的擴充套件塊兒。對於檔案的擴充套件塊兒來講就是檔案切割的單元。它有兩種模式（coarse & fine）。對於coarse模式來講，擴充套件塊兒大小等於AU大小，對應的引數固定不變（_asm_stripesize=AU，_asm_stripewidth=1）。對於fine模式來講，擴充套件塊兒大小是可以進行調整，根據我們的業務需求進行適當調整。例如設定為256K，那麼原來1M的檔案寫在一個磁碟中的AU中，那麼現在可以並行寫入到賜個磁碟的4個AU當中。充分發揮了小IO的並行讀寫效能。但是對於某些大IO的資料庫業務，那麼AU可以適當調整到4M，同時啟用作業系統的大頁讀寫引數。檔案擴充套件塊兒可以保持corse模式。對於一般的OLTP業務來講，資料檔案、歸檔檔案一般設定為corse；而redo日誌、控制檔案、flashback日誌設定為fine。對於11g之後的oracle，這些引數基本不需要我們去主動調整，除非確實有效能問題與之相關。

2.5 ASM記憶體管理引數

（1）記憶體引數相關

 db_cache_size: 緩衝區，存放metadata塊兒的buffer cache，建議值為64M。

 shared_pool: 管理ASM例項所需要的記憶體池，建議值為128M。

 Large_pool: 用來儲存 extent maps，建議值為64M。

（2）其他引數相關

在11g當中，如果多個資料庫共享ASM例項的話，那麼建議按照以下規則計算process的數目設定。

ASM processes = 25 + （10 + max（可能的併發資料檔案變化））* 資料庫的數目。當然這個數目需要一個經驗的評估，需要根據叢集環境資料庫的情況以及業務IO的判斷來估算。

2.6 非同步IO配置

一般來講資料庫應用都是要啟用非同步IO來提高資料庫的IO效能。同時需要開啟作業系統的非同步IO引數和資料庫的非同步IO引數。以Linux為例，在作業系統層面需要設定引數 aio-max-nr=1048576（11g 中設定為 4194304），表示同時可以擁有的非同步IO請求數目。然後在Oracle資料庫層面設定以下兩個引數：filesystemio_option=setall；disk_asynch_io=true。對於AIX來說，需要設定以下三個引數（aix_maxservers, aix_minservers,aio_maxreqs）對於OLTP業務來講，IBM官方的建議值為（800,200，16384）。

以上的引數值只是一個通用的參考，但是以上所述的引數具體配置的值還是需要根據自己環境的資料來評估。比如我們需要關注iostat中的io等待情況和aio的一系列指標來判斷設定值的科學與否。

2.7 ASMLib & Udev

對於Linux平臺而言，Oracle RAC的ASM磁碟管理有三種方式（ASMlib、DM、udev），我們首選的方式是ASMlib，對於 RHEL6（從6.4開始），核心驅動軟體包'kmod-oracleasm'已經在 Redhat 平臺上啟動，並且可以透過RedHat Network (RHN)上的"RHEL Server Supplementary (v. 6 64-bit x86_64)" 渠道進行安裝。這個模組的更新將會由 RedHat 提供。

對於ASMlib的方式，它是透過以下命令方式建立ASM磁碟：

# /usr/sbin/oracleasm createdisk disk_name device_partition_name

透過這種方式建立的ASM磁碟組名稱（disk_name）,唯一繫結的是後面的device_partition_name，因此我們必須保障作業系統在日後的Lun變更過程中，這個命名是不能夠變更的。假設我們用的是第三方多路徑軟體管理方式實現，那麼需要透過多路徑管理軟體的方式來講磁碟的device_partition_name和磁碟的唯一ID關聯。例如emcpowerpath可以用emcadm export/import方式來保障Rac節點上的Lun名稱一致。

對於udev的方式，同樣道理我們需要將磁碟的scsi-id和最終形成的asm磁碟名稱進行關聯，而不是用磁碟在作業系統顯示的裝置名來關聯。例如：

KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="36000c29a972d7d5fe0bf683b21046b34", NAME="asmgrid_disk1", OWNER="grid", GROUP="asmadmin", MODE="0660"

其中的PROGRAM欄位非常重要，它表示我們是用什麼方式來關聯磁碟在作業系統和ASM之間的對應關係。如果在日後的運維過程中，隨著磁碟的增減變化或者伺服器的重啟變更等導致了磁碟裝置名發生變化，那麼就會導致ASM磁碟符號紊亂，最終資料庫叢集無法啟動。當然這個問題在11g之後就不存在了，因為11g之後ASM自動會去根據磁碟的唯一ID匹配ASM識別的磁碟ID，節點的讀寫是根據磁碟的ASM標示來執行的。但是從管理科學角度還是應該按照最佳實踐來做從而保障沒有任何風險。

2.8 AIX平臺關注的儲存引數

對於AIX平臺而言，儲存卷的系統引數必須遵循以下規則。

(1) reserve_lock、reserve_policy

該兩個引數其實都是表示作業系統是否持有儲存卷的共享鎖方式。儲存陣列型別為SSA, FAStT, 或者其他 non-MPIO-capable disks，引數設定參照A。儲存陣列型別為SS, EMC, HDS, CLARiiON, 或者其他 MPIO-capable disks，引數設定方式參照B。

A. # chdev -l hdiskn -a reserve_lock=no

B. # chdev -l hdiskn -a reserve_policy=no_reserve

(2) 磁碟在加入ASM磁碟組之前，必須清除其盤頭PVID資訊。否則就會導致ORA-15063、ORA-15040、ORA-15042等磁碟錯誤。

(3) fc_err_recov。

該參數列示因為AIX平臺下光纖斷掉場合下，讀寫錯誤切換的時間。正常情況下，這個切換會導致資料庫IO掛起10分鐘。如果是Vote disk，就會導致叢集重啟。為了避免此類情況發生需要把該引數的值設定為fast_fail，實現快速切換。

(4) max_transfer。

該引數建議設定最少為Oracle最大請求的IO大小，一般超過1M。

(5) queue_depth。

該參數列示Lun的最大IO佇列深度，這個引數的設定必須足以支撐資料庫併發讀寫的負載。

(6) max_xfer_size。

該參數列示光纖卡的最大傳輸大小，這個引數的設定必須與磁碟的吞吐引數保持倍數關係，並且必須大於磁碟設定的引數。

(7) num_cmd_elems。

該參數列示光纖卡接受的最大IO請求數目，這個引數同樣與磁碟的queue_depth有著倍數關係，具體值的設定需要看環境當中光纖卡和其所容納Lun的數目。

3.網路規劃設計的關鍵點 3.1 硬體及引數

從Oracle官方的推薦來看，他們首先推薦使用萬兆乙太網，至少使用千兆乙太網，負載如果很高那麼私網可以採用infiniband。當然這個完全取決於客戶生產環境的具體業務量及負載情況。這個僅僅是個參考，有條件的情況下可以按照推薦進行配置。私網的連線需要使用交換機，Oracle叢集安裝並不支援私網的直連架構。網路卡及交換機的雙攻擊速率引數保持正確一致。

3.2 網路卡繫結

各種平臺都有自己的網路卡繫結工具，而且提供負載均衡和主備模式的繫結。首先為了提高公網和私網的網路高可用，網路卡需要繫結。對於Linux平臺我們需要在配置檔案 “/etc/modprobe.d/dist.conf” 中將數mode來控制網路卡繫結的具體策略：

 mod=0，即：(balance-rr)Round-robin policy（平衡掄迴圈策略）。

 mod=1，即： (active-backup)Active-backup policy（主-備份策略）。

 mod=2，即：(balance-xor)XOR policy（平衡策略）。

 mod=3，即：broadcast（廣播策略）。

 mod=4，即：IEEE 802.3ad Dynamic link aggregation（IEEE802.3ad 動態連結聚合）。

 mod=5，即：(balance-tlb)Adaptive transmit load balancing（介面卡傳輸負載均衡）。

 mod=6，即：(balance-alb)Adaptive load balancing（介面卡適應性負載均衡）。

對於私網網路卡繫結方式mode=3&6會導致ORA-600，公網網路卡繫結方式mode=6會導致BUG9081436。對於具體的繫結模式，對於平臺版本低而且網路架構非常複雜的場合，還是建議主備模式，因為主備模式更穩定，不容易產生資料包路徑不一致的問題。如果是負載均衡模式的場合，如果網路引數設定不是很科學的情況下，很容易出現從一個物理網路卡傳送報文，但是回報文卻回到另外一個物理網路卡上，網路鏈路再加入防火牆的規則之後，非常容易導致丟包問題發生。

而對於AIX平臺來講，將引數mode修改為NIB或者Standard值。Standard是根據目標IP地址來決定用哪個物理網路卡來傳送報文，是基於IP地址的負載均衡，也不易產生上述的丟包問題。

3.3 SCAN

Oracle RAC，從11gr2之後增加了SCAN（Single ClientAccess Name）的特性。

SCAN是一個域名，可以解析至少1個IP，最多解析3個SCAN IP，客戶端可以透過這個SCAN 名字來訪問資料庫，另外SCAN ip必須與public ip和VIP在一個子網。啟用SCAN 之後，會在資料庫與客戶端之間，新增了一層虛擬的服務層，就是SCAN IP和SCAN IP Listener，在客戶端僅需要配置SCAN IP的tns資訊，透過SCANIP Listener，連線後臺叢集資料庫。這樣，不論叢集資料庫是否有新增或者刪除節點的操作，均不會對客戶端產生影響，也就不需要修改配置。對於SCAN相關的配置，有以下一些配置注意事項：

（1）主機的預設閘道器必須與SCAN以及VIP在同一個子網上。

（2）建議透過 DNS，按round-robin方式將 SCAN 名稱（11gR2 和更高版本）至少解析為 3 個 IP 地址，無論叢集大小如何。

（3）為避免名稱解析出現問題，假設我們設定了三個SCAN地址，那麼HOSTs檔案當中不能出現SAN的記錄，因為HOSTs檔案當中的記錄是靜態解析，與DNS動態解析相悖。

3.4 網路引數

作業系統平臺上關於網路的核心引數非常重要，直接決定私網公網資料傳輸的穩定性和效能。不過針對不同的作業系統，相關的引數設定也各有差異。

1．Linux

對於Linux平臺的核心引數，有兩個非常重要（net.core.rmem_default、net.core.rmem_max）。具體功能解釋如下：

 net.ipv4.conf.eth#.rp_filter：資料包反向過濾技術。

 net.ipv4.ip_local_port_range：表示應用程式可使用的IPv4埠範圍。

 net.core.rmem_default：表示套接字接收緩衝區大小的預設值。

 net.core.rmem_max：表示套接字接收緩衝區大小的最大值。

 net.core.wmem_default：表示套接字傳送緩衝區大小的預設值。

 net.core.wmem_max：表示套接字傳送緩衝區大小的最大值。

為了獲得更好的網路效能，我們需要根據具體情況把以上兩個引數從其預設值適當調整為原來的2-3倍甚至更高，關閉或者設定反向過濾功能為禁用0或者寬鬆模式2。

2.AIX

對於AIX平臺的核心引數，以下設定是從Oracle官方文件摘出的最佳配置：

tcp_recvspace = 65536；tcp_sendspace = 65536；

udp_sendspace = ((db_block_size *db_multiblock_read_count) + 4096) ；

udp_recvspace = 655360；

rfc1323 = 1；

sb_max = 4194304；

ipqmaxlen = 512；

第1、2個參數列示TCP視窗大小，第3、4個參數列示UDP視窗大小。rfc1323啟用由 RFC 1323（TCP 擴充套件以得到高效能）指定的視窗定標和時間圖示。視窗定標允許 TCP 視窗大小（tcp_recvspace 和 tcp_sendspace）大於 64KB（65536）並且通常用於大的 MTU 網路。預設為0(關)，如果試圖將 tcp_sendspace 和 tcp_recvspace 設為大於 64 KB則需要先修改此值為1。ipqmaxlen 表示指定接收包的數目，這些包可以列在 IP 協議輸入佇列中。sb_max指定一個 TCP 和 UDP 套接字允許的最大緩衝區大小。

3.5 安全配置事項

1．Linux平臺下的防火牆需要關閉，否則會引起公網或者私網的通訊問題。

# chkconfig iptables stop

2．Linux平臺下的selinux安全配置項需要關閉，配置檔案為/etc/security/config。

SELINUX=disabled

3．如果是Power System主機的PowerVM虛擬化架構下的AIX平臺，如果發現Oracle RAC的兩個節點之間有大量丟包現象或者是以下幾種事件：

 Cache Fusion "block lost"

 IPC Send timeout

 Instance Eviction

 SKGXPSEGRCV: MESSAGE TRUNCATED user data nnnn bytes payload nnnn bytes

那麼我們需要檢查VIOS分割槽作業系統的補丁資訊，如果沒有APAR IZ97457，那麼我們需要將這個補丁打上，詳細需到IBM官網找到相應的補丁及其詳細解釋。

3.6 通用注意事項

1.系統主機名、域名等配置不允許有下劃線。

2.網路卡名稱在兩個節點上保持一致（例：public->eth1ð1，private->eth2ð2）。

3.網路卡裝置名稱當中不能包含“.”等特殊字元。

4.私網地址需遵守RFC1918標準，採用其所規定的ABC三類企業內部私網地址。否則會引起BUG4437727發生。A類：10.0.0.0 -10.255.255.255 (10/8位元字首)； B類：172.16.0.0 -172.31.255.255 (172.16/12位元字首)； C類：192.168.0.0 -192.168.255.255 (192.168/16位元字首)。而且私網VLAN需要與上述no-routeable子網之間需要是1:1的對映關係，以免引起BUG9761210。

5.從11gr2起，私網網段配置需要支援組播功能，因為私網需要透過組播模式實現通訊。

3.7 send (tx) / receive (rx)

UDP包傳輸的過程中，接受程式會讀取資料包頭的校驗值。任何校驗值損壞都會使這個包被丟棄，並導致重發，這會增加CPU的使用率並且延緩資料包處理。

由於網路卡上開啟了Checksum offloading 導致了checksum 錯誤，如果出現這樣的問題請檢查checksum offloading的功能是否被禁用，測試後考慮關閉網路卡上的該項功能。在Linux系統上執行ethtool -K <IF> rx off tx off可以關閉該功能。

3.8 MTU

不匹配的MTU大小設定會導致傳輸過程中出現 "packet too big" 錯誤並丟失資料包，導致global cache block丟失和大量的重傳（retransmission）申請。而且私網中不一致的MTU值會導致節點無法加入叢集的問題。

對於乙太網（Ethernet），大多數UNIX平臺的預設值是1500位元組。私網鏈路中所有裝置都應該定義相同的MTU。請確認並監控私網鏈路中的所有的裝置。為ping ,tracepath,traceroute命令指定大的，非預設尺寸，ICMP probe 包來檢查MTU設定是否存在不一致。使用ifconfig或者廠商推薦的工具為伺服器網路卡（NIC）的MTU設定合適的值。

Jumbo Frames 並不是IEEE 標準配置。單個Jumb Frame的大小是9000 bytes左右。Frame 的大小取決於網路裝置供應商，在不同的通訊裝置上的大小可能是不一致的。如果預設的MTU 尺寸不是9000bytes，請保證通訊路徑中的所有裝置（例如：交換機/網路裝置/網路卡）都能夠支援一個統一的MTU值，在操作的過程中必須把Frame Size（MTU Size）配置成這個值。不合適的MTU設定，例如：交換機上配置MTU=1500,但是伺服器上的私網網路卡配置成MTU=9000，這樣會造成丟包，包的碎片和重組的錯誤，這些都會導致嚴重的效能問題和節點異常當機。大部分的平臺上我們都可以透過netstat –s命令的‘IP stats’輸出發現包的碎片和重組的錯誤。大部分的平臺上我們可以透過ifconfig –a命令找到frame size的設定。關於交換機上的配置查詢，需要檢視交換機提供商的文件來確定。

4.作業系統層的關鍵最佳化項

4.1 相容性檢查

在Oracle建設實施之前，根據作業系統平臺對即將採用的相關資料庫技術進行相容性檢查。下面的link是官方的Matrix，分別針對Linux平臺和Unix平臺：

4.2 平臺版本及補丁

當我們選擇了具體的作業系統平臺以及具體的資料庫版本之後，接下需要做的事情就是要根據官方提供的文件來檢查我們的系統補丁以及相關軟體包是否齊全準確：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184026698780346&parent=DOCUMENT&sourceId=1526555.1&id=169706.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_240

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184190072886338&parent=DOCUMENT&sourceId=1526555.1&id=1393041.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_338

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=184287678146090&parent=DOCUMENT&sourceId=1526555.1&id=282036.1&_afrWindowMode=0&_adf.ctrl-state=bjsizj5t_436

Oracle官方對所有資料庫叢集及RDBMS等建議的最新補丁列表：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=202212137729856&parent=DOCUMENT&sourceId=1526083.1&id=756671.1&_afrWindowMode=0&_adf.ctrl-state=yi6z8ecqc_839#r11204

另外在AIX平臺上有一個不容忽視的地方，那就是必須保障Hacmp沒有安裝或者沒有任何殘留痕跡。

4.3 時間同步設定項

NTP是11gr2之前必須的選項，用來同步節點之間的時間。而到了11gr2之後，不僅僅可以採用NTP也可以採用CTSSD（Cluster Time Synchronization Daemon）代替NTP。如果NTP啟用的話，Oracle會採用NTP，CTSSD自動處於觀察模式。但是在NTP的啟用模式上，我們需要採用漸進式模式（需要利用啟動引數-x）。可以參照下面的配置：

1. /etc/sysconfig/ntpd

# Drop root to id 'ntp:ntp' by default.

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

# Set to 'yes' to sync hw clock after successful ntpdate

SYNC_HWCLOCK=no

# Additional options for ntpdate

NTPDATE_OPTIONS=""

4.4 ASLR (Address Space Layout Randomization)

ASLR是REL5 Linux以上版本中預設開啟的一個特性，是參與保護緩衝區溢位問題的一個電腦保安技術。是為了防止攻擊者在記憶體中能夠可靠地對跳轉到特定利用函式。ASLR包括隨機排列程式的關鍵資料區域的位置，包括可執行的部分、堆、棧及共享庫的位置。ASLR透過製造更多讓攻擊者預測目標地址的困難以阻礙一些型別的安裝攻擊。而在ORACLE的程式管理當中，多個程式共享相同地址的共享記憶體，開啟ASLR特性之後，Oracle就無法保障共享記憶體可用。從而導致ORA-00445錯誤發生。要在Linux上關閉這個特性需要新增或修改以下兩個引數到/etc/sysctl.conf檔案：

kernel.randomize_va_space=0

kernel.exec-shield=0

4.5 HugePage

大多數作業系統採用了分段或分頁的方式進行管理。分段是粗粒度的管理方式，而分頁則是細粒度管理方式，分頁方式可以避免記憶體空間的浪費。相應地，也就存在記憶體的實體地址與虛擬地址的概念。透過前面這兩種方式，CPU必須把虛擬地址轉換程實體記憶體地址才能真正訪問記憶體。為了提高這個轉換效率，CPU會快取最近的虛擬記憶體地址和實體記憶體地址的對映關係，並儲存在一個由CPU維護的對映表中。為了儘量提高記憶體的訪問速度，需要在對映表中儲存儘量多的對映關係。

Linux的記憶體管理採取的是分頁存取機制，為了保證實體記憶體能得到充分的利用，核心會按照LRU演算法在適當的時候將實體記憶體中不經常使用的記憶體頁自動交換到虛擬記憶體中，而將經常使用的資訊保留到實體記憶體。

通常情況下，Linux預設情況下每頁是4K，這就意味著如果實體記憶體很大，則對映表的條目將會非常多，會影響CPU的檢索效率。因為記憶體大小是固定的，為了減少對映表的條目，可採取的辦法只有增加頁的尺寸。因此Hugepage便因此而來。也就是打破傳統的小頁面的記憶體管理方式，使用大頁面2m,4m等。如此一來對映條目則明顯減少。如果系統有大量的實體記憶體（大於8G），則物理32位的作業系統還是64位的，都應該使用Hugepage。

那麼如何控制Oracle資料庫對HugePage的利用呢？主要分為以下幾個步驟：

1．需要在/etc/security/limits.conf 中設定memlock值(單位KB)，該值小於記憶體大小。

2． 如果你使用11G及以後的版本，AMM已經預設開啟，但是AMM與Hugepages是不相容的，必須先關閉AMM。

3．編輯/etc/sysctl.conf 設定 vm.nr_hugepages引數的具體值。

4．停止例項並重啟OS系統，並透過以下命令檢查設定是否生效：

# grep HugePages /proc/meminfo

HugePages_Total: 1496

HugePages_Free: 485

HugePages_Rsvd: 446

HugePages_Surp: 0

5．透過以下引數控制資料庫對HugePage的使用方式(11gr2之後)：

use_large_pages = {true/only/false/auto}

預設值是true，如果系統設定Hugepages的話，SGA會優先使用hugepages，有多少用多少。如果設定為false， SGA就不會使用hugepages。如果設定為only 如果hugepages大小不夠的話，資料庫例項是無法啟動的。設定為auto，這個選項會觸發oradism程式重新配置linux核心，以增加hugepages的數量。一般設定為true。

SQL> alter system set use_large_pages=true scope=spfile sid='*';

4.6 Transparent HugePage

透明大頁管理和前面所述的標準大頁管理都是作業系統為了減少頁錶轉換消耗的資源而釋出的新特性，雖然Oracle建議利用大頁機制來提高資料庫的效能，但是Oracle卻同時建議關閉透明大頁管理。這二者的區別在於大頁的分配機制，標準大頁管理是預分配的方式，而透明大頁管理則是動態分配的方式。

對於資料庫來講這種動態的分配方式在系統負載很高的情況下非常有可能導致資料庫出現嚴重的效能問題。這在Oracle官方文件1557478.1當中有詳細的記載。

那麼如何來關閉系統的透明大頁管理呢？只要修改如下引數即可：

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

4.7 vm.min_free_kbytes

該引數是Linux核心當中用來控制保留最小空閒記憶體的數量，Oracle建議調大該值為512M。這樣的設定有利於相對加快記憶體的回收速度，從而降低記憶體吃緊的壓力。

4.8 AIX虛擬記憶體引數

這一項主要是針對AIX的記憶體管理。AIX記憶體管理和Linux的記憶體管理機制不一樣，它採用計算記憶體和非計算記憶體方式來管理記憶體。IBM對Oracle的建議值為以下方案：

minperm%=3

maxperm%=90

maxclient%=90

lru_file_repage=0

lru_poll_interval=10

strict_maxperm=0

strict_maxclient=1

page_steal_method=1

minperm和maxperm控制非計算記憶體中的檔案頁的下限和上限；maxclient控制非計算記憶體中的客戶頁面；lru_file_repage表示分頁替換守護程式將根據其內部重新分頁表來確定選擇何種型別的分頁進行操作。strict_maxperm&strict_maxclient表示無論是否有空閒記憶體，都會嚴格限制檔案頁以及客戶頁的最大佔有比率不得超越限制。page_steal_method表示換頁時的策略，0為全部頁面，1為非計算持久頁面。以上引數放方案表示費計算持久頁面的上限為90%，下限為3%；客戶機頁面上限為90%；採用非嚴格持久頁面上限控制策略；嚴格客戶機頁面上限控制策略。lru_file_repage & page_steal_method配合使用表示LRUD在尋找空閒頁時，只尋找費計算記憶體當中的持久記憶體頁面。

vmm_klock_mode=2

這個引數是是否對核心頁進行加鎖的控制。0則表示不進行加鎖，那麼核心頁有可能被錯誤換出從而導致Page Fault發生；1則表示部分核心頁面加鎖；2則表示對所有核心頁面進行加鎖。在Oracle RAC環境下或者EMC的儲存作為系統的Swap Device的時候，IBM強烈建議將該引數設定為2。

4.9 PowerVM環境下的引數調整

PowerVM環境下，由於其利用Hypervisor實現了很多虛擬化的功能，這些功能大多從靈活性及擴充套件型來考慮，但是如果我們執行的是Oracle Rac的話，那麼還是有很多關鍵點需要注意。

1. cpu folding

虛擬處理器摺疊功能，當系統負載比較低的時候，AIX系統自動休眠一些虛擬處理器，以減少Hypervisor的開銷，提升PowerVM平臺整體效能。但是在某些情況下，當資料庫的負載變化非常快的時候，CPU摺疊或者開啟的速度反而會影響資料庫甚至系統的效能，嚴重導致系統掛起。下面是IBM針對該BUG的一個補丁，主要針對AIX5.3 & 6.1。

4.10 Linux核心引數

以下是Oracle官方針對Linux平臺核心引數設定的一個通用方案：

fs.aio-max-nr = 1048576

fs.file-max = 6815744

kernel.shmall = 2097152

kernel.shmmax = 4294967295

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

net.ipv4.ip_local_port_range = 9000 65500

net.core.rmem_default = 4194304

net.core.rmem_max = 4194304

net.core.wmem_default = 4194304

net.core.wmem_max = 4194304

kernel.shmmax： 是核心引數中最重要的引數之一，用於定義單個共享記憶體段的最大值。設定應該足夠大，能在一個共享記憶體段下容納下整個的SGA ,設定的過低可能會導致需要建立多個共享記憶體段，這樣可能導致系統效能的下降。

至於導致系統下降的主要原因為在例項啟動以及ServerProcess建立的時候，多個小的共享記憶體段可能會導致當時輕微的系統效能的降低(在啟動的時候需要去建立多個虛擬地址段，在程式建立的時候要讓程式對多個段進行“識別”，會有一些影響)，但是其他時候都不會有影響。

64位linux系統：可取的最大值為實體記憶體值-1byte，建議值為多於實體記憶體的一半，一般取值大於SGA_MAX_SIZE即可，可以取實體記憶體-1byte。例如，如果為12G實體記憶體，可取210241024*1024-1=12884901887，SGA肯定會包含在單個共享記憶體段中。

kernel.shmall：  該引數控制可以使用的共享記憶體的總頁數。Linux共享記憶體頁大小為4KB,共享記憶體段的大小都是共享記憶體頁大小的整數倍。一個共享記憶體段的最大大小是16G，那麼需要共享記憶體頁數是16GB/4KB=16777216KB /4KB=4194304（頁），也就是64Bit系統下16GB實體記憶體，設定kernel.shmall = 4194304才符合要求(幾乎是原來設定2097152的兩倍)。這時可以將shmmax引數調整到16G了，同時可以修改SGA_MAX_SIZE和SGA_TARGET為12G（您想設定的SGA最大大小，當然也可以是2G~14G等，還要協調PGA引數及OS等其他記憶體使用，不能設定太滿，比如16G）。

kernel.shmmni： 該引數是共享記憶體段的最大數量。shmmni預設值4096，一般肯定是夠用了。

fs.file-max： 該引數決定了系統中所允許的檔案控制程式碼最大數目，檔案控制程式碼設定代表linux系統中可以開啟的檔案的數量。

fs.aio-max-nr： 此引數限制併發未完成的請求，應該設定避免I/O子系統故障。

kernel.sem： 以kernel.sem = 250 32000 100 128為例：250是引數semmsl的值，表示一個訊號量集合中能夠包含的訊號量最大數目。32000是引數semmns的值，表示系統內可允許的訊號量最大數目。100是引數semopm的值，表示單個semopm()呼叫在一個訊號量集合上可以執行的運算元量。128是引數semmni的值，表示系統訊號量集合總數。

net.ipv4.ip_local_port_range： 表示應用程式可使用的IPv4埠範圍。

net.core.rmem_default： 表示套接字接收緩衝區大小的預設值。

net.core.rmem_max： 表示套接字接收緩衝區大小的最大值。

net.core.wmem_default： 表示套接字傳送緩衝區大小的預設值。

net.core.wmem_max： 表示套接字傳送緩衝區大小的最大值。

5.配置叢集層的關鍵點

5.1 diagwait

在叢集進行驅逐節點時，節點發生重新啟動的場合下，作業系統需要轉儲CrashDump，這個引數就是叢集需要等待作業系統轉儲的時間引數。對於版本 10gR2 和 11gR1，所有平臺上的最佳實踐都是將 CSS diagwait 引數設定為小於等於13。對於11gR2已經不要求對該引數進行設定。

5.2 ORA_CRS_HOME

對於這個變數，Oracle官方給出的建議是：不要設定 ORA_CRS_HOME 環境變數（在所有平臺上）。設定此變數將使各個 Oracle 元件出現問題，而且 CRS 程式完全不需要此變數，因為它們都有包裝指令碼。

5.3 關於組播和多播

Oracle11gR2私網採用的是組播方式通訊，組播地址段為230.0.1.0 或 224.0.0.251網段，為了保障叢集私網通訊的正常及穩定，一方面這個網段的網路配置需要支援組播，另外一方面不要讓主機的任何其他網路配置和這兩個網段衝突。曾經遇到過浪潮的X86伺服器的帶外管理的某個地址也正好利用了這個網段，結果導致了Oracle Rac節點的異常重啟。這種問題一般會顯示為私網通訊報錯，但是正常狀況下只要帶外管理收集日誌工具不啟動的話，那麼是不會發現這個問題的，屬於偶發性問題。所以我們需要特別小心此類問題，不要等到發生時候再去花費大量實踐調查。

6.安裝叢集時的關鍵點

6.1 cluvfy

如果安裝過10g以後的RAC環境，應該對這個工具並不陌生。在安裝Cluster和Database之前通常會執行runcluvfy.sh指令碼來檢查當前系統是否滿足安裝條件。runcluvfy.sh將cluvfy工具的功能在shell中實現，使得使用者在資料庫和CLUSTER安裝之前就可以利用這個工具的功能。這個工具的主要作用就是驗證系統是否滿足安裝的條件，尤其是檢查網路和域名解析，如果網路和域名解析在安裝之前沒有正常的配置，通常直接導致安裝的失敗。主要用法如下所列兩個功能：

# runcluvfy.sh stage -list

# runcluvfy.sh comp -list

6.2 升級順序問題

安裝完叢集軟體也好，RDBMS也好，打補丁是必然要做的事情。但是究竟是等安裝完所有的元件之後再統一打補丁呢還是說將每一個元件都按照安裝&補丁升級的順序依次做完呢？Oracle給的建議是：在執行 11gR2 之前的安裝時，建議在執行任何 RDBMS 或 ASM 主目錄安裝前應用補丁程式將 Clusterware 主目錄升級到所需的級別。

6.3 root.sh & rootupgrade.sh

安裝或者升級期間，最後的步驟就是要執行以上的指令碼。當然按照安裝文件的要求必須是用超級使用者root來執行。但是可能有些人認為只要利用root的許可權去執行就可以了，很想當然的用了su root -c或者是sudo等去執行，結果導致執行失敗，日誌報錯crsd.bin crashes。因為指令碼的執行不僅僅是要用超級使用者root的許可權，還要利用root使用者的環境配置等。

6.4 /etc/init.cssd

11.2 之前再AIX系統上，OPROCD 預設不在 AIX 全域性執行佇列執行 ，這可能會導致 OPROCD 錯誤地重啟節點。(Bug 13623902)。此問題的更正操作是修改 /etc/init.cssd 檔案，加入如下引數：

RT_GRQ=ON

export RT_GRQ

但是AIX6.1 TL4以上的版本就自帶了對該問題的修正程式。所以當我們採用低版本的AIX作業系統時，需要特別注意這個配置文 件。

7.資料庫層的關鍵最佳化項

7.1 pre_page_sga & lock_sga

這兩個引數都是對資料庫SGA的保護引數。lock_sga是控制SGA不被換出到交換空間上，會保障資料庫記憶體頁一致留在實體記憶體上，從而提高效能。而pre_page_sga是保障資料庫例項啟動時就把所有SGA讀到實體記憶體上，雖然啟動會慢，但是後續效能會好。

但是pre_page_sga同時還有一個作用。pre_page_sga 為true時, 每個程式建立的時候都會去touch一遍sga裡的page, 當sga越大的時候,這個touch所消耗的時間就越長，特別是在斷開式連線,短連線的Application上, 將會消耗很多資源。當客戶端連線感覺到慢的時候，這個引數就一定要設定成false了。Oracle的建議也是false。

SQL> alter system set pre_page_sga=false scope=spfile sid='';

SQL> alter system set lock_sag=true scope=spfile sid='';

7.2 關於重做日誌

首先、接觸過資料庫的人相信對這個概念都不陌生。資料庫在做SQL更新的時候，首先要將事務執行過程記入重做日誌當中，然後才會把日誌刷入磁碟，將資料更新持久化。一條資料提交之後成功的標準時日誌落到磁碟，而不是真正的資料落盤。因此日誌的配置（大小、數量）直接決定著資料庫讀寫的效能，如果日誌大小非常大，那麼會造成歸檔切換時間非常長，一旦這時候發生了不可恢復的DB災難，那麼透過備份恢復的資料流失量或者說RPO就會較大。日誌大小非常小的話，勢必會造成日誌頻繁切換，AWR裡面有大量的日誌切換事件，這樣對資料庫的效能會有較大影響。因此根據效能測試的AWR報告中日誌切換的等待事件、和切換頻度來決定其資料量和大小是否需要調整。一般的OLTP建議（10組、500M）。

接著、我們還需要考慮與其相關的引數設定。

1. _use_adaptive_log_file_sync

它直接決定了日誌落盤的方式，對於日誌緩衝區的資料落盤的方式，11g增加一種新的方式就是polling的方式，傳統方式是post/wait方式。oracle底層自動判斷何時用何種方法來完成lgwr程式的寫任務。對於post/wait方式來講，客戶端做了commit之後，需要等待事件完成。oracle一旦完成會通知使用者程式，使用者程式立刻感知。但是這一通知post，會耗費大量CPU資源。polling是oracle前臺程式啟動檢查任務，自動檢查後臺lgwr寫入情況，耗費CPU資源比較少，但是使用者程式並不一定能立刻感知。

所以兩種方法各有千秋。但是關鍵是後臺實現兩種方法切換的時候要耗費系統效能，尤其在繁忙的時候頻繁切換的話反而會導致資料庫效能下降。awr出現大量log file sync，Bug 13707904。

SQL> alter system set "_use_adaptive_log_file_sync"=false scope=spfile sid='*';

2. archive_lag_target 它決定了我們是否開啟日誌強制切換功能，為了減少故障時資料損失，可以設定archive_lag_target引數，強制進行日誌切換。這個引數的預設值是0，即為不啟用該引數。建議設定值為1800。 SQL> alter system set archive_lag_target=1800 scope=spfile sid='*';

7.3 AMM

首先、ORACLE通用的兩種記憶體管理方式AMM&ASMM，從Oracle 11g開始，ORACLE預設使用AMM(自動記憶體管理)，即讓資料庫完全管理SGA、PGA的大小，而對於管理員只需要設定一個總的大小（memory_target），資料庫會動態的調整SGA、PGA的大小以及其中包含的各個元件大小，如Database buffer cache、Shared pool等。這個特性設計的初衷是好的，它希望避免不正確的SGA和PGA設定導致的記憶體使用不平衡的效能問題。

但是在實際應用過程中，這個特性是不是一定非常出色呢？AMM中在資料庫啟動是會有一個固定比例來分配SGA/PGA 大小：

sga_target =memory_target 60%

pga_aggregate_target=memory_target *40%。

但是在併發較高，資料庫非常繁忙的場合下，自動記憶體調整的速度很可能趕不上大量會話對記憶體的請求的速度。另外當PGA隨著會話不斷增加而需求量猛增的情況下，它會首先搶佔SGA，導致資料庫效能故障。在高併發的資料庫場景中並不建議使用AMM。採用10g更為成熟的自動共享記憶體管理(ASMM)和自動PGA管理。手動調整記憶體引數，具體可以參照以下：

1. 關閉記憶體自動管理

SQL> alter system set memory_target=0 scope=spfile sid='';

SQL> alter system set memory_max_target=0 scope=spfile sid='*';

2. 設定SGA為固定值，可以根據效能測試中的AWR報告中的建議

SQL> alter system set sga_max_size=XG scope=spfile sid='';

SQL> alter system set sga_target=XG scope=spfile sid='';

3. 設定PGA等引數

SQL> alter system set pga_aggregate_target=XG scope=spfile sid='';

SQL> alter system set large_pool_size=256M scope=spfile sid='';

pga_aggregate_target=XG

large_pool_size=256M

另外很重要的一個引數，“_shared_pool_reserved_pct”，如果這個引數設定小了，很可能導致ORA04031，所以需要一個合理的設定。

SQL> alter system set“_shared_pool_reserved_pct”=10 scope=spfile sid='*';

7.4 SQL解析

1. 繫結變數窺測

在Oracle中每條SQL語在執行之前都需要經過解析，這裡面又分為軟解析和硬解析。在Oracle中存在兩種型別的SQL語句，一類為 DDL語句(資料定義語言)，他們是從來不會共享使用的，也就是每次執行都需要進行硬解析。還有一類就是DML語句(資料操縱語言)，他們會根據情況選擇要麼進行硬解析，要麼進行軟解析。一般我們希望我們的AWR報告中硬解析偏少，而軟解析偏多。因為硬解析的代價會非常高。為了減少帶繫結變數的sql的解析時間，oracle 9i引入的繫結變數窺測的功能。也就是在同一個SQL的變數被賦於不同值時採用同一個遊標，這樣雖然節省了sql的解析時間。大家有沒有透過功能的開啟或者關閉實際觀察過AWR中的軟硬解析數目的實際狀況呢？其實對於繫結變數窺測這個特性以及後來的自適應遊標等特性，都是oracle為了找到最優執行計劃而啟用的一些新特性，但是在實際應用過程中，對於不同量級不同特性的業務場景也曾經因此出現了很多bug( Bug 20370037，Bug 13456573，Bug 20082921）等。

根據自己的業務系統特點，做大量的效能測試和業務測試，根據引數的關閉開啟對比awr報告當中顯示出的軟硬解析比率以及執行計劃資料決定是否開啟或者關係相應功能特性。如下引數：

"_optim_peek_user_binds"

"_optimizer_adaptive_cursor_sharing"

"_optimizer_extended_cursor_sharing"

"_optimizer_extended_cursor_sharing_rel"

"_optimizer_use_feedback"

2. open_cursors & session_cached_cursors

與之相關的幾個引數：open_cursors、session_cached_cursors 這兩個引數決定著應用會話可以控制開啟以及快取的遊標數量，如果數量不足，就會引起SQL解析的效能問題。這兩個引數要根據v$resource_limit檢視中的值的情況進行調整，避免資源設定不合理導致的效能問題。

SQL> alter system set open_cusors=N scope=spfile sid='';

SQL> alter system set session_cached_cursors=M scope=spfile sid='';

3. _b_tree_bitmap_plans

與執行解析執行計劃相關的幾個引數，_b_tree_bitmap_plans、有時將B-Tree索引進行BITMAP轉換來進行SQL執行，往往會生成極其惡劣的執行計劃，導致CPU100%。Select Fails With ORA-600 [20022] (文件 ID 1202646.1) 建議可以關掉。

SQL> alter system set "_b_tree_bitmap_plans"=false scope=spfile sid='*';

7.5 process & sessions

process 限制了能夠連線到SGA的作業系統程式數，這個總數必須足夠大，從而能夠適用於後臺程式與所有的專用伺服器程式，此外共享伺服器程式與排程程式的數目也被計算在內。session 是通訊雙方從開始通訊到通訊結束期間的一個上下文(context)。這個上下文是一段位於伺服器端的記憶體：記錄了本次連線的客戶端機器、透過哪個應用程式、哪個使用者在登入等資訊。

Oracle的連線數sessions與其引數檔案中的程式數process相關，它們的關係如下： sessions=(1.1process+5)

這兩個引數的設定是需要根據應用的具體併發需求來決定具體的設定方案。

SQL> alter system set process=N scope=spfile sid='';

SQL> alter system set sessions=1.1N+5 scope=spfile sid='';

7.6 DRM

資料庫節點之間的競爭有很多，包括鎖（各種粒度鎖）的競爭以及資料的傳輸等。完全避免競爭那就失去了RAC的意義了，RAC本身就是希望能在兩個節點並行執行任務。如果特別極致的並行一定引起嚴重的效能問題，如果完全禁止，既無法做到又失去了叢集本來的意義。所以我們只能在一定程度上去平衡：

首先、關於DRM，oracle的DRM特性從理論上來看，它是為了避免節點間的資料量傳輸，避免節點間的鎖等待事件頻繁發生。DRM的極致是做到請求節點和Master節點統一化。但是實踐中，這個特性引起了很多的BUG、反而導致了節點間的競爭出現了效能故障。Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。所以建議關閉。

SQL> alter system set "_gc_policy_time"=0 scope=spfile sid='*';

SQL> alter system set "_gc_undo_affinity"=false scope=spfile sid='*';

7.7 parallel_force_local

關於引數“parallel_force_local”，ORACLE RAC為了實現多節點並行處理是花費了很大代價的，假設一個叢集當中有三個節點，對於某一個資料塊兒讀寫，有一個Master、有一個請求者、有一個擁有者，請求者向Master請求資料塊兒的最新版本，Master把請求轉發給擁有者，擁有者按照請求資訊把資料塊兒傳送給申請者，然後加鎖進行讀寫。這一過程是需要有大量的資料傳輸和競爭存在的，一旦這個事情成為多數，那麼勢必造成節點間的通訊負載過大，造成大量的鎖等待時間，嚴重影響資料庫整體效能。尤其是在做跨資料中心高可用的場合下。因此我們只要做到業務級別的併發處理，而不要追求一個SQL級別的絕對併發。物極必反的道理就在於此。因此把引數開啟，使得程式級別併發實現本地化處理，不要跨節點處理。在官方文件 ID 1536272.1當中，必須最佳化的引數就包括這個。

SQL> alter system set parallel_force_local=true scope=spfile sid='*';

7.8 關於自動任務

Oracle 11g 資料庫有三個預定義自動維護任務：

1. Automatic Optimizer Statistics Collection（自動最佳化器統計資訊收集）： 收集資料庫中所有無統計資訊或僅有過時統計資訊的 Schema 物件的 Optimizer（最佳化器）統計資訊。QL query optimizer（SQL 查詢最佳化器）使用此任務收集的統計資訊提高 SQL 執行的效能。

2. Automatic Segment Advisor（自動段指導）： 識別有可用回收空間的段，並提出如何消除這些段中的碎片的建議。也可以手動執行 Segment Advisor 獲取更多最新建議。

3. Automatic SQL Tuning Advisor（自動 SQL 最佳化指導）：檢查高負載 SQL 語句的效能，並提出如何最佳化這些語句的建議。您可以配置此指導，自動應用建議的SQL profile。

關於統計資訊收集，資料庫是有其自己的預設啟動時間，11g是在22:00-2:00之間，假設這個時間跟我們的跑批時間有衝突的話，我們可以修改器具體執行時間。但是這個任務必須保留。關於其他的兩個最佳化指導，其實要看我們實際工作中用到的機率是否很高，是否有價值留著給我們提供一些最佳化的理論指導。如果感覺意義不大，可以不用。

7.9 安全方面的配置最佳化

首先、是資料庫要不要保留審計？如何保留？

假設不開啟審計，那麼將來出來安全問題，我們無法尋找線索；假設開啟，那麼很可能因為使得審計日誌佔用大量的儲存空間，甚至影響資料庫IO效能。一般情況下還是需要對一些基本登入行為的審計，但是我們可以把日誌位置修改制定到作業系統層面減少資料庫層因此的效能壓力，而且應該定期轉儲，減少碎檔案太多而把檔案系統i節點用光的極端情況。可以透過對引數"audit_trail"以及adump引數的調整來實現此項最佳化。

接著、alert日誌和trace檔案的控制引數。

max_dump_file_size，它決定了這些檔案的大小限制，預設情況下是unlimited，如果生成了很大的檔案，就會達到OS對檔案上限的要求，導致寫入失敗。

SQL> alter system set max_dump_file_size='100m' scope=spfile sid='*';

7.10 parallel_min_servers

這個引數決定了例項可以並行執行的程式的最大數目。設定太小查詢程式沒有並行執行能力。如果設定太大，那麼可能會導致記憶體資源緊張，從而影響系統整體效能。確保監控活動並行伺服器程式的數量並計算要應用於 parallel_min_servers 的平均值。可透過以下操作完成：

SQL> select * from v$pq_syssstat;

檢視列值 "Servers Highwater"；

根據硬體情況最佳化 parallel_max_servers的值。最開始可以使用 (2 * ( 2 個執行緒 ) (CPU_COUNT)) = 4 x CPU 計算，然後使用測試資料對更高的值重複測試。一般OLTP系統需限制其不超過128（ORACLE的預設演算法有BUG，在cpu核數超過128，預設並行引數設定過高時，容易被觸發，會導數oracle無法啟動。另外，如果這個引數太高，並行的程式開的太大了，會導數資料庫無法承受併發壓力）。

SQL> alter system set parallel_max_servers=128 scope=spfile sid='';

7.11 fast_start_mttr_target & fast_start_parallel_rollback

fast_start_mttr_target={0-3600} 一旦設定具體值，那麼崩潰恢復將在此要求的時間範圍內完成。fast_start_parallel_rollback={high/low/false}，high啟動4倍於CPU數目的並行恢復程式，low啟動2倍於CPU數目的並行恢復程式，false關閉並行恢復程式。這兩個引數都是用來加速在故障場合下的奔潰恢復，其根本的機制就是要透過主動觸發checkpoint來縮短最近依次checkpoint和聯機重做日誌之間的距離。但是這個無疑會帶來一定的效能風險。所以這兩個值的設定需要根據具體業務情況來設定，同時要進行壓力測試，不要因為激進的策略帶來效能問題。

與此相關還有一個引數log_checkpoints_to_alert，預設是關閉狀態。開啟這個引數會在trace檔案當中記錄詳細的檢查點發生資訊，對於資料庫診斷來講是一個必不可少的功能。因此建議開啟。

SQL> alter system set fast_start_mttr_target=120 scope=spfile sid='';

SQL> alter system set fast_start_parallel_rollback=low scope=spfile sid='';

SQL> alter system set log_checkpoints_to_alert=true scope=spfile sid='*';

7.12 listener.ora

對於11.2之前的 listener， 首先得保證IPC項存在，且此項列在所有RAC listener的地址列表的第一個。否則，可能會對 VIP 在公網介面出現故障時進行故障轉移所用的時長產生不利影響。

LISTENER_n1 =

(DEION_LIST =

(DEION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)))

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = n1vip)(PORT = 1521)(IP = FIRST)))

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.8.21.121)(PORT = 1521)(IP = FIRST)))

)

)

假設把TCP列到第一項，那麼監聽需要等待TCP timeout，而TCP timeout是受作業系統相關引數控制，並且timeout時間較長，那麼就有可能引起故障轉移並不能非常及時的問題。

7.13 sqlnet.ora

資料庫連線的客戶端異常斷開後，其佔有的相應並沒有被釋放，如從v$session檢視中依舊可以看到對應的session處於inactive，且對應的伺服器程式也沒有釋放，導致資源長時間地被佔用，對於這種情形開該如何處理呢？sqlnet.expire_time對於這個問題我們提供瞭解決方案，專門用於清理那些異常斷開的情形，如網路異常中斷，客戶端異常掉電，異常重啟等。可以在sqlnet.ora檔案當中設定引數sqlnet.expire_time=5。

7.14 回收站

從ORACLE 10g開始，引入了一個叫回收站(Recycle Bin)的概念。它的全稱叫Tablespace Recycle Bin。回收站實際是一個邏輯容器。它以表空間中現有已經分配的空間為基礎，而不是從表空間上物理劃出一個固定區域用作回收站。這意味著回收站和表空間中的物件共用儲存區域、系統沒有給回收站預留空間。因此，當表被DROP後，如果可用空間充足，並且沒有對回收站進行清理，那麼被DROP掉的物件會一直存在回收站中，但是如果可用空間緊張的情況下，資料庫會根據先進先出的順序覆蓋Recycle Bin中的物件。回收站這個特性主要的好處就是在誤刪除一個表時有一個恢復機制，不必透過資料庫還原來實現，避免大量的人工誤操作。

但是對於業務場景存在大量的drop物件但是沒有purge操作的場合下，那麼回收站的開啟勢必會帶來資料庫系統表空間大量佔用以及資料庫效能降低的風險，尤其是在金融業務批次的業務環境。所以就實際的生產環境而言，這個功能的用途並非像理論上想象的那麼有意義。基於風險的考慮，還是建議把該功能關閉掉。

SQL> show parameter recyclebin

SQL> salter system set recyclebin=off cope=spfile sid='*';

SQL> spurge recyclebin

SQL> spurge dba_recyclebin

7.15 結果快取

結果快取是11g之後增加的特性。分為server和client兩種型別，server是指在SGA的Share Pool當中保留一塊兒記憶體空間用來儲存SQL或者PLSQL的查詢結果，供其他程式來共享使用。Client是指在OCI連線程式當中的記憶體當中儲存SQL查詢結果，供程式內所有session來使用。本意都是要提高查詢效率。但是在實際使用的過程當中，它曾導致了很多問題，例如RC Latch、reliable message等資源等待問題（ID 1951729.1 - Bug 19557279，12c已經修復了這個問題）。

因此，為了避免系統遇到以上情況下發生更嚴重的效能問題，建議將結果快取關閉掉。

SQL> alter system set "_optimizer_ads_use_result_cache"=false scope=spfile sid='*';

SQL> alter system set "_result_cache_max_size"=900 scope=spfile sid='*';

7.16 undo

在事務提交或回滾之後，因為flashback或一致讀的需求，還需要將對應的undo資料儲存在undo表空間中一段時間，這個時間就是由undo_retention來設定的。根據undo_retention可以繼續將undo的inactive狀態劃分為EXPIRED，UNEXPIRED兩類，undo中超過undo_retention時間之外的inactive undo回滾區稱為expired, 還處於unod_retention時間之內的inactive undo回滾區稱為unexpired。undo_retention不是說必須達到這個時間後才能被覆蓋，而只是一個期望值，比如undo表空間檔案設定為非自動擴充套件，當一個大事務需要將undo中未使用的區域及過期的undo區域都使用完了，而undo空間不能自動擴充套件，這時保證事務順利執行優先順序比較高，undo中沒有過期的回滾區也會被覆蓋使用(從其中使用時間越早的開始)，也就是說retention設定的時間段內的undo非過期資料是沒有保證的。

10g之後引入一個新的引數“_undo_autotune”，這個參數列示Oracle對undo自動最佳化，就是在undo表空間非自動增長的情況下，Oracle會根據undo表空間的大小來調整undo RETENTION的大小，自動調整retention就是最大限度的利用當前undo表空間的可用空間，儘可能的保留最多的undo資料，以最大化的減少類似ORA-01555 等錯誤發生。

_undo_autotune此引數預設開啟，有利於時間長的查詢，但是對於典型的OLTP系統來說不太適用。尤其在系統繁忙的時候，經常會出現undo不夠用的情況。回收undo，簡單resize會報錯。因此建議關閉次引數並設定合理的retetion時間。

SQL> alter system set "_undo_autotune"=false scope=spfile sid='*';

SQL> alter system set undo_retention=900 scope=spfile sid='*';

（1.OLTP系統:15分鐘 / 2.混合:1小時 / 3.DSS系統:3小時）

7.17 執行計劃中的排序

正常情況下，我們認為SQL查詢計劃如果利用index排序索引的話，從效能上看會是比較優的選擇。但是往往在實際生產過程中，很多中情況如果走排序的話不一定會獲得最優的查詢計劃，有的時候反而會更糟糕。因此Oracle用一個引數“_sort_elimination_cost_ratio”來控制是否一定走排序尋找最優執行計劃。

當“不排序的成本/排序的成本”這個比值小於“_sort_elimination_cost_ratio”引數值時，Oracle會選擇不走排序去獲取執行計劃。“_sort_elimination_cost_ratio”的預設值為0，也就是說Oracle預設任何情況下都選擇排序獲取執行計劃，即使排序的成本是無窮大。

實踐證明預設的選擇往往是不對的，會將查詢引入到錯誤的執行計劃。因此建議將引數值設定為5。 SQL> alter system set "_sort_elimination_cost_ratio"=5 scope=spfile sid='*';

7.18 控制檔案

關於控制檔案的記錄儲存時間控制引數control_file_record_keep_time，預設值為7，也就是說控制檔案只保留7天記錄，超過7天的備份記錄會被認為是無效的。這個值的設定需要跟兩個地方關聯起來：

1. 集中備份軟體設定的備份策略中關於過期時間的定義。

2. Rman的引數retention policy。

例如我們的備份策略對某系統備份集過期的時間定義為30天，那麼我們就分別對控制檔案和RMAN兩個地方的引數做如下設定（RMAN保留時間設定太長會導致list backup命令執行多幾分鐘時間）：

SQL> alter system set control_file_record_keep_time=30 scope=spfile sid='*';

RMAN> configure retention policy to recovery window of 30 days;

7.19 job_queue_processes

如果同一時間內執行的Job數很多，過小的引數值導致job不得不進行等待。而過大的引數值則消耗更多的系統資源。應該設定一個比較合理的數值，以避免此類事情發生。

Oracle預設值為1000，這個值對於一般的OLTP系統來講比較大，所以需要進行合理的修改。

7.20 rman

1. 為了提高rman備份的效率，假設磁帶備份裝置支援非同步I/O，建議將這個引數設定為true，以啟動該設定。建立一個large pool，使得RMAN中獲得良好的效能。 SQL> alter system set backup_tape_io_slaves=true scope=spfile sid='*';

2. 關於ADG備庫的RMAN引數設定， RMAN> configure archivelog deletion policy to applied on standby; 這個引數設定是保護沒有被應用的日誌不被刪除，在11g的高版本實際上已經不需要再設定了，但是低版本的就需要注意了。

7.21 其他

1．表空間的資料檔案是否採用了自動擴充套件的方式？

2．表空間的資料檔案是否都用了ASM的方式？

3．ASM的冗餘方式是否一致？

4．應用使用者的預設密碼策略是不是已經取消了180天的限制等等。

5．資料庫的監控指標是否覆蓋了（叢集、服務、監聽、ASM、表空間、效能等所有應該涵蓋的方面）？

6．OS層面的監控是否已經啟用？尤其是私網之間的通訊、CPU、記憶體的監控等？是Nmon還是osw，他們的日誌是定期迴圈還是持續不斷增長等等？

7．資料庫巡檢的體系是否完善？日巡檢月度巡檢的內容是否經過精心設計？是否已經實現了自動化等等？強烈建議日巡檢工作實現指令碼自動化，任務定時執行，日誌統一整合到共享檔案系統上，有條件的可以進行整合入庫，按照自己的巡檢機制和體系實現按需調入調出。

8.總結及展望

本文是基於資料建設的規劃、實施以及配置最佳化等階段對大量文獻的總結提煉以及專案的實踐出發，對資料庫建設過程中各個層面應該注意的事項進行了一個總結。希望對正在從事此項工作的同業以及將來要從事這類專案的同業給予參考，也希望更多人在此基礎之上能夠將其完善和最佳化分享給大家。

【主要參考文獻】

[1]. RAC 和 Oracle Clusterware 最佳實踐和初學者指南（平臺無關部分） (文件 ID 1526083.1)

[2]. RAC and Oracle Clusterware Best Practices and Starter Kit (Linux) (文件 ID 811306.1)

[3]. RAC and Oracle Clusterware Best Practices and Starter Kit (AIX) (文件 ID 811293.1)

[4]. Top 11 Things to do NOW to Stabilize your RAC Cluster Environment (文件 ID 1344678.1)

[5]. IBM System p Advanced POWER Virtualization Best Practices

[6]. 最佳實踐：主動避免資料庫和查詢相關的效能問題 (文件 ID 1549184.1)

[7]. 11gR2 Clusterware and Grid Home - What You Need to Know (文件 ID 1053147.1)

[8]. Oracle Databases on VMware Best Practices Guide

[9]. Deploying Oracle Database 11g R2 on Red Hat Enterprise Linux 6 Best Practices

[10].10g 和 11gR1 ASM 技術最佳實踐 (文件 ID 1602417.1)

[11]. Oracle® Database High Availability Best Practices 11g Release 1 (11.1)

[12]. Oracle® Database High Availability Best Practices 11g Release 2 (11.2)

[13]. Oracle on AIX – Configuration & Tuning. R Ballough (ppt)

[14]. Oracle Database 11g R2 Oracle Database 11g R2 RAC on IBM AIX Tips and Considerations

[15]. Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip

此文章是轉載於搜狐的文章