OracleRAC建設(shè)過程中各個層面關(guān)鍵點和優(yōu)化項總結(jié)

原題：Oracle RAC建設(shè)過程中必須要知和要做的事情   作者：趙海，某城商行系統(tǒng)架構(gòu)師，專注并擅長銀行數(shù)據(jù)中心解決方案規(guī)劃及設(shè)計。

數(shù)據(jù)庫建設(shè)過程中缺少可以遵循的實踐標準，知識點和經(jīng)驗點散落四處難以快速形成邏輯性強的參照標準，面對項目令人無從下手。本文是基于數(shù)據(jù)建設(shè)的規(guī)劃、實施以及配置優(yōu)化等階段對大量文獻的總結(jié)提煉，以及從項目的實踐出發(fā)，對數(shù)據(jù)庫建設(shè)過程中各個層面應(yīng)該注意的事項進行的總結(jié)。優(yōu)質(zhì)長文，建議先收藏后看。

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),清豐企業(yè)網(wǎng)站建設(shè),清豐品牌網(wǎng)站建設(shè),網(wǎng)站定制,清豐網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,清豐網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

1.背景描述

數(shù)據(jù)庫建設(shè)是每一個企業(yè)數(shù)據(jù)中心建設(shè)過程中非常重要的一個環(huán)節(jié)，直接關(guān)系到業(yè)務(wù)連續(xù)性和穩(wěn)定性。但是我們在數(shù)據(jù)庫建設(shè)過程當中卻很少有可以遵循的實踐標準。當我們面對整個建設(shè)項目的規(guī)劃設(shè)計和配置優(yōu)化的時候，又覺得無從下手。散落在官方網(wǎng)站上的一些知識點和經(jīng)驗點無法讓我們快速形成一個具有很強邏輯性的參照標準。本文希望通過以下篇幅的總結(jié)和分析，從各個層面給予實踐標準，為日后從事數(shù)據(jù)庫建設(shè)的項目提供一個參考思路。

2.存儲規(guī)劃設(shè)計的關(guān)鍵點 2.1 OCR/VOTE磁盤的合理規(guī)劃事項

什么是OCR/VOTE磁盤，它在集群中是什么樣的角色呢？

ORACLE RAC ASM管理模式下，磁盤組通常有三個（+DATA，+FRA，+OCR），在OCR磁盤組當中所有的磁盤中存儲的數(shù)據(jù)包括兩部分，一部分是Vote File，另外一部分就是OCR（Oracle Cluster Registry）。Vote File是用來記錄集群節(jié)點的磁盤心跳信息，而OCR是保存集群配置信息的數(shù)據(jù)。Vote File，以整個文件的方式存儲在OCR磁盤上，不做任何條帶。下圖是其信息記錄的一個說明：

以上是一個三節(jié)點的ORACLE RAC集群的Vote FIle的一個示意矩陣，每一行是一個節(jié)點的寫入的信息，例如第一行，Instance1分別把其對集群中的三個成員（1、2、3）進行私網(wǎng)檢測的結(jié)果寫入到仲裁文件當中，Instance2、Instance3同樣把其檢測結(jié)果寫入仲裁文件，最終組成了三個節(jié)點的仲裁矩陣。當私網(wǎng)發(fā)生故障而從網(wǎng)絡(luò)上導(dǎo)致集群分割為幾個孤島子集的時候，集群是通過這個文件的信息來判斷最后存活的節(jié)點。具體算法有兩個非常重要的規(guī)則：

1. 保障隔離后的集群子集中節(jié)點數(shù)目最多的子集存活。

2. 當隔離后的集群子集獲得的仲裁票數(shù)相等時，保障實例號小者存活。

對于Vote File本身的數(shù)目來講，Oracle又有一個非常重要的規(guī)則：集群節(jié)點獲得的Vote File數(shù)目小于N/2+1時，節(jié)點就會被集群驅(qū)逐出集群，N是Vote File的總數(shù)目。也就是說集群中所有節(jié)點獲得的Vote File數(shù)目必須要大于等于N/2+1。

根據(jù)以上結(jié)果來看，對于VOTE磁盤組的規(guī)劃，首先偶數(shù)個仲裁磁盤必然會造成一個浪費。那么我們就沒有必要選擇偶數(shù)仲裁磁盤。然后我們再考慮磁盤組磁盤的容錯能力，為了保障我們至少有1份磁盤容錯能力，我們的仲裁磁盤至少是3塊兒。也就是說對于OCR磁盤組的規(guī)劃來講，至少保障其內(nèi)有三個容錯組，每一個容錯組里面一塊兒仲裁磁盤。

對于OCR來講，它屬于集群的資源注冊信息，是集群運行的前提條件。所以一定要保障它的高可用性。由于它屬于配置數(shù)據(jù)，那么一定會遵循ORACLE ASM的磁盤冗余策略（External、Normal、High）。也就是說OCR在OCR磁盤組里面可以擁有1份、2份、3份鏡像。每份鏡像的數(shù)據(jù)條帶會落在一個獨立的容錯組里。

綜上所述，對于OCR磁盤組的規(guī)劃，為了保障仲裁盤的至少一份的容錯能力以及OCR數(shù)據(jù)的高冗余策略，我們應(yīng)該至少將磁盤組內(nèi)規(guī)劃為3個磁盤，每一個磁盤落在一個獨立的容錯組。磁盤大小建議為1GB以上（雖然OCR Device = 300M左右）。

2.2 存儲外部冗余架構(gòu)設(shè)計

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

2.3 NFS架構(gòu)的存儲配置參數(shù)

Orace RAC的ASM磁盤可以是網(wǎng)絡(luò)存儲架構(gòu)實現(xiàn)的Lun，當然我們也可以利用文件系統(tǒng)或者裸盤作為數(shù)據(jù)庫的存儲資源。但是在掛載NFS卷的時候，有若干參數(shù)是值得我們注意的。

1）Hard/soft：當應(yīng)用進程發(fā)送一個請求，Hard情況下，客戶端遇到錯誤不會立即通知應(yīng)用，而是在后臺進行重試直到正常，這會導(dǎo)致應(yīng)用進程的阻塞；Soft情況下，客戶端會立刻通知應(yīng)用導(dǎo)致應(yīng)用掛起。從這個意義上來講，Soft對應(yīng)用的響應(yīng)速度會比Hard好，但是如果網(wǎng)絡(luò)不穩(wěn)，那么Soft有可能導(dǎo)致應(yīng)用數(shù)據(jù)被損壞。這也是Oracle建議將這個參數(shù)設(shè)置為Hard的理由。

2）Rsize/Wsize:客戶端從服務(wù)器端讀寫文件的最大數(shù)目（byte）/每次請求。如果該參數(shù)不做設(shè)置的話，那么它是通過客戶端和服務(wù)器端的協(xié)商完成的。一般建議設(shè)置為固定的32768。

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

4）Intr/nointr: 是否允許接受文件操作的中斷信號，一般而言設(shè)置為nointr。

5）Noac/ac: ac情況下，客戶端會緩存文件屬性信息，從而提高客戶端的讀性能。Noac情況下，客戶端不會緩存文件屬性信息，任何情況下的讀都是NFS文件系統(tǒng)上文件的實時版本信息。Ac情況下，客戶端會定期掃描Server端的文件實時信息，其他時候都是讀取自己緩存的信息。NFS卷作為數(shù)據(jù)庫的存儲磁盤，只需要實時反映文件的真實版本信息即可，不需要客戶端再去做緩存，數(shù)據(jù)庫有自己的緩存機制。因此一般情況下Oracle建議將這個參數(shù)設(shè)置為Noac。

