Oracle 真正應用集群 (RAC) 是 RDBMS 市場中的最佳數據庫集群。Oracle RAC 的配置選項和特性為公司提供設計其高可用性解決方案的廣泛的靈活性。但是，如何使用所有配置選項、特性和靈活性成功地實施？
本文是定義、設計和提供成功 Oracle RAC 項目的指南。它詳細介紹了減少風險和增加成功實施機會的詳細步驟。此外，它還突出了您在實施 Oracle RAC 項目過程中可能會犯的錯誤，並提供了避免這些錯誤的建議。
盡管這篇文章側重於 Oracle RAC，但下列步驟對許多種 Oracle 實施項目均試用。（注意，本指南僅用於提供信息，無論在何種情形下，您都不可將其視為咨詢服務。）
下面我們開始吧！
確定需求
成功實施 Oracle RAC 的第一個重要階段是確定項目的真實目標。“確定 需求”一步涉及識別和記錄項目實施階段要提供的特性和功能。
在實施 Oracle RAC 過程中，您還要經常核對這些需求。將需求記錄成文將有助於實施 Oracle RAC 項目。否則，您將發現該項目難以管理，這是因為在項目實施過程中會不斷出現意料不到的新問題。
避免錯誤的方法 1： 確保關鍵業務和技術人員積極地參加項目需求的確定。明確地將所有需求傳達給項目負責人，包括關鍵的管理人員、技術人員以及最終用戶。
第 1 步 — 確定項目范圍
“確定需求”階段的第一步就是確定項目范圍。項目范圍是用於論證項目業務需求的一系列細項，它說明了項目的可交付成果。項目范圍有時也稱為“業務需求”。
要確定項目范圍，請回答下列問題：
以下是一個詳細說明一個 Oracle RAC 示例的高級目標的項目范圍文檔。
理由
我們實施 Oracle RAC 是為了使我們的應用程序可伸縮和高度可用，以及為我們的客戶提供更可靠的服務。
目標/可交付產品
該項目的最終產品將是一個新的 Oracle RAC 系統，它支持在我們的服務等級要求文檔中詳細規定的服務等級*。*見下面的附件
項目日程限制
該項目必須在 2006 8 月 前完成。
項目成本限制
項目成本應不超過 $XXX,XXX。
避免錯誤的方法 2： 努力使項目目標量化。您將能重新核對這些目標，掌握整個項目的完成情況。量化目標的工作包括記錄項目日程和成本限制。
第 2 步 – 確定項目團隊
確定項目團隊就要確定為項目制定交付目標的人和願意完成項目方案中的任務的人。這些人可能來自組織的多個部門，如決策人員、業務分析人員和技術人員。
下表是典型 Oracle RAC 項目的人員組成，並列明了他們的職能和完成項目所采取的步驟。
角色
職責
參與階段
Oracle RAC–具體任務
決策人
IT 經理
項目經理
數據庫管理員
網絡管理員
系統管理員
應用程序開發人員
測試人員
應用程序用戶
Oracle RAC 項目團隊成員的職責會因地制宜，這取決於場地的大小和系統需求。
在組建該項目團隊的時候，可能無法找到最合適的人員，因此，您只能找到可用的人員。在這種情況下，對項目團隊成員進行適當的技術培訓可以降低實施風險。技術培訓通常可以降低項目風險和較高質量地完成項目。
避免錯誤的方法 3： 如果新的 Oracle RAC 系統要取代已有的舊系統，需要讓對舊系統經驗豐富的人也參與。吸納這些團隊成員將有助於確保滿足所有項目需求。
第 3 步 – 確定服務等級需求
“需求確定”階段的第三步是確定服務等級需求。服務等級需求是指期望 Oracle RAC 項目實施支持的服務等級。這些需求包含預期的服務等級和操作需求，並提供處理延期和失敗的指導原則。
服務等級需求可以分為兩類：服務等級需求和操作需求。
服務等級需求幫助 Oracle RAC 技術實施與項目的范圍（項目的業務目標）保持一致。確定服務等級需求應先從分析現有系統的需求開始。分析包括查看現有系統的操作、技術以及支持的程序和文檔。
可以通過回答諸如以下問題進一步確定服務等級需求
這些問題的回答通常可組成一個分級、分層的服務等級需求表，該表定義了不同的服務等級。
下面是一個服務等級表示例。具體的服務等級和層數取決於您的組織數和業務部門數。
層
安全等級描述
性能
可用性
所需解決方法
5
正常操作
系統響應正常。
系統 100% 可用。所有中斷均正確排定。
無
4
安全等級 4：
問題微不足道，影響很小或無影響
性能比所要求的基准低 10%-30%。
應用程序應用程序功能的 90%-95% 可用。
必須在五天內解決
3
安全等級 3：
問題很小，幾乎沒有影響
性能比所要求的基准低 30%-50%。
應用程序應用程序功能的 85%-90% 可用。
必須在三天內解決
2
安全等級 2：
問題需要關注，可感受到有影響
性能比所要求的基准低 50%-70%。
應用程序應用程序功能的 80%-85% 可用。
必須在一天內解決
1
安全等級 1：
問題很嚴重，對業務有嚴重影響
性能比所要求的基准低 70% 或更低。
應用程序應用程序功能的 75% 以下可用。
必須在三小時內解決
操作需求規定了維護 Oracle RAC 系統和滿足以上定義的服務等級需求所需的程序。通常，操作需求包括排定的維護中斷、系統啟動和關閉、系統備份、Oracle RAC 系統可用性、故障切換程序以及災難恢復計劃的信息。
可以通過回答諸如以下問題確定操作需求
以下是一個 Oracle RAC 操作需求列表示例。
排定的維護中斷
留出每個月的最後一個周末來進行 Oracle RAC 系統維護操作。中斷時間不會超過 56 小時（從星期五晚上開始）。這些中斷專門留給那些無法“聯機”執行的維護操作。
系統備份
完整備份將在周末聯機執行，而在一周其他天的晚上則執行累積備份。磁帶上保存著相當於四周的備份，而磁盤上則保存相當於一天的備份。
故障切換程序
所有應用程序會話在發生單節點故障時都應可切換到可用的 Oracle RAC 節點上。在發生一個局部災難，使所有 Oracle RAC 節點都不可用時，該處的備用環境應在三個小時內聯機。
災難恢復程序
當災難遍及整個場所時，場所外的備用環境將在三個小時內聯機。
系統容量
系統應支持當前的用戶負載（以及兩年內的用戶數量預期增長）以及當前的應用程序。在系統無法滿足用戶負載要求時，就需要增加 Oracle RAC 節點。處理器、內存和存儲需求將基於從運行在現有硬件上的當前應用程序的性能來確定。
避免錯誤的方法 4： 獲得系統最終用戶、客戶和操作人員對服務等級和操作需求的認可和官方批准。這包括就性能、可用性以及對系統失敗的適當反應達成一致。
第 4 步 – 確定項目日程
“確定需求”階段的最後一步就是確定項目日程。由於需要確保有足夠的時間建立 Oracle RAC 解決方案來滿足以上定義的所有需求，因此日程安排對項目成敗至關重要。
日程安排涉及構建系統、為每個任務分配時間、以最優的順序排列任務等所有任務的細節。
避免錯誤的方法 5： 在安排項目日程的過程中，應努力使每個項目成員清楚所有時間限制（見“第 1 步”）。征詢每個團隊成員的意見，准確評估和規劃項目日程。
有時，可以在項目日程中同時執行多個任務。巧妙地並行安排任務通常會按時完成項目並節省項目成本。
以下是一個高級 Oracle RAC 日程示例。它展示了在 Oracle RAC 部署中經常執行的任務。
任務名稱
存在期間
開始時間
結束時間
前置任務
1
服務器硬件配置
2 天
2005 年 12 月 1 日星期四
2005 年 12 月 2 日星期五
2
共享存儲配置
1 天
2005 年 12 月 1 日星期四
2005 年 12 月 1 日星期四
3
OS 安裝
1 天
2005 年 12 月 5 日星期一
2005 年 12 月 5 日星期一
1
4
網絡配置
1 天
2005 年 12 月 6 日星期二
2005 年 12 月 6 日星期二
3
5
Oracle 數據庫軟件安裝
1 天
2005 年 12 月 7 日星期三
2005 年 12 月 7 日星期三
4
6
數據庫構建
2 天
2005 年 12 月 8 日星期四
2005 年 12 月 9 日星期五
5
7
數據加載
5 天
2005 年 12 月 12 日星期一
2005 年 12 月 16 日星期五
6
8
單元測試
2 天
2005 年 12 月 19 日星期一
2005 年 12 月 20 日星期二
7
9
壓力/集成測試
5 天
2005 年 12 月 21 日星期三
2005 年 12 月 29 日星期四
8
10
故障切換測試
2 天
2005 年 12 月 30 日星期五
2005 年 1 月 3 日星期二
9
11
備份與恢復測試
19 天
2006 年 12 月 12 日星期三
2005 年 1 月 4 日星期三
5
12
系統集成
5 天
2006 年 1 月 5 日星期四
2006 年 1 月 11 日星期三
11
…
…
一個相對詳細的項目日程可以使 Oracle RAC 團隊跟蹤項目的進度，主動對日程遲延做出回應。當需要更改日程時，一定要確保完全記錄了所有更改。最初的項目日程和該更改報告為以後項目日程的制定提供了重要的參考。
避免錯誤的方法 6： 利用可同時執行的多個任務。在上述的項目日程中，注意 Task #11 是如何與 Task #7 到 Task #10 同時運行的。
在確定和記錄了項目范圍、項目團隊、服務等級需求以及項目日程後，采用一個強有力的更改控制機制。仔細管理對需求的任意更改，把成本控制在預算內，使項目按日程進行。
技術架構設計和構建
成功部署 RAC 實施的第二個主要階段是確定和實施 Oracle RAC 部署的技術架構規范。技術架構描述了將組成新系統的硬件、軟件和配置的詳細情況。由於大多數 Oracle RAC 實施集中在從單實例環境移植到 Oracle RAC 實例環境，而沒有重新設計他們的應用程序和數據庫，因此您將在該階段中設計和構建 Oracle RAC 環境。
下列步驟解釋了如何將需求轉化為可用的設計。
第 1 步 – 確定硬件和軟件規范
該步驟包括了解上面定義的服務等級需求和操作需求，然後把這些需求轉化為硬件和軟件規范。它還考慮了硬件的兼容性，特定的操作系統要求以及 Oracle RAC 特定的軟件需求。
使用下面的“硬件/軟件注意事項表”組為核對單，用於記錄在本步驟中決定。對於您的個別實施，填寫您項目使用的真正硬件和軟件。
填寫該表時，回答以下問題
避免錯誤的方法 7： 確保 Oracle RAC 項目團隊知道組成 Oracle RAC 系統每個組件的功能和特性，以及所有組件已通過認證，可以一起使用。您可以通過適當的技術培訓和概念驗證測試來降低 Oracle RAC 項目的風險。
組件
滿足項目需求？
滿足 OS 需求？
滿足 Oracle RAC 需求？
與其他硬件/軟件組件兼容？
硬件組件
服務器（節點數）
處理器（每節點 CPU 數）
內存（每節點 GB 數）
HBA
網卡（每節點網卡數）
本地磁盤（每節點 GB 數）
SAN/共享存儲（GB）
軟件組件
操作系統
硬件驅動器
卷管理/多路徑軟件
*包括 ASM、RAW 或 OCFS 卷管理決定
Oracle Clusterware/Oracle 數據庫軟件
Oracle 客戶端軟件
避免錯誤的方法 8： 如果要移植到一個全新的硬件和/或軟件平台，那一定要測試一下您的應用程序。更換平台可能需要更多的處理器或內存，以滿足服務等級需求。
第2 步 – 執行規范
填完上述核對單後，就要搭建 Oracle RAC 環境了。
這些任務包括：
RAC 系統測試
Oracle RAC 測試策略應至少包括四種測試：概念驗證測試、單元測試、集成測試以及負載測試。
該測試策略不是一個獨立於以上階段單獨執行的功能，而是一個集成到了確定、設計、構建等階段中的一個過程。
該部分著重強調四種測試，並確定每種測試所對應的項目階段。
概念驗證測試
概念驗證測試是對概念可行性的測試。它可以是新技術、新軟件架構或新硬件的測試。概念驗證測試使項目團隊可以測試項目決策的有效性，從而使他們可以快速做出有關項目方向的重要決策。概念驗證測試通常在“服務級別需求”和“技術架構設計和構建”步驟中執行。
測試
說明
項目階段
好處
概念驗證測試
確認項目決策的有效性，尤其是硬件和軟件決策的有效性
使項目團隊可以做出大是大非的項目決策
單元測試
單元測試包含單一硬件或軟件組件測試以及單一應用程序或應用程序模塊測試。這些孤立的測試確定單一組件或模塊是否按執行要求運行。
Oracle 10g 第 2 版包括一個稱為 Cluster Verification Utility (CVU) 的驗證實用程序，它是一個用於對 Oracle RAC 節點的硬件和軟件配置進行測試的工具。可以使用該實用程序驗證 Oracle RAC 節點的配置、檢查操作系統以及檢查網絡設置。
單元測試的一個重要元素就是“破壞性測試”的引入。測試人員通過破壞性測試模擬異常活動以及試圖破壞系統。Oracle RAC 環境中的一個破壞性測試示例為故意破壞 Oracle Cluster Registry (OCR)，然後執行恢復系統所需的步驟。像這樣的測試會讓項目成員發現系統的薄弱環節，從而做好應對准備。
測試
說明
項目階段
好處
單元測試
測試個別硬件、軟件和應用程序組件，加入“破壞性測試”發現系統的薄弱環節
“技術架構構建”任務：
確認單個組件和模塊正常運行
集成測試
集成測試包括確認多個硬件、軟件或應用程序模塊可共同運行。集成測試確認系統是否按規定運行。
測試
說明
項目階段
好處
集成測試
測試多個硬件、軟件以及應用程序組件共同運行
“技術架構構建”任務：
確認集成的組件和模塊可共同運行
壓力測試
壓力測試也稱為負載測試或系統測試，是一個模擬動態生產負載的端到端測試。它用於確定系統是否可以承受生產使用等級、是否滿足服務等級需求，以及收集性能數據。它還用於預測當前和未來的使用容量。通常在上述測試返回肯定的結果時以及完全配置硬件、軟件和應用程序組件後才執行壓力測試。由於它代表一個重要的項目裡程碑，因此將其視為一個獨立的項目階段。
測試
說明
項目階段
好處
壓力測試
模擬系統上的一個動態生產負載
壓力測試
確認系統已可用於生產
避免錯誤的方法 9： 測試會耗費大量時間和金錢。對比執行測試所需的資源和再生產階段發生系統故障的風險，仔細權衡測試方案的長處和短處。
操作就緒
什麼時候可以使用新系統？
前述項目階段及其相關的步驟簡化了新系統可用性的測試。盡管完整的核對單取決於您具體的站點，但以下通用大綱可以幫助您定義、設計、測試您的 Oracle RAC 實施。
操作就緒的確定取決於已完成的任務熟、項目日程中完成任意未完成任務所剩的時間、新系統當前狀態下的穩定性。它還取決於已滿足的項目需求數。
下面是一個包含本文所述的所有事實階段和步驟地一個詳細的項目方案。它包括一個集成的測試方案和一個“啟動必需？”列，幫助您確定是否確實需要該特定項來使系統聯機 — 或是否在系統啟動後將該特定項聯機。
任務
任務說明
啟動必需？
完成？
定義
確定需求
確定項目范圍
確定項目的高級業務目標
確定項目團隊
確定項目團隊
確定服務等級需求
確定服務等級需求
確定操作需求
確定操作需求
概念驗證測試
使項目團隊初步熟悉所涉及的技術，幫助確定項目日程以及為“設計和構建”階段做好准備
確定項目日程
確定項目日程
設計和構建
技術架構設計和構建
硬件和軟件規范
確定項目要使用的硬件和軟件組件
概念驗證測試
驗證硬件和軟件組件的選擇
服務器硬件配置
構建服務器硬件
操作系統配置
安裝和配置操作系統
服務器單元測試
測試節點單元（在安裝 Oracle 數據庫前使用 CVU 預驗證服務器配置）
操作系統單元測試
測試 OS 單元（在安裝 Oracle 數據庫軟件前使用 CVU 驗證 OS 配置）
網絡單元測試
測試節點單元（在安裝 Oracle 數據庫前使用 CVU 驗證網絡配置）
Oracle 軟件配置
安裝和配置 Oracle 數據庫軟件
集成測試
確認所有硬件和軟件組件可正常運行，例如通過創建一個 Oracle RAC 測試數據庫
操作任務
為壓力測試和生產使用准備好系統
集成測試
確認應用程序在新 Oracle RAC 環境中正常運行
測試
Oracle RAC 系統測試
壓力測試
模擬 Oracle RAC 系統上的生產負載
總結
在前三個項目階段中，您確定了核心的項目目標、確定了項目需求、把需求轉換為規范、創建了測試方案。此外，您還創建了確定 Oracle RAC 實施的操作就緒性的標准。所有這些加在一起就是您的 Oracle RAC 實施項目方案。
該方案變成了一個無價的工具，幫助您實現您的最終目標，使您可以一路預測任意問題。使用這樣的方案可以 確保成功的 Oracle RAC 實施 — 在預算內按時交付。
