尹人香蕉久久99天天拍,在教室伦流澡到高潮h强圩

圖4為i.sql腳本的輸出。在14：30：43這一時(shí)刻，正在共有4個(gè)RAC實(shí)例在運(yùn)行。

圖4：在進(jìn)行故障注入測(cè)試時(shí)的RAC實(shí)例狀態(tài)

在圖5中，我們執(zhí)行io.sql腳本以顯示在14：23：13Oracle每秒在集群范圍內(nèi)正在執(zhí)行約9,424個(gè)物理I/O。這說(shuō)明該集群已經(jīng)達(dá)到了一個(gè)飽和穩(wěn)定階段。

通過(guò)使用TotalStorage Performance Monitor，我們還可以輕松地獲得集群范圍內(nèi)I/O活動(dòng)的概況圖。如圖6所示，在14：28：37 I/O速率為每秒9,985次傳輸。

圖6：節(jié)點(diǎn)3出現(xiàn)故障前一時(shí)刻的TotalStorage Performance Monitor

當(dāng)工作負(fù)載達(dá)到穩(wěn)定狀態(tài)時(shí)，我們隨即突然斷掉該集群節(jié)點(diǎn)3的電源，模擬一次服務(wù)器故障。圖7顯示了來(lái)自一個(gè)RAC節(jié)點(diǎn)的PolyServe Matrix Server matrix.log文件屏幕截圖，說(shuō)明在14：38：24節(jié)點(diǎn)3 (192.168.3.23)脫離PolyServe Matrix集群。

時(shí)鐘旋即開(kāi)始計(jì)時(shí)，測(cè)量需要花費(fèi)多長(zhǎng)時(shí)間才能恢復(fù)OLTP處理。

4 TotalStorage Performance Monitor可以在左下角顯示監(jiān)控會(huì)話何時(shí)開(kāi)始（14:26:59），并在右下角顯示監(jiān)控會(huì)話共運(yùn)行了多長(zhǎng)時(shí)間（1分鐘38秒）。此屏幕截圖于14:28:37截取。

圖7：正如PolyServe matrix.log文件中所報(bào)告的，該集群的節(jié)點(diǎn)3在14:38:24停機(jī)

此時(shí)，在OLTP處理恢復(fù)之前，需要進(jìn)行3種形式的恢復(fù)：

指出下列事實(shí)非常重要：用于Linux和Windows的Oracle10g Release 2 Real Application Cluster，不再以任何方式與任何主機(jī)群件集成。取而代之的是，Oracle群件與主機(jī)群件并行運(yùn)行。由于PolyServe Matrix Server是等級(jí)更低的主機(jī)群件⁵，以"內(nèi)核"模式執(zhí)行其集群狀態(tài)代碼，所以，它總能確定一個(gè)節(jié)點(diǎn)是否已經(jīng)死亡，并遠(yuǎn)在Oracle Clusterware意識(shí)到該節(jié)點(diǎn)已經(jīng)死亡之前將其隔離。因?yàn)镺racle Clusterware沒(méi)有與主機(jī)群件集成，所以它必須自己判斷出一個(gè)節(jié)點(diǎn)是否已經(jīng)死亡。

用于確定某節(jié)點(diǎn)是否已死亡的方法取決于節(jié)點(diǎn)死亡的方式，但是為了簡(jiǎn)化，該方法將基于節(jié)點(diǎn)與Oracle Cluster Synchronization Services (CSS)主機(jī)定期"登記聯(lián)系"的方案。若某RAC節(jié)點(diǎn)已經(jīng)在一段可調(diào)整的時(shí)間內(nèi)沒(méi)有"登記"了，則Oracle群件可以將其從RAC集群中排除⁶。錯(cuò)過(guò)登記的容限是可調(diào)整的，默認(rèn)值為60秒。在極極端系統(tǒng)負(fù)載條件下，若將此參數(shù)調(diào)得過(guò)低可能會(huì)導(dǎo)致錯(cuò)誤出現(xiàn)，所以必須要保持一個(gè)平衡。這就是Oracle Clusterware的架構(gòu)方式，它與PolyServe Database Utility for Oracle無(wú)關(guān)。