當然這些參數(shù)，根據(jù)不同的操作系統(tǒng)特點是會有一些差異。表2.3是摘自O(shè)racle官方發(fā)布的NFS存儲最佳實踐參數(shù)表當中的一部分，可以提供通用參考。

2.4 ASM磁盤組規(guī)劃

（1）磁盤組相關(guān)

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

（2）磁盤分配單元及文件條帶

AU是ASM Disk Group磁盤空間分配單元。Strip實際上是文件層面的條帶，準確說法應(yīng)該是文件的擴展塊兒。對于文件的擴展塊兒來講就是文件切割的單元。它有兩種模式（coarse & fine）。對于coarse模式來講，擴展塊兒大小等于AU大小，對應(yīng)的參數(shù)固定不變（_asm_stripesize=AU，_asm_stripewidth=1）。對于fine模式來講，擴展塊兒大小是可以進行調(diào)整，根據(jù)我們的業(yè)務(wù)需求進行適當調(diào)整。例如設(shè)置為256K，那么原來1M的文件寫在一個磁盤中的AU中，那么現(xiàn)在可以并行寫入到賜個磁盤的4個AU當中。充分發(fā)揮了小IO的并行讀寫性能。但是對于某些大IO的數(shù)據(jù)庫業(yè)務(wù)，那么AU可以適當調(diào)整到4M，同時啟用操作系統(tǒng)的大頁讀寫參數(shù)。文件擴展塊兒可以保持corse模式。對于一般的OLTP業(yè)務(wù)來講，數(shù)據(jù)文件、歸檔文件一般設(shè)置為corse；而redo日志、控制文件、flashback日志設(shè)置為fine。對于11g之后的oracle，這些參數(shù)基本不需要我們?nèi)ブ鲃诱{(diào)整，除非確實有性能問題與之相關(guān)。

2.5 ASM內(nèi)存管理參數(shù)

（1）內(nèi)存參數(shù)相關(guān)

? db_cache_size: 緩沖區(qū)，存放metadata塊兒的buffer cache，建議值為64M。

? shared_pool: 管理ASM實例所需要的內(nèi)存池，建議值為128M。

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

（2）其他參數(shù)相關(guān)

在11g當中，如果多個數(shù)據(jù)庫共享ASM實例的話，那么建議按照以下規(guī)則計算process的數(shù)目設(shè)置。

ASM processes = 25 + （10 + max（可能的并發(fā)數(shù)據(jù)文件變化））* 數(shù)據(jù)庫的數(shù)目。當然這個數(shù)目需要一個經(jīng)驗的評估，需要根據(jù)集群環(huán)境數(shù)據(jù)庫的情況以及業(yè)務(wù)IO的判斷來估算。

2.6 異步IO配置

一般來講數(shù)據(jù)庫應(yīng)用都是要啟用異步IO來提高數(shù)據(jù)庫的IO性能。同時需要打開操作系統(tǒng)的異步IO參數(shù)和數(shù)據(jù)庫的異步IO參數(shù)。以Linux為例，在操作系統(tǒng)層面需要設(shè)置參數(shù) aio-max-nr=1048576（11g 中設(shè)置為 4194304），表示同時可以擁有的異步IO請求數(shù)目。然后在Oracle數(shù)據(jù)庫層面設(shè)置以下兩個參數(shù)：filesystemio_option=setall；disk_asynch_io=true。對于AIX來說，需要設(shè)置以下三個參數(shù)（aix_maxservers, aix_minservers,aio_maxreqs）對于OLTP業(yè)務(wù)來講，IBM官方的建議值為（800,200，16384）。

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

2.7 ASMLib & Udev

對于Linux平臺而言，Oracle RAC的ASM磁盤管理有三種方式（ASMlib、DM、udev），我們首選的方式是ASMlib，對于 RHEL6（從6.4開始），內(nèi)核驅(qū)動軟件包'kmod-oracleasm'已經(jīng)在 Redhat 平臺上啟動，并且可以通過RedHat Network (RHN)上的"RHEL Server Supplementary (v. 6 64-bit x86_64)" 渠道進行安裝。這個模塊的更新將會由 RedHat 提供。

對于ASMlib的方式，它是通過以下命令方式創(chuàng)建ASM磁盤：

# /usr/sbin/oracleasm createdisk disk_name device_partition_name

通過這種方式創(chuàng)建的ASM磁盤組名稱（disk_name）,唯一綁定的是后面的device_partition_name，因此我們必須保障操作系統(tǒng)在日后的Lun變更過程中，這個命名是不能夠變更的。假設(shè)我們用的是第三方多路徑軟件管理方式實現(xiàn)，那么需要通過多路徑管理軟件的方式來講磁盤的device_partition_name和磁盤的唯一ID關(guān)聯(lián)。例如emcpowerpath可以用emcadm export/import方式來保障Rac節(jié)點上的Lun名稱一致。

對于udev的方式，同樣道理我們需要將磁盤的scsi-id和最終形成的asm磁盤名稱進行關(guān)聯(lián)，而不是用磁盤在操作系統(tǒng)顯示的設(shè)備名來關(guān)聯(lián)。例如：

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

其中的PROGRAM字段非常重要，它表示我們是用什么方式來關(guān)聯(lián)磁盤在操作系統(tǒng)和ASM之間的對應(yīng)關(guān)系。如果在日后的運維過程中，隨著磁盤的增減變化或者服務(wù)器的重啟變更等導(dǎo)致了磁盤設(shè)備名發(fā)生變化，那么就會導(dǎo)致ASM磁盤符號紊亂，最終數(shù)據(jù)庫集群無法啟動。當然這個問題在11g之后就不存在了，因為11g之后ASM自動會去根據(jù)磁盤的唯一ID匹配ASM識別的磁盤ID，節(jié)點的讀寫是根據(jù)磁盤的ASM標示來執(zhí)行的。但是從管理科學角度還是應(yīng)該按照最佳實踐來做從而保障沒有任何風險。

2.8 AIX平臺關(guān)注的存儲參數(shù)

對于AIX平臺而言，存儲卷的系統(tǒng)參數(shù)必須遵循以下規(guī)則。

(1) reserve_lock、reserve_policy

該兩個參數(shù)其實都是表示操作系統(tǒng)是否持有存儲卷的共享鎖方式。存儲陣列類型為SSA, FAStT, 或者其他 non-MPIO-capable disks，參數(shù)設(shè)置參照A。存儲陣列類型為SS, EMC, HDS, CLARiiON, 或者其他 MPIO-capable disks，參數(shù)設(shè)置方式參照B。

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

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

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

(3) fc_err_recov。

該參數(shù)表示因為AIX平臺下光纖斷掉場合下，讀寫錯誤切換的時間。正常情況下，這個切換會導(dǎo)致數(shù)據(jù)庫IO掛起10分鐘。如果是Vote disk，就會導(dǎo)致集群重啟。為了避免此類情況發(fā)生需要把該參數(shù)的值設(shè)置為fast_fail，實現(xiàn)快速切換。

(4) max_transfer。

該參數(shù)建議設(shè)置最少為Oracle最大請求的IO大小，一般超過1M。

(5) queue_depth。

該參數(shù)表示Lun的最大IO隊列深度，這個參數(shù)的設(shè)置必須足以支撐數(shù)據(jù)庫并發(fā)讀寫的負載。

(6) max_xfer_size。

該參數(shù)表示光纖卡的最大傳輸大小，這個參數(shù)的設(shè)置必須與磁盤的吞吐參數(shù)保持倍數(shù)關(guān)系，并且必須大于磁盤設(shè)置的參數(shù)。

(7) num_cmd_elems。

該參數(shù)表示光纖卡接受的最大IO請求數(shù)目，這個參數(shù)同樣與磁盤的queue_depth有著倍數(shù)關(guān)系，具體值的設(shè)定需要看環(huán)境當中光纖卡和其所容納Lun的數(shù)目。

3.網(wǎng)絡(luò)規(guī)劃設(shè)計的關(guān)鍵點 3.1 硬件及參數(shù)

從Oracle官方的推薦來看，他們首先推薦使用萬兆以太網(wǎng)，至少使用千兆以太網(wǎng)，負載如果很高那么私網(wǎng)可以采用infiniband。當然這個完全取決于客戶生產(chǎn)環(huán)境的具體業(yè)務(wù)量及負載情況。這個僅僅是個參考，有條件的情況下可以按照推薦進行配置。私網(wǎng)的連接需要使用交換機，Oracle集群安裝并不支持私網(wǎng)的直連架構(gòu)。網(wǎng)卡及交換機的雙攻擊速率參數(shù)保持正確一致。

3.2 網(wǎng)卡綁定

各種平臺都有自己的網(wǎng)卡綁定工具，而且提供負載均衡和主備模式的綁定。首先為了提高公網(wǎng)和私網(wǎng)的網(wǎng)絡(luò)高可用，網(wǎng)卡需要綁定。對于Linux平臺我們需要在配置文件 “/etc/modprobe.d/dist.conf” 中將數(shù)mode來控制網(wǎng)卡綁定的具體策略：

? mod=0，即：(balance-rr)Round-robin policy（平衡掄循環(huán)策略）。

? 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 動態(tài)鏈接聚合）。

? mod=5，即：(balance-tlb)Adaptive transmit load balancing（適配器傳輸負載均衡）。

? mod=6，即：(balance-alb)Adaptive load balancing（適配器適應(yīng)性負載均衡）。

對于私網(wǎng)網(wǎng)卡綁定方式mode=3&6會導(dǎo)致ORA-600，公網(wǎng)網(wǎng)卡綁定方式mode=6會導(dǎo)致BUG9081436。對于具體的綁定模式，對于平臺版本低而且網(wǎng)絡(luò)架構(gòu)非常復(fù)雜的場合，還是建議主備模式，因為主備模式更穩(wěn)定，不容易產(chǎn)生數(shù)據(jù)包路徑不一致的問題。如果是負載均衡模式的場合，如果網(wǎng)絡(luò)參數(shù)設(shè)置不是很科學的情況下，很容易出現(xiàn)從一個物理網(wǎng)卡發(fā)送報文，但是回報文卻回到另外一個物理網(wǎng)卡上，網(wǎng)絡(luò)鏈路再加入防火墻的規(guī)則之后，非常容易導(dǎo)致丟包問題發(fā)生。

而對于AIX平臺來講，將參數(shù)mode修改為NIB或者Standard值。Standard是根據(jù)目標IP地址來決定用哪個物理網(wǎng)卡來發(fā)送報文，是基于IP地址的負載均衡，也不易產(chǎn)生上述的丟包問題。

3.3 SCAN

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

SCAN是一個域名，可以解析至少1個IP，最多解析3個SCAN IP，客戶端可以通過這個SCAN 名字來訪問數(shù)據(jù)庫，另外SCAN ip必須與public ip和VIP在一個子網(wǎng)。啟用SCAN 之后，會在數(shù)據(jù)庫與客戶端之間，添加了一層虛擬的服務(wù)層，就是SCAN IP和SCAN IP Listener，在客戶端僅需要配置SCAN IP的tns信息，通過SCANIP Listener，連接后臺集群數(shù)據(jù)庫。這樣，不論集群數(shù)據(jù)庫是否有添加或者刪除節(jié)點的操作，均不會對客戶端產(chǎn)生影響，也就不需要修改配置。對于SCAN相關(guān)的配置，有以下一些配置注意事項：

（1）主機的默認網(wǎng)關(guān)必須與SCAN以及VIP在同一個子網(wǎng)上。

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

（3）為避免名稱解析出現(xiàn)問題，假設(shè)我們設(shè)置了三個SCAN地址，那么HOSTs文件當中不能出現(xiàn)SAN的記錄，因為HOSTs文件當中的記錄是靜態(tài)解析，與DNS動態(tài)解析相悖。

3.4 網(wǎng)絡(luò)參數(shù)

操作系統(tǒng)平臺上關(guān)于網(wǎng)絡(luò)的內(nèi)核參數(shù)非常重要，直接決定私網(wǎng)公網(wǎng)數(shù)據(jù)傳輸?shù)姆€(wěn)定性和性能。不過針對不同的操作系統(tǒng)，相關(guān)的參數(shù)設(shè)置也各有差異。

