[[387357]]

 OLTP、OLAP、VDI和SPC-1是當前性能評估中常見的三類業(yè)務(wù)場景。SPC-1是業(yè)界通用的隨機IOPS型的IO模型，在不清楚實際業(yè)務(wù)類型的條件下，常用此模型來進行性能評估。四種模型的簡單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)問題，本章重點剖析OLTP和OLAP主要區(qū)別、規(guī)劃方法及基于Oracle的最佳實踐。

OLTP與OLAP的介紹

數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機事務(wù)處理OLTP(On-line transaction processing)、聯(lián)機分析處理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)橹?，評估其系統(tǒng)的時候，一般看其每秒執(zhí)行的Transaction以及Execute SQL的數(shù)量。在這樣的系統(tǒng)中，單個數(shù)據(jù)庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select語句的執(zhí)行量每秒幾千甚至幾萬個。典型的OLTP系統(tǒng)有電子商務(wù)系統(tǒng)、銀行、證券等：

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

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

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

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

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

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

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

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

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

OLTP系統(tǒng)最容易出現(xiàn)瓶頸的地方是存儲系統(tǒng)的帶寬。陣列的帶寬則往往取決于主機到陣列的前端網(wǎng)絡(luò)和后端硬盤的個數(shù)，這個時候，陣列CACHE基本是沒有效果的，數(shù)據(jù)庫的讀寫類型基本上是db file scattered read與direct path read/write。

在實際應(yīng)用中，既然OLTP中存放了大量的細節(jié)數(shù)據(jù)，為什么不直接在OLTP上進行分析處理呢?

由于OLTP主要是為了操作數(shù)據(jù)而設(shè)計(操作系統(tǒng))，用于處理已知的任務(wù)和負載：常見的優(yōu)化在于主碼索引和散列，檢索特定的記錄。去優(yōu)化某一些特定的查詢語句。

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

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

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

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

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

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

位圖索引也是一樣，如果用在OLTP環(huán)境中，很容易造成阻塞與死鎖。但是，在OLAP環(huán)境中，可能會因為其特有的特性，提高OLAP的查詢速度。MV也是基本一樣，包括觸發(fā)器等，在DML頻繁的OLTP系統(tǒng)上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環(huán)境上，則可能會因為使用恰當而提高查詢速度。

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

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

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

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

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

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

最佳實踐

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

本文OLTP 業(yè)務(wù)測試模型采用 SwingBench Order Entry 進行驗證。該業(yè)務(wù)模型中定義了一種在線訂單業(yè)務(wù)，模擬大量用戶登陸系統(tǒng)，執(zhí)行產(chǎn)品查詢、下發(fā)訂單、處理訂單、查看訂單等交易系統(tǒng)最常見的操作。該業(yè)務(wù)模型的主要性能指標有兩個：每分鐘事務(wù)數(shù)(TPM)、事務(wù)平均響應(yīng)時間。TPM 代表系統(tǒng)在單位時間內(nèi)所能夠處理的交易量，TPM 高，代表著更強的生產(chǎn)力。事務(wù)響應(yīng)時間直接影響到用戶操作完成的速度，事務(wù)響應(yīng)時間低，代表著更佳的用戶體驗。

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

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

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

對于 Oracle 數(shù)據(jù)庫來說，I/O 隊列深度是影響性能的重要參數(shù)。操作系統(tǒng)層存在兩個參數(shù)影響到 I/O 隊列深度：塊設(shè)備隊列深度和 HBA 卡隊列深度。建議按照如下策略配置塊設(shè)備隊列深度和 HBA 卡隊列深度。

對于 Linux 操作系統(tǒng)，塊設(shè)備最大隊列深度為 128，而 HBA卡的隊列參數(shù)與卡類型和驅(qū)動程序相關(guān)，請參考 HBA 廠商給出的規(guī)格值，如 Qlogic 8Gbps FC 雙口 HBA 卡，限制每個 LUN 的最大隊列深度為 32。而建議采用增加 LUN 個數(shù)的方式提高整體 I/O 隊列深度。

對于 AIX 操作系統(tǒng)，華為建議安裝 UltraPath 多路徑，而不建議使用系統(tǒng)多路徑或第三方多路徑。安裝了華為 UltraPath 多路徑，塊設(shè)備最大隊列深度被調(diào)整為 32，若不使用華為 UltraPath，系統(tǒng)默認塊設(shè)備最大隊列深度為 5，建議將此值修改為 32 或更高。AIX 的 HBA 卡最大隊列深度默認值為 200，可根據(jù)實際業(yè)務(wù)需求進行調(diào)整。

對于 Windows 操作系統(tǒng)，單個 LUN 的最大 I/O 隊列深度同樣取決于 HBA 卡廠商給出的規(guī)格值。

Oracle 11g 數(shù)據(jù)庫 OLTP 業(yè)務(wù)下，建議針對以下參數(shù)進行調(diào)整，參數(shù)的最佳值應(yīng)根據(jù)實際業(yè)務(wù)進行測試調(diào)整，以獲取最佳性能和可靠性。下表列出了關(guān)鍵參數(shù)的含義和推薦值：

采用SwingBench測試，配置特定用戶會話數(shù)，測試出來的性能如下：

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