由于PolyServe Matrix Server是以完全對(duì)稱的分布式方法鎖定管理，并以聯(lián)機(jī)模式完成某些恢復(fù)工作，所以，其全面恢復(fù)的部分過(guò)程極為簡(jiǎn)潔。圖7說(shuō)明了PolyServe可以在12秒內(nèi)（14:38:36）以聯(lián)機(jī)模式開(kāi)始其恢復(fù)工作。聯(lián)機(jī)恢復(fù)一旦開(kāi)始，即可啟動(dòng)Oracle處理。

5 在所有Unix 群件（例如HACMP）上的Oracle10gR2都遵循此同一個(gè)模式。

6 Oracle以通知服務(wù)器重新啟動(dòng)自己的方式將該服務(wù)器從RAC集群中驅(qū)逐。

圖8顯示在14:38:58，Oracle Clusterware確定節(jié)點(diǎn)3不再"活動(dòng)"⁷。同時(shí)，Oracle Clusterware開(kāi)始進(jìn)行恢復(fù)。

圖8：正如ocssd.log文件中所報(bào)告的，Oracle Clusterware在14:38:58將節(jié)點(diǎn)3排除

最后，這些單獨(dú)的恢復(fù)水平指標(biāo)并不是特別重要，重要的是恢復(fù)OLTP交易所花費(fèi)的時(shí)間有多長(zhǎng)。圖9顯示了一個(gè)在14:39:07執(zhí)行–i.sql腳本的會(huì)話的屏幕截圖，說(shuō)明當(dāng)時(shí)共有3個(gè)實(shí)例在線。截至此時(shí)，從節(jié)點(diǎn)3死亡開(kāi)始時(shí)間已經(jīng)過(guò)去了63秒。事實(shí)上i.sql腳本的執(zhí)行時(shí)間是14:39:07，但是，這并不能準(zhǔn)確地描述交易恢復(fù)的時(shí)間。事實(shí)上，查看TotalStorage Performance Monitor可以更有效地完成此任務(wù)。

圖9：恢復(fù)之后，gv$instance視圖報(bào)告說(shuō)明共存在3個(gè)依然存在的節(jié)點(diǎn)。

7 Oracle Clusterware使用可調(diào)整的參數(shù)，以減少錯(cuò)過(guò)登記的次數(shù)。您可以使用crsctl命令了解默認(rèn)值， Linux 10.2.0.1版本的默認(rèn)值為60。

圖10為14:39:06⁸的屏幕截圖，顯示集群范圍內(nèi)RAC I/O請(qǐng)求數(shù)量已經(jīng)上升到每秒2,799次。在獲取此屏幕截圖之前，該數(shù)據(jù)庫(kù)至少已經(jīng)有一段時(shí)間可以使用了，因此才能回升到此I/O水平。

圖10：TotalStorage Performance Monitor顯示，在故障注入42秒內(nèi)，I/O已回升到每秒2,799次

圖10顯示I/O是在14:39:06開(kāi)始回升。而另一方面，圖11顯示，在節(jié)點(diǎn)3死亡（14:39:33⁹）的69秒內(nèi)，集群范圍內(nèi)的I/O速率已經(jīng)回升到每秒7,777個(gè)I/O，占4個(gè)節(jié)點(diǎn)取得的I/O速率的77%。所以，PolyServe能夠得到恢復(fù)，而Oracle能夠執(zhí)行其60秒CSS戰(zhàn)略，而OLTP I/O也在近69秒內(nèi)恢復(fù)到預(yù)計(jì)的3個(gè)節(jié)點(diǎn)的水平。毫無(wú)疑問(wèn)，調(diào)整Oracle Clusterware的時(shí)間容限將加速此任務(wù)的完成。關(guān)鍵是在損失一個(gè)負(fù)載繁重的節(jié)點(diǎn)后，集群架構(gòu)能夠得到恢復(fù)。

8監(jiān)控會(huì)話于15:26:59開(kāi)始啟動(dòng)，此屏幕截圖是在該會(huì)話開(kāi)始啟動(dòng)12分鐘零6秒后–即14:39:06獲取的。

9監(jiān)控會(huì)話于15:26:59開(kāi)始啟動(dòng)，此屏幕截圖是在該會(huì)話開(kāi)始啟動(dòng)12分鐘46秒后–即14:39:33獲取的。

圖11：TotalStorage Performance Monitor顯示，I/O速率已回升到3個(gè)依然存在節(jié)點(diǎn)的預(yù)期值