1．Linux

對于Linux平臺的內(nèi)核參數(shù)，有兩個非常重要（net.core.rmem_default、net.core.rmem_max）。具體功能解釋如下：

? net.ipv4.conf.eth#.rp_filter：數(shù)據(jù)包反向過濾技術(shù)。

? net.ipv4.ip_local_port_range：表示應(yīng)用程序可使用的IPv4端口范圍。

? net.core.rmem_default：表示套接字接收緩沖區(qū)大小的缺省值。

? net.core.rmem_max：表示套接字接收緩沖區(qū)大小的最大值。

? net.core.wmem_default：表示套接字發(fā)送緩沖區(qū)大小的缺省值。

? net.core.wmem_max：表示套接字發(fā)送緩沖區(qū)大小的最大值。

為了獲得更好的網(wǎng)絡(luò)性能，我們需要根據(jù)具體情況把以上兩個參數(shù)從其默認值適當調(diào)整為原來的2-3倍甚至更高，關(guān)閉或者設(shè)置反向過濾功能為禁用0或者寬松模式2。

2.AIX

對于AIX平臺的內(nèi)核參數(shù)，以下設(shè)置是從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個參數(shù)表示TCP窗口大小，第3、4個參數(shù)表示UDP窗口大小。rfc1323啟用由 RFC 1323（TCP 擴展以得到高性能）指定的窗口定標和時間圖標。窗口定標允許 TCP 窗口大?。╰cp_recvspace 和 tcp_sendspace）大于 64KB（65536）并且通常用于大的 MTU 網(wǎng)絡(luò)。默認為0(關(guān))，如果試圖將 tcp_sendspace 和 tcp_recvspace 設(shè)為大于 64 KB則需要先修改此值為1。ipqmaxlen 表示指定接收包的數(shù)目，這些包可以列在 IP 協(xié)議輸入隊列中。sb_max指定一個 TCP 和 UDP 套接字允許的最大緩沖區(qū)大小。

3.5 安全配置事項

1．Linux平臺下的防火墻需要關(guān)閉，否則會引起公網(wǎng)或者私網(wǎng)的通訊問題。

# chkconfig iptables stop

2．Linux平臺下的selinux安全配置項需要關(guān)閉，配置文件為/etc/security/config。

SELINUX=disabled

