[[387357]]

 OLTP、OLAP、VDI和SPC-1是當(dāng)前性能評(píng)估中常見的三類業(yè)務(wù)場(chǎng)景。SPC-1是業(yè)界通用的隨機(jī)IOPS型的IO模型，在不清楚實(shí)際業(yè)務(wù)類型的條件下，常用此模型來進(jìn)行性能評(píng)估。四種模型的簡(jiǎn)單IO特征如下表所示。

Oracle 數(shù)據(jù)庫是典型的的OLTP業(yè)務(wù)模型，在核心 IT 業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛，OLTP類型的 Oracle 數(shù)據(jù)庫往往承載著企業(yè)核心的業(yè)務(wù)支撐系統(tǒng)，如 ERP、CRM 等，其性能和可用性出現(xiàn)問題，本章重點(diǎn)剖析OLTP和OLAP主要區(qū)別、規(guī)劃方法及基于Oracle的最佳實(shí)踐。

OLTP與OLAP的介紹

數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機(jī)事務(wù)處理OLTP(On-line transaction processing)、聯(lián)機(jī)分析處理OLAP(On-Line Analytical Processing)。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉庫系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。

OLTP與OLAP之間的比較：

OLTP應(yīng)用的IO特征

OLTP通常是指事務(wù)性非常高的在線系統(tǒng)，以小的事務(wù)以及小的查詢?yōu)橹?，評(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的Transaction以及Execute SQL的數(shù)量。在這樣的系統(tǒng)中，單個(gè)數(shù)據(jù)庫每秒處理的Transaction往往超過幾百個(gè)，或者是幾千個(gè)，Select語句的執(zhí)行量每秒幾千甚至幾萬個(gè)。典型的OLTP系統(tǒng)有電子商務(wù)系統(tǒng)、銀行、證券等：

• 每個(gè)I/O非常小，通常為2KB~8KB
• 訪問磁盤數(shù)據(jù)的位置非常隨機(jī)
• 至少30%的數(shù)據(jù)是隨機(jī)寫操作
• 聯(lián)機(jī)重做日志是寫入非常頻繁的順序?qū)?/li>

1、業(yè)務(wù)特征：每個(gè)事務(wù)的讀，寫，更改涉及的數(shù)據(jù)量非常小，同時(shí)有很多用戶連接到數(shù)據(jù)庫，使用數(shù)據(jù)庫，要求數(shù)據(jù)庫有很快的響應(yīng)時(shí)間，通常一個(gè)事務(wù)在幾秒內(nèi)完成，時(shí)延要求一般在10-20ms。

2、IO特征：針對(duì)DATA LUN，隨機(jī)小IO，IO大小主要為8KB(IO大小與數(shù)據(jù)庫的Block塊大小一致)，讀寫比約為3:2，讀全隨機(jī)，寫有一定合并。針對(duì)LOG LUN，多路順序小IO，大小不定，幾乎都是寫IO。

OLTP系統(tǒng)最容易出現(xiàn)瓶頸的地方除了服務(wù)器的CPU，就是存儲(chǔ)系統(tǒng)IOPS處理能力。因?yàn)樵贠LTP環(huán)境中，硬盤物理讀一般都是db file sequential read，即單個(gè)數(shù)據(jù)塊物理讀，但是這個(gè)讀的次數(shù)非常頻繁。如果頻繁到硬盤子系統(tǒng)都不能承載其IOPS的時(shí)候，就會(huì)出現(xiàn)大的性能問題。

OLAP應(yīng)用的IO特征

OLAP系統(tǒng)，也稱為DSS決策支持系統(tǒng)，就是我們說的數(shù)據(jù)倉庫。在這樣的系統(tǒng)中，絕大多數(shù)時(shí)候數(shù)據(jù)庫上運(yùn)行著的是報(bào)表作業(yè)，執(zhí)行基本上是聚合類的SQL 操作，比如Group by，同時(shí)掃描非常多的行，一個(gè)查詢將花費(fèi)數(shù)小時(shí)，甚至數(shù)天，一次讀取的數(shù)據(jù)量大;一般無數(shù)據(jù)修改，或者只有非常少的數(shù)據(jù)修改：

• 單個(gè)I/O很大，典型的值為64KB~1MB
• 讀取操作為順序讀取
• 當(dāng)讀取操作進(jìn)行時(shí)，發(fā)生的寫操作通常在臨時(shí)表空間內(nèi)
• 平常對(duì)在線日志寫入很少，除非在批量加載數(shù)據(jù)時(shí)

