在我們設計數據庫的IO子系統的時候，應該考慮以下因素：

■ 存儲，最小的磁盤容量

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

■ 性能，諸如I/O的吞吐量和系統響應時間

基本的IO設計

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

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

■ Stripe width 指的stripe depth 和 stripe設定中驅動器的數目的乘積。

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

■ I/O請求的大小

■ 同時發生I/O

■ Physical Stripe Boundaries 和 Block Size Boundaries

■ Manageability of the PRoposed System

I/O請求的大小

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

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

OS block size：操作系統塊的大小

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

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

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

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

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

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

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

這是完全理想化的設計。

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

并發的I/O

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

在高并發的系統中，一般stripe depth設計為n×DB_BLOCK_SIZE,n>1.

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

粗顆粒stripe設計也同樣有益于DSS系統，但它應該設計得小一點，同樣它大小也為n×DB_BLOCK_SIZE，但n應該小于DB_FILE_MULTIBLOCK_READ_COUNT。

而細顆粒設計能夠獲得最好的響應時間。

Alignment of Physical Stripe Boundaries with Block Size Boundaries

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

Random reads and writes 兩倍BLOCK大小

Sequential reads 兩倍DB_FILE_MULTIBLOCK_READ_COUNT×DB_BLOCK_SIZE

Manageability of the Proposed System

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

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

手工分布I/O

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

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

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

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

什么時候需要分割文件

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

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

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

stripe它們的存儲環境。避免使用RAID5。

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

建議

stripe所有的磁盤

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

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

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

最后，講一講數據塊大小的選擇。

8K是適合于大多是系統的，但是有時候OLTP系統使用更小，DSS使用更大的數據塊可以提供更優的性能。

READS

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

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

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

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

在一個高并發的OLTP系統中，使用一個大塊，那么要慎重的考慮INITRANS,

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

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