Page 10:
圖4為i.sql腳本的輸出。在14：30：43這一時刻，正在共有4個RAC實例在運行。
圖4：在進行故障注入測試時的RAC實例狀態(tài)
在圖5中，我們執(zhí)行io.sql腳本以顯示在14：23：13Oracle每秒在集群范圍內(nèi)正在執(zhí)行約9,424個物理I/O。這說明該集群已經(jīng)達到了一個飽和穩(wěn)定階段。
圖5：由gv$性能視圖報告的集群范圍內(nèi)的物理I/O
Page 11:
通過使用TotalStorage Performance Monitor，我們還可以輕松地獲得集群范圍內(nèi)I/O活動的概況圖。如圖6所示，在14：28：37 I/O速率為每秒9,985次傳輸。
圖6：節(jié)點3出現(xiàn)故障前一時刻的TotalStorage Performance Monitor
當工作負載達到穩(wěn)定狀態(tài)時，我們隨即突然斷掉該集群節(jié)點3的電源，模擬一次服務(wù)器故障。圖7顯示了來自一個RAC節(jié)點的PolyServe Matrix Server matrix.log文件屏幕截圖，說明在14：38：24節(jié)點3 (192.168.3.23)脫離PolyServe Matrix集群。
時鐘旋即開始計時，測量需要花費多長時間才能恢復OLTP處理。
4 TotalStorage Performance Monitor可以在左下角顯示監(jiān)控會話何時開始（14:26:59），并在右下角顯示監(jiān)控會話共運行了多長時間（1分鐘38秒）。此屏幕截圖于14:28:37截取。
Page 12:
圖7：正如PolyServe matrix.log文件中所報告的，該集群的節(jié)點3在14:38:24停機
此時，在OLTP處理恢復之前，需要進行3種形式的恢復：
指出下列事實非常重要：用于Linux和Windows的Oracle10g Release 2 Real Application Cluster，不再以任何方式與任何主機群件集成。取而代之的是，Oracle群件與主機群件并行運行。由于PolyServe Matrix Server是等級更低的主機群件5，以"內(nèi)核"模式執(zhí)行其集群狀態(tài)代碼，所以，它總能確定一個節(jié)點是否已經(jīng)死亡，并遠在Oracle Clusterware意識到該節(jié)點已經(jīng)死亡之前將其隔離。因為Oracle Clusterware沒有與主機群件集成，所以它必須自己判斷出一個節(jié)點是否已經(jīng)死亡。
用于確定某節(jié)點是否已死亡的方法取決于節(jié)點死亡的方式，但是為了簡化，該方法將基于節(jié)點與Oracle Cluster Synchronization Services (CSS)主機定期"登記聯(lián)系"的方案。若某RAC節(jié)點已經(jīng)在一段可調(diào)整的時間內(nèi)沒有"登記"了，則Oracle群件可以將其從RAC集群中排除6。錯過登記的容限是可調(diào)整的，默認值為60秒。在極極端系統(tǒng)負載條件下，若將此參數(shù)調(diào)得過低可能會導致錯誤出現(xiàn)，所以必須要保持一個平衡。這就是Oracle Clusterware的架構(gòu)方式，它與PolyServe Database Utility for Oracle無關(guān)。
由于PolyServe Matrix Server是以完全對稱的分布式方法鎖定管理，并以聯(lián)機模式完成某些恢復工作，所以，其全面恢復的部分過程極為簡潔。圖7說明了PolyServe可以在12秒內(nèi)（14:38:36）以聯(lián)機模式開始其恢復工作。聯(lián)機恢復一旦開始，即可啟動Oracle處理。
5 在所有Unix 群件（例如HACMP）上的Oracle10gR2都遵循此同一個模式。
6 Oracle以通知服務(wù)器重新啟動自己的方式將該服務(wù)器從RAC集群中驅(qū)逐。
Page 13:
圖8顯示在14:38:58，Oracle Clusterware確定節(jié)點3不再"活動"7。同時，Oracle Clusterware開始進行恢復。
圖8：正如ocssd.log文件中所報告的，Oracle Clusterware在14:38:58將節(jié)點3排除
最后，這些單獨的恢復水平指標并不是特別重要，重要的是恢復OLTP交易所花費的時間有多長。圖9顯示了一個在14:39:07執(zhí)行–i.sql腳本的會話的屏幕截圖，說明當時共有3個實例在線。截至此時，從節(jié)點3死亡開始時間已經(jīng)過去了63秒。事實上i.sql腳本的執(zhí)行時間是14:39:07，但是，這并不能準確地描述交易恢復的時間。事實上，查看TotalStorage Performance Monitor可以更有效地完成此任務(wù)。
圖9：恢復之后，gv$instance視圖報告說明共存在3個依然存在的節(jié)點。
7 Oracle Clusterware使用可調(diào)整的參數(shù)，以減少錯過登記的次數(shù)。您可以使用crsctl命令了解默認值， Linux 10.2.0.1版本的默認值為60。
Page 14:
圖10為14:39:068的屏幕截圖，顯示集群范圍內(nèi)RAC I/O請求數(shù)量已經(jīng)上升到每秒2,799次。在獲取此屏幕截圖之前，該數(shù)據(jù)庫至少已經(jīng)有一段時間可以使用了，因此才能回升到此I/O水平。
圖10：TotalStorage Performance Monitor顯示，在故障注入42秒內(nèi)，I/O已回升到每秒2,799次
圖10顯示I/O是在14:39:06開始回升。而另一方面，圖11顯示，在節(jié)點3死亡（14:39:339）的69秒內(nèi)，集群范圍內(nèi)的I/O速率已經(jīng)回升到每秒7,777個I/O，占4個節(jié)點取得的I/O速率的77%。所以，PolyServe能夠得到恢復，而Oracle能夠執(zhí)行其60秒CSS戰(zhàn)略，而OLTP I/O也在近69秒內(nèi)恢復到預計的3個節(jié)點的水平。毫無疑問，調(diào)整Oracle Clusterware的時間容限將加速此任務(wù)的完成。關(guān)鍵是在損失一個負載繁重的節(jié)點后，集群架構(gòu)能夠得到恢復。
8監(jiān)控會話于15:26:59開始啟動，此屏幕截圖是在該會話開始啟動12分鐘零6秒后–即14:39:06獲取的。
9監(jiān)控會話于15:26:59開始啟動，此屏幕截圖是在該會話開始啟動12分鐘46秒后–即14:39:33獲取的。
Page 15:
圖11：TotalStorage Performance Monitor顯示，I/O速率已回升到3個依然存在節(jié)點的預期值
故障恢復總結(jié)
通過在OLTP峰值吞吐率期間將集群中的一個節(jié)點斷電，此測試確定PolyServe Database Utility for Oracle中恢復Real Application Cluster的能力。不進行任何調(diào)整，用戶可以觀察到的唯一效果是PolyServe集群文件系統(tǒng)訪問存在12秒的停頓。從這一時刻僅過了30秒，物理I/O便恢復到故障前水平（每秒9,984次I/O）的約28%。如上所述，在損失節(jié)點3后的69秒內(nèi)，該集群所有3個依然運行的節(jié)點的OLTP吞吐率已經(jīng)恢復到故障前的水平。沒有對Oracle 群件進行任何專門調(diào)整，獲得這樣的結(jié)果已經(jīng)非常了不起了。最重要的是，當節(jié)點3出現(xiàn)故障時，與其余3個節(jié)點上的Oracle實例相連的會話并沒有中斷。它們依然能夠保持連接，而Oracle的恢復剛剛完成，它們的交易也隨之立即恢復。
Page 16；
按照需要動態(tài)、透明地進行擴展
決策支持系統(tǒng)（DSS）：輕量級掃描
按照配置，為了測試TotalStorage DS4500 SAN的性能情況，我們進行了Oracle Parallel Query Option (PQO)輕量級掃描測試。
圖文翻譯：
Light Weight Scan (LWS) Workload：輕量級掃描（LWS）工作負載
Scan of 2 Billion Rows (75GB)：掃描20億行（75GB）
Throughput (MB/sec)：吞吐率（MB/秒）
1 Node：1個節(jié)點
2 Nodes： 2個節(jié)點
Blades：刀片服務(wù)器
圖12.決策支持系統(tǒng)（DSS）：輕量級掃描（LWS）工作負載
輕量級掃描由對20億行的信用卡交易表進行的select count(*)組成。Parallel Query Option的I/O設(shè)置為直接路徑讀?。╠irect-path reads）。直接路徑讀取是1MB異步串行I/O操作，在PGA內(nèi)進行緩存，在個并行查詢從進程同時可以并行進行4或8個查詢。測試Oracle服務(wù)器在給定的硬件配置上能夠?qū)崿F(xiàn)的基本掃描吞吐率，Parallel Query輕量級掃描是最簡單的方法。
決策支持系統(tǒng)（DSS）：數(shù)據(jù)加載吞吐率
我們還測量了卡表的加載。該測試包括將20億pipe-delimited格式的數(shù)據(jù)記錄。從平面文件同步加載到卡表中。平面文件和目標卡表空間都駐留在PolyServe Matrix Serve集群文件系統(tǒng)中。單一節(jié)點測試包括8個SQL*Loader流，每個流將加載等量的平面文件數(shù)據(jù)。在4個節(jié)點中，每個節(jié)點都有2個并發(fā)SQL*Loader進程，且4個節(jié)點的每個節(jié)點都并發(fā)地執(zhí)行2個加載（loader）流。記錄長度約為54個字節(jié)。平面文件總共需要約110GB文件系統(tǒng)空間。一經(jīng)插入，該表需要約75GB空間。圖13顯示了一個集群文件系統(tǒng)，列出了8個平面文件，并顯示了其中一個文件的幾個最新記錄。
Page 17:
圖13.集群文件系統(tǒng)列表
LS20刀片數(shù)據(jù)加載時間展示了出色的可擴展性。圖14顯示，當LS20刀片服務(wù)器從1個節(jié)點擴展到4個節(jié)點使，大塊數(shù)據(jù)加載的擴展能力實現(xiàn)了82%。一個節(jié)點的插入速率為每秒564,972行，完成任務(wù)需要59分鐘…增加第二個節(jié)點并再次執(zhí)行測試，結(jié)果為每秒可以插入1,075,269行，完成任務(wù)需要31分鐘–擴展能力實現(xiàn)了95%。最后，在4個節(jié)點上執(zhí)行該測試，結(jié)果為每秒插入1,851,852行，完成任務(wù)需要18分鐘。
圖文翻譯：
Decision Support Sustem (DSS)Workload：決策支持系統(tǒng)（DSS）工作負載
Reduction in Completion Time：完成時間縮短
Time to Completion (Minutes)：完成時間（分鐘）
1 Node：1個節(jié)點
2 Nodes：2個節(jié)點
4 Nodes：4個節(jié)點
Blades：刀片服務(wù)器
圖14.隨著節(jié)點數(shù)量的增加，完成時間縮短
Page 18:
DSS測試亮點如下：
OLTP環(huán)境中的可擴展性
為了測試靈活數(shù)據(jù)庫集群架構(gòu)在OLTP環(huán)境中的可擴展性，我們在RAC集群的節(jié)點1到節(jié)點4執(zhí)行了前面描述的Order Entry工作負載。此工作負載極具爭議，其讀寫率為約65:35。沒有使用任何形式的分區(qū)（如工作負載、依賴于數(shù)據(jù)的請求路由等）。
圖15顯示測試得到的從1個節(jié)點（310 TPS）到4個節(jié)點（1081 TPS）的可擴展性為87%。
圖文翻譯：
On-Line Transaction Processing (OLTP) Workload：聯(lián)機交易處理（OLTP）工作負載
Transactions per Second：每秒處理的交易
1 Node：1個節(jié)點
2 Nodes：2個節(jié)點
3 Nodes：3個節(jié)點
4 Nodes：4個節(jié)點
Blades：刀片服務(wù)器
圖15. OLTP環(huán)境中的可擴展性
此工作負載耗盡CPU資源，但是對了解生成的I/O負載也是很重要的。如圖16所示，I/O曲線與吞吐率曲線極為相像，這也說明了工作負載始終在擴展。4個節(jié)點每秒的物理I/O操作數(shù)量峰值超過了6,500，顯而易見，LS20刀片服務(wù)器能夠處理大量OLTP I/O負載。
Page 19:
圖文翻譯：
On-Line Transaction Processing (OLTP) Workload：聯(lián)機交易處理（OLTP）工作負載
Physical I/O per Second：每秒處理的物理I/O數(shù)量
1 Node：1個節(jié)點
2 Nodes：2個節(jié)點
3 Nodes：3個節(jié)點
4 Nodes：4個節(jié)點
Blades：刀片服務(wù)器
圖16. 運行OLTP工作負載的I/O可擴展性
如圖16所示，在1個節(jié)點上測量的物理I/O數(shù)量為2,185，但是，LS20刀片并不局限于此。這是一個Oracle OLTP工作負載，在交易層處理從磁盤讀入數(shù)據(jù)時，包含了大量CPU密集型工作。無需運行生成I/O請求的全處理器密集型交易工作負載，即可測量一個服務(wù)器能夠處理的Oracle OLTP I/O的最大理論值。Orion測試工具包可以用于此類測量。
Oracle I/O工作負載(Orion)
Orion代表Oracle IO數(shù)量?？梢詮腛racle網(wǎng)站上獲得Orion10。簡言之，Orion工具包由在生產(chǎn)中運行Oracle時執(zhí)行I/O的實際服務(wù)器代碼組成。它還帶有一個驅(qū)動這些具有不同工作負載性質(zhì)（例如，大量連續(xù)掃描和隨機單塊傳輸）的I/O例程層。如需深入了解Orion測試工具包，請訪問Oracle網(wǎng)站上的Orion Web頁面。
為了在單一LS20節(jié)點上測試單節(jié)點Oracle服務(wù)器OLTP讀取吞吐率的理論最大值，我們在PolyServe Matrix Server集群文件系統(tǒng)中創(chuàng)建一個256GB的Orion文件，并通過直接I/O進行訪問。
Orion測試顯示，單一LS20刀片服務(wù)器每秒能夠從256GB文件中完成9,496次隨機的4KB傳輸。因為目標文件要比TotalStorage陣列緩存大得多，Orion測量的每秒9,496次操作的I/O延遲為10.12ms。此測說明，LS20中的I/O子系統(tǒng)完全能夠滿足完成OLTP I/O請求的要求–事實上，對于全Oracle Server的驅(qū)動程度比以往要高得多。
10 http://www.oracle.com/technology/software/tech/orion/index.html。
Page 20:
總結(jié)
IBM BladeCenter H、PolyServe Matrix Server和Oracle10g RAC相互協(xié)作，使靈活數(shù)據(jù)庫集群成為了一個支持多應用的強大平臺。本文中提供的FDC分析驗證了FDC架構(gòu)和技術(shù)，并證實了以下內(nèi)容：
Page 21:
©2006年，IBM及其他公司版權(quán)所有。
IBM Systems and Technology Group
Department 23U
Research Triangle Park, NC 27709
美國制造
4-06
保留所有權(quán)利。
如需有關(guān)安全和有效計算方面的最新信息，請定期訪問www.ibm.com/pc/safecomputing如需獲得適當產(chǎn)品的保修副本，請寫信至：Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203。IBM 對于有關(guān)第三方產(chǎn)品或服務(wù)（包括指定為ServerProven或ClusterProven的產(chǎn)品或服務(wù)）不作任何聲明或保證。
IBM、八條杠標志、xSeries、BladeCenter、BladeCenter H、ServerProven和TotalStorage是國際商業(yè)機器公司在美國和/或其他國家的商標或注冊商標。如需其他IBM商標清單，請訪問：http://www.ibm.com/legal/copytrade.shtml。
AMD和皓龍是Advanced Micro Devices公司的商標或注冊商標。
Oracle和Oracle10g Java是Oracle公司的商標或注冊商標。
UNIX是The Open Group在美國和/或其他國家的注冊商標。
PolyServe和PolyServe標志是PolyServe公司的商標。
其他公司、產(chǎn)品或服務(wù)的名稱可能是其他公司的商標或服務(wù)標志。
本文中有關(guān)非 IBM 產(chǎn)品的信息來自于那些產(chǎn)品的制造商或他們發(fā)布的聲明。IBM 尚未對這些產(chǎn)品進行測試，因此無法證實其性能、兼容性或任何與非 IBM 產(chǎn)品相關(guān)的聲明。有關(guān)非 IBM 產(chǎn)品性能的問題應該由那些產(chǎn)品的供應商解決。
IBM保留改變規(guī)范或其他產(chǎn)品信息的權(quán)利，無需另行通知。本文引用了 IBM 的產(chǎn)品或服務(wù)，但并不意味著 IBM 計劃在公司業(yè)務(wù)涉及的所有國家提供這些產(chǎn)品或服務(wù)。IBM是"按原樣"提供此出版物，并不提供任何明示或暗含的保證，包括對于適銷和適用于某種特定用途的暗示保證。有些國家或地區(qū)不允許在免責聲明中對于某些交易進行明示或暗示保證，所以，此聲明可能對您并不適用。
此出版物可能包含到第三方站點的鏈接，它們不受IBM的控制或由IBM維護。訪問任何第三方網(wǎng)站的風險由用戶自行承擔，且IBM不對這些網(wǎng)站上的任何信息、數(shù)據(jù)、觀點、建議或聲明的準確性和可靠性負責。IBM只是將這些鏈接作為一種方便條件提供，包含這種站點的鏈接并不意味著對其的認可。
本文僅用于提供信息的目的，對于由PolyServe公司提供或?qū)⒁峁┑娜魏诬浖?、軟件特性或服?wù)不提供任何明示或暗示的保證。PolyServe公司保留隨時更改本文的權(quán)利，無需另行通知，且不對其使用負責。此信息文檔中描述的特性可能目前尚未上市。如需有關(guān)特性和產(chǎn)品可用性的信息，請聯(lián)系PolyServe公司總部。
IBM TotalStorage IBM Server Proven
