| 導購 | 订阅 | 在线投稿
分享
 
 
 

詳細講解Oracle I/O子系統的配置和設計

來源:互聯網  2008-06-01 03:14:55  評論

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

在我們設計數據庫的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系統的索引,因爲很容易産生索引葉子塊的相互競爭。

很多人都知道,Oracle IO子系統是數據庫中一個非常重要的組成部分。 由于很多軟件系統的瓶頸都是由DISK IO引起的,系統花費了大量的CPU_TIMES用于等待I/O行爲的完成。 在我們設計數據庫的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系統的索引,因爲很容易産生索引葉子塊的相互競爭。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有