3．如果是Power System主機的PowerVM虛擬化架構(gòu)下的AIX平臺，如果發(fā)現(xiàn)Oracle RAC的兩個節(jié)點之間有大量丟包現(xiàn)象或者是以下幾種事件：

? Cache Fusion "block lost"

? IPC Send timeout

? Instance Eviction

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

那么我們需要檢查VIOS分區(qū)操作系統(tǒng)的補丁信息，如果沒有APAR IZ97457，那么我們需要將這個補丁打上，詳細需到IBM官網(wǎng)找到相應(yīng)的補丁及其詳細解釋。

3.6 通用注意事項

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

2.網(wǎng)卡名稱在兩個節(jié)點上保持一致（例：public->eth2e1，private->eth3e2）。

3.網(wǎng)卡設(shè)備名稱當中不能包含“.”等特殊字符。

4.私網(wǎng)地址需遵守RFC1918標準，采用其所規(guī)定的ABC三類企業(yè)內(nèi)部私網(wǎng)地址。否則會引起B(yǎng)UG4437727發(fā)生。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比特前綴)。而且私網(wǎng)VLAN需要與上述no-routeable子網(wǎng)之間需要是1:1的映射關(guān)系，以免引起B(yǎng)UG9761210。

5.從11gr2起，私網(wǎng)網(wǎng)段配置需要支持組播功能，因為私網(wǎng)需要通過組播模式實現(xiàn)通訊。

3.7 send (tx) / receive (rx)

UDP包傳輸?shù)倪^程中，接受進程會讀取數(shù)據(jù)包頭的校驗值。任何校驗值損壞都會使這個包被丟棄，并導(dǎo)致重發(fā)，這會增加CPU的使用率并且延緩數(shù)據(jù)包處理。

由于網(wǎng)卡上開啟了Checksum offloading 導(dǎo)致了checksum 錯誤，如果出現(xiàn)這樣的問題請檢查checksum offloading的功能是否被禁用，測試后考慮關(guān)閉網(wǎng)卡上的該項功能。在Linux系統(tǒng)上執(zhí)行ethtool -K <IF> rx off tx off可以關(guān)閉該功能。

3.8 MTU

不匹配的MTU大小設(shè)置會導(dǎo)致傳輸過程中出現(xiàn) "packet too big" 錯誤并丟失數(shù)據(jù)包，導(dǎo)致global cache block丟失和大量的重傳（retransmission）申請。而且私網(wǎng)中不一致的MTU值會導(dǎo)致節(jié)點無法加入集群的問題。

對于以太網(wǎng)（Ethernet），大多數(shù)UNIX平臺的默認值是1500字節(jié)。私網(wǎng)鏈路中所有設(shè)備都應(yīng)該定義相同的MTU。請確認并監(jiān)控私網(wǎng)鏈路中的所有的設(shè)備。為ping ,tracepath,traceroute命令指定大的，非默認尺寸，ICMP probe 包來檢查MTU設(shè)置是否存在不一致。使用ifconfig或者廠商推薦的工具為服務(wù)器網(wǎng)卡（NIC）的MTU設(shè)置合適的值。

Jumbo Frames 并不是IEEE 標準配置。單個Jumb Frame的大小是9000 bytes左右。Frame 的大小取決于網(wǎng)絡(luò)設(shè)備供應(yīng)商，在不同的通信設(shè)備上的大小可能是不一致的。如果默認的MTU 尺寸不是9000bytes，請保證通信路徑中的所有設(shè)備（例如：交換機/網(wǎng)絡(luò)設(shè)備/網(wǎng)卡）都能夠支持一個統(tǒng)一的MTU值，在操作的過程中必須把Frame Size（MTU Size）配置成這個值。不合適的MTU設(shè)置，例如：交換機上配置MTU=1500,但是服務(wù)器上的私網(wǎng)網(wǎng)卡配置成MTU=9000，這樣會造成丟包，包的碎片和重組的錯誤，這些都會導(dǎo)致嚴重的性能問題和節(jié)點異常宕機。大部分的平臺上我們都可以通過netstat –s命令的‘IP stats’輸出發(fā)現(xiàn)包的碎片和重組的錯誤。大部分的平臺上我們可以通過ifconfig –a命令找到frame size的設(shè)置。關(guān)于交換機上的配置查詢，需要查看交換機提供商的文檔來確定。

4.操作系統(tǒng)層的關(guān)鍵優(yōu)化項

4.1 兼容性檢查

在Oracle建設(shè)實施之前，根據(jù)操作系統(tǒng)平臺對即將采用的相關(guān)數(shù)據(jù)庫技術(shù)進行兼容性檢查。下面的link是官方的Matrix，分別針對Linux平臺和Unix平臺：

http://www.oracle.com/technetwork/database/clustering/tech-generic-linux-new-086754.html

http://www.oracle.com/technetwork/database/clustering/tech-generic-unix-new-166583.html

4.2 平臺版本及補丁

當我們選擇了具體的操作系統(tǒng)平臺以及具體的數(shù)據(jù)庫版本之后，接下需要做的事情就是要根據(jù)官方提供的文檔來檢查我們的系統(tǒng)補丁以及相關(guān)軟件包是否齊全準確：

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官方對所有數(shù)據(jù)庫集群及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 時間同步設(shè)置項

NTP是11gr2之前必須的選項，用來同步節(jié)點之間的時間。而到了11gr2之后，不僅僅可以采用NTP也可以采用CTSSD（Cluster Time Synchronization Daemon）代替NTP。如果NTP啟用的話，Oracle會采用NTP，CTSSD自動處于觀察模式。但是在NTP的啟用模式上，我們需要采用漸進式模式（需要利用啟動參數(shù)-x）?？梢詤⒄障旅娴呐渲茫?/p>

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以上版本中默認開啟的一個特性，是參與保護緩沖區(qū)溢出問題的一個計算機安全技術(shù)。是為了防止攻擊者在內(nèi)存中能夠可靠地對跳轉(zhuǎn)到特定利用函數(shù)。ASLR包括隨機排列程序的關(guān)鍵數(shù)據(jù)區(qū)域的位置，包括可執(zhí)行的部分、堆、棧及共享庫的位置。ASLR通過制造更多讓攻擊者預(yù)測目標地址的困難以阻礙一些類型的安裝攻擊。而在ORACLE的進程管理當中，多個進程共享相同地址的共享內(nèi)存，開啟ASLR特性之后，Oracle就無法保障共享內(nèi)存可用。從而導(dǎo)致ORA-00445錯誤發(fā)生。要在Linux上關(guān)閉這個特性需要添加或修改以下兩個參數(shù)到/etc/sysctl.conf文件：

kernel.randomize_va_space=0

kernel.exec-shield=0

4.5 HugePage

大多數(shù)操作系統(tǒng)采用了分段或分頁的方式進行管理。分段是粗粒度的管理方式，而分頁則是細粒度管理方式，分頁方式可以避免內(nèi)存空間的浪費。相應(yīng)地，也就存在內(nèi)存的物理地址與虛擬地址的概念。通過前面這兩種方式，CPU必須把虛擬地址轉(zhuǎn)換程物理內(nèi)存地址才能真正訪問內(nèi)存。為了提高這個轉(zhuǎn)換效率，CPU會緩存最近的虛擬內(nèi)存地址和物理內(nèi)存地址的映射關(guān)系，并保存在一個由CPU維護的映射表中。為了盡量提高內(nèi)存的訪問速度，需要在映射表中保存盡量多的映射關(guān)系。

