RAC 和 Oracle Clusterware 最佳實踐和初學者指南（平臺無關部分）

文件內容

適用於:

用途

最佳實踐和初學者指南之 Oracle Real Application Clusters (RAC) 系列，主要目標是為了幫助客戶快速瞭解實施、升級與維護 Oracle RAC 系統的通用的以及針對特定平臺的最佳實踐。Oracle 根據自己的經驗及其全球 RAC 客戶的反饋編寫和維護本文件。

本初學者指南的目的不在於取代 Oracle 文件集，而是作為它的補充。對於本文沒有明確解決的任何問題，還應仔細閱讀、理解和參考 Oracle 文件，以從中尋找答案。

您的運營團隊應仔細稽核所有建議，且只有通過了相應的風險評估後方能實施。風險評估只能由具備豐富的系統、應用和企業環境方面知識的人員來執行。

由於每個客戶環境都是獨一無二的，因此 Oracle Database 實施（包括 Oracle RAC 實施）的成功源於成功的測試環境。對於本文中的任一建議，在生產環境中加以實施之前，務必要在作為目標生產環境複製品的測試環境中進行充分的測試和驗證，以確保不會產生與所實施建議相關的負面影響。

適用範圍

本文章適用於所有新的和現有 RAC 實施以及 RAC 升級。

詳細資訊

RAC 平臺特定的入門套件和最佳實踐

本文件重點介紹與平臺無關（通用）的 RAC 最佳實踐，以下文件則包含了平臺特定的具體最佳實踐（包括分步安裝說明）。

RAC 平臺通用的負載測試和系統測試計劃概述

所有成功實施（特別是關鍵業務的最大可用性環境）的關鍵任務是測試。對於 RAC 環境，測試應包含負載生成和故障注入測試。通過負載測試，可衡量系統在負載繁重時的反應，而故障注入測試則有助於確保系統在發生不可避免的硬體和（或）軟體故障時能夠按照設計進行反應。下面的文件將介紹執行此重要測試時應遵循的指南。

這些文件用於驗證您的系統設定和配置，也可以作為練習應對某種故障的處理過程的一種方法。

ORAchk（之前的RACcheck） - Oracle 配置稽核工具

ORAchk 是一款配置稽核工具，主要用於稽核 Real Application Clusters (RAC)、Oracle Clusterware (CRS)、Automatic Storage Management (ASM) 和 Grid Infrastructure 環境中各個重要的配置設定。此實用程式用於驗證由 RAC Assurance 開發和支援團隊維護的 Oracle Real Application Clusters (RAC) 最佳實踐和初學者指南文件系列定義的最佳實踐和成功要素。目前，ORAchk 支援 Linux（x86 和 x86_64）、Solais SPARC 和 AIX（使用 bash shell）平臺。我們強烈建議在 ORAchk 支援的平臺上執行 RAC 的客戶使用此工具找出會影響叢集穩定性的潛在配置問題。

保持 RAC 叢集環境穩定當前必須要做的 11 件事

為了積極預防叢集因為常見的已知問題出現不穩定的情況，Oracle RAC Proactive Support 團隊編寫了一個包含會影響 RAC 叢集穩定性的最常見的11 個問題的列表。雖然所有這些建議都包含在最佳實踐和入門套件系列中，我們還是強烈建議您閱讀以下文件，因為我們認為這些文件是非常重要的成功因素。

設計注意事項

以下“設計注意事項”提供與 Infrastructure（平臺無關）相關的指南和最佳實踐資訊，以支援 Oracle RAC 實施。此資訊不僅適用於新安裝和升級，也能為那些支援現有 RAC 的實施提供有用資訊。

一般設計注意事項

• 為簡化系統的複雜度和與第三方軟體之間的互動，Oracle 建議避免使用第三方叢集管理軟體，除非實在需要。

• 推薦將 Automatic Storage Management (ASM) 用於資料庫儲存。有關 ASM 的其他資訊，請參見 Document .

• 檢查產品支援矩陣，以確保產品、版本和平臺組合的可支援性，或瞭解在某些組合中需要額外完成的所有特定步驟，請參見 Document 337737.1

• 與磁碟供應商聯絡，確認節點數、OS 版本、RAC 版本、CRS 版本、網路結構和補丁是否經過認證，因為有些儲存/San 供應商可能要求針對特定的節點數進行專門認證。

• 計劃並記錄容量要求。與伺服器供應商合作，制定詳細的容量計劃和系統配置，但請注意：使用正常的容量計劃流程估計執行工作負載所需的 CPU 數。隨著 CPU 數量的增加，SMP 和 RAC 叢集的成本會同步增加。如果 CPU 數量較少，通常是 SMP 的伸縮性較好；如果 CPU 數量較多，RAC 叢集的伸縮性通常要比 SMP 好。

• 消除架構中的所有單一故障點。示例包括（但不限於）：叢集私網冗餘（NIC 繫結等）、儲存的多路存取路徑、使用 2 個或多個 HBA 或發起程式和多路徑軟體、磁碟映象/RAID。其他詳細資訊請見後文描述。

• 使用經過證實的最大可用性策略。RAC 是最大可用性整體架構中的一個元件。檢視 Oracle 的最大可用性架構藍圖，網址：http://www.oracle.com/technetwork/database/features/availability/maa-096107.html.

• 使用系統測試計劃幫助制定意外停機的計劃並將其付諸實踐，這個步驟非常重要。本文件附有“系統測試計劃概述”示例，可指導您進行系統測試，以便為潛在的計劃外故障做準備。

• 強烈建議用於生產的RAC 例項不與 DEV、TEST、QA 或 TRAINING 例項共享一個節點。這些額外的例項通常會給生產環境帶來意外的效能改變。同時，強烈建議測試環境儘可能地接近生產環境的映象。

• 如能為 RAC 專案實施制定分步計劃，那將會非常有幫助。下面的 OTN 文章中包含了示例專案概述： http://www.oracle.com/technetwork/articles/haskins-rac-project-guide-099429.html

網路注意事項

• 對於私網，強烈推薦使用萬兆乙太網，至少需要使用千兆乙太網。

