DBCA建庫四個選項的區別------定製數據庫 數據倉庫 通常用途 事務處理

10G數據庫模型：

11g數據庫模型：

定製數據庫=自定義

數據倉庫=OLAP

通常用途=兼顧OLAP和OLTP

事務處理=OLTP

====================詳細介紹========================

Oracle OLAP和OLTP介紹 

數據處理大體能夠分紅兩大類：聯機事務處理OLTP(On-line Transaction Processing）和聯機分析處理OLAP(On-line Analytical Processing )。OLTP是傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果。

OLTP: 系統強調數據內存效率，強調內存各類指標的命令率，強調綁定變量，強調併發操做；

OLAP: 系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

什麼是OLTP

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

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來串行化用戶的操做。當一個用戶得到了lacth後，其餘用戶就只能等待，獲取這個數據塊的用戶越多，等待就越明顯。這就是熱塊的問題。這種熱快多是數據塊，也多是回滾端塊。對於數據塊來說，一般是數據庫的數據分佈不均勻致使，若是是索引的數據塊，能夠考慮建立反向索引來達到從新分佈數據的目的，對於回滾段數據塊，能夠適當多增長几個回滾段來避免這種爭用。

什麼是OLAP

 OLAP,也叫聯機分析處理（Online Analytical Processing）系統，有的時候也叫DSS決策支持系統，就是咱們說的數據倉庫。在這樣的系統中，語句的執行量不是考覈標準，由於一條語句的執行時間可能會很是長，讀取的數據也很是多。因此，在這樣的系統中，考覈的標準每每是磁盤子系統的吞吐量（帶寬），如能達到多少MB/s的流量。

磁盤子系統的吞吐量則每每取決於磁盤的個數，在這個時候，Cache基本是沒有效果的，數據庫的讀寫類型基本上是db file scattered read與direct path read/write。應儘可能採用個數比較多的磁盤以及較大的帶寬，如4Gb的光纖接口。

在OLAP系統中，常採用分區技術、並行技術。

（1）分區技術在OLAP系統中的重要性主要體如今數據管理上，好比數據庫加載，能夠經過分區交換的方式實現，備份能夠經過備份分區表空間實現，刪除數據能夠經過分區進行刪除，至於分區在性能上的影響，它可使得一些大表的掃描變得很快（只掃描單個分區）。另外，若是分區結合並行的話，也可使得整個表的掃描變得很快。總之，分區只要的功能是管理上的方便性，它並不能絕對保證查詢性能的提升，有時候分區會帶來性能上的提升，有時候會下降。

（2）並行技術除了與分區技術結合外，在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的優化很是重要，由於它的數據量很大，作全表掃描和索引對性能上來講差別是很是大的。