Linux的內(nèi)存管理采取的是分頁存取機制，為了保證物理內(nèi)存能得到充分的利用，內(nèi)核會按照LRU算法在適當?shù)臅r候?qū)⑽锢韮?nèi)存中不經(jīng)常使用的內(nèi)存頁自動交換到虛擬內(nèi)存中，而將經(jīng)常使用的信息保留到物理內(nèi)存。

通常情況下，Linux默認情況下每頁是4K，這就意味著如果物理內(nèi)存很大，則映射表的條目將會非常多，會影響CPU的檢索效率。因為內(nèi)存大小是固定的，為了減少映射表的條目，可采取的辦法只有增加頁的尺寸。因此Hugepage便因此而來。也就是打破傳統(tǒng)的小頁面的內(nèi)存管理方式，使用大頁面2m,4m等。如此一來映射條目則明顯減少。如果系統(tǒng)有大量的物理內(nèi)存（大于8G），則物理32位的操作系統(tǒng)還是64位的，都應(yīng)該使用Hugepage。

那么如何控制Oracle數(shù)據(jù)庫對HugePage的利用呢？主要分為以下幾個步驟：

1．需要在/etc/security/limits.conf 中設(shè)置memlock值(單位KB)，該值小于內(nèi)存大小。

2． 如果你使用11G及以后的版本，AMM已經(jīng)默認開啟，但是AMM與Hugepages是不兼容的，必須先關(guān)閉AMM。

3．編輯/etc/sysctl.conf 設(shè)置 vm.nr_hugepages參數(shù)的具體值。

4．停止實例并重啟OS系統(tǒng)，并通過以下命令檢查設(shè)置是否生效：

# grep HugePages /proc/meminfo

HugePages_Total: 1496

HugePages_Free: 485

HugePages_Rsvd: 446

HugePages_Surp: 0

5．通過以下參數(shù)控制數(shù)據(jù)庫對HugePage的使用方式(11gr2之后)：

use_large_pages = {true/only/false/auto}

默認值是true，如果系統(tǒng)設(shè)置Hugepages的話，SGA會優(yōu)先使用hugepages，有多少用多少。如果設(shè)置為false， SGA就不會使用hugepages。如果設(shè)置為only 如果hugepages大小不夠的話，數(shù)據(jù)庫實例是無法啟動的。設(shè)置為auto，這個選項會觸發(fā)oradism進程重新配置linux內(nèi)核，以增加hugepages的數(shù)量。一般設(shè)置為true。

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

4.6 Transparent HugePage

透明大頁管理和前面所述的標準大頁管理都是操作系統(tǒng)為了減少頁表轉(zhuǎn)換消耗的資源而發(fā)布的新特性，雖然Oracle建議利用大頁機制來提高數(shù)據(jù)庫的性能，但是Oracle卻同時建議關(guān)閉透明大頁管理。這二者的區(qū)別在于大頁的分配機制，標準大頁管理是預(yù)分配的方式，而透明大頁管理則是動態(tài)分配的方式。

對于數(shù)據(jù)庫來講這種動態(tài)的分配方式在系統(tǒng)負載很高的情況下非常有可能導(dǎo)致數(shù)據(jù)庫出現(xiàn)嚴重的性能問題。這在Oracle官方文檔1557478.1當中有詳細的記載。

那么如何來關(guān)閉系統(tǒng)的透明大頁管理呢？只要修改如下參數(shù)即可：

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

4.7 vm.min_free_kbytes

該參數(shù)是Linux內(nèi)核當中用來控制保留最小空閑內(nèi)存的數(shù)量，Oracle建議調(diào)大該值為512M。這樣的設(shè)置有利于相對加快內(nèi)存的回收速度，從而降低內(nèi)存吃緊的壓力。

4.8 AIX虛擬內(nèi)存參數(shù)

這一項主要是針對AIX的內(nèi)存管理。AIX內(nèi)存管理和Linux的內(nèi)存管理機制不一樣，它采用計算內(nèi)存和非計算內(nèi)存方式來管理內(nèi)存。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控制非計算內(nèi)存中的文件頁的下限和上限；maxclient控制非計算內(nèi)存中的客戶頁面；lru_file_repage表示分頁替換守護進程將根據(jù)其內(nèi)部重新分頁表來確定選擇何種類型的分頁進行操作。strict_maxperm&strict_maxclient表示無論是否有空閑內(nèi)存，都會嚴格限制文件頁以及客戶頁的最大占有比率不得超越限制。page_steal_method表示換頁時的策略，0為全部頁面，1為非計算持久頁面。以上參數(shù)放方案表示費計算持久頁面的上限為90%，下限為3%；客戶機頁面上限為90%；采用非嚴格持久頁面上限控制策略；嚴格客戶機頁面上限控制策略。lru_file_repage & page_steal_method配合使用表示LRUD在尋找空閑頁時，只尋找費計算內(nèi)存當中的持久內(nèi)存頁面。

vmm_klock_mode=2

這個參數(shù)是是否對內(nèi)核頁進行加鎖的控制。0則表示不進行加鎖，那么內(nèi)核頁有可能被錯誤換出從而導(dǎo)致Page Fault發(fā)生；1則表示部分內(nèi)核頁面加鎖；2則表示對所有內(nèi)核頁面進行加鎖。在Oracle RAC環(huán)境下或者EMC的存儲作為系統(tǒng)的Swap Device的時候，IBM強烈建議將該參數(shù)設(shè)置為2。

4.9 PowerVM環(huán)境下的參數(shù)調(diào)整

PowerVM環(huán)境下，由于其利用Hypervisor實現(xiàn)了很多虛擬化的功能，這些功能大多從靈活性及擴展型來考慮，但是如果我們運行的是Oracle Rac的話，那么還是有很多關(guān)鍵點需要注意。

1. cpu folding

虛擬處理器折疊功能，當系統(tǒng)負載比較低的時候，AIX系統(tǒng)自動休眠一些虛擬處理器，以減少Hypervisor的開銷，提升PowerVM平臺整體性能。但是在某些情況下，當數(shù)據(jù)庫的負載變化非?？斓臅r候，CPU折疊或者打開的速度反而會影響數(shù)據(jù)庫甚至系統(tǒng)的性能，嚴重導(dǎo)致系統(tǒng)掛起。下面是IBM針對該BUG的一個補丁，主要針對AIX5.3 & 6.1。

https://www-01.ibm.com/support/docview.wss?uid=isg1fixinfo105201

4.10 Linux內(nèi)核參數(shù)

以下是Oracle官方針對Linux平臺內(nèi)核參數(shù)設(shè)置的一個通用方案：

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： 是核心參數(shù)中最重要的參數(shù)之一，用于定義單個共享內(nèi)存段的最大值。設(shè)置應(yīng)該足夠大，能在一個共享內(nèi)存段下容納下整個的SGA ,設(shè)置的過低可能會導(dǎo)致需要創(chuàng)建多個共享內(nèi)存段，這樣可能導(dǎo)致系統(tǒng)性能的下降。

至于導(dǎo)致系統(tǒng)下降的主要原因為在實例啟動以及ServerProcess創(chuàng)建的時候，多個小的共享內(nèi)存段可能會導(dǎo)致當時輕微的系統(tǒng)性能的降低(在啟動的時候需要去創(chuàng)建多個虛擬地址段，在進程創(chuàng)建的時候要讓進程對多個段進行“識別”，會有一些影響)，但是其他時候都不會有影響。

