但是在筆者工作經驗中，常常看見一些企業沒有弄清楚自己的業務類型到底是什么，搞不清楚自身系統的瓶頸究竟在哪里，就開始盲目的尋求系統優化的方法，結果不但對系統性能沒有任何的提高，甚至可能帶來適得其反的效果。
因此，在進行系統優化之前，搞清楚自己的業務類型是非常重要的，只有確定清除自身的業務類型后，才有可能對癥下藥對系統進行優化。一般而言，數據庫系統的類型通常包括兩種類型：OLTP和OLAP。
OLTP對服務器CPU的影響
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個邏輯讀，那么這樣的語句CPU每秒可以處理10,000個，而1000個邏輯讀一個的語句，每秒則只能處理100個。很顯然前一種情況相比后一種情況速度提升很多，因此整體系統的運行效率能夠大幅度的提高。而當我們確定數據庫的邏輯讀速度后，我們也可以根據數據庫的運行負荷來選擇或者擴充服務器CPU。
OLTP對存儲系統的影響
我們在上面分析了OLTP的語句形式不同，對CPU不同的運行壓力。同樣的道理，物理讀乘以執行次數，就決定了存儲子系統的處理能力。
在一個OLTP環境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個典型的OLTP系統，db file sequential read應當基本等于磁盤子系統的讀IOPS。而磁盤子系統的IOPS處理能力，則是與cache命中率以及磁盤個數有很大的關系。
在我此前的一些文章中，曾經詳細分析過磁盤系統IOPS能力與緩存、cache命中率的關系。請參考RAID5和RAID10，哪種RAID適合你（下），在我的這篇文章中，我們發現一個15K轉速的磁盤，每秒最多能處理的iops達到150個，基本就達到該磁盤的性能極限。在cache完全不命中的情況下， 100個磁盤最多能處理的IOPS也僅僅是15000個，而實際上，考慮到一些其他不可見的損耗，大多數都達不到這個值。因此提高cache命中率對于提高存儲子系統的運行效率至關重要。
OLTP數據庫系統中最常用的技術就是cache技術與btree索引，通過各種有效的方式提高cache命中率，從而決定了很多語句不需要從磁盤子系統獲得數據，因此能夠大大的提高磁盤讀取的速度。也因此，web cache與oracle data buffer對OLTP系統是很重要的。
另外，在索引使用方面，語句是越簡單越好，而且一定要使用綁定變量，減少語句解析，盡量減少關聯，這樣的好處是執行計劃較為簡單穩定。
其它方面，基本不使用分區技術，MV技術，并行技術以及位圖索引，因為并發量很高，批量更新可能要盡量快速提交避免阻塞的發生。
根據筆者的經驗，在美國ebay電子交易網站的數據庫設計中，有一個很重要的點就是，數據庫只負責存放數據，業務邏輯盡量在業務層實現，因為數據庫擴展是困難的，而應用服務器擴展是簡單的。這種規劃是非常合理的，也就是說，在高可用的OLTP環境中，數據庫使用越簡單的功能越好。
尋找OLAP的瓶頸
OLAP，也叫聯機分析(Online Analytical Processing)，有的時候也叫DSS決策支持系統，就是我們說的數據倉庫。比較典型的系統包括一些高校的圖書館系統、醫院的PACS系統等等。
在這樣的系統中，語句的執行量不是考核標準，因為一個語句的執行時間可能會非常長，讀取的數據也非常多。所以，這樣的系統中，考核的標準往往決定于磁盤子系統的吞吐量。
磁盤子系統的吞吐量直接取決于磁盤的個數，這個時候cache基本對整體系統沒有太多的影響，這個時候數據庫的讀寫基本上是db file scattered read與direct path read/write。
在我前面的文章RAID5和RAID10，哪種RAID適合你（下）中就描述過，如果一個15K的磁盤的IO量每秒13M，那么，100個磁盤，最多能提供的吞吐量則是1300M/s（實際上，也基本達不到這個值）。在磁盤個數足夠的情況下，還需要考慮采用比較大的帶寬，如4GB的光纖接口。
在OLAP系統中，常使用的技術有分區技術，并行技術。如分區技術可以使得一些大表的掃描變得很快（只掃描單個分區），而且方便管理。另外，如果分區結合并行的話，也可以使得整個表的掃描也會變得很快。
并行技術除了與分區技術結合外，在oracle 10g中，與rac結合實現多節點的同時掃描，效果也非常不錯，把一個任務，如select的全表掃描，平均的分派到多個rac的節點上去。
在OLAP系統中，不需要使用綁定變量，因為整個系統的執行量很少，分析時間對于執行時間來說，可以忽略，而且避免出現錯誤的執行計劃。但是OLAP中可以大量使用位圖索引，物化視圖，對于大的事務，盡量的尋求速度上的優化，沒有必要象OLTP需要快速提交，甚至要刻意減慢執行的速度。
總結：選擇合適的優化方法
這兩種不同的業務類型需要不同的優化方式，特別是在高可用的OLTP環境中，不要盲目的把OLAP的技術拿過來用，如分區技術，如果不是大范圍的使用了分區關鍵字作為where條件，而采用其它的字段作為where條件，那么，如果是本地索引，你將不得不掃描多個索引，而使得性能變的更為低下。如果是全局索引，那分區的意義又何在，只是多出一份分區技術的license而已。
并行技術也是如此，一般是在大型任務的時候才使用，好比說，實際生活中，一個比較大型的工作，如翻譯一本書，你可以先安排多個人，每個人翻譯不同的章節，這樣是可以提高翻譯速度，但是，你現在只是翻譯一頁，你也去分配不同的人翻譯不同的行，再組合起來，這個時間，你一個人或者早就翻譯完了。
位圖索引如果用在oltp環境中，可能因為阻塞范圍太大，很容易阻塞與死鎖，但是，在olap環境中，可能會因為其特有的特性，提高olap的查詢速度。mv也是基本一樣，包括觸發器等等，在dml頻繁的oltp系統上，很容易成為瓶頸，而在olap環境上，則可能會因為使用恰當而提高查詢速度。
因此，在實際的系統維護過程中，大家需要慢慢的體會，分清楚業務類型，再判斷合適的系統優化方法，不能盲目拿來使用。
