[[387357]]

 OLTP、OLAP、VDI和SPC-1是當前性能評估中常見的三類業務場景。SPC-1是業界通用的隨機IOPS型的IO模型，在不清楚實際業務類型的條件下，常用此模型來進行性能評估。四種模型的簡單IO特征如下表所示。

Oracle 數據庫是典型的的OLTP業務模型，在核心 IT 業務系統中應用廣泛，OLTP類型的 Oracle 數據庫往往承載著企業核心的業務支撐系統，如 ERP、CRM 等，其性能和可用性出現問題，本章重點剖析OLTP和OLAP主要區別、規劃方法及基于Oracle的最佳實踐。

OLTP與OLAP的介紹

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

OLTP與OLAP之間的比較：

OLTP應用的IO特征

OLTP通常是指事務性非常高的在線系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。在這樣的系統中，單個數據庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統有電子商務系統、銀行、證券等：

• 每個I/O非常小，通常為2KB~8KB
• 訪問磁盤數據的位置非常隨機
• 至少30%的數據是隨機寫操作
• 聯機重做日志是寫入非常頻繁的順序寫

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

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

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

OLAP應用的IO特征

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

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

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

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

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

在實際應用中，既然OLTP中存放了大量的細節數據，為什么不直接在OLTP上進行分析處理呢?

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

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

但是OLAP系統數據來源與各種OLTP數據庫。因為OLTP系統存儲的數據往往是異質的，所以OLAP系統需要把各種來源于OLTP的異質數據通過轉換(ETL)做到同質并且合并。

分開設計與優化

在設計上要特別注意，如在高可用的OLTP環境中，不要盲目地把OLAP的技術拿過來用。

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

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

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

數據庫模板

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

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

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

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

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

最佳實踐

Oracle 數據庫在核心 IT 業務系統中應用廣泛，存儲子系統的規劃配置至關重要，不合理的存儲規劃往往導致 IT 系統性能低下，甚至可用性和數據可靠性得不到保證。OLTP類型的 Oracle 數據庫往往承載著企業核心的業務支撐系統，如 ERP、CRM 等，其性能和可用性出現問題，會直接導致企業運營效率低下甚至中斷。

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

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

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

Oracle RAC 組網示意圖

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

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

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

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

Oracle 11g 數據庫 OLTP 業務下，建議針對以下參數進行調整，參數的最佳值應根據實際業務進行測試調整，以獲取最佳性能和可靠性。下表列出了關鍵參數的含義和推薦值：

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

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