在Oracle數據庫系統中，很多人沒有弄清楚自己的業務類型到底是什麼，就在開始盲目的尋求優化方法，而往往是把OLAP的方法使用在OLTP上，或者是OLTP的方法使用在OLAP上。這樣的使用，有的時候，對性能沒有任何的提高，甚至是大大的影響了性能，得到適得其反的效果。所以，在優化系統之前，弄清楚自己的業務類型。
1、什麼是OLTP
OLTP，也叫聯機事務處理(Online Transaction Processing)，表示事務性非常高的系統，一般都是高可用的在線系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的transaction以及execute sql的數量。在這樣的系統中，每秒處理的transaction往往超過幾百個，或者是幾千個，select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統如電子商務系統，銀行，證卷等等，如美國ebay的業務數據庫，就是很典型的OLTP數據庫。
OLTP系統最容易出現的瓶頸就是CPU與磁盤子系統。cpu則取決於邏輯讀以及內部調用，如函數等等。一個執行頻繁的SQL語句，如果每個語句可以減少很少的邏輯讀，也相當於優化了一些邏輯讀很差的大型語句。很多人不感覺不到這裡的作用，覺得一個語句幾十個邏輯讀，執行時間基本為0，就不需要優化了，其實，只要他的執行次數非常頻繁，而且有優化的余地，就一定要優化，如減少一定的邏輯讀或者降低執行次數，都是優化方法。
另外，一些計算性的函數，如sum，count，decode被非常頻繁的使用，也是非常消耗cpu的，我遇到一個系統，因為一個sql語句，大量的使用了sum與decode進行行列轉換，結果這一個語句就耗費了整個機器一半以上的CPU。
那麼，在一般的OLTP系統中，如果不考慮我上面說的函數問題，那麼，邏輯讀乘以執行次數，決定了cpu的消耗程度，如一個語句，每秒執行次數為500次，每個邏輯讀為15，但是，通過優化，能讓每個語句的邏輯讀從15降到10，那麼，每秒的邏輯讀就可以減少500*5=2500個，其實就是相當於優化了一個執行頻率為每秒1次，每次邏輯讀為2500個的語句（注意，2500個邏輯讀，在oltp系統是非常差的語句）。再如，假定一個1GHZ的cpu每秒能正常處理的邏輯讀是100,000個，如果是10個邏輯讀一個的語句，每秒可以處理10,000個，而1000個邏輯讀一個的語句，每秒則只能處理100個。
同以上道理，物理讀乘以執行次數，則決定了存儲子系統的處理能力，在一個OLTP環境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個典型的OLTP系統，db file sequential read應當基本等於磁盤子系統的讀的IOPS。而磁盤子系統的IOPS處理能力，與cache命中率以及磁盤個數有很大的關系。我的一些文章中，也分析到了這些問題，如一個15K轉速的磁盤，每秒最多能處理的iops達到150個，基本就是極限了，如果cache不命中，那麼100個磁盤，最多能處理的IOPS僅僅是15000個（但是，實際上，還基本達不到這個值）。
OLTP最常用的技術就是cache技術與btree索引，cache決定了很多語句不需要從磁盤子系統獲得數據，所以，web cache與oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句是越簡單越好，這樣執行計劃也穩定，而且一定要使用綁定變量，減少語句解析，盡量減少關聯。其它方面，基本不使用分區技術，MV技術，並行技術以及位圖索引，因為並發量很高，批量更新可能要盡量快速提交避免阻塞的發生。
在ebay的數據庫設計中，有一個很重要的點就是，數據庫只負責存放數據，業務邏輯盡量在業務層實現，因為數據庫擴展是困難的，而應用服務器擴展是簡單的。其實，也就是說，在高可用的OLTP環境中，數據庫使用越簡單的功能越好。
2、什麼是OLAP
OLAP，也叫聯機分析(Online Analytical Processing)，有的時候也叫DSS決策支持系統，就是我們說的數據倉庫。在這樣的系統中，語句的執行量不是考核標准，因為一個語句的執行時間可能會非常長，讀取的數據也非常多。所以，這樣的系統中，考核的標准往往決定於磁盤子系統的吞吐量。磁盤子系統的吞吐量則直接取決於磁盤的個數，這個時候，cache基本是沒有效果的，這個時候數據庫的讀寫基本上是db file scattered read與direct path read/write。在我前面的一些文章中描述過，如果一個15K的磁盤的IO量每秒13M，那麼，100個磁盤，最多能提供的吞吐量則是1300M/s（實際上，也基本達不到這個值）。如果磁盤個數足夠的話，還需要考慮采用比較大的帶寬，如4GB的光纖接口。
在OLAP系統中，常使用的技術有分區技術，並行技術。如分區技術可以使得一些大表的掃描變得很快（只掃描單個分區），而且方便管理。另外，如果分區結合並行的話，也可以使得整個表的掃描也會變得很快。並行技術除了與分區技術結合外，在oracle 10g中，與rac結合實現多節點的同時掃描，效果也非常不錯，把一個任務，如select的全表掃描，平均的分派到多個rac的節點上去。
在OLAP系統中，不需要使用綁定變量，因為整個系統的執行量很少，分析時間對於執行時間來說，可以忽略，而且避免出現錯誤的執行計劃。但是OLAP中可以大量使用位圖索引，物化視圖，對於大的事務，盡量的尋求速度上的優化，沒有必要象OLTP需要快速提交，甚至要刻意減慢執行的速度。
3、總結
特別是在高可用的OLTP環境中，不要盲目的把OLAP的技術拿過來用，如分區技術，如果不是大范圍的使用了分區關鍵字作為where條件，而采用其它的字段作為where條件，那麼，如果是本地索引，你將不得不掃描多個索引，而性能變的更為低下。如果是全局索引，那分區的意義又何在，只是多出一份分區技術的license而已。
並行技術也是如此，一般是在大型任務的時候才使用，好比說，實際生活中，一個比較大型的工作，如翻譯一本書，你可以先安排多個人，每個人翻譯不同的章節，這樣是可以提高翻譯速度，但是，你現在只是翻譯一頁，你也去分配不同的人翻譯不同的行，再組合起來，這個時間，你一個人或者早就翻譯完了。
位圖索引在我前幾篇文章中有交代，如果用在oltp環境中，可能因為阻塞范圍太大，很容易阻塞與死鎖，但是，在olap環境中，可能會因為其特有的特性，提高olap的查詢速度。mv也是基本一樣，包括觸發器等等，在dml頻繁的oltp系統上，很容易成為瓶頸，而在olap環境上，則可能會因為使用恰當而提高查詢速度。
更多的差別與技術，細說下來太多了，有些東西，是要靠大家慢慢去體會的，我這裡也就不多說了，大家可以平常在自己的業務中多多體會。
oltp數據
olap數據
原始數據
導出數據
細節性數據
綜合性和提煉性數據
當前值數據
歷史數據
可更新
不可更新，但周期性刷新
一次處理的數據量小
一次處理的數據量大
面向應用，事務驅動
面向分析，分析驅動
面向操作人員，支持日常操作
面向決策人員，支持管理需要
