OLTP、OLAP、VDI和SPC-1是當(dāng)前性能評(píng)估中常見(jiàn)的三類(lèi)業(yè)務(wù)場(chǎng)景。SPC-1是業(yè)界通用的隨機(jī)IOPS型的IO模型，在不清楚實(shí)際業(yè)務(wù)類(lèi)型的條件下，常用此模型來(lái)進(jìn)行性能評(píng)估。四種模型的簡(jiǎn)單IO特征如下表所示。
Oracle 數(shù)據(jù)庫(kù)是典型的的OLTP業(yè)務(wù)模型，在核心 IT 業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛，OLTP類(lèi)型的 Oracle 數(shù)據(jù)庫(kù)往往承載著企業(yè)核心的業(yè)務(wù)支撐系統(tǒng)，如 ERP、CRM 等，其性能和可用性出現(xiàn)問(wèn)題，本章重點(diǎn)剖析OLTP和OLAP主要區(qū)別、規(guī)劃方法及基于Oracle的最佳實(shí)踐。OLTP與OLAP的介紹
數(shù)據(jù)處理大致可以分成兩大類(lèi)：聯(lián)機(jī)事務(wù)處理OLTP（On-line transaction processing）、聯(lián)機(jī)分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢(xún)結(jié)果。
OLTP應(yīng)用的IO特征
OLTP通常是指事務(wù)性非常高的在線系統(tǒng)，以小的事務(wù)以及小的查詢(xún)?yōu)橹?，評(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的Transaction以及Execute SQL的數(shù)量。在這樣的系統(tǒng)中，單個(gè)數(shù)據(jù)庫(kù)每秒處理的Transaction往往超過(guò)幾百個(gè)，或者是幾千個(gè)，Select語(yǔ)句的執(zhí)行量每秒幾千甚至幾萬(wàn)個(gè)。典型的OLTP系統(tǒng)有電子商務(wù)系統(tǒng)、銀行、證券等：- 訪問(wèn)磁盤(pán)數(shù)據(jù)的位置非常隨機(jī)
- 至少30％的數(shù)據(jù)是隨機(jī)寫(xiě)操作
- 聯(lián)機(jī)重做日志是寫(xiě)入非常頻繁的順序?qū)?/span>
1、業(yè)務(wù)特征：每個(gè)事務(wù)的讀，寫(xiě)，更改涉及的數(shù)據(jù)量非常小，同時(shí)有很多用戶(hù)連接到數(shù)據(jù)庫(kù)，使用數(shù)據(jù)庫(kù)，要求數(shù)據(jù)庫(kù)有很快的響應(yīng)時(shí)間，通常一個(gè)事務(wù)在幾秒內(nèi)完成，時(shí)延要求一般在10-20ms。
2、IO特征：針對(duì)DATA LUN，隨機(jī)小IO，IO大小主要為8KB（IO大小與數(shù)據(jù)庫(kù)的Block塊大小一致），讀寫(xiě)比約為3:2，讀全隨機(jī)，寫(xiě)有一定合并。針對(duì)LOG LUN，多路順序小IO，大小不定，幾乎都是寫(xiě)IO。
OLTP系統(tǒng)最容易出現(xiàn)瓶頸的地方除了服務(wù)器的CPU，就是存儲(chǔ)系統(tǒng)IOPS處理能力。因?yàn)樵贠LTP環(huán)境中，硬盤(pán)物理讀一般都是db file sequential read，即單個(gè)數(shù)據(jù)塊物理讀，但是這個(gè)讀的次數(shù)非常頻繁。如果頻繁到硬盤(pán)子系統(tǒng)都不能承載其IOPS的時(shí)候，就會(huì)出現(xiàn)大的性能問(wèn)題。
OLAP應(yīng)用的IO特征
OLAP系統(tǒng)，也稱(chēng)為DSS決策支持系統(tǒng)，就是我們說(shuō)的數(shù)據(jù)倉(cāng)庫(kù)。在這樣的系統(tǒng)中，絕大多數(shù)時(shí)候數(shù)據(jù)庫(kù)上運(yùn)行著的是報(bào)表作業(yè)，執(zhí)行基本上是聚合類(lèi)的SQL 操作，比如Group by，同時(shí)掃描非常多的行，一個(gè)查詢(xún)將花費(fèi)數(shù)小時(shí)，甚至數(shù)天，一次讀取的數(shù)據(jù)量大；一般無(wú)數(shù)據(jù)修改，或者只有非常少的數(shù)據(jù)修改：- 單個(gè)I/O很大，典型的值為64KB~1MB
- 當(dāng)讀取操作進(jìn)行時(shí)，發(fā)生的寫(xiě)操作通常在臨時(shí)表空間內(nèi)
- 平常對(duì)在線日志寫(xiě)入很少，除非在批量加載數(shù)據(jù)時(shí)
1、業(yè)務(wù)特征：一般很少有數(shù)據(jù)修改，除非在批量加載數(shù)據(jù)時(shí)；系統(tǒng)調(diào)用非常復(fù)雜的查詢(xún)語(yǔ)句，同時(shí)掃描非常多的行；一個(gè)查詢(xún)將花費(fèi)數(shù)小時(shí)，甚至數(shù)天；主要取決于查詢(xún)語(yǔ)句的復(fù)雜程度；查詢(xún)的輸出通常是一個(gè)統(tǒng)計(jì)值，由group by與order by得出；當(dāng)讀取操作進(jìn)行時(shí)，發(fā)生的寫(xiě)操作通常在臨時(shí)表空間內(nèi)；平常對(duì)在線日志寫(xiě)入很少，除非在批量加載數(shù)據(jù)時(shí)；分析型業(yè)務(wù)，一般對(duì)時(shí)延沒(méi)有要求。2、IO特征：針對(duì)DATA LUN，多路順序大IO（可以近似認(rèn)為是隨機(jī)大IO），IO大小與主機(jī)側(cè)設(shè)置的分條大小有關(guān)（如512KB），90%以上為讀業(yè)務(wù)，混合間斷讀寫(xiě)。針對(duì)TMP LUN，隨機(jī)IO，讀寫(xiě)混合（先寫(xiě)后讀，計(jì)算時(shí)寫(xiě)，讀臨時(shí)表時(shí)讀，大部分是寫(xiě)，占整個(gè)業(yè)務(wù)中很少部分的IO），IO大小基本為200KB以上大IO。 OLTP系統(tǒng)最容易出現(xiàn)瓶頸的地方是存儲(chǔ)系統(tǒng)的帶寬。陣列的帶寬則往往取決于主機(jī)到陣列的前端網(wǎng)絡(luò)和后端硬盤(pán)的個(gè)數(shù)，這個(gè)時(shí)候，陣列CACHE基本是沒(méi)有效果的，數(shù)據(jù)庫(kù)的讀寫(xiě)類(lèi)型基本上是db file scattered read與direct path read/write。在實(shí)際應(yīng)用中，既然OLTP中存放了大量的細(xì)節(jié)數(shù)據(jù)，為什么不直接在OLTP上進(jìn)行分析處理呢？由于OLTP主要是為了操作數(shù)據(jù)而設(shè)計(jì)（操作系統(tǒng)），用于處理已知的任務(wù)和負(fù)載：常見(jiàn)的優(yōu)化在于主碼索引和散列，檢索特定的記錄。去優(yōu)化某一些特定的查詢(xún)語(yǔ)句。而OLAP則是為了分析數(shù)據(jù)而設(shè)計(jì)（數(shù)據(jù)倉(cāng)庫(kù))，其查詢(xún)的方式往往是復(fù)雜且未知的，通常會(huì)涉及大量數(shù)據(jù)在匯總后的計(jì)算，這種需要基于多維視圖的數(shù)據(jù)操作在OLTP上執(zhí)行的時(shí)候性能將是非常差的，并且是也是極其危險(xiǎn)的。但是OLAP系統(tǒng)數(shù)據(jù)來(lái)源與各種OLTP數(shù)據(jù)庫(kù)。因?yàn)镺LTP系統(tǒng)存儲(chǔ)的數(shù)據(jù)往往是異質(zhì)的，所以O(shè)LAP系統(tǒng)需要把各種來(lái)源于OLTP的異質(zhì)數(shù)據(jù)通過(guò)轉(zhuǎn)換（ETL）做到同質(zhì)并且合并。分開(kāi)設(shè)計(jì)與優(yōu)化
在設(shè)計(jì)上要特別注意，如在高可用的OLTP環(huán)境中，不要盲目地把OLAP的技術(shù)拿過(guò)來(lái)用。 如分區(qū)技術(shù)，假設(shè)不是大范圍地使用分區(qū)關(guān)鍵字，而采用其它的字段作為where條件，那么，如果是本地索引，將不得不掃描多個(gè)索引，而性能變得更為低下。如果是全局索引，又失去分區(qū)的意義。
并行技術(shù)也是如此，一般在完成大型任務(wù)時(shí)才使用，如在實(shí)際生活中，翻譯一本書(shū)，可以先安排多個(gè)人，每個(gè)人翻譯不同的章節(jié)，這樣可以提高翻譯速度。如果只是翻譯一頁(yè)書(shū)，也去分配不同的人翻譯不同的行，再組合起來(lái)，就沒(méi)必要了，因?yàn)樵诜峙涔ぷ鞯臅r(shí)間里，一個(gè)人或許早就翻譯完了。
位圖索引也是一樣，如果用在OLTP環(huán)境中，很容易造成阻塞與死鎖。但是，在OLAP環(huán)境中，可能會(huì)因?yàn)槠涮赜械奶匦裕岣逴LAP的查詢(xún)速度。MV也是基本一樣，包括觸發(fā)器等，在DML頻繁的OLTP系統(tǒng)上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環(huán)境上，則可能會(huì)因?yàn)槭褂们‘?dāng)而提高查詢(xún)速度。
Oracle 10g以前的版本建庫(kù)過(guò)程中可供選擇的模板有：Data Warehouse （數(shù)據(jù)倉(cāng)庫(kù)）、General Purpose （通用目的、一般用途）、New Database和Transaction Processing （事務(wù)處理）
Oracle 11g的版本建庫(kù)過(guò)程中可供選擇的模板有：一般用途或事務(wù)處理、定制數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)等；個(gè)人對(duì)這些模板的理解為： 聯(lián)機(jī)分析處理（OLAP），數(shù)據(jù)量大，DML少。使用數(shù)據(jù)倉(cāng)庫(kù)模板； 聯(lián)機(jī)事務(wù)處理（OLTP），數(shù)據(jù)量少，DML頻繁，并行事務(wù)處理多，但是一般都很短。使用一般用途或事務(wù)處理模板。 決策支持系統(tǒng)（DDS，Decision support system)，典型的操作是全表掃描，長(zhǎng)查詢(xún)，長(zhǎng)事務(wù)，但是一般事務(wù)的個(gè)數(shù)很少，往往是一個(gè)事務(wù)獨(dú)占系統(tǒng)。最佳實(shí)踐
Oracle 數(shù)據(jù)庫(kù)在核心 IT 業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛，存儲(chǔ)子系統(tǒng)的規(guī)劃配置至關(guān)重要，不合理的存儲(chǔ)規(guī)劃往往導(dǎo)致 IT 系統(tǒng)性能低下，甚至可用性和數(shù)據(jù)可靠性得不到保證。OLTP類(lèi)型的 Oracle 數(shù)據(jù)庫(kù)往往承載著企業(yè)核心的業(yè)務(wù)支撐系統(tǒng)，如 ERP、CRM 等，其性能和可用性出現(xiàn)問(wèn)題，會(huì)直接導(dǎo)致企業(yè)運(yùn)營(yíng)效率低下甚至中斷。本文OLTP 業(yè)務(wù)測(cè)試模型采用 SwingBench Order Entry 進(jìn)行驗(yàn)證。該業(yè)務(wù)模型中定義了一種在線訂單業(yè)務(wù)，模擬大量用戶(hù)登陸系統(tǒng)，執(zhí)行產(chǎn)品查詢(xún)、下發(fā)訂單、處理訂單、查看訂單等交易系統(tǒng)最常見(jiàn)的操作。該業(yè)務(wù)模型的主要性能指標(biāo)有兩個(gè)：每分鐘事務(wù)數(shù)（TPM）、事務(wù)平均響應(yīng)時(shí)間。TPM 代表系統(tǒng)在單位時(shí)間內(nèi)所能夠處理的交易量，TPM 高，代表著更強(qiáng)的生產(chǎn)力。事務(wù)響應(yīng)時(shí)間直接影響到用戶(hù)操作完成的速度，事務(wù)響應(yīng)時(shí)間低，代表著更佳的用戶(hù)體驗(yàn)。Order Entry 業(yè)務(wù)模型中共定義了 9 張表，記錄產(chǎn)品、客戶(hù)、訂單、倉(cāng)庫(kù)、登陸等信息。在執(zhí)行負(fù)載測(cè)試時(shí)，50%為查詢(xún)操作，30%為插入操作，20%為更新操作，無(wú)刪除操作。從 I/O 層來(lái)看，該業(yè)務(wù)模型為小數(shù)據(jù)塊隨機(jī)訪問(wèn)，讀寫(xiě)比例為 6:4，代表一種最為典型的 OLTP 業(yè)務(wù)模型。在SAN（Storage Area Network）組網(wǎng)中，使用兩個(gè)物理上獨(dú)立的交換平面（每個(gè)交換平面包括一個(gè)交換機(jī)或多個(gè)相互級(jí)聯(lián)的交換機(jī)），每個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)與兩個(gè)交換平面相連，每個(gè)存儲(chǔ)控制器和兩個(gè)交換平面相連。
Oracle RAC 組網(wǎng)示意圖
對(duì)于 Oracle 數(shù)據(jù)庫(kù)來(lái)說(shuō)，I/O 隊(duì)列深度是影響性能的重要參數(shù)。操作系統(tǒng)層存在兩個(gè)參數(shù)影響到 I/O 隊(duì)列深度：塊設(shè)備隊(duì)列深度和 HBA 卡隊(duì)列深度。建議按照如下策略配置塊設(shè)備隊(duì)列深度和 HBA 卡隊(duì)列深度。
對(duì)于 Linux 操作系統(tǒng)，塊設(shè)備最大隊(duì)列深度為 128，而 HBA卡的隊(duì)列參數(shù)與卡類(lèi)型和驅(qū)動(dòng)程序相關(guān)，請(qǐng)參考 HBA 廠商給出的規(guī)格值，如 Qlogic 8Gbps FC 雙口 HBA 卡，限制每個(gè) LUN 的最大隊(duì)列深度為 32。而建議采用增加 LUN 個(gè)數(shù)的方式提高整體 I/O 隊(duì)列深度。
對(duì)于 AIX 操作系統(tǒng)，華為建議安裝 UltraPath 多路徑，而不建議使用系統(tǒng)多路徑或第三方多路徑。安裝了華為 UltraPath 多路徑，塊設(shè)備最大隊(duì)列深度被調(diào)整為 32，若不使用華為 UltraPath，系統(tǒng)默認(rèn)塊設(shè)備最大隊(duì)列深度為 5，建議將此值修改為 32 或更高。AIX 的 HBA 卡最大隊(duì)列深度默認(rèn)值為 200，可根據(jù)實(shí)際業(yè)務(wù)需求進(jìn)行調(diào)整。
對(duì)于 Windows 操作系統(tǒng)，單個(gè) LUN 的最大 I/O 隊(duì)列深度同樣取決于 HBA 卡廠商給出的規(guī)格值。
Oracle 11g 數(shù)據(jù)庫(kù) OLTP 業(yè)務(wù)下，建議針對(duì)以下參數(shù)進(jìn)行調(diào)整，參數(shù)的最佳值應(yīng)根據(jù)實(shí)際業(yè)務(wù)進(jìn)行測(cè)試調(diào)整，以獲取最佳性能和可靠性。下表列出了關(guān)鍵參數(shù)的含義和推薦值：
采用SwingBench測(cè)試，配置特定用戶(hù)會(huì)話數(shù)，測(cè)試出來(lái)的性能如下：
最佳實(shí)踐介紹了基于存儲(chǔ)系統(tǒng)部署 Oracle 數(shù)據(jù)庫(kù)的規(guī)劃配置方案，并提供經(jīng)驗(yàn)證的規(guī)劃配置參考架構(gòu)。用戶(hù)在 存儲(chǔ)陣列規(guī)劃、部署 Oracle 11g 時(shí)可以利用提供的組網(wǎng)、參數(shù)設(shè)置、測(cè)試方法等等信息，在實(shí)踐中予以指導(dǎo)，減少方案規(guī)劃時(shí)的負(fù)擔(dān)與實(shí)施過(guò)程中的風(fēng)險(xiǎn)。
轉(zhuǎn)載申明：轉(zhuǎn)載本號(hào)文章請(qǐng)注明作者和來(lái)源，本號(hào)發(fā)布文章若存在版權(quán)等問(wèn)題，請(qǐng)留言聯(lián)系處理，謝謝。
推薦閱讀
更多架構(gòu)相關(guān)技術(shù)知識(shí)總結(jié)請(qǐng)參考“架構(gòu)師技術(shù)全聯(lián)盟書(shū)店”相關(guān)電子書(shū)(35本技術(shù)資料打包匯總詳情可通過(guò)“閱讀原文”獲取)。
全店內(nèi)容持續(xù)更新，現(xiàn)下單“架構(gòu)師技術(shù)全店打包匯總(全)”，后續(xù)可享全店內(nèi)容更新“免費(fèi)”贈(zèng)閱，價(jià)格僅收188元(原總價(jià)290元)。
溫馨提示：
掃描二維碼關(guān)注公眾號(hào)，點(diǎn)擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書(shū)資料詳情。