1、業(yè)務(wù)特征：一般很少有數(shù)據(jù)修改，除非在批量加載數(shù)據(jù)時(shí);系統(tǒng)調(diào)用非常復(fù)雜的查詢語句，同時(shí)掃描非常多的行;一個(gè)查詢將花費(fèi)數(shù)小時(shí)，甚至數(shù)天;主要取決于查詢語句的復(fù)雜程度;查詢的輸出通常是一個(gè)統(tǒng)計(jì)值，由group by與order by得出;當(dāng)讀取操作進(jìn)行時(shí)，發(fā)生的寫操作通常在臨時(shí)表空間內(nèi);平常對(duì)在線日志寫入很少，除非在批量加載數(shù)據(jù)時(shí);分析型業(yè)務(wù)，一般對(duì)時(shí)延沒有要求。

2、IO特征：針對(duì)DATA LUN，多路順序大IO(可以近似認(rèn)為是隨機(jī)大IO)，IO大小與主機(jī)側(cè)設(shè)置的分條大小有關(guān)(如512KB)，90%以上為讀業(yè)務(wù)，混合間斷讀寫。針對(duì)TMP LUN，隨機(jī)IO，讀寫混合(先寫后讀，計(jì)算時(shí)寫，讀臨時(shí)表時(shí)讀，大部分是寫，占整個(gè)業(yè)務(wù)中很少部分的IO)，IO大小基本為200KB以上大IO。

OLTP系統(tǒng)最容易出現(xiàn)瓶頸的地方是存儲(chǔ)系統(tǒng)的帶寬。陣列的帶寬則往往取決于主機(jī)到陣列的前端網(wǎng)絡(luò)和后端硬盤的個(gè)數(shù)，這個(gè)時(shí)候，陣列CACHE基本是沒有效果的，數(shù)據(jù)庫的讀寫類型基本上是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ù)載：常見的優(yōu)化在于主碼索引和散列，檢索特定的記錄。去優(yōu)化某一些特定的查詢語句。

而OLAP則是為了分析數(shù)據(jù)而設(shè)計(jì)(數(shù)據(jù)倉庫)，其查詢的方式往往是復(fù)雜且未知的，通常會(huì)涉及大量數(shù)據(jù)在匯總后的計(jì)算，這種需要基于多維視圖的數(shù)據(jù)操作在OLTP上執(zhí)行的時(shí)候性能將是非常差的，并且是也是極其危險(xiǎn)的。

但是OLAP系統(tǒng)數(shù)據(jù)來源與各種OLTP數(shù)據(jù)庫。因?yàn)镺LTP系統(tǒng)存儲(chǔ)的數(shù)據(jù)往往是異質(zhì)的，所以O(shè)LAP系統(tǒng)需要把各種來源于OLTP的異質(zhì)數(shù)據(jù)通過轉(zhuǎn)換(ETL)做到同質(zhì)并且合并。

分開設(shè)計(jì)與優(yōu)化

在設(shè)計(jì)上要特別注意，如在高可用的OLTP環(huán)境中，不要盲目地把OLAP的技術(shù)拿過來用。

如分區(qū)技術(shù)，假設(shè)不是大范圍地使用分區(qū)關(guān)鍵字，而采用其它的字段作為where條件，那么，如果是本地索引，將不得不掃描多個(gè)索引，而性能變得更為低下。如果是全局索引，又失去分區(qū)的意義。

并行技術(shù)也是如此，一般在完成大型任務(wù)時(shí)才使用，如在實(shí)際生活中，翻譯一本書，可以先安排多個(gè)人，每個(gè)人翻譯不同的章節(jié)，這樣可以提高翻譯速度。如果只是翻譯一頁書，也去分配不同的人翻譯不同的行，再組合起來，就沒必要了，因?yàn)樵诜峙涔ぷ鞯臅r(shí)間里，一個(gè)人或許早就翻譯完了。

位圖索引也是一樣，如果用在OLTP環(huán)境中，很容易造成阻塞與死鎖。但是，在OLAP環(huán)境中，可能會(huì)因?yàn)槠涮赜械奶匦?，提高OLAP的查詢速度。MV也是基本一樣，包括觸發(fā)器等，在DML頻繁的OLTP系統(tǒng)上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環(huán)境上，則可能會(huì)因?yàn)槭褂们‘?dāng)而提高查詢速度。