• 根據 RFC952 - DoD 主機列表說明，在主機名或域名中不使用下劃線。這條規則也適用於 Net（網路）、Host（主機）、Gateway（閘道器）或 Domain（域）名。

• VIP 和 SCAN VIP 應與公網在同一個子網上。有關其他資訊，請參見 Understanding SCAN VIP white paper.

• 預設閘道器必須與 VIP（包括 SCAN VIP）在同一個子網上，以防止出現 VIP 啟動/停止/故障轉移問題。在 11gR2 中，OUI 會檢測出並報告此問題，如果忽略檢查，此問題將導致無法啟動 VIP，從而導致安裝自身也出現故障。

• 建議通過 DNS，按round-robin方式將 SCAN 名稱（11gR2 和更高版本）至少解析為 3 個 IP 地址，無論叢集大小如何。有關其他資訊，請參見 Understanding SCAN VIP white paper.

• 為避免名稱解析出現問題，請確保 HOSTS 檔案和 DNS 中提供了 VIP 與公共主機名。SCAN 不得位於 HOSTS 檔案中，因為 HOSTS 檔案只能顯示 1:1 主機到 IP 的對映。

• 網路介面必須在所有節點上使用相同的名稱（如 eth1 -> eth1 支援 VIP，eth2 -> eth2 支援專用私網網路）。

• 網路介面卡 (NIC) 名稱中不得包含 "." 。

• 私網使用 Jumbo Frames 是提高 Cache Fusion 操作效能的最佳實踐。請參考 Document 341788.1

• 對私網使用non-routable的網路地址；A 類：10.0.0.0 到 10.255.255.255，B 類：172.16.0.0 到 172.31.255.255，C 類：192.168.0.0 到 192.168.255.255。有關其他資訊，請參考 RFC1918  和 Document 338924.1

• 請確保根據速度、雙工等正確配置網路介面。可用於監視和測試網路的各種工具有：ethtool、iperf、netperf、spray 和 tcp。請參考 Document 563566.1.
• 為避免公網或私網出現單一故障點，Oracle 強烈建議在每個叢集節點上配置公共網路介面卡 (Network Interface Card, NIC) 和私網 NIC 的冗餘集。請參考 Document 787420.1。  從 11.2.0.2 開始，Oracle Grid Infrastructure 可為私網（不是公網）提供冗餘和負載均衡，對於 11.2.0.2（必須使用 11.2.0.2 Database），這是 NIC 冗餘的首選方法。更多資訊，請參考 Document 1210883.1。
  
  
  注意：  如果使用 11.2.0.2 Redundant Interconnect/HAIP 功能，目前要求所有私網要在不同的子網上。如果全部介面在同一個子網上，且從路由表的第一個 NIC 中拔出電纜，則將發生GI stacks重啟或節點重啟的情況。有關此要求的技術說明，請參見 Document 1481481.1。
   
• 如果希望對發現硬體的可預測性更強，請將 HBA 和 NIC 卡插入 Grid 中每臺伺服器上的同一對應插槽中。
  
  
• 私網連線需要使用交換機，或冗餘交換機（不支援交叉線直連）。
  
  
• 由於在交換機上部署私有網路（甚至在使用 VLAN 時）可能會使私網鏈路在大型 IP 網路拓撲中遭遇擁堵並變得不穩定，因此強烈建議為私網使用專用冗餘交換機。如果在 VLAN 上部署私網，則在 VLAN 和non-routable的子網之間應該有一個 1:1 對映，並且 VLAN 不應該跨越多個 VLAN（已標記）或多個交換機。此環境中的部署問題包括在大型 IP 網路拓撲更改時的“Spanning Tree ”環、可能導致資料包洪流的不對稱路由以及缺乏對 VLAN/埠的細粒度監視。請參考 Bug 9761210。
  
  
• 如果在 VLAN 上部署叢集私網，請檢視 Oracle RAC and Clusterware Interconnect Virtual Local Area Networks (VLANs) 白皮書中的注意事項。
  
  
• 考慮對有高流量要求的工作負載的私網使用 Infiniband。Infiniband 還可以通過降低延遲來提高效能。實施 Infiniband 後，可以使用 RDS 協議進一步降低延遲。請參見 Document 751343.1 瞭解詳細資訊。
  
  
• 從版本12.1.0.1 開始，叢集公網支援IPv6，而叢集私網必須使用IPv4。有關詳細資訊，請參見 Oracle Database IPv6 State of Direction white paper （Oracle Database IPv6 發展方向白皮書）。

• 對於Grid Infrastructure版本 11.2.0.2，私網必須在子網 230.0.1.0支援多播傳輸（multicast）。Oracle Grid Infrastructure 11.2.0.2 的 Patch: 9974223  （包含在 GI PSU 11.2.0.2.1 和更高版本中）對私網上的 224.0.0.251 多播地址啟用了多播功能。必須允許這兩個地址中的其中一個所對應的私網使用多播（假設已應用補丁程式）。Document 1212703.1 中提供了測試多播功能的其他資訊和程式。

儲存注意事項（包括 ASM）

• 對使用兩個或多個 HBA 或 Initiator 的儲存陣列，多路徑軟體通過這些HBA 實現對這些陣列的多路徑存取。如果可能，請使用偽裝置（多路徑 I/O）作為 ASM 的 diskstring。比如：EMC PowerPath、Veritas DMP、Sun Traffic Manager、Hitachi HDLM、IBM SDDPC、Linux 2.6 Device Mapper。這對 I/O 的負載均衡和故障轉移非常有用。請參考 Document 294869.1 和  Multipathing Best Practices white paper（多路徑最佳實踐白皮書）。

• RAC 與 NFS 一起使用時，請確保對 NFS 磁碟使用正確的 mount 選項。Document 359515.1 中詳細介紹了針對各個平臺的 mount 選項。

• ASM 是儲存 Oracle Database 目前和未來的發展方向。也就是說，強烈建議在 RAC 環境中使用 ASM（而不是使用其它的叢集檔案系統），這是最佳實踐。使用 Oracle RAC 標準版時，資料檔案儲存需要使用 ASM。

