資料處理大致可以分成兩大類：聯機事務處理oltp（on-line transaction processing）、聯機分析處理olap（on-line analytical processing）。oltp是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。olap是資料倉儲系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。olap 系統則強調資料分析，強調sql執行市場，強調磁碟i/o，強調分割槽等。
oltp與olap之間的比較：
oltp系統最容易出現瓶頸的地方就是cpu與磁碟子系統。
（1）cpu出現瓶頸常表現在邏輯讀總量與計算性函式或者是過程上，邏輯讀總量等於單個語句的邏輯讀乘以執行次數，如果單個語句執行速度雖然很快，但是執行次數非常多，那麼，也可能會導致很大的邏輯讀總量。設計的方法與優化的方法就是減少單個語句的邏輯讀，或者是減少它們的執行次數。另外，一些計算型的函式，如自定義函式、decode等的頻繁使用，也會消耗大量的cpu時間，造成系統的負載公升高，正確的設計方法或者是優化方法，需要盡量避免計算過程，如儲存計算結果到統計表就是乙個好的方法。
（2）磁碟子系統在oltp環境中，它的承載能力一般取決於它的iops處理能力. 因為在oltp環境中，磁碟物理讀一般都是db file sequential read，也就是單塊讀，但是這個讀的次數非常頻繁。如果頻繁到磁碟子系統都不能承載其iops的時候，就會出現大的效能問題。
oltp比較常用的設計與優化方式為cache技術與b-tree索引技術，cache決定了很多語句不需要從磁碟子系統獲得資料，所以，web cache與oracle data buffer對oltp系統是很重要的。另外，在索引使用方面，語句越簡單越好，這樣執行計畫也穩定，而且一定要使用繫結變數，減少語句解析，儘量減少表關聯，儘量減少分布式事務，基本不使用分割槽技術、mv技術、並行技術及位圖索引。因為併發量很高，批量更新時要分批快速提交，以避免阻塞的發生。
oltp 系統是乙個資料塊變化非常頻繁，sql 語句提交非常頻繁的系統。 對於資料塊來說，應盡可能讓資料塊儲存在記憶體當中，對於sql來說，盡可能使用變數繫結技術來達到sql重用，減少物理i/o 和重複的sql 解析，從而極大的改善資料庫的效能。
這裡影響效能除了繫結變數，還有可能是熱快（hot block）。 當乙個塊被多個使用者同時讀取時，oracle 為了維護資料的一致性，需要使用latch來序列化使用者的操作。當乙個使用者獲得了latch後，其他使用者就只能等待，獲取這個資料塊的使用者越多，等待就越明顯。 這就是熱快的問題。 這種熱快可能是資料塊，也可能是回滾端塊。 對於資料塊來講，通常是資料庫的資料分布不均勻導致，如果是索引的資料塊，可以考慮建立反向索引來達到重新分布資料的目的，對於回滾段資料塊，可以適當多增加幾個回滾段來避免這種爭用。
olap，也叫聯機分析處理（online analytical processing）系統，有的時候也叫dss決策支援系統，就是我們說的資料倉儲。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。所以，在這樣的系統中，考核的標準往往是磁碟子系統的吞吐量（頻寬），如能達到多少mb/s的流量。
磁碟子系統的吞吐量則往往取決於磁碟的個數，這個時候，cache基本是沒有效果的，資料庫的讀寫型別基本上是db file scattered read與direct path read/write。應盡量採用個數比較多的磁碟以及比較大的頻寬，如4gb的光纖介面。
在olap系統中，常使用分割槽技術、並行技術。
分割槽技術在olap系統中的重要性主要體現在資料庫管理上，比如資料庫載入，可以通過分割槽交換的方式實現，備份可以通過備份分割槽表空間實現，刪除資料可以通過分割槽進行刪除，至於分割槽在效能上的影響，它可以使得一些大表的掃瞄變得很快（只掃瞄單個分割槽）。另外，如果分割槽結合並行的話，也可以使得整個表的掃瞄會變得很快。總之，分割槽主要的功能是管理上的方便性，它並不能絕對保證查詢效能的提高，有時候分割槽會帶來效能上的提高，有時候會降低。
並行技術除了與分割槽技術結合外，在oracle 10g中，與rac結合實現多節點的同時掃瞄，效果也非常不錯，可把乙個任務，如select的全表掃瞄，平均地分派到多個rac的節點上去。
在olap系統中，不需要使用繫結（bind）變數，因為整個系統的執行量很小，分析時間對於執行時間來說，可以忽略，而且可避免出現錯誤的執行計畫。但是olap中可以大量使用位圖索引，物化檢視，對於大的事務，盡量尋求速度上的優化，沒有必要像oltp要求快速提交，甚至要刻意減慢執行的速度。
繫結變數真正的用途是在oltp系統中，這個系統通常有這樣的特點，使用者併發數很大，使用者的請求十分密集，並且這些請求的sql 大多數是可以重複使用的。
對於olap系統來說，絕大多數時候資料庫上執行著的是報表作業，執行基本上是聚合類的sql 操作，比如group by，這時候，把優化器模式設定為all_rows是恰當的。 而對於一些分頁操作比較多的**類資料庫，設定為first_rows會更好一些。 但有時候對於olap 系統，我們又有分頁的情況下，我們可以考慮在每條sql 中用hint。 如：
select a.* from table a;
分開設計與優化
在設計上要特別注意，如在高可用的oltp環境中，不要盲目地把olap的技術拿過來用。
如分割槽技術，假設不是大範圍地使用分割槽關鍵字，而採用其它的字段作為where條件，那麼，如果是本地索引，將不得不掃瞄多個索引，而效能變得更為低下。如果是全域性索引，又失去分割槽的意義。
並行技術也是如此，一般在完成大型任務時才使用，如在實際生活中，翻譯一本書，可以先安排多個人，每個人翻譯不同的章節，這樣可以提高翻譯速度。如果只是翻譯一頁書，也去分配不同的人翻譯不同的行，再組合起來，就沒必要了，因為在分配工作的時間裡，乙個人或許早就翻譯完了。
位圖索引也是一樣，如果用在oltp環境中，很容易造成阻塞與死鎖。但是，在olap環境中，可能會因為其特有的特性，提高olap的查詢速度。mv也是基本一樣，包括觸發器等，在dml頻繁的oltp系統上，很容易成為瓶頸，甚至是library cache等待，而在olap環境上，則可能會因為使用恰當而提高查詢速度。
對於olap系統，在記憶體上可優化的餘地很小，增加cpu 處理速度和磁碟i/o 速度是最直接的提高資料庫效能的方法，當然這也意味著系統成本的增加。
比如我們要對幾億條或者幾十億條資料進行聚合處理，這種海量的資料，全部放在記憶體中操作是很難的，同時也沒有必要，因為這些資料快很少重用，快取起來也沒有實際意義，而且還會造成物理i/o相當大。 所以這種系統的瓶頸往往是磁碟i/o上面的。
對於olap系統，sql 的優化非常重要，因為它的資料量很大，做全表掃瞄和索引對效能上來說差異是非常大的。
–** super_wu
OLTP與OLAP的介紹
oltp與olap的介紹 資料處理大致可以分成兩大類 聯機事務處理oltp on line transaction processing 聯機分析處理olap on line analytical processing oltp是傳統的關係型資料庫的主要應用，主要是基本的 日常的事務處理，例如銀行交...
OLTP與OLAP的介紹
資料處理大致可以分成兩大類 聯機事務處理oltp on line transaction processing 聯機分析處理olap on line analytical processing oltp是傳統的關係型 color red b 資料庫 b color 的主要應用，主要是基本的 日常的事...
OLTP與OLAP的介紹
oltp與olap的介紹 資料處理大致可以分成兩大類 聯機事務處理oltp on line transaction processing 聯機分析處理olap on line analytical processing oltp是傳統的關係型資料庫的主要應用，主要是基本的 日常的事務處理，例如銀行交...