聯機分析處理 (OLAP) 的概念最早是由關係資料庫之父E.F.Codd於1993年提出的，他同時提出了關於OLAP的12條準則。OLAP的提出引起了很大的反響，OLAP作為一類產品同聯機事務處理 (OLTP) 明顯區分開來。
      當今的資料處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。

區別OLTP還是OLAP

在資料庫的設計中，就算完全掌握了以上的方法，但是，在不同的資料庫型別上，使用起來也是大有差別的，這就需要設計者弄清楚自己的業務型別。如果沒有正確地識別自己的業務型別，就盲目地開始設計資料庫，或者是盲目地尋求優化方法，則往往是把OLAP的方法使用在OLTP上，或者是把OLTP的方法使用在OLAP上。如果這樣，很可能會適得其反。

什麼是OLTP

OLTP，也叫聯機事務處理（Online Transaction Processing），表示事務性非常高的系統，一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。在這樣的系統中，單個數據庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統有電子商務系統、銀行、證券等，如美國eBay的業務資料庫，就是很典型的OLTP資料庫。

注意：如果不特殊指定，本書中的高可用資料庫都是指OLTP型別的資料庫。

OLTP系統最容易出現瓶頸的地方就是CPU與磁碟子系統。

CPU出現瓶頸常表現在邏輯讀總量與計算性函式或者是過程上，邏輯讀總量等於單個語句的邏輯讀乘以執行次數，如果單個語句執行速度雖然很快，但是執行次數非常多，那麼，也可能會導致很大的邏輯讀總量。設計的方法與優化的方法就是減少單個語句的邏輯讀，或者是減少它們的執行次數。另外，一些計算型的函式，如自定義函式、decode等的頻繁使用，也會消耗大量的CPU時間，造成系統的負載升高，正確的設計方法或者是優化方法，需要儘量避免計算過程，如儲存計算結果到統計表就是一個好的方法。

磁碟子系統在OLTP環境中，它的承載能力一般取決於它的IOPS處理能力。

OLTP比較常用的設計與優化方式為Cache技術與B-tree索引技術，Cache決定了很多語句不需要從磁碟子系統獲得資料，所以，Web cache與Oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句越簡單越好，這樣執行計劃也穩定，而且一定要使用繫結變數，減少語句解析，儘量減少表關聯，儘量減少分散式事務，基本不使用分割槽技術、MV技術、並行技術及點陣圖索引。因為併發量很高，批量更新時要分批快速提交，以避免阻塞的發生。

什麼是OLAP

OLAP，也叫聯機分析處理（Online Analytical Processing）系統，有的時候也叫DSS決策支援系統，就是我們說的資料倉庫。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。所以，在這樣的系統中，考核的標準往往是磁碟子系統的吞吐量（頻寬），如能達到多少MB/s的流量。磁碟子系統的吞吐量則往往取決於磁碟的個數，這個時候，Cache基本是沒有效果的，資料庫的讀寫型別基本上是db file scattered read與direct path read/write。應儘量採用個數比較多的磁碟以及比較大的頻寬，如4Gb的光纖介面。

在OLAP系統中，常使用分割槽技術、並行技術。如分割槽技術可以使得一些大表的掃描變得很快（只掃描單個分割槽），而且方便管理。另外，如果分割槽結合並行的話，也可以使得整個表的掃描會變得很快。並行技術除了與分割槽技術結合外，在Oracle 10g中，與RAC結合實現多節點的同時掃描，效果也非常不錯，可把一個任務，如select的全表掃描，平均地分派到多個RAC的節點上去。

在OLAP系統中，不需要使用繫結（BIND）變數，因為整個系統的執行量很小，分析時間對於執行時間來說，可以忽略，而且可避免出現錯誤的執行計劃。但是OLAP中可以大量使用點陣圖索引，物化檢視，對於大的事務，儘量尋求速度上的優化，沒有必要像OLTP要求快速提交，甚至要刻意減慢執行的速度。

分開設計與優化

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

如分割槽技術，假設不是大範圍地使用分割槽關鍵字，而採用其它的欄位作為where條件，那麼，如果是本地索引，將不得不掃描多個索引，而效能變得更為低下。如果是全域性索引，又失去分割槽的意義。

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

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

關於SGA、PGA與系統記憶體三者間的關聯，目前有一個相對通用的計算規則可供參考：

對於OLTP資料庫，SGA=系統記憶體*70%*80%，PGA=SGA*（10%~20%）。SGA=系統記憶體*0.56 PGA=系統記憶體*（0.05~0.1）

對於OLAP資料庫，SGA=系統記憶體*80%*60%，PGA=SGA*（45%~65%）。SGA=系統記憶體*0.48 PGA=系統記憶體*（0.22~0.31）

（對於32bit平臺，預設情況下SGA最大可用記憶體有1.7GB的限制）

OLAP由於有著大量的全表掃描等操作，這樣的環境中SGA的作用就不太大，因為可能一張表的資料量都比DB CACHE大，一個FTS的就需要反覆幾次資料經過SGA再轉到PGA進行處理；至於共享池的存在意義就更不大了，因為很少有語句需要共享的。將PGA設定大一些就是因為OLAP裡面的很多操作是需要到PGA來處理的，比如大資料量的排序、連線等操作，通過並行處理，通常是發生direct path read，這樣資料通常是直接從資料檔案讀取到PGA進行處理，因此需要PGA大一些