通過(guò)在OLTP峰值吞吐率期間將集群中的一個(gè)節(jié)點(diǎn)斷電，此測(cè)試確定PolyServe Database Utility for Oracle中恢復(fù)Real Application Cluster的能力。不進(jìn)行任何調(diào)整，用戶可以觀察到的唯一效果是PolyServe集群文件系統(tǒng)訪問(wèn)存在12秒的停頓。從這一時(shí)刻僅過(guò)了30秒，物理I/O便恢復(fù)到故障前水平（每秒9,984次I/O）的約28%。如上所述，在損失節(jié)點(diǎn)3后的69秒內(nèi)，該集群所有3個(gè)依然運(yùn)行的節(jié)點(diǎn)的OLTP吞吐率已經(jīng)恢復(fù)到故障前的水平。沒(méi)有對(duì)Oracle 群件進(jìn)行任何專門(mén)調(diào)整，獲得這樣的結(jié)果已經(jīng)非常了不起了。最重要的是，當(dāng)節(jié)點(diǎn)3出現(xiàn)故障時(shí)，與其余3個(gè)節(jié)點(diǎn)上的Oracle實(shí)例相連的會(huì)話并沒(méi)有中斷。它們依然能夠保持連接，而Oracle的恢復(fù)剛剛完成，它們的交易也隨之立即恢復(fù)。

按照配置，為了測(cè)試TotalStorage DS4500 SAN的性能情況，我們進(jìn)行了Oracle Parallel Query Option (PQO)輕量級(jí)掃描測(cè)試。

Light Weight Scan (LWS) Workload：輕量級(jí)掃描（LWS）工作負(fù)載

圖12.決策支持系統(tǒng)（DSS）：輕量級(jí)掃描（LWS）工作負(fù)載

輕量級(jí)掃描由對(duì)20億行的信用卡交易表進(jìn)行的select count(*)組成。Parallel Query Option的I/O設(shè)置為直接路徑讀?。╠irect-path reads）。直接路徑讀取是1MB異步串行I/O操作，在PGA內(nèi)進(jìn)行緩存，在個(gè)并行查詢從進(jìn)程同時(shí)可以并行進(jìn)行4或8個(gè)查詢。測(cè)試Oracle服務(wù)器在給定的硬件配置上能夠?qū)崿F(xiàn)的基本掃描吞吐率，Parallel Query輕量級(jí)掃描是最簡(jiǎn)單的方法。

我們還測(cè)量了卡表的加載。該測(cè)試包括將20億pipe-delimited格式的數(shù)據(jù)記錄。從平面文件同步加載到卡表中。平面文件和目標(biāo)卡表空間都駐留在PolyServe Matrix Serve集群文件系統(tǒng)中。單一節(jié)點(diǎn)測(cè)試包括8個(gè)SQL*Loader流，每個(gè)流將加載等量的平面文件數(shù)據(jù)。在4個(gè)節(jié)點(diǎn)中，每個(gè)節(jié)點(diǎn)都有2個(gè)并發(fā)SQL*Loader進(jìn)程，且4個(gè)節(jié)點(diǎn)的每個(gè)節(jié)點(diǎn)都并發(fā)地執(zhí)行2個(gè)加載（loader）流。記錄長(zhǎng)度約為54個(gè)字節(jié)。平面文件總共需要約110GB文件系統(tǒng)空間。一經(jīng)插入，該表需要約75GB空間。圖13顯示了一個(gè)集群文件系統(tǒng)，列出了8個(gè)平面文件，并顯示了其中一個(gè)文件的幾個(gè)最新記錄。

LS20刀片數(shù)據(jù)加載時(shí)間展示了出色的可擴(kuò)展性。圖14顯示，當(dāng)LS20刀片服務(wù)器從1個(gè)節(jié)點(diǎn)擴(kuò)展到4個(gè)節(jié)點(diǎn)使，大塊數(shù)據(jù)加載的擴(kuò)展能力實(shí)現(xiàn)了82%。一個(gè)節(jié)點(diǎn)的插入速率為每秒564,972行，完成任務(wù)需要59分鐘…增加第二個(gè)節(jié)點(diǎn)并再次執(zhí)行測(cè)試，結(jié)果為每秒可以插入1,075,269行，完成任務(wù)需要31分鐘–擴(kuò)展能力實(shí)現(xiàn)了95%。最后，在4個(gè)節(jié)點(diǎn)上執(zhí)行該測(cè)試，結(jié)果為每秒插入1,851,852行，完成任務(wù)需要18分鐘。