數(shù)據(jù)庫模板

Oracle 10g以前的版本建庫過程中可供選擇的模板有：Data Warehouse (數(shù)據(jù)倉庫)、General Purpose (通用目的、一般用途)、New Database和Transaction Processing (事務(wù)處理)

Oracle 11g的版本建庫過程中可供選擇的模板有：一般用途或事務(wù)處理、定制數(shù)據(jù)庫、數(shù)據(jù)倉庫等;個(gè)人對(duì)這些模板的理解為：

聯(lián)機(jī)分析處理(OLAP)，數(shù)據(jù)量大，DML少。使用數(shù)據(jù)倉庫模板;

聯(lián)機(jī)事務(wù)處理(OLTP)，數(shù)據(jù)量少，DML頻繁，并行事務(wù)處理多，但是一般都很短。使用一般用途或事務(wù)處理模板。

決策支持系統(tǒng)(DDS，Decision support system)，典型的操作是全表掃描，長(zhǎng)查詢，長(zhǎng)事務(wù)，但是一般事務(wù)的個(gè)數(shù)很少，往往是一個(gè)事務(wù)獨(dú)占系統(tǒng)。

最佳實(shí)踐

Oracle 數(shù)據(jù)庫在核心 IT 業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛，存儲(chǔ)子系統(tǒng)的規(guī)劃配置至關(guān)重要，不合理的存儲(chǔ)規(guī)劃往往導(dǎo)致 IT 系統(tǒng)性能低下，甚至可用性和數(shù)據(jù)可靠性得不到保證。OLTP類型的 Oracle 數(shù)據(jù)庫往往承載著企業(yè)核心的業(yè)務(wù)支撐系統(tǒng)，如 ERP、CRM 等，其性能和可用性出現(xiàn)問題，會(huì)直接導(dǎo)致企業(yè)運(yùn)營(yíng)效率低下甚至中斷。

本文OLTP 業(yè)務(wù)測(cè)試模型采用 SwingBench Order Entry 進(jìn)行驗(yàn)證。該業(yè)務(wù)模型中定義了一種在線訂單業(yè)務(wù)，模擬大量用戶登陸系統(tǒng)，執(zhí)行產(chǎn)品查詢、下發(fā)訂單、處理訂單、查看訂單等交易系統(tǒng)最常見的操作。該業(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í)間直接影響到用戶操作完成的速度，事務(wù)響應(yīng)時(shí)間低，代表著更佳的用戶體驗(yàn)。

Order Entry 業(yè)務(wù)模型中共定義了 9 張表，記錄產(chǎn)品、客戶、訂單、倉庫、登陸等信息。在執(zhí)行負(fù)載測(cè)試時(shí)，50%為查詢操作，30%為插入操作，20%為更新操作，無刪除操作。從 I/O 層來看，該業(yè)務(wù)模型為小數(shù)據(jù)塊隨機(jī)訪問，讀寫比例為 6:4，代表一種最為典型的 OLTP 業(yè)務(wù)模型。

在SAN(Storage Area Network)組網(wǎng)中，使用兩個(gè)物理上獨(dú)立的交換平面(每個(gè)交換平面包括一個(gè)交換機(jī)或多個(gè)相互級(jí)聯(lián)的交換機(jī))，每個(gè)數(shù)據(jù)庫節(jié)點(diǎn)與兩個(gè)交換平面相連，每個(gè)存儲(chǔ)控制器和兩個(gè)交換平面相連。

Oracle RAC 組網(wǎng)示意圖

對(duì)于 Oracle 數(shù)據(jù)庫來說，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ù)與卡類型和驅(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ù)庫 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è)試，配置特定用戶會(huì)話數(shù)，測(cè)試出來的性能如下：

最佳實(shí)踐介紹了基于存儲(chǔ)系統(tǒng)部署 Oracle 數(shù)據(jù)庫的規(guī)劃配置方案，并提供經(jīng)驗(yàn)證的規(guī)劃配置參考架構(gòu)。用戶在 存儲(chǔ)陣列規(guī)劃、部署 Oracle 11g 時(shí)可以利用提供的組網(wǎng)、參數(shù)設(shè)置、測(cè)試方法等等信息，在實(shí)踐中予以指導(dǎo)，減少方案規(guī)劃時(shí)的負(fù)擔(dān)與實(shí)施過程中的風(fēng)險(xiǎn)。