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

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

■ 存儲(chǔ)，最小的磁盤(pán)容量

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

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

基本的IO設(shè)計(jì)

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

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

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

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

■ I/O請(qǐng)求的大小

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

■ Physical Stripe Boundaries 和 Block Size Boundaries

■ Manageability of the Proposed System

I/O請(qǐng)求的大小

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

DB_BLOCK_SIZE：?jiǎn)螇KI/O請(qǐng)求的大小，也被用于診斷多塊I/O請(qǐng)求。

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

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

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

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

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

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

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

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

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

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

并發(fā)的I/O

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

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

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

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

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

Alignment of Physical Stripe Boundaries with Block Size Boundaries

如果物理stripe顆粒和塊大小一致的化，就可能會(huì)導(dǎo)致一個(gè)單獨(dú)I/O分散到兩個(gè)物理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可以更加容易配置所有可用磁盤(pán)的stripe，在大多數(shù)環(huán)境下，單卷就可以提供良好的性能。不過(guò)單卷只在使用RAID技術(shù)的時(shí)候可用，如RAID 1，不過(guò)丟失一個(gè)卷卷意味著丟失所有卷。

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

手工分布I/O

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

1.檢查磁盤(pán)和文件的大小，估計(jì)數(shù)據(jù)庫(kù)的存儲(chǔ)需求

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

這里存在一個(gè)誤解，就是把index和data分開(kāi)，這是不恰當(dāng)?shù)摹Ｒ驗(yàn)樵谝粋€(gè)事務(wù)的過(guò)程中，是先訪問(wèn)索引，再訪問(wèn)表，它們是有序的，所以在同一磁盤(pán)中是沒(méi)有競(jìng)爭(zhēng)的。這個(gè)是很多人都曾經(jīng)誤解的，包括我。

什么時(shí)候需要分割文件

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

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

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

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

archived redo log，如果歸檔慢，則要考慮歸檔進(jìn)程和LGWR的競(jìng)爭(zhēng)。

建議

stripe所有的磁盤(pán)

移動(dòng)歸檔文件到不同的磁盤(pán)

移動(dòng)在線日志到單獨(dú)的磁盤(pán)

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

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

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

READS

如何行比較小，訪問(wèn)比較隨機(jī)，選擇較小的塊

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

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

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

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

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

小結(jié)：一般來(lái)說(shuō)，小塊減少鎖競(jìng)爭(zhēng)，適合隨機(jī)訪問(wèn)，但是元數(shù)據(jù)管理需要很大的頭空間，不適合大行，容易產(chǎn)生行鏈。大塊，可以存儲(chǔ)更多的數(shù)據(jù)，減少管理開(kāi)銷，適合連續(xù)的訪問(wèn)和存儲(chǔ)LOB類型，但是浪費(fèi)空間大，不適合存儲(chǔ)OLTP系統(tǒng)的索引，因?yàn)楹苋菀桩a(chǎn)生索引葉子塊的相互競(jìng)爭(zhēng)。