Decision Support Sustem (DSS)Workload：決策支持系統(tǒng)（DSS）工作負(fù)載

圖14.隨著節(jié)點(diǎn)數(shù)量的增加，完成時(shí)間縮短

為了測(cè)試靈活數(shù)據(jù)庫(kù)集群架構(gòu)在OLTP環(huán)境中的可擴(kuò)展性，我們?cè)赗AC集群的節(jié)點(diǎn)1到節(jié)點(diǎn)4執(zhí)行了前面描述的Order Entry工作負(fù)載。此工作負(fù)載極具爭(zhēng)議，其讀寫(xiě)率為約65:35。沒(méi)有使用任何形式的分區(qū)（如工作負(fù)載、依賴于數(shù)據(jù)的請(qǐng)求路由等）。

圖15顯示測(cè)試得到的從1個(gè)節(jié)點(diǎn)（310 TPS）到4個(gè)節(jié)點(diǎn)（1081 TPS）的可擴(kuò)展性為87%。

On-Line Transaction Processing (OLTP) Workload：聯(lián)機(jī)交易處理（OLTP）工作負(fù)載

此工作負(fù)載耗盡CPU資源，但是對(duì)了解生成的I/O負(fù)載也是很重要的。如圖16所示，I/O曲線與吞吐率曲線極為相像，這也說(shuō)明了工作負(fù)載始終在擴(kuò)展。4個(gè)節(jié)點(diǎn)每秒的物理I/O操作數(shù)量峰值超過(guò)了6,500，顯而易見(jiàn)，LS20刀片服務(wù)器能夠處理大量OLTP I/O負(fù)載。

On-Line Transaction Processing (OLTP) Workload：聯(lián)機(jī)交易處理（OLTP）工作負(fù)載

如圖16所示，在1個(gè)節(jié)點(diǎn)上測(cè)量的物理I/O數(shù)量為2,185，但是，LS20刀片并不局限于此。這是一個(gè)Oracle OLTP工作負(fù)載，在交易層處理從磁盤(pán)讀入數(shù)據(jù)時(shí)，包含了大量CPU密集型工作。無(wú)需運(yùn)行生成I/O請(qǐng)求的全處理器密集型交易工作負(fù)載，即可測(cè)量一個(gè)服務(wù)器能夠處理的Oracle OLTP I/O的最大理論值。Orion測(cè)試工具包可以用于此類測(cè)量。

Orion代表Oracle IO數(shù)量。可以從Oracle網(wǎng)站上獲得Orion¹⁰。簡(jiǎn)言之，Orion工具包由在生產(chǎn)中運(yùn)行Oracle時(shí)執(zhí)行I/O的實(shí)際服務(wù)器代碼組成。它還帶有一個(gè)驅(qū)動(dòng)這些具有不同工作負(fù)載性質(zhì)（例如，大量連續(xù)掃描和隨機(jī)單塊傳輸）的I/O例程層。如需深入了解Orion測(cè)試工具包，請(qǐng)?jiān)L問(wèn)Oracle網(wǎng)站上的Orion Web頁(yè)面。

為了在單一LS20節(jié)點(diǎn)上測(cè)試單節(jié)點(diǎn)Oracle服務(wù)器OLTP讀取吞吐率的理論最大值，我們?cè)赑olyServe Matrix Server集群文件系統(tǒng)中創(chuàng)建一個(gè)256GB的Orion文件，并通過(guò)直接I/O進(jìn)行訪問(wèn)。

Orion測(cè)試顯示，單一LS20刀片服務(wù)器每秒能夠從256GB文件中完成9,496次隨機(jī)的4KB傳輸。因?yàn)槟繕?biāo)文件要比TotalStorage陣列緩存大得多，Orion測(cè)量的每秒9,496次操作的I/O延遲為10.12ms。此測(cè)說(shuō)明，LS20中的I/O子系統(tǒng)完全能夠滿足完成OLTP I/O請(qǐng)求的要求–事實(shí)上，對(duì)于全Oracle Server的驅(qū)動(dòng)程度比以往要高得多。

