很多人都知道，Oracle IO子系統(tǒng)是數(shù)據(jù)庫中一個非常重要的組成部分。 由于很多軟件系統(tǒng)的瓶頸都是由DISK IO引起的，系統(tǒng)花費了大量的CPU_TIMES用于等待I/O行為的完成。

在我們設(shè)計數(shù)據(jù)庫的IO子系統(tǒng)的時候，應(yīng)該考慮以下因素：

■ 存儲，最小的磁盤容量

■ 可用性，諸如(24 x 7) 不間斷的服務(wù)

■ 性能，諸如I/O的吞吐量和系統(tǒng)響應(yīng)時間

基本的IO設(shè)計

使用操作系統(tǒng)或者硬件來條帶化文件存儲，如果你的操作系統(tǒng)有類似LVM和硬件striping,的化，那么使用它們來盡可能的分散IO。在striping中，要考慮兩個要素：stripe width 和stripe depth

■ Stripe depth 指的stripe的大小,也被稱為stripe unit。

■ Stripe width 指的stripe depth 和 stripe設(shè)定中驅(qū)動器的數(shù)目的乘積。

在Oracle數(shù)據(jù)庫中，一個合理的stripe depths 應(yīng)該在256KB到1M。不同類型的應(yīng)用需要不同stripe depth，最理想的stripe depth 和 stripe width應(yīng)該考慮以下：

■ I/O請求的大小

■ 同時發(fā)生I/O

■ Physical Stripe Boundaries 和 Block Size Boundaries

■ Manageability of the Proposed System

I/O請求的大小

下面是在配置I/O會用DB和OS參數(shù)：

DB_BLOCK_SIZE：單塊I/O請求的大小，也被用于診斷多塊I/O請求。

OS block size：操作系統(tǒng)塊的大小

Maximum OS I/O size：OS能提供的最大單塊I/O的大小

DB_FILE_MULTIBLOCK_READ_COUNT：它和DB_BLOCK_SIZE的積用于計算全表掃描最大I/O，注意能超過OS限制。默認(rèn)為8。

SORT_AREA_SIZE：排序操作需要的I/O大小

HASH_AREA_SIZE：hash操作需要的I/O大小

出了I/O大小外，并發(fā)度也決定了stripe的depth。在選擇stripe width和stripe depth的時候請考慮以下因素：

■在低并發(fā)的系統(tǒng)中，確保在同一磁盤上不會發(fā)生重復(fù)單一的I/O。這是什么意思呢？例如，假設(shè)stripe width有4個磁盤，stripe depth

是32KB，這時候Oracle server process發(fā)出一個1MB的I/O請求，那么每個磁盤都會返回8次I/O請求。為了盡量避免這種情況，平均I/O請求的大小應(yīng)該小于stripe width×stripe depth，在這里是32KB×4，否則就會在一個磁盤發(fā)生第二次I/O。

這是完全理想化的設(shè)計。

■在高并發(fā)的系統(tǒng)中，要確保單一的I/O請求會被分散到多個物理I/O中完成，如果不行，則會嚴(yán)重的影響系統(tǒng)響應(yīng)時間。

并發(fā)的I/O

在OLTP系統(tǒng)中，特點是高并發(fā)和低I/O需求，這時最好Stripe depth大于一個單獨I/O的大小，這種被稱為粗顆粒stripe。

在高并發(fā)的系統(tǒng)中，一般stripe depth設(shè)計為n×DB_BLOCK_SIZE,n>1.

粗顆粒stripe設(shè)計使得磁盤可以以隊列的方式同時執(zhí)行多個I/O，這樣就可以以最小的成本處理大量的并發(fā)I/O。不過，一旦系統(tǒng)不具備并發(fā)足夠并發(fā)，就會導(dǎo)致磁盤熱點。

粗顆粒stripe設(shè)計也同樣有益于DSS系統(tǒng)，但它應(yīng)該設(shè)計得小一點，同樣它大小也為n×DB_BLOCK_SIZE，但n應(yīng)該小于DB_FILE_MULTIBLOCK_READ_COUNT。