• 遵守 ASM 最佳實踐。請參考： Document 265633.1 ASM Technical Best Practices.   雖然未明確說明，但是本文中列出的這些最佳實踐也適用於 11gR2。11gR2 ASM 最佳實踐也記錄在了 Oracle Automatic Storage Management Administrator's Guide11g Release 2 (11.2).

• 請確認客製化ASM Diskstring 以便優化ASM 磁碟發現時間，請參考Document 1608549.1 Improving ASM Disk Discovery (ASM_DISKSTRING) Time Best Practices.

• 建議保持 ASM 磁碟組不超過兩個，一個用於儲存資料檔案，一個用於閃回區（flash recovery area），而且每個磁碟組位於不同的物理磁碟。RAID 儲存陣列 LUN 可作為 ASM 磁碟，以最小化 OS 中顯示的 LUN 個數。

• 每個 ASM 磁碟組上最少要有四個大小和效能相同的 LUN（每個 LUN在不同的RAID 組），以確保效能最優。

• 使用高階儲存陣列時使用外部冗餘磁碟組。高階儲存陣列一般提供硬體 RAID 保護。不使用硬體 RAID 或需要使用基於主機的卷管理功能（如跨儲存系統映象）時，則使用 Oracle ASM 映象冗餘。在地理位置上分離的兩站點間映象（擴充套件的叢集）時，可以在配置中使用 Oracle ASM 映象。
• 在 11g 中，預設對 ASM 例項啟用 Automatic Memory Management (AMM)，即使沒有設定 MEMORY_TARGET 引數。大多數環境使用 MEMORY_TARGET 的預設值並不能使滿足要求，建議設定MEMORY_TARGET為1536M。如果在您的 ASM 例項中遇到 ORA-4031 錯誤，可能需要調整 AMM 設定。請參考 Document 1370925.1 (ASM Instances Are Reporting ORA-04031 Errors)，瞭解如何正確設定以避免共享池耗盡。