64位linux系統(tǒng)：可取的最大值為物理內(nèi)存值-1byte，建議值為多于物理內(nèi)存的一半，一般取值大于SGA_MAX_SIZE即可，可以取物理內(nèi)存-1byte。例如，如果為12G物理內(nèi)存，可取210241024*1024-1=12884901887，SGA肯定會包含在單個共享內(nèi)存段中。

kernel.shmall：  該參數(shù)控制可以使用的共享內(nèi)存的總頁數(shù)。Linux共享內(nèi)存頁大小為4KB,共享內(nèi)存段的大小都是共享內(nèi)存頁大小的整數(shù)倍。一個共享內(nèi)存段的最大大小是16G，那么需要共享內(nèi)存頁數(shù)是16GB/4KB=16777216KB /4KB=4194304（頁），也就是64Bit系統(tǒng)下16GB物理內(nèi)存，設(shè)置kernel.shmall = 4194304才符合要求(幾乎是原來設(shè)置2097152的兩倍)。這時可以將shmmax參數(shù)調(diào)整到16G了，同時可以修改SGA_MAX_SIZE和SGA_TARGET為12G（您想設(shè)置的SGA最大大小，當然也可以是2G~14G等，還要協(xié)調(diào)PGA參數(shù)及OS等其他內(nèi)存使用，不能設(shè)置太滿，比如16G）。

kernel.shmmni： 該參數(shù)是共享內(nèi)存段的最大數(shù)量。shmmni缺省值4096，一般肯定是夠用了。

fs.file-max： 該參數(shù)決定了系統(tǒng)中所允許的文件句柄最大數(shù)目，文件句柄設(shè)置代表linux系統(tǒng)中可以打開的文件的數(shù)量。

fs.aio-max-nr： 此參數(shù)限制并發(fā)未完成的請求，應(yīng)該設(shè)置避免I/O子系統(tǒng)故障。

kernel.sem： 以kernel.sem = 250 32000 100 128為例：250是參數(shù)semmsl的值，表示一個信號量集合中能夠包含的信號量最大數(shù)目。32000是參數(shù)semmns的值，表示系統(tǒng)內(nèi)可允許的信號量最大數(shù)目。100是參數(shù)semopm的值，表示單個semopm()調(diào)用在一個信號量集合上可以執(zhí)行的操作數(shù)量。128是參數(shù)semmni的值，表示系統(tǒng)信號量集合總數(shù)。

net.ipv4.ip_local_port_range： 表示應(yīng)用程序可使用的IPv4端口范圍。

net.core.rmem_default： 表示套接字接收緩沖區(qū)大小的缺省值。

net.core.rmem_max： 表示套接字接收緩沖區(qū)大小的最大值。

net.core.wmem_default： 表示套接字發(fā)送緩沖區(qū)大小的缺省值。

net.core.wmem_max： 表示套接字發(fā)送緩沖區(qū)大小的最大值。

5.配置集群層的關(guān)鍵點

5.1 diagwait

在集群進行驅(qū)逐節(jié)點時，節(jié)點發(fā)生重新啟動的場合下，操作系統(tǒng)需要轉(zhuǎn)儲CrashDump，這個參數(shù)就是集群需要等待操作系統(tǒng)轉(zhuǎn)儲的時間參數(shù)。對于版本 10gR2 和 11gR1，所有平臺上的最佳實踐都是將 CSS diagwait 參數(shù)設(shè)置為小于等于13。對于11gR2已經(jīng)不要求對該參數(shù)進行設(shè)置。

5.2 ORA_CRS_HOME

對于這個變量，Oracle官方給出的建議是：不要設(shè)置 ORA_CRS_HOME 環(huán)境變量（在所有平臺上）。設(shè)置此變量將使各個 Oracle 組件出現(xiàn)問題，而且 CRS 程序完全不需要此變量，因為它們都有包裝腳本。

5.3 關(guān)于組播和多播

Oracle11gR2私網(wǎng)采用的是組播方式通訊，組播地址段為230.0.1.0 或 224.0.0.251網(wǎng)段，為了保障集群私網(wǎng)通訊的正常及穩(wěn)定，一方面這個網(wǎng)段的網(wǎng)絡(luò)配置需要支持組播，另外一方面不要讓主機的任何其他網(wǎng)絡(luò)配置和這兩個網(wǎng)段沖突。曾經(jīng)遇到過浪潮的X86服務(wù)器的帶外管理的某個地址也正好利用了這個網(wǎng)段，結(jié)果導(dǎo)致了Oracle Rac節(jié)點的異常重啟。這種問題一般會顯示為私網(wǎng)通訊報錯，但是正常狀況下只要帶外管理收集日志工具不啟動的話，那么是不會發(fā)現(xiàn)這個問題的，屬于偶發(fā)性問題。所以我們需要特別小心此類問題，不要等到發(fā)生時候再去花費大量實踐調(diào)查。

6.安裝集群時的關(guān)鍵點

6.1 cluvfy

如果安裝過10g以后的RAC環(huán)境，應(yīng)該對這個工具并不陌生。在安裝Cluster和Database之前通常會執(zhí)行runcluvfy.sh腳本來檢查當前系統(tǒng)是否滿足安裝條件。runcluvfy.sh將cluvfy工具的功能在shell中實現(xiàn)，使得用戶在數(shù)據(jù)庫和CLUSTER安裝之前就可以利用這個工具的功能。這個工具的主要作用就是驗證系統(tǒng)是否滿足安裝的條件，尤其是檢查網(wǎng)絡(luò)和域名解析，如果網(wǎng)絡(luò)和域名解析在安裝之前沒有正常的配置，通常直接導(dǎo)致安裝的失敗。主要用法如下所列兩個功能：

# runcluvfy.sh stage -list

# runcluvfy.sh comp -list

6.2 升級順序問題

安裝完集群軟件也好，RDBMS也好，打補丁是必然要做的事情。但是究竟是等安裝完所有的組件之后再統(tǒng)一打補丁呢還是說將每一個組件都按照安裝&補丁升級的順序依次做完呢？Oracle給的建議是：在執(zhí)行 11gR2 之前的安裝時，建議在執(zhí)行任何 RDBMS 或 ASM 主目錄安裝前應(yīng)用補丁程序?qū)?Clusterware 主目錄升級到所需的級別。

6.3 root.sh & rootupgrade.sh

安裝或者升級期間，最后的步驟就是要執(zhí)行以上的腳本。當然按照安裝文檔的要求必須是用超級用戶root來執(zhí)行。但是可能有些人認為只要利用root的權(quán)限去執(zhí)行就可以了，很想當然的用了su root -c或者是sudo等去執(zhí)行，結(jié)果導(dǎo)致執(zhí)行失敗，日志報錯crsd.bin crashes。因為腳本的執(zhí)行不僅僅是要用超級用戶root的權(quán)限，還要利用root用戶的環(huán)境配置等。

6.4 /etc/init.cssd

11.2 之前再AIX系統(tǒng)上，OPROCD 默認不在 AIX 全局運行隊列運行 ，這可能會導(dǎo)致 OPROCD 錯誤地重啟節(jié)點。(Bug 13623902)。此問題的更正操作是修改 /etc/init.cssd 文件，加入如下參數(shù)：

RT_GRQ=ON

export RT_GRQ

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

7.數(shù)據(jù)庫層的關(guān)鍵優(yōu)化項