而細(xì)顆粒設(shè)計能夠獲得最好的響應(yīng)時間。

Alignment of Physical Stripe Boundaries with Block Size Boundaries

如果物理stripe顆粒和塊大小一致的化，就可能會導(dǎo)致一個單獨I/O分散到兩個物理IO中。這不是最優(yōu)化的OLTP環(huán)境，所以stripe最好是兩倍BLOCK的大小。下面是關(guān)于大小的建議：

Random reads and writes 兩倍BLOCK大小

Sequential reads 兩倍DB_FILE_MULTIBLOCK_READ_COUNT×DB_BLOCK_SIZE

Manageability of the Proposed System

使用LVM可以更加容易配置所有可用磁盤的stripe，在大多數(shù)環(huán)境下，單卷就可以提供良好的性能。不過單卷只在使用RAID技術(shù)的時候可用，如RAID 1，不過丟失一個卷卷意味著丟失所有卷。

除了了性能以外，還有一個問題要考慮，那就是數(shù)據(jù)的增加要容易擴展。

手工分布I/O

如果你的系統(tǒng)不能做stripe，那么你就要手工配置你文件來達到盡量均勻分布I/O的目的。

1.檢查磁盤和文件的大小，估計數(shù)據(jù)庫的存儲需求

2.為每個文件預(yù)估I/O，分辨出高I/O和低I/O的文件，將它們分布到磁盤組中。

這里存在一個誤解，就是把index和data分開，這是不恰當(dāng)?shù)?。因為在一個事務(wù)的過程中，是先訪問索引，再訪問表，它們是有序的，所以在同一磁盤中是沒有競爭的。這個是很多人都曾經(jīng)誤解的，包括我。

什么時候需要分割文件

這個問題很簡單，當(dāng)I/O需求已經(jīng)不能被滿足的時候，將可能需要分割文件。

I/O熱點一般發(fā)生在table、index或者TEMP TABLESPACE,造成I/O過高的大多數(shù)原因是由于SQL，這個時候需要做SQL tuning。其它：

Redo log file如果發(fā)生很高的I/O，考慮把它們單獨放置到一個磁盤，或者分布到幾個磁盤，這樣還可以提高可用性。

stripe它們的存儲環(huán)境。避免使用RAID5。

archived redo log，如果歸檔慢，則要考慮歸檔進程和LGWR的競爭。

建議

stripe所有的磁盤

移動歸檔文件到不同的磁盤

移動在線日志到單獨的磁盤

使用Oracle管理文件可以獲得更多益處。

最后，講一講數(shù)據(jù)塊大小的選擇。

8K是適合于大多是系統(tǒng)的，但是有時候OLTP系統(tǒng)使用更小，DSS使用更大的數(shù)據(jù)塊可以提供更優(yōu)的性能。

READS

如何行比較小，訪問比較隨機，選擇較小的塊

如果行比較小，訪問是連續(xù)的，選擇較大的塊

如果行比較小，訪問情況復(fù)雜，盡量選擇較大的塊

如果行比較大，包含諸如LOB類型的字段，那么選擇較大塊WRITES

在一個高并發(fā)的OLTP系統(tǒng)中，使用一個大塊，那么要慎重的考慮INITRANS,

MAXTRANS, 和FREELISTS設(shè)置。這些參數(shù)影響到一個塊的并發(fā)更新率。不過，如果你使用自動段空間管理，則不用考慮FREELISTS。如果你還是不能確定塊的大小，那么就使用8K，如果你大量使用LOB類型，那么就可以大于8k。

小結(jié)：一般來說，小塊減少鎖競爭，適合隨機訪問，但是元數(shù)據(jù)管理需要很大的頭空間，不適合大行，容易產(chǎn)生行鏈。大塊，可以存儲更多的數(shù)據(jù)，減少管理開銷，適合連續(xù)的訪問和存儲LOB類型，但是浪費空間大，不適合存儲OLTP系統(tǒng)的索引，因為很容易產(chǎn)生索引葉子塊的相互競爭。