但是在筆者工作經(jīng)驗(yàn)中，常常看見(jiàn)一些企業(yè)沒(méi)有弄清楚自己的業(yè)務(wù)類型到底是什么，搞不清楚自身系統(tǒng)的瓶頸究竟在哪里，就開始盲目的尋求系統(tǒng)優(yōu)化的方法，結(jié)果不但對(duì)系統(tǒng)性能沒(méi)有任何的提高，甚至可能帶來(lái)適得其反的效果。
因此，在進(jìn)行系統(tǒng)優(yōu)化之前，搞清楚自己的業(yè)務(wù)類型是非常重要的，只有確定清除自身的業(yè)務(wù)類型后，才有可能對(duì)癥下藥對(duì)系統(tǒng)進(jìn)行優(yōu)化。一般而言，數(shù)據(jù)庫(kù)系統(tǒng)的類型通常包括兩種類型：OLTP和OLAP。
OLTP對(duì)服務(wù)器CPU的影響
OLTP，也叫聯(lián)機(jī)事務(wù)處理(Online Transaction Processing)，表示事務(wù)性非常高的系統(tǒng)，一般都是高可用的在線系統(tǒng)，以小的事務(wù)以及小的查詢?yōu)橹鳌Ｔ谠u(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的transaction以及execute sql的數(shù)量。
在這樣的系統(tǒng)中，每秒處理的transaction往往超過(guò)幾百個(gè)，或者是幾千個(gè)，select 語(yǔ)句的執(zhí)行量每秒幾千甚至幾萬(wàn)個(gè)。典型的OLTP系統(tǒng)如電子商務(wù)系統(tǒng)，銀行，證卷等等，如美國(guó)ebay的業(yè)務(wù)數(shù)據(jù)庫(kù)，就是很典型的OLTP數(shù)據(jù)庫(kù)。
OLTP系統(tǒng)最容易出現(xiàn)的瓶頸就是服務(wù)器系統(tǒng)的CPU與磁盤子系統(tǒng)。
CPU的損耗取決于邏輯讀以及內(nèi)部調(diào)用的執(zhí)行頻度，如函數(shù)等等。對(duì)于這種類型的損耗，最有效的優(yōu)化措施是對(duì)數(shù)據(jù)庫(kù)語(yǔ)句做一定的優(yōu)化。
例如，一個(gè)執(zhí)行頻繁的SQL語(yǔ)句，即使每個(gè)語(yǔ)句只減少了很少的邏輯讀，也相當(dāng)于優(yōu)化了邏輯讀很差的大型語(yǔ)句，對(duì)整體系統(tǒng)性能能有較大的提高。很多人似乎感覺(jué)不到這里的作用，覺(jué)得一個(gè)語(yǔ)句幾十個(gè)邏輯讀，執(zhí)行時(shí)間基本為0，就不需要優(yōu)化了。其實(shí)，只要他的執(zhí)行的頻次非常頻繁，而且有優(yōu)化的余地，就一定要優(yōu)化。減少一定的邏輯讀或者降低執(zhí)行次數(shù)，都是有效的優(yōu)化方法。
此外，數(shù)據(jù)庫(kù)系統(tǒng)中一些計(jì)算性的函數(shù)，如sum，count，decode被非常頻繁的使用，也會(huì)產(chǎn)生相當(dāng)大的CPU損耗，筆者就曾經(jīng)遇到一個(gè)系統(tǒng)，因?yàn)橐粋€(gè)sql語(yǔ)句，大量的使用了sum與decode進(jìn)行行列轉(zhuǎn)換，結(jié)果這一個(gè)語(yǔ)句就耗費(fèi)了整個(gè)機(jī)器一半以上的CPU。
在一般的OLTP系統(tǒng)中，如果不考慮筆者上面所說(shuō)的函數(shù)問(wèn)題，那么，邏輯讀乘以執(zhí)行次數(shù)，就決定了cpu的消耗程度。
比如一個(gè)語(yǔ)句，每秒執(zhí)行次數(shù)為500次，每個(gè)邏輯讀為15，但是，通過(guò)優(yōu)化，能讓每個(gè)語(yǔ)句的邏輯讀從15降到10，那么，每秒的邏輯讀就可以減少500*5=2500個(gè)，其實(shí)就是相當(dāng)于優(yōu)化了一個(gè)執(zhí)行頻率為每秒1次，每次邏輯讀為2500個(gè)的語(yǔ)句（注意，2500個(gè)邏輯讀，在OLTP系統(tǒng)中是非常差的語(yǔ)句）。
再比如，我們假定一個(gè)1GHZ的cpu每秒能正常處理的邏輯讀是100,000個(gè)，假定每個(gè)語(yǔ)句都包括10個(gè)邏輯讀，那么這樣的語(yǔ)句CPU每秒可以處理10,000個(gè)，而1000個(gè)邏輯讀一個(gè)的語(yǔ)句，每秒則只能處理100個(gè)。很顯然前一種情況相比后一種情況速度提升很多，因此整體系統(tǒng)的運(yùn)行效率能夠大幅度的提高。而當(dāng)我們確定數(shù)據(jù)庫(kù)的邏輯讀速度后，我們也可以根據(jù)數(shù)據(jù)庫(kù)的運(yùn)行負(fù)荷來(lái)選擇或者擴(kuò)充服務(wù)器CPU。
OLTP對(duì)存儲(chǔ)系統(tǒng)的影響
我們?cè)谏厦娣治隽薕LTP的語(yǔ)句形式不同，對(duì)CPU不同的運(yùn)行壓力。同樣的道理，物理讀乘以執(zhí)行次數(shù)，就決定了存儲(chǔ)子系統(tǒng)的處理能力。
在一個(gè)OLTP環(huán)境中，物理讀一般都是db file sequential read決定的，也就是單塊讀，一個(gè)典型的OLTP系統(tǒng)，db file sequential read應(yīng)當(dāng)基本等于磁盤子系統(tǒng)的讀IOPS。而磁盤子系統(tǒng)的IOPS處理能力，則是與cache命中率以及磁盤個(gè)數(shù)有很大的關(guān)系。
在我此前的一些文章中，曾經(jīng)詳細(xì)分析過(guò)磁盤系統(tǒng)IOPS能力與緩存、cache命中率的關(guān)系。請(qǐng)參考RAID5和RAID10，哪種RAID適合你（下），在我的這篇文章中，我們發(fā)現(xiàn)一個(gè)15K轉(zhuǎn)速的磁盤，每秒最多能處理的iops達(dá)到150個(gè)，基本就達(dá)到該磁盤的性能極限。在cache完全不命中的情況下， 100個(gè)磁盤最多能處理的IOPS也僅僅是15000個(gè)，而實(shí)際上，考慮到一些其他不可見(jiàn)的損耗，大多數(shù)都達(dá)不到這個(gè)值。因此提高cache命中率對(duì)于提高存儲(chǔ)子系統(tǒng)的運(yùn)行效率至關(guān)重要。
OLTP數(shù)據(jù)庫(kù)系統(tǒng)中最常用的技術(shù)就是cache技術(shù)與btree索引，通過(guò)各種有效的方式提高cache命中率，從而決定了很多語(yǔ)句不需要從磁盤子系統(tǒng)獲得數(shù)據(jù)，因此能夠大大的提高磁盤讀取的速度。也因此，web cache與oracle data buffer對(duì)OLTP系統(tǒng)是很重要的。
另外，在索引使用方面，語(yǔ)句是越簡(jiǎn)單越好，而且一定要使用綁定變量，減少語(yǔ)句解析，盡量減少關(guān)聯(lián)，這樣的好處是執(zhí)行計(jì)劃較為簡(jiǎn)單穩(wěn)定。
其它方面，基本不使用分區(qū)技術(shù)，MV技術(shù)，并行技術(shù)以及位圖索引，因?yàn)椴l(fā)量很高，批量更新可能要盡量快速提交避免阻塞的發(fā)生。
根據(jù)筆者的經(jīng)驗(yàn)，在美國(guó)ebay電子交易網(wǎng)站的數(shù)據(jù)庫(kù)設(shè)計(jì)中，有一個(gè)很重要的點(diǎn)就是，數(shù)據(jù)庫(kù)只負(fù)責(zé)存放數(shù)據(jù)，業(yè)務(wù)邏輯盡量在業(yè)務(wù)層實(shí)現(xiàn)，因?yàn)閿?shù)據(jù)庫(kù)擴(kuò)展是困難的，而應(yīng)用服務(wù)器擴(kuò)展是簡(jiǎn)單的。這種規(guī)劃是非常合理的，也就是說(shuō)，在高可用的OLTP環(huán)境中，數(shù)據(jù)庫(kù)使用越簡(jiǎn)單的功能越好。
尋找OLAP的瓶頸
OLAP，也叫聯(lián)機(jī)分析(Online Analytical Processing)，有的時(shí)候也叫DSS決策支持系統(tǒng)，就是我們說(shuō)的數(shù)據(jù)倉(cāng)庫(kù)。比較典型的系統(tǒng)包括一些高校的圖書館系統(tǒng)、醫(yī)院的PACS系統(tǒng)等等。
在這樣的系統(tǒng)中，語(yǔ)句的執(zhí)行量不是考核標(biāo)準(zhǔn)，因?yàn)橐粋€(gè)語(yǔ)句的執(zhí)行時(shí)間可能會(huì)非常長(zhǎng)，讀取的數(shù)據(jù)也非常多。所以，這樣的系統(tǒng)中，考核的標(biāo)準(zhǔn)往往決定于磁盤子系統(tǒng)的吞吐量。
磁盤子系統(tǒng)的吞吐量直接取決于磁盤的個(gè)數(shù)，這個(gè)時(shí)候cache基本對(duì)整體系統(tǒng)沒(méi)有太多的影響，這個(gè)時(shí)候數(shù)據(jù)庫(kù)的讀寫基本上是db file scattered read與direct path read/write。
在我前面的文章RAID5和RAID10，哪種RAID適合你（下）中就描述過(guò)，如果一個(gè)15K的磁盤的IO量每秒13M，那么，100個(gè)磁盤，最多能提供的吞吐量則是1300M/s（實(shí)際上，也基本達(dá)不到這個(gè)值）。在磁盤個(gè)數(shù)足夠的情況下，還需要考慮采用比較大的帶寬，如4GB的光纖接口。
在OLAP系統(tǒng)中，常使用的技術(shù)有分區(qū)技術(shù)，并行技術(shù)。如分區(qū)技術(shù)可以使得一些大表的掃描變得很快（只掃描單個(gè)分區(qū)），而且方便管理。另外，如果分區(qū)結(jié)合并行的話，也可以使得整個(gè)表的掃描也會(huì)變得很快。
并行技術(shù)除了與分區(qū)技術(shù)結(jié)合外，在oracle 10g中，與rac結(jié)合實(shí)現(xiàn)多節(jié)點(diǎn)的同時(shí)掃描，效果也非常不錯(cuò)，把一個(gè)任務(wù)，如select的全表掃描，平均的分派到多個(gè)rac的節(jié)點(diǎn)上去。
在OLAP系統(tǒng)中，不需要使用綁定變量，因?yàn)檎麄€(gè)系統(tǒng)的執(zhí)行量很少，分析時(shí)間對(duì)于執(zhí)行時(shí)間來(lái)說(shuō)，可以忽略，而且避免出現(xiàn)錯(cuò)誤的執(zhí)行計(jì)劃。但是OLAP中可以大量使用位圖索引，物化視圖，對(duì)于大的事務(wù)，盡量的尋求速度上的優(yōu)化，沒(méi)有必要象OLTP需要快速提交，甚至要刻意減慢執(zhí)行的速度。
總結(jié)：選擇合適的優(yōu)化方法
這兩種不同的業(yè)務(wù)類型需要不同的優(yōu)化方式，特別是在高可用的OLTP環(huán)境中，不要盲目的把OLAP的技術(shù)拿過(guò)來(lái)用，如分區(qū)技術(shù)，如果不是大范圍的使用了分區(qū)關(guān)鍵字作為where條件，而采用其它的字段作為where條件，那么，如果是本地索引，你將不得不掃描多個(gè)索引，而使得性能變的更為低下。如果是全局索引，那分區(qū)的意義又何在，只是多出一份分區(qū)技術(shù)的license而已。
并行技術(shù)也是如此，一般是在大型任務(wù)的時(shí)候才使用，好比說(shuō)，實(shí)際生活中，一個(gè)比較大型的工作，如翻譯一本書，你可以先安排多個(gè)人，每個(gè)人翻譯不同的章節(jié)，這樣是可以提高翻譯速度，但是，你現(xiàn)在只是翻譯一頁(yè)，你也去分配不同的人翻譯不同的行，再組合起來(lái)，這個(gè)時(shí)間，你一個(gè)人或者早就翻譯完了。
位圖索引如果用在oltp環(huán)境中，可能因?yàn)樽枞秶螅苋菀鬃枞c死鎖，但是，在olap環(huán)境中，可能會(huì)因?yàn)槠涮赜械奶匦裕岣遫lap的查詢速度。mv也是基本一樣，包括觸發(fā)器等等，在dml頻繁的oltp系統(tǒng)上，很容易成為瓶頸，而在olap環(huán)境上，則可能會(huì)因?yàn)槭褂们‘?dāng)而提高查詢速度。
因此，在實(shí)際的系統(tǒng)維護(hù)過(guò)程中，大家需要慢慢的體會(huì)，分清楚業(yè)務(wù)類型，再判斷合適的系統(tǒng)優(yōu)化方法，不能盲目拿來(lái)使用。