• 在 11g 環境中，如果多個資料庫共享同一個 ASM 例項，可能需要修改 ASM processes 引數。根據經驗法則，ASM 的最佳程式數為 150 個，可用於確定合適值的公式為：
  
  ASM processes = 50 x (<max # instances on db node> + <1 for first 10>) + 10 x (<subsequent instances after 10>)
• 對於 10g，增大 ASM 例項 SGA 引數大小分配的預設值：

• 磁碟做RAID條帶化的尺寸 需要選擇大小為 2 的冪且小於或等於 Oracle ASM Allocation Unit 的值。

• 如果 ASM 磁碟組中的 LUN 大於 2TB，則可能會發生 ORA-15196（ASM 塊損壞）。修復這個問題後，如果指定的磁碟大於 2TB，將發生 ORA-15099。無論是否存在 asmlib 這個問題都會發生。繞過問題的方法：不要向磁碟組中新增大於 2 TB 的磁碟。請參考 Document 6453944.8

• 在某些平臺上，警告日誌中可能會重複出現關於 AIO 限制的警告：
  "WARNING:Oracle process running out of OS kernel I/O resources." 解決這個問題需要應用 Patch 6687381，（許多平臺上都有）。此問題會影響 10.2.0.3、10.2.0.4 和 11.1.0.6。版本11.1.0.7 中已修正此問題。請參考 Document 6687381.8

• 在將 ASM 從 10.2 版升級到 11.1 或 11.2 版期間，會發生 Bug 5100163 (possible metadata corruption) ；在執行 ASM 升級前，僅當 ASM 磁碟組的 AU > 1 MB 時才會發生此 bug。對於在 11.1 或 11.2 版上直接建立的新磁碟組，不會遇到此 bug。
• 為了防止發生 Bug 5100163，My Oracle Support 上已生成了相關的公告。請參考： Document 1145365.1 Alert: Querying v$asm_file Gives ORA-15196 After ASM Was Upgraded From 10gR2 To 11gR2。總之，您可能要執行“alter diskgroup <DG_NAME> check all repair”以驗證和修復所有升級後的磁碟組。

Clusterware 和 Grid Infrastructure 配置注意事項

• 對於 11gR2 之前的版本，建議將 Voting Disks 儲存在 裸裝置或塊裝置（取決於 OS 和 Oracle 版本）上，並使用 Oracle 提供的冗餘，而不用考慮底層儲存配置。建議使用兩個 OCR。Voting Disks 的數量應保持為奇數，且最小數量為 3。之所以建議 Voting Disks 為奇數，是因為如果所有 Voting Disks 丟失 1/2 或更多，將導致節點從叢集中被驅逐，或導致節點將自己驅逐出叢集。

• 在 Grid Infrastructure 11gR2 中，已棄用 裸裝置和塊裝置，建議使用 ASM 儲存 OCR 和Voting Disks。在 11gR2 和更高版本中，將 OCR 和 Voting Disks 儲存在 ASM 中時，建議保持 ASM 磁碟組不超過 2 個（請參見“ASM 最佳實踐”）。這意味著 OCR 和 Voting Disks 將與資料庫相關檔案一起儲存。如果要對磁碟組使用外部冗餘（請參見“ASM 注意事項”瞭解有關磁碟組冗餘的詳細資訊），這意味著您將使用 1 個 Voting Disk 和 1 個 OCR。

• 在 11.2.0.2 中，Oracle Grid Infrastructure 可為私有網路（不是公共網路）提供冗餘和負載均衡，對於 11.2.0.2 版本的GI（必須使用 11.2.0.2 Database），這是 NIC 冗餘的首選方法。更多資訊，請參考 Document 1210883.1.

• 對於版本 10gR2 和 11gR1，所有平臺上的最佳實踐都是將 CSS diagwait 引數設定為 13，以便在出現節點驅逐時提供轉儲診斷資訊的時間。如果 Oracle Support 沒有明確說明，建議 diagwait 的值不要超過 13。在 Oracle Clusterware 11g Release 2 中，將不再要求進行此設定。有關 diagwait 的更多詳細資訊，請參考 Document 559365.1 for more details on diagwait.
  
  
• 不要設定 ORA_CRS_HOME 環境變數（在所有平臺上）。設定此變數將使各個 Oracle 元件出現問題，而且 CRS 程式完全不需要此變數，因為它們都有包裝指令碼。

虛擬化注意事項

• 具有特定平臺、版本和補丁程式要求的特定虛擬化技術（如 Oracle VM）支援 Oracle Clusterware、Grid Infrastructure 和 RAC。在虛擬化的環境中部署 RAC 時，很重要的一點是要滿足 RAC 虛擬化矩陣 中列出的支援要求，以確保成功實施受支援的部署。

安裝注意事項

• 請使用“真正”的root 使用者執行root.sh/rootupgrade.sh指令碼，不要使用sudo。當切換到root使用者時，請使用"su -" 或 "su - root"，以便提供完整的環境設定，而sudo，pbrun，"su root" 或 "su"或類似的工具則不會。推薦在"完整"的root環境下執行root.sh/rootupgrade.sh指令碼。請參考Document 1210883.1, Document 1235944.1, Document 1259874.1 和 Document 1315203.1獲得更多資訊。

• 建議在安裝 Oracle RAC 軟體時使用本地檔案系統，以允許使用滾動補丁升級，並避免出現單一故障點和其他故障。其它有關資訊，請參見 Oracle Real Application Clusters Environment 白皮書。請注意，不支援將 11gR2 Grid Infrastructure 安裝到叢集檔案系統上，請參見 Oracle Grid Infrastructure Installation Guide 11g Release 2 (11.2) for Linux 的 2.5.4 部分。
• 使用 cluvfy（叢集驗證實用程式）檢查叢集先決條件。在安裝 Oracle 軟體前，以及安裝期間的所有階段使用 cluvfy。安裝 11gR2 之前的版本時，務必下載最新版本的 cluvfy OTN。 Document 339939.1 和 Document 316817.1 中包含了有關本主題的更多相關資訊。

• 在執行 11gR2 之前的安裝時，建議在執行任何 RDBMS 或 ASM 主目錄安裝前應用補丁程式將 Clusterware 主目錄升級到所需的級別。例如，在安裝 10.2.0.1 RDBMS 前，先安裝 Clusterware 10.2.0.1 並使用補丁程式升級到 10.2.0.4。

• 在 11gR2 之前的環境中，出於維護和可用性的考慮（如獨立補丁程式和升級），將 ASM安裝到單獨的ORACLE_HOME 。為輕鬆升級到 11gR2，ASM 軟體所有者應與 Clusterware 軟體所有者相同。

• 從 11gR2 開始，所有補丁程式集都是可完全安裝的版本。例如，要安裝 11.2.0.2（11gR2 Patchset 1），可直接安裝 11.2.0.2，無需先安裝 11.2.0.1 再應用補丁程式升級到 11.2.0.2。對於 11gR2 Grid Infrastructure，所有補丁程式集升級都是 out-of-place 的。對於 11gR2 RDBMS，您可以執行 out-of-place 或 in-place升級，但建議使用 out-of-place 升級方法。更多資訊，請參考 Document 1189783.1.

• 如果安裝 Oracle Clusterware的使用者屬於多個作業系統使用者組，安裝程式將在叢集的所有節點上安裝Oracle Clusterware，並將軟體的組所有權設定為安裝使用者的當前活動組或主要組所有。因此，確保檔案 /etc/group 中列出的第一個組是當前活動組，或使用以下命令列選項呼叫 Oracle Clusterware 安裝，以強制安裝程式在對所有檔案設定組所有權時使用正確的組：runInstaller s_usergroup=current_active_group （Bug 4433140）

補丁安裝注意事項

本部分旨在為新實施和現有實施制定積極的修補策略。對於新實施，強烈建議您在開始測試時，對您的平臺應用最新的可用 Patchset 和適用的 Patch Set Update (PSU)。如果由於內部延遲或第三方應用認證或由於其他限制導致無法使用最新版本的 RDBMS，則仍建議 CRS 主目錄和 ASM（或 Grid Infrastructure）主目錄的 patch級別比 RDBMS 主目錄高。作為最佳實踐（有一些例外，請參見下面參考部分中的文件），Oracle Support 建議遵循以下說明：

• Clusterware（或 Grid Infrastructure）的補丁程式級別或版本必須高於或等同於 RDBMS 主目錄的補丁程式級別或版本（比較到版本號的第四位）。對於 11.2 之前的版本，Clusterware 的補丁程式級別或版本必須高於或等同於 ASM 和 RDBMS 主目錄的補丁程式級別或版本（比較到版本號的第四位）。

• 在應用補丁前，使用 opatch 檢查ASM 或 Clusterware 主目錄檔案系統上的可用空間，並使用 Document 550522.1 估計需要多少空間，以及如果應用補丁期間出現檔案系統被填滿的情況時該如何處理。
  

• Document 557934.1 提供了在 11gR2 之前的版本中給 Oracle Clusterware 應用補丁的基本概述，並介紹了 Oracle Clusterware 的元件是如何通過應用補丁獲得更新的。
  

• 如果要通過補丁程式將 Grid Infrastructure 從 11.2.0.1 升級到 11.2.0.2，請務必參考  Document 1312225.1 - "Things to Consider Before Upgrading to Grid Infrastructure 11.2.0.2" be reviewed。本文件介紹了所有必須遵守的先決條件和過程，以確保成功升級到 11.2.0.2。

• 制定積極的修補策略，對最新的已知問題防患於未然。應用最新的Patch Set Update（請參見 Document 850471.1中的介紹），並瞭解最新的推薦補丁（請參見 Document 756671.1中的介紹）。制定定期（如按季度）維護視窗的計劃，以應用最新推薦的 PSU 和補丁程式。

• 版本11.2.0.3的 GI 已經被加強，在引導時可以使用 broadcast 或 multicast(在230.0.1.0 或 224.0.0.251 網段)。但是，
  應用了 PSU5（11.2.0.3.5）版本的GI，如果多播（multicast）被禁用，您會遇到Bug 16547309。請注意，大多數的網路
  無需任何配置也能夠在網段224.0.0.251上支援多播，所以極大的減少了在版本 11.2.0.3.5 到 11.2.0.3.7 和 12.1.0.1上遇到這個
  問題的機率。請參考 Document 1212703.1 和 Document 1564555.1 獲得更多的資訊，已存在的補丁和解決方案。

  
  

升級注意事項

本部分實際上分為 2 個子部分。第一部分介紹 Clusterware、ASM 和 Grid Infrastructure 升級，第二部分介紹 RDBMS 升級。

Clusterware、ASM 和 Grid Infrastructure 升級注意事項

• 如要升級到 11.2.0.3或更高版本，請使用 ORAchk 的升級準備情況評估功能幫助執行升級前要求計劃和升級後驗證。

  有關其他詳細資訊，請參考 ORAchk 文件 Document 1

• 請使用“真正”的root 使用者執行root.sh/rootupgrade.sh指令碼，不要使用sudo。當切換到root使用者時，請使用"su -" 或 "su - root"，以便提供完整的環境設定，而sudo，pbrun，"su root" 或 "su"或類似的工具則不會。推薦在"完整"的root環境下執行root.sh/rootupgrade.sh指令碼。請參考Document 1210883.1, Document 1235944.1, Document 1259874.1 和 Document 1315203.1獲得更多資訊。

• 從 Oracle Clusterware 和 Oracle ASM 到 Grid Infrastructure 的升級應始終是 out-of-place 的。在 11g release 2 (11.2) 中，無法以 in-place 的方式將 Oracle Clusterware 和 Oracle ASM 升級。

• 如果現有 Oracle Clusterware 主目錄是共享主目錄，請注意，您可以對 Oracle Grid Infrastructure 使用非共享主目錄。

• 在開始升級 Grid Infrastructure 或升級到 Grid Infrastructure 前，務必參考以下文件（取決於目標版本）：
  
  Document 1312225.1 - Things to Consider Before Upgrading to Grid Infrastructure 11.2.0.2
  Document 1363369.1 - Things to Consider Before Upgrading to 11.2.0.3/11.2.0.4 Grid Infrastructure/ASM

  下面列出了上述文件的一些要點（詳細資訊請參考文件）：

• 驗證現有 Clusterware 和 ASM（或 Grid Infrastructure）配置是否正常
• 確保將所有必須的補丁程式應用於升級前的 Clusterware/ASM/Grid Infrastructure 主目錄，例如：
• 如果要從 GI 11.2.0.1 升級到 11.2.0.2，在嘗試升級前，必須將 Patch 9706490 應用於 GI 11.2.0.1 主目錄。
• 如要升級到 11.2.0.2，請驗證叢集私網上的多播功能。
• 在執行 rootupgrade.sh（或 root.sh）前，將 11.2.0.2 升級到最新的 GI PSU，詳細說明請參考 Document 1312225.1。

• 要將 10gR2 Clusterware 升級到 11g，根據 Oracle Upgrade Guide 11gR1  http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/upgrade.htm#BABCEGBC 所述，最低必須從版本 10.2.0.3 開始，11gR2 GI 平臺特定的文件中也介紹了類似的內容。該文件介紹了以下內容：
  
  
  注意： Oracle 新新增了先決條件檢查操作，以確保 Oracle Clusterware 10.2.0.x 版本為 10.2.0.3（或更高版）後，才能嘗試將其升級到 Oracle Clusterware 11g release 1 (11.1)。如果此檢查失敗，系統將指導您將 Oracle Clusterware 補丁程式集 10.2.0.3.0 或更高版應用於現有版本，然後才能進行升級。所有其他升級路徑和新的安裝不會受這些先決條件檢查操作的影響。

• 如果可能，可以對 Oracle Clusterware (CRS) 使用滾動升級，請參考 Document 338706.1。如需詳細的升級幫助，請參考與您的版本對應的“升級指南”：  Document 466181.1 10g Upgrade Companion 和 Document 601807.1 Oracle 11gR1 Upgrade Companion。 對於 11gR2，Clusterware 自身的升級是滾動升級（所有節點上的舊版本的程式必須處於執行狀態）；對於 ASM 11.1 和更高版本，ASM 升級也是滾動升級。ASM 11.1 之前的版本不是滾動升級。

• 如果計劃在 11gR2 Grid Infrastrucutre 環境中執行 11gR2 之前的資料庫，請檢視 Document 948456.1 : Pre 11.2 Database Issues in 11gR2 Grid Infrastructure Environment。

• 對於 11.2.0.2 之前的資料庫，11.2.0.2 HAIP 功能將不提供 NIC 冗餘或負載均衡，如果計劃在 11.2.0.2 Grid Infrastructure 上執行 11.2.0.2 之前的資料庫，必須使用第三方 NIC 冗餘解決方案，與 11.2.0.2 之前版本中的操作相同。

RDBMS 升級注意事項

• 請您務必檢視與您的目標版本對應的“升級指南”：
  
  Oracle 11gR2 Upgrade Companion Document 785351.1
  Oracle 11gR1 Upgrade Companion Document 601807.1
• 檢視與您的目標版本對應的“資料庫升級指南”：
  
  Oracle Database Upgrade Guide 11g Release 2 (11.2)
  Oracle Database Upgrade Guide 11g Release 1 (11.1)
• 升級到 11gR2 時，務必檢視 Best Practices for Upgrading to Oracle Database 11g Release 2 （升級到 Oracle Database 11g Release 2 的最佳實踐）。
• 如要升級到 11.2.0.3，請使用 RACcheck 的升級準備情況評估功能幫助執行升級前要求計劃和升級後驗證。有關其他詳細資訊，請參見 Document 1457357.1 RACcheck 11.2.0.3 Upgrade Readiness Assessment for additional details.

• 如果在決定使用哪種方法將資料庫升級到 11gR2 時需要幫助，請檢視 Upgrade Methods for Upgrading to Oracle Database 11g Release 2 （升級到 Oracle Database 11g Release 2 的升級方法）白皮書。

• 在將 Oracle Database 10g 升級到 11g 時，請檢視：
  http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-management-11gr2-133099.pdf

• 對於希望在升級資料庫時將停機時間縮到最短的使用者，可以考慮使用 logical standby 做過渡，請參考 Document 949322.1 : Oracle11g Data Guard: Database Rolling Upgrade Shell Script。

RAC 的資料庫配置注意事項

資料庫初始化引數注意事項

• 設定 PRE_PAGE_SGA=false。如果設定為 true，將大大增加建立資料庫連線所需的時間。如果客戶端投訴與資料庫的連線太慢，則考慮將此引數設定為 false，因為這樣做可以避免在程式啟動時對映整個 SGA，從而節省連線時間。
• 12c或者以上版本PRE_PAGE_SGA行為變化，參考 Doc ID 1987975.1

• 確保監控活動並行伺服器程式的數量並計算要應用於 PARALLEL_MIN_SERVERS 的平均值。可通過以下操作完成：

Select * from v$pq_syssstat;
Then: Get/save the value for row "Servers Highwater"

• 根據您的硬體情況優化 PARALLEL_MAX_SERVERS的值。最開始可以使用 (2 * ( 2 個執行緒 ) *(CPU_COUNT)) = 4 x CPU 計算，然後使用測試資料對更高的值重複測試。

• 考慮設定 FAST_START_PARALLEL_ROLLBACK。此引數可確定將有多少個程式用於事務恢復（在 redo 應用後執行）。為了確保在出現計劃外故障後仍能獲得高效的工作負載，優化事務恢復顯得非常重要。只要系統不大量佔用 CPU，最佳實踐是將此引數設定為值“HIGH”。這會導致 Oracle 使用四倍於 CPU 個數 (4 X cpu_count) 的並行程式進行事務恢復。此引數的預設值是“LOW”，或兩倍的 CPU 計數 (2 X cpu_count)。

• 將 FAST_START_MTTR_TARGET 設定為非零值（以秒為單位）。崩潰恢復將在此要求的時間範圍內完成。

• 在 10g 和 11g 資料庫中，不應再設定初始化引數 ACTIVE_INSTANCE_COUNT。這是因為 RACG 層不會考慮此引數。作為替代，您應該建立具有一個首選例項的服務。

• 對於 11gR2 之前的版本，將 PARALLEL_EXECUTION_MESSAGE_SIZE 從預設值（通常為 2048）增加到 8192。對於基於資料倉儲的系統（通過 PQ 傳輸大量資料），可以將其設定的更高。在版本 11gR2 中，PARALLEL_EXECUTION_MESSAGE_SIZE 的預設值是 16K，經證明，該值在大多數情況下都能夠滿足要求。

• 設定 OPTIMIZER_DYNAMIC_SAMPLING = 1 或確保您的資料庫物件都收集了統計資訊，因為 10g 動態取樣在執行 SQL 語句期間可以生成額外的 CR 緩衝區。

• 對於所有版本在Oracle 10.2.0.3 到 11.0.6.0之間的資料庫，LMON 程式可能會掛起，並且 Instance Membership Recovery (IMR) 無法驅逐掛起的例項。11.1.0.7 中已修正此問題。在 10gR2 中，可通過 bug 5259835 修復此問題。此增強已包含在 10.2.0.4.1 和更高版本的 PSU 中，在某些平臺上作為 10.2.0.3 和 10.2.0.5 都有的one-off補丁程式。對於 11.1.0.6.0，需要進行以下設定：
  
  _lm_rcvr_hang_check_frequency = 20
  _lm_rcvr_hang_allow_time = 70
  _lm_rcvr_hang_kill = true

效能優化注意事項

• 在所有資料庫系統中，不管是 RAC 還是單例項，最突出的效能改進往往都是通過使用傳統應用程式優化技術實現的。在 RAC 資料庫中，這些技術的優勢尤為顯著。

• 移除選擇性不好的索引。在 RAC 環境中，對於頻繁需要做插入操作的表，選擇性不好的索引的資料塊會頻繁在不同節點間傳輸，從而導致節點之間的塊爭用。

• 為了避免“checkpoint not complete”情況和頻繁的日誌切換影響效能，建議至少為每個執行緒建立 3 個 redo（重做）日誌組，並且 redo 日誌的大小應允許每 15 - 30 分鐘發生一次日誌切換。請參見 Document 147468.1 瞭解詳細資訊。

• 使用自動段空間管理 (Automatic Segment Space Management, ASSM)。ASSM 表空間可自動完成 freelist 管理，並且不需要（也不能）為在這些表空間中建立的各個表和索引指定 PCTUSED、FREELISTS 和 FREELIST GROUPS 儲存引數。請參見 Document 180608.1 瞭解其他詳細資訊。

• 增加 Insert 密集型應用的序列快取，可以改進由序列產生的索引值的例項關聯性。增加應用程式使用的序列和某些系統序列的快取可獲得更高的效能。使用約 10,000 或更大的快取值。另外，雖然使用 NOORDER 屬性最有效，但它並不能保證以請求順序生成序列號（實際上這是預設設定）。
  
  注意： 此建議不適用於 OLAP S$ 物件。如果重組這些物件，則 OLAP AW（包含所有多維資料）將損壞，因為它們嚴格依賴於值的順序。

• SYS.AUDSES$ 序列的預設設定是 20，這對於可從多個節點同時登入的 RAC 系統來說過低。請參考 Document 395314.1。 10.2.0.3 和更高版本中已修正此問題。

• 將 AWR 資料的保留期從 7 天增加到至少一個業務週期。使用 awrinfo.sql 指令碼來計算需要儲存在 AWR 中的資訊量，然後進行相應的設定。

• 對在 RAC 環境中設定緩衝區快取大小的建議與單節點相似，適用相同的優化程式。儘管實際記憶體要求取決於應用的工作負載，但一般建議是大約增加 10% 的緩衝區快取以適應擴充套件要求（例如：1 個節點 - 1000 個使用者，2 個節點 - 2000 個使用者）。

• 優化 DataGuard 以避免出現與叢集相關的等待。不正確的 DataGuard 設定可使 LOG FILE SYNC WAIT 和 GLOBAL CACHE LOG FLUSH TIME 變得較高。參考： http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-dataguardnetworkbestpr-134557.pdf and http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-recoverybestpractices-131010.pdf

資料庫網路注意事項

• 正確配置 Oracle Net Services 負載均衡以分發連線。負載均衡應該與 Workload Management 結合使用以提供最高可用性。工作負載服務的 CLB_GOAL 屬性應根據應用要求進行相應的配置。不同工作負載可能會有不同的負載均衡目標。請為每個服務使用 CLB_GOAL 單獨配置每個工作負載。

• 對於 11.2 之前的 listener，請確保 IPC 項存在，且此項列在所有 RAC  listener 的 listener.ora 地址列表的第一個。否則，可能會對 VIP 在公網介面出現故障時進行故障轉移所用的時長產生不利影響。請檢視 Document 403743.1 瞭解詳細資訊。

• 對於 11.2 之前的實施，建議從 ASM 主目錄（假設ASM在單獨的ORACLE_HOME下執行）執行 listener。這樣即可在帶有 listener的一個節點上註冊多個資料庫，且無需繫結到特定資料庫主目錄。

• 對於 11gR2，預設情況下將從 Grid Infrastructure 主目錄執行 listener。最佳實踐是不修改此配置。

• 對於 11gR2 環境，不應為 Grid Infrastructure 環境設定 TNS_ADMIN 環境變數，因為它會導致 oraagent 無法維護 listener配置檔案。TNS_ADMIN 也可能會影響 Clusterware 啟動、停止和監控 listener 的能力。

• 強烈建議為 11.2 資料庫使用 SCAN（用於 11.2 客戶端連線），因為這樣可以簡化客戶端連線，且在叢集新增和（或）刪除節點時無需修改資料庫連線字串。SCAN 也可以按照 Document 1058646.1 與 11.2 之前的客戶端整合。有關 SCAN 的更多資訊，請參見 Document 887522.1.

• 應該為listener配置 remote listener進行交叉註冊以支援工作負載重定向和負載均衡，從而允許在 RAC 叢集中分發服務連線請求。通過此配置，每個 listener都會知道是哪個例項在處理特定服務以及當前給定的資料庫例項上有多少負載。這讓客戶端可以在 listener之間對要在服務級別進行管理的工作負載進行連線請求的負載均衡。請參見 Document 728787.1 - How to Set Up Cross-Registration in RAC.

• 在 11gR2 之前，LOCAL_LISTENER 引數應該指向正在執行特定資料庫例項的本地系統 listener的 VIP地址。對於 11gR2，LOCAL_LISTENER 引數應設定為其預設值，以允許 oraagent 根據 OCR 中儲存的 listener配置正確設定引數。

• 一般而言，每個 RAC 節點（不包括 SCAN）僅需要一個 listener為給定叢集上執行的所有資料庫處理連線。如果需要或要求在每個叢集節點上使用多個 listener，則務必在 OCR 上註冊這些額外的 listener，以確保這些額外 listener的 HA 和正確管理。

• 建議建立額外資料庫服務以處理應用程式連線，而使用預設資料庫服務用於管理用途。這樣，管理員除了能夠輕鬆控制哪些應用程式連線到哪些例項，同時還可以靈活地實現諸如伺服器端 TAF、FAN、FCF 和執行時連線負載均衡等功能。有關這些服務的更多資訊，請參見“Oracle Real Application Clusters Administration and Deployment Guide 11g Release 2 (11.2)（Oracle Real Application Clusters 管理和部署指南 11g Release 2 (11.2)）”中的 Chapter 5。

• 利用面向連線的可用性功能，例如透明應用故障轉移 (Transparent Application Failover, TAF)、快速應用通知 (Fast Application Notification, FAN)、快速連線故障轉移 (Fast Connection Failover, FCF)、執行時連線負載均衡 (Runtime Connection Load Balancing, RCLB)。有關更多詳細資訊，請參見 Automatic Workload Management with Oracle Real Application Clusters （Oracle Real Application Clusters 自動工作負載管理）白皮書。
• 使用安全傳輸類 (Class of Secure Transport, OST) 限制例項註冊，從而防止資料庫向 listener進行未授權註冊。這樣可以避免 Oracle 安全警告 CVE-2012-1675 中釋出的問題。有關實施 COST  listener註冊的說明，可以在 Document 1340831.1 中找到。

一般資料庫注意事項

• 在 10gR2 和更高版本中，LMS 程式應該在實時排程類中執行。在某些情況下，我們注意到該操作由於 oradism 可執行檔案（儲存在 $ORACLE_HOME/bin 目錄中）的所有權和許可權不正確而被阻止。有關它的更多詳細資訊，請參見 Document 602419.1。

• 在給定叢集節點上執行的資料庫例項數量應受到限制，以便節點上的實時 LMS 程式總數不會超過建議的 CPU 數量 – 1。所有這些實時程式都可能使給定叢集節點超載，從而導致效能不佳和例項/節點驅逐。對於 LMS 程式數量（gcs_server_processes 引數），如果沒有 Oracle Support 的指導，不應修改其預設值。請參見 Document 558185.1 瞭解詳細資訊。

• 對於 11gR2（預設情況下禁用 NUMA）之前的版本，除非明確要求並已經過測試，請確保禁用 NUMA（Non Uniform Memory Architecture）功能，因為根據報告顯示，啟用 NUMA 後會出現問題。請參考 Document 759565.1 瞭解詳細資訊。

• 閱讀並遵循 XA 和 RAC 的最佳實踐指南，以避免XA 事務被拆分到多個RAC 例項的問題。請參考： http://www.oracle.com/technetwork/database/enterprise-edition/bestpracticesforxaandrac-128676.pdf 和 http://www.oracle.com/technetwork/database/clustering/overview/distributed-transactions-and-xa-163941.pdf

• 從執行資料庫的 RDBMS 主目錄中使用 SRVCTL 註冊並管理資料庫資源。資源註冊必須由擁有 RDBMS 軟體的 OS 使用者執行。

診斷和故障排除

一般注意事項

• 安裝並使用TFA 簡化診斷資訊的蒐集工作。Trace File Analyzer Collector (TFA)是一個診斷資訊蒐集工具，它適用於Oracle 叢集管理軟體（Clusterware/Grid Infrastructure），RAC和單例項資料庫系統。TFA 和 Oracle 叢集管理軟體中整合的資訊蒐集工具類似，但是它更加強大，而且能夠集中，自動管理蒐集到的診斷資訊。11.2.0.4 和 12.1.0.2 版本已經整合TFA功能，單機環境通過Document 1513912.1安裝。TFA提供下面功能：

  • 通過縮短蒐集時間的方式提高蒐集診斷資訊的效率

    • 只需要在一個節點執行一條命令就能夠完成整個叢集的診斷資訊蒐集

    • 全面蒐集診斷資訊，包含了Grid Infrastructure/Oracle Clusterware, ASM, RAC 和 OS 層面的日誌檔案和trace 檔案。

    • 蒐集到的資訊被彙總到單一節點，便於上傳

• • 節省10倍以上的資訊上傳時間
    • 診斷資訊能夠被隔離而且只有問題期間的診斷資訊會被清除
  • 降低SR解決時間
    • 正確的蒐集診斷能夠確保蒐集到全部的診斷資訊並且儘量避免support 工程師多次蒐集資訊。

• 檢視 Document 166650.1 Working Effectively with Global Customer Support。它將幫您瞭解作為 Oracle Support 客戶可用的支援流程、程式和資源。

• 主動安裝並執行 OSWATCHER (OSW) 以獲得 OS 資源使用情況。OSW 是用於收集作業系統和網路資訊，以幫助診斷效能問題的 UNIX shell 指令碼集合，這些指令碼被設計為連續執行並將這些指標儲存到歸檔目錄的 ASCII 檔案。儲存的歸檔資料量和收集頻率基於使用者在啟動 OSW 時設定的引數。強烈建議始終在叢集所有節點上安裝並連續執行 OSW。請參考 Document 301137.1。請確保為每個節點使用單獨的目錄以儲存 OSW 輸出。在 RAC 環境中使用 OSWatcher 時，每個節點必須將其輸出檔案寫入到單獨的歸檔目錄。不支援將所有節點的輸出放到同一個目錄下，因為這樣將導致 OSWg 工具崩潰。可以放到共享儲存上，但每個節點都需要一個單獨的歸檔目錄。

• 在Windows、Solaris 和 Linux 平臺上，可以使用 Cluster Health Monitor (CHM) 來跟蹤 OS 資源消耗並在整個叢集範圍內收集和分析資料。對於除了HP-UX 以外的所有平臺，CHM 會隨 Grid Infrastructure 11.2.0.3（及以上版本） 自動安裝。對於 Windows 和 Linux，可以 單獨下載 （如果未執行 11.2.0.2 GI）。如果您正在 Solaris 或 Linux 上執行 11.2.0.2 GI，您不能安裝單獨下載的 CHM。有關 CHM 的更多資訊，請參見 Document 1328466.1。

• 安裝使用技術支援工具包(TFA, ORAchk, OSWatcher, Procwatcher, SQLT, ORATOP, RDA) 可以有效提高問題分析處理的效率。
  技術支援工具包有關資訊請參考Document 1594347.1。

• 使用叢集 deinstall 工具來移除 CRS 安裝（如果需要）。clusterdeconfig 工具將移除並取消與 Oracle Clusterware 或 Oracle RAC 資料庫安裝關聯的所有軟體和共享檔案的配置。clusterdeconfig 工具將移除叢集中所有節點中的軟體和共享檔案。請參考 http://www.oracle.com/technology/products/database/clustering/index.html

Clusterware 和 Grid Infrastructure 診斷

• 在向 Oracle Support 發出與 Clusterware/Grid Infrastructure 問題相關的 SR 時，建議按照 Document 330358.1 中所述，上傳 diagcollection 實用程式的輸出。如果這是節點驅逐相關問題，還應該上傳 OSWatcher 或 CHM 資料（請參見上文的 OSWatcher 和（或）CHM 資訊）。在建立 SR 時提供此資料可以減少 SR 的週轉時間。有關 Grid Infrastructure 和 Clusterware 問題的診斷收集的其他資訊，請參見：
  Data Gathering for Troubleshooting CRS Issues Document 289690.1

• 在解決Clusterware 和 Grid Infrastructure問題時，以下文件通常非常重要：
  
  RAC: Frequently Asked Questions Document 220970.1
  11gR2 Clusterware and Grid Home - What You Need to Know Document 1053147.1
  Troubleshooting 11.2 Clusterware Node Evictions (Reboots) Document 1050693.1
  Troubleshooting 10g and 11.1 Clusterware Reboots Document 265769.1
  Data Gathering for Troubleshooting CRS Issues Document 289690.1
  
  注意： 有關更多資訊，請參見 Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure Document 1096952.1.

RAC 資料庫診斷

• 在向 Oracle Support 發出與 RAC 資料庫問題相關的 SR 時，請務必檢視 Document 289690.1 ，以確保在建立 SR 時收集並提供正確的診斷資訊。預先提供這些資訊可以減少 SR 的週轉時間。

• 在解決 RAC 相關的資料庫問題時，以下文件通常非常重要：
  
  RAC: Frequently Asked Questions Document 220970.1
  GC Lost Blocks Diagnostics Document 563566.1
  Troubleshoot ORA-29740 errors in a RAC Environment Document 219361.1
  11g How to Unpack a Package in to ADR Document 745960.1
  11g Quick Steps to Package and Send Critical Error Diagnostic Information to Support Document 443529.1
  Data Gathering for Troubleshooting RAC Issues Document 289690.1
  
  注意：有關更多資訊，請參見 Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure Document 1096952.1.

應用補丁診斷 (OPatch)

• 在解決 OPatch 相關的資料庫問題時，以下文件通常非常重要：
  
  Top OPATCH/PATCH Questions/Issues in Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environment Document 1339140.1
  
  注意： 有關 OPatch 的更多資訊，請參見 Master Note for OPatch Document 293369.1

參考