IBM BladeCenter H、PolyServe Matrix Server和Oracle10g RAC相互協(xié)作，使靈活數(shù)據(jù)庫(kù)集群成為了一個(gè)支持多應(yīng)用的強(qiáng)大平臺(tái)。本文中提供的FDC分析驗(yàn)證了FDC架構(gòu)和技術(shù)，并證實(shí)了以下內(nèi)容：

如需有關(guān)安全和有效計(jì)算方面的最新信息，請(qǐng)定期訪問(wèn)www.ibm.com/pc/safecomputing如需獲得適當(dāng)產(chǎn)品的保修副本，請(qǐng)寫(xiě)信至：Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203。IBM 對(duì)于有關(guān)第三方產(chǎn)品或服務(wù)（包括指定為ServerProven或ClusterProven的產(chǎn)品或服務(wù)）不作任何聲明或保證。

IBM、八條杠標(biāo)志、xSeries、BladeCenter、BladeCenter H、ServerProven和TotalStorage是國(guó)際商業(yè)機(jī)器公司在美國(guó)和/或其他國(guó)家的商標(biāo)或注冊(cè)商標(biāo)。如需其他IBM商標(biāo)清單，請(qǐng)?jiān)L問(wèn)：http://www.ibm.com/legal/copytrade.shtml。

AMD和皓龍是Advanced Micro Devices公司的商標(biāo)或注冊(cè)商標(biāo)。

Oracle和Oracle10g Java是Oracle公司的商標(biāo)或注冊(cè)商標(biāo)。

UNIX是The Open Group在美國(guó)和/或其他國(guó)家的注冊(cè)商標(biāo)。

其他公司、產(chǎn)品或服務(wù)的名稱可能是其他公司的商標(biāo)或服務(wù)標(biāo)志。

本文中有關(guān)非 IBM 產(chǎn)品的信息來(lái)自于那些產(chǎn)品的制造商或他們發(fā)布的聲明。IBM 尚未對(duì)這些產(chǎn)品進(jìn)行測(cè)試，因此無(wú)法證實(shí)其性能、兼容性或任何與非 IBM 產(chǎn)品相關(guān)的聲明。有關(guān)非 IBM 產(chǎn)品性能的問(wèn)題應(yīng)該由那些產(chǎn)品的供應(yīng)商解決。

IBM保留改變規(guī)范或其他產(chǎn)品信息的權(quán)利，無(wú)需另行通知。本文引用了 IBM 的產(chǎn)品或服務(wù)，但并不意味著 IBM 計(jì)劃在公司業(yè)務(wù)涉及的所有國(guó)家提供這些產(chǎn)品或服務(wù)。IBM是"按原樣"提供此出版物，并不提供任何明示或暗含的保證，包括對(duì)于適銷和適用于某種特定用途的暗示保證。有些國(guó)家或地區(qū)不允許在免責(zé)聲明中對(duì)于某些交易進(jìn)行明示或暗示保證，所以，此聲明可能對(duì)您并不適用。

此出版物可能包含到第三方站點(diǎn)的鏈接，它們不受IBM的控制或由IBM維護(hù)。訪問(wèn)任何第三方網(wǎng)站的風(fēng)險(xiǎn)由用戶自行承擔(dān)，且IBM不對(duì)這些網(wǎng)站上的任何信息、數(shù)據(jù)、觀點(diǎn)、建議或聲明的準(zhǔn)確性和可靠性負(fù)責(zé)。IBM只是將這些鏈接作為一種方便條件提供，包含這種站點(diǎn)的鏈接并不意味著對(duì)其的認(rèn)可。

本文僅用于提供信息的目的，對(duì)于由PolyServe公司提供或?qū)⒁峁┑娜魏诬浖④浖匦曰蚍?wù)不提供任何明示或暗示的保證。PolyServe公司保留隨時(shí)更改本文的權(quán)利，無(wú)需另行通知，且不對(duì)其使用負(fù)責(zé)。此信息文檔中描述的特性可能目前尚未上市。如需有關(guān)特性和產(chǎn)品可用性的信息，請(qǐng)聯(lián)系PolyServe公司總部。

^{<blockquote id="5lgus"></blockquote>}

多易

相關(guān)推薦

近期文章

熱門(mén)標(biāo)簽