7.1 pre_page_sga & lock_sga

這兩個參數(shù)都是對數(shù)據(jù)庫SGA的保護參數(shù)。lock_sga是控制SGA不被換出到交換空間上，會保障數(shù)據(jù)庫內(nèi)存頁一致留在物理內(nèi)存上，從而提高性能。而pre_page_sga是保障數(shù)據(jù)庫實例啟動時就把所有SGA讀到物理內(nèi)存上，雖然啟動會慢，但是后續(xù)性能會好。

但是pre_page_sga同時還有一個作用。pre_page_sga 為true時, 每個進程創(chuàng)建的時候都會去touch一遍sga里的page, 當sga越大的時候,這個touch所消耗的時間就越長，特別是在斷開式連接,短連接的Application上, 將會消耗很多資源。當客戶端連接感覺到慢的時候，這個參數(shù)就一定要設(shè)置成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 關(guān)于重做日志

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

接著、我們還需要考慮與其相關(guān)的參數(shù)設(shè)置。

1. _use_adaptive_log_file_sync

它直接決定了日志落盤的方式，對于日志緩沖區(qū)的數(shù)據(jù)落盤的方式，11g增加一種新的方式就是polling的方式，傳統(tǒng)方式是post/wait方式。oracle底層自動判斷何時用何種方法來完成lgwr進程的寫任務(wù)。對于post/wait方式來講，客戶端做了commit之后，需要等待事件完成。oracle一旦完成會通知用戶進程，用戶進程立刻感知。但是這一通知post，會耗費大量CPU資源。polling是oracle前臺進程啟動檢查任務(wù)，自動檢查后臺lgwr寫入情況，耗費CPU資源比較少，但是用戶進程并不一定能立刻感知。

所以兩種方法各有千秋。但是關(guān)鍵是后臺實現(xiàn)兩種方法切換的時候要耗費系統(tǒng)性能，尤其在繁忙的時候頻繁切換的話反而會導(dǎo)致數(shù)據(jù)庫性能下降。awr出現(xiàn)大量log file sync，Bug 13707904。

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

2. archive_lag_target 它決定了我們是否開啟日志強制切換功能，為了減少故障時數(shù)據(jù)損失，可以設(shè)置archive_lag_target參數(shù)，強制進行日志切換。這個參數(shù)的缺省值是0，即為不啟用該參數(shù)。建議設(shè)置值為1800。 SQL> alter system set archive_lag_target=1800 scope=spfile sid='*';

7.3 AMM

首先、ORACLE通用的兩種內(nèi)存管理方式AMM&ASMM，從Oracle 11g開始，ORACLE默認使用AMM(自動內(nèi)存管理)，即讓數(shù)據(jù)庫完全管理SGA、PGA的大小，而對于管理員只需要設(shè)置一個總的大?。╩emory_target），數(shù)據(jù)庫會動態(tài)的調(diào)整SGA、PGA的大小以及其中包含的各個組件大小，如Database buffer cache、Shared pool等。這個特性設(shè)計的初衷是好的，它希望避免不正確的SGA和PGA設(shè)置導(dǎo)致的內(nèi)存使用不平衡的性能問題。

但是在實際應(yīng)用過程中，這個特性是不是一定非常出色呢？AMM中在數(shù)據(jù)庫啟動是會有一個固定比例來分配SGA/PGA 大小：

sga_target =memory_target 60%

pga_aggregate_target=memory_target *40%。

但是在并發(fā)較高，數(shù)據(jù)庫非常繁忙的場合下，自動內(nèi)存調(diào)整的速度很可能趕不上大量會話對內(nèi)存的請求的速度。另外當PGA隨著會話不斷增加而需求量猛增的情況下，它會首先搶占SGA，導(dǎo)致數(shù)據(jù)庫性能故障。在高并發(fā)的數(shù)據(jù)庫場景中并不建議使用AMM。采用10g更為成熟的自動共享內(nèi)存管理(ASMM)和自動PGA管理。手動調(diào)整內(nèi)存參數(shù)，具體可以參照以下：

1. 關(guān)閉內(nèi)存自動管理

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

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

2. 設(shè)置SGA為固定值，可以根據(jù)性能測試中的AWR報告中的建議

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

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

3. 設(shè)置PGA等參數(shù)

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

另外很重要的一個參數(shù)，“_shared_pool_reserved_pct”，如果這個參數(shù)設(shè)置小了，很可能導(dǎo)致ORA04031，所以需要一個合理的設(shè)置。

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

7.4 SQL解析

1. 綁定變量窺測

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

根據(jù)自己的業(yè)務(wù)系統(tǒng)特點，做大量的性能測試和業(yè)務(wù)測試，根據(jù)參數(shù)的關(guān)閉打開對比awr報告當中顯示出的軟硬解析比率以及執(zhí)行計劃數(shù)據(jù)決定是否打開或者關(guān)系相應(yīng)功能特性。如下參數(shù)：

"_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

與之相關(guān)的幾個參數(shù)：open_cursors、session_cached_cursors 這兩個參數(shù)決定著應(yīng)用會話可以控制打開以及緩存的游標數(shù)量，如果數(shù)量不足，就會引起SQL解析的性能問題。這兩個參數(shù)要根據(jù)v$resource_limit視圖中的值的情況進行調(diào)整，避免資源設(shè)置不合理導(dǎo)致的性能問題。

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

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

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

7.5 process & sessions

process 限制了能夠連接到SGA的操作系統(tǒng)進程數(shù)，這個總數(shù)必須足夠大，從而能夠適用于后臺進程與所有的專用服務(wù)器進程，此外共享服務(wù)器進程與調(diào)度進程的數(shù)目也被計算在內(nèi)。session 是通信雙方從開始通信到通信結(jié)束期間的一個上下文(context)。這個上下文是一段位于服務(wù)器端的內(nèi)存：記錄了本次連接的客戶端機器、通過哪個應(yīng)用程序、哪個用戶在登錄等信息。

Oracle的連接數(shù)sessions與其參數(shù)文件中的進程數(shù)process相關(guān)，它們的關(guān)系如下： sessions=(1.1process+5)

這兩個參數(shù)的設(shè)置是需要根據(jù)應(yīng)用的具體并發(fā)需求來決定具體的設(shè)置方案。

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

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

7.6 DRM

數(shù)據(jù)庫節(jié)點之間的競爭有很多，包括鎖（各種粒度鎖）的競爭以及數(shù)據(jù)的傳輸?shù)?。完全避免競爭那就失去了RAC的意義了，RAC本身就是希望能在兩個節(jié)點并行執(zhí)行任務(wù)。如果特別極致的并行一定引起嚴重的性能問題，如果完全禁止，既無法做到又失去了集群本來的意義。所以我們只能在一定程度上去平衡：

首先、關(guān)于DRM，oracle的DRM特性從理論上來看，它是為了避免節(jié)點間的數(shù)據(jù)量傳輸，避免節(jié)點間的鎖等待事件頻繁發(fā)生。DRM的極致是做到請求節(jié)點和Master節(jié)點統(tǒng)一化。但是實踐中，這個特性引起了很多的BUG、反而導(dǎo)致了節(jié)點間的競爭出現(xiàn)了性能故障。Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。所以建議關(guān)閉。

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

關(guān)于參數(shù)“parallel_force_local”，ORACLE RAC為了實現(xiàn)多節(jié)點并行處理是花費了很大代價的，假設(shè)一個集群當中有三個節(jié)點，對于某一個數(shù)據(jù)塊兒讀寫，有一個Master、有一個請求者、有一個擁有者，請求者向Master請求數(shù)據(jù)塊兒的最新版本，Master把請求轉(zhuǎn)發(fā)給擁有者，擁有者按照請求信息把數(shù)據(jù)塊兒傳送給申請者，然后加鎖進行讀寫。這一過程是需要有大量的數(shù)據(jù)傳輸和競爭存在的，一旦這個事情成為多數(shù)，那么勢必造成節(jié)點間的通訊負載過大，造成大量的鎖等待時間，嚴重影響數(shù)據(jù)庫整體性能。尤其是在做跨數(shù)據(jù)中心高可用的場合下。因此我們只要做到業(yè)務(wù)級別的并發(fā)處理，而不要追求一個SQL級別的絕對并發(fā)。物極必反的道理就在于此。因此把參數(shù)打開，使得進程級別并發(fā)實現(xiàn)本地化處理，不要跨節(jié)點處理。在官方文檔 ID 1536272.1當中，必須優(yōu)化的參數(shù)就包括這個。

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

7.8 關(guān)于自動任務(wù)

Oracle 11g 數(shù)據(jù)庫有三個預(yù)定義自動維護任務(wù)：

1. Automatic Optimizer Statistics Collection（自動優(yōu)化器統(tǒng)計信息收集）： 收集數(shù)據(jù)庫中所有無統(tǒng)計信息或僅有過時統(tǒng)計信息的 Schema 對象的 Optimizer（優(yōu)化器）統(tǒng)計信息。QL query optimizer（SQL 查詢優(yōu)化器）使用此任務(wù)收集的統(tǒng)計信息提高 SQL 執(zhí)行的性能。

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

3. Automatic SQL Tuning Advisor（自動 SQL 優(yōu)化指導(dǎo)）：檢查高負載 SQL 語句的性能，并提出如何優(yōu)化這些語句的建議。您可以配置此指導(dǎo)，自動應(yīng)用建議的SQL profile。

關(guān)于統(tǒng)計信息收集，數(shù)據(jù)庫是有其自己的默認啟動時間，11g是在22:00-2:00之間，假設(shè)這個時間跟我們的跑批時間有沖突的話，我們可以修改器具體執(zhí)行時間。但是這個任務(wù)必須保留。關(guān)于其他的兩個優(yōu)化指導(dǎo)，其實要看我們實際工作中用到的幾率是否很高，是否有價值留著給我們提供一些優(yōu)化的理論指導(dǎo)。如果感覺意義不大，可以不用。

7.9 安全方面的配置優(yōu)化

首先、是數(shù)據(jù)庫要不要保留審計？如何保留？

假設(shè)不打開審計，那么將來出來安全問題，我們無法尋找線索；假設(shè)打開，那么很可能因為使得審計日志占用大量的存儲空間，甚至影響數(shù)據(jù)庫IO性能。一般情況下還是需要對一些基本登錄行為的審計，但是我們可以把日志位置修改制定到操作系統(tǒng)層面減少數(shù)據(jù)庫層因此的性能壓力，而且應(yīng)該定期轉(zhuǎn)儲，減少碎文件太多而把文件系統(tǒng)i節(jié)點用光的極端情況?？梢酝ㄟ^對參數(shù)"audit_trail"以及adump參數(shù)的調(diào)整來實現(xiàn)此項優(yōu)化。

接著、alert日志和trace文件的控制參數(shù)。

max_dump_file_size，它決定了這些文件的大小限制，默認情況下是unlimited，如果生成了很大的文件，就會達到OS對文件上限的要求，導(dǎo)致寫入失敗。

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

7.10 parallel_min_servers

這個參數(shù)決定了實例可以并行執(zhí)行的進程的最大數(shù)目。設(shè)置太小查詢進程沒有并行執(zhí)行能力。如果設(shè)置太大，那么可能會導(dǎo)致內(nèi)存資源緊張，從而影響系統(tǒng)整體性能。確保監(jiān)控活動并行服務(wù)器進程的數(shù)量并計算要應(yīng)用于 parallel_min_servers 的平均值?？赏ㄟ^以下操作完成：

SQL> select * from v$pq_syssstat;

查看列值 "Servers Highwater"；

根據(jù)硬件情況優(yōu)化 parallel_max_servers的值。最開始可以使用 (2 * ( 2 個線程 ) (CPU_COUNT)) = 4 x CPU 計算，然后使用測試數(shù)據(jù)對更高的值重復(fù)測試。一般OLTP系統(tǒng)需限制其不超過128（ORACLE的默認算法有BUG，在cpu核數(shù)超過128，默認并行參數(shù)設(shè)置過高時，容易被觸發(fā)，會導(dǎo)數(shù)oracle無法啟動。另外，如果這個參數(shù)太高，并行的進程開的太大了，會導(dǎo)數(shù)數(shù)據(jù)庫無法承受并發(fā)壓力）。

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} 一旦設(shè)置具體值，那么崩潰恢復(fù)將在此要求的時間范圍內(nèi)完成。fast_start_parallel_rollback={high/low/false}，high啟動4倍于CPU數(shù)目的并行恢復(fù)進程，low啟動2倍于CPU數(shù)目的并行恢復(fù)進程，false關(guān)閉并行恢復(fù)進程。這兩個參數(shù)都是用來加速在故障場合下的奔潰恢復(fù)，其根本的機制就是要通過主動觸發(fā)checkpoint來縮短最近依次checkpoint和聯(lián)機重做日志之間的距離。但是這個無疑會帶來一定的性能風險。所以這兩個值的設(shè)置需要根據(jù)具體業(yè)務(wù)情況來設(shè)置，同時要進行壓力測試，不要因為激進的策略帶來性能問題。

與此相關(guān)還有一個參數(shù)log_checkpoints_to_alert，默認是關(guān)閉狀態(tài)。打開這個參數(shù)會在trace文件當中記錄詳細的檢查點發(fā)生信息，對于數(shù)據(jù)庫診斷來講是一個必不可少的功能。因此建議打開。

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 在公網(wǎng)接口出現(xiàn)故障時進行故障轉(zhuǎn)移所用的時長產(chǎn)生不利影響。

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)))

)

)

假設(shè)把TCP列到第一項，那么監(jiān)聽需要等待TCP timeout，而TCP timeout是受操作系統(tǒng)相關(guān)參數(shù)控制，并且timeout時間較長，那么就有可能引起故障轉(zhuǎn)移并不能非常及時的問題。

7.13 sqlnet.ora

數(shù)據(jù)庫連接的客戶端異常斷開后，其占有的相應(yīng)并沒有被釋放，如從v$session視圖中依舊可以看到對應(yīng)的session處于inactive，且對應(yīng)的服務(wù)器進程也沒有釋放，導(dǎo)致資源長時間地被占用，對于這種情形開該如何處理呢？sqlnet.expire_time對于這個問題我們提供了解決方案，專門用于清理那些異常斷開的情形，如網(wǎng)絡(luò)異常中斷，客戶端異常掉電，異常重啟

文章題目：OracleRAC建設(shè)過程中各個層面關(guān)鍵點和優(yōu)化項總結(jié)
URL分享：http://bm7419.com/article14/pccige.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、微信公眾號、App開發(fā)、自適應(yīng)網(wǎng)站、企業(yè)建站、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)