前言 

決定應(yīng)該賦予數(shù)據(jù)庫什么樣的存儲(chǔ)和 配置，已經(jīng)成為一項(xiàng)雜亂無章的工作，這種現(xiàn)象我見得多了。數(shù)據(jù)庫工程師一般都是數(shù)據(jù)庫的專家，而對于存儲(chǔ)配置的低層細(xì)節(jié)幾乎一無所知。另外存儲(chǔ)管理員和工 程師也往往不知道數(shù)據(jù)庫如何利用下層的存儲(chǔ)，以及數(shù)據(jù)庫、索引文件、記錄文件，當(dāng)然還有文件系統(tǒng)和卷管理器的需求和最佳配置又是什么。 

這往往造成了存儲(chǔ)資源利用率低，增加了整體成本，導(dǎo)致性能降低甚至可能無法滿足你的需求，此外預(yù)算也總是很緊張，而管理上又要求有效地利用可獲得的預(yù)算。本文將解決數(shù)據(jù)庫管理員和存儲(chǔ)工程師在解決架構(gòu)問題而進(jìn)行協(xié)作時(shí)的一些問題。 

數(shù)據(jù)庫與存儲(chǔ)架構(gòu)配置 

組件 

大部分?jǐn)?shù)據(jù)庫的端到端存儲(chǔ)架構(gòu)所需硬件和軟件如下： 

數(shù)據(jù)庫 

控制文件(Control file) 

表空間(Table space) 

索引文件(Index file) 

重做日志(亦稱在線日志，Redo log) 

操作系統(tǒng) 

文件系統(tǒng)和卷管理器(如果數(shù)據(jù)庫運(yùn)行在裸設(shè)備上，這一項(xiàng)可能沒有關(guān)系) 

主機(jī)總線適配器(HBA) 

存儲(chǔ)硬件 

以上每一部分都擁有多個(gè)組件，具有多種特性和功能，對整體性能影響顯著。 

數(shù)據(jù)庫 

數(shù)據(jù)庫應(yīng)用本身具有多重特性和功能，必須加以考慮。Oracle的組件如下： 

控制文件----記錄數(shù)據(jù)庫的物理結(jié)構(gòu)，用于激活數(shù)據(jù)庫 

表空間----來自數(shù)據(jù)庫各行各列的實(shí)際數(shù)據(jù) 

索引文件/空間----Oracle中并不需要索引，不過大型數(shù)據(jù)庫總會(huì)用到索引，因?yàn)樵跀?shù)據(jù)庫中進(jìn)行查找時(shí)，索引可以大幅提升查找速度 

重做日志----被激活的數(shù)據(jù)庫請求，允許你在數(shù)據(jù)庫崩潰后進(jìn)行重建并重新啟動(dòng)(這些日志本質(zhì)上類似于文件系統(tǒng)日志) 

因?yàn)樯鲜鼋M件都有不同類型的訪問模式，所以每種文件類型均被存儲(chǔ)在不同的文件系統(tǒng)中，并有調(diào)節(jié)選項(xiàng)。其它數(shù)據(jù)庫也擁有相似的文件類型，需要以相似的方式考慮。 

控制文件 

大部分?jǐn)?shù)據(jù)庫都建議使用多個(gè)控制文件以確保可靠性。控制文件并不需要常寫常讀，不過你必須確定各文件被放置在不同的RAID集上，適用于不同的RAID控制器。 

表空間 

表空間一般是數(shù)據(jù)庫中量最大的數(shù)據(jù)。當(dāng)讀取列上的大表時(shí)，表空間可以由更大的I/O請求訪問。根據(jù)大小和更新頻率的不同，表空間常常位于更大的數(shù)據(jù)條帶化RAID-5上，以便獲得較RAID-1更高的密度和提升的性能。 

索引文件/空間 

在許多數(shù)據(jù)庫中，索引文件是被訪 問頻率最高的數(shù)據(jù)。查找索引文件有可能需要很大的IOPS(每秒I/O操作)。另外，有時(shí)候數(shù)據(jù)庫被重新索引，這在計(jì)算上非常密集，并且需要大量的I/O 帶寬。因?yàn)閿?shù)據(jù)庫和所需的查找類型不同，索引空間也許會(huì)很大，一般來說，根據(jù)傳統(tǒng)的UNIX文件尺寸，索引文件的大小為2 GB。 

重做日志

重做日志文件中存放了各種記錄，你可以撤銷對數(shù)據(jù)庫的各種操作，這些被稱為重做記錄。重做記錄用于循環(huán)緩沖器中，因?yàn)樗�一般是小I/O，所以用RAID-1就不錯(cuò)。由于需要兩個(gè)或以上的重做日志文件，通常將日志文件放在不同的RAID-1卷上。

 

操作系統(tǒng)

數(shù)據(jù)庫一般都需要具備操作系統(tǒng)的一些特性和功能，如共享內(nèi)存和標(biāo)志等。另外，數(shù)據(jù)庫也經(jīng)常利用計(jì)算機(jī)內(nèi)大量的內(nèi)存，這通常由改變數(shù)據(jù)庫中的可調(diào)參數(shù)來實(shí)現(xiàn)。

在許多操作系統(tǒng)中，I/O請求的大小限制在256 KB或128 KB，不能改變，所以如果必須對存儲(chǔ)和操作系統(tǒng)完成更多的請求，就會(huì)影響到I/O性能。

文件系統(tǒng)和卷管理器

 

架構(gòu)決策中最重要的事情之一就是為每個(gè)數(shù)據(jù)庫組件確定最理想的卷管理器和文件系統(tǒng)設(shè)置，對于每種類型的I/O，你可能希望進(jìn)行不同的設(shè)置，請考慮以下的I/O類型：

 

長和短的連續(xù)塊

長和短的多重?cái)?shù)據(jù)流塊

所有的讀

所有的寫

 

多線程

對所有這些類型的I/O來說，只有一組設(shè)置的文件系統(tǒng)表現(xiàn)得都不好，而且我敢說對于上述任何兩種類型的I/O來說，只有一組可調(diào)參數(shù)的文件系統(tǒng)也無法做好，也不可能通過改變參數(shù)來提升性能。

 

設(shè)計(jì)中要確定的兩個(gè)關(guān)鍵因素是：

 

1.對于所要處理的I/O類型，什么是最好的卷管理器和文件系統(tǒng)

 

2.對于該文件系統(tǒng)和卷管理器，什么又是最好的可調(diào)參數(shù)

 

幾年前我曾做過一個(gè)數(shù)據(jù)庫，由于一些原因而無法進(jìn)行擴(kuò)展，不過我認(rèn)為其中最主要的原因是RAID緩存在進(jìn)行索引查找時(shí)未得到有效利用。RAID的讀訪問率小于20%，而且我認(rèn)為大部分是不規(guī)則的連續(xù)讀(先對幾個(gè)請求連續(xù)讀，然后隨機(jī)跳過幾個(gè)，又開始連續(xù)讀)。

檢查卷管理器后，我發(fā)現(xiàn)了問題所在。每個(gè)文件系統(tǒng)有32個(gè)LUN(邏輯單元號(hào))，每個(gè)LUN為8 GB。文件系統(tǒng)上的數(shù)據(jù)條設(shè)置為32 KB，與RAID分配相符。每個(gè)索引文件是2 GB。

考慮到RAID緩存的工作方式，你必須先讀兩個(gè)連續(xù)塊再讀第三個(gè)塊，這是常用的算法，因此在下一個(gè)I/O到達(dá)緩存之前，需要32 KB*32 LUN*2，即2 MB的連續(xù)讀數(shù)據(jù)。

RAID緩存利用率如此低下并不奇怪。客戶被告知他們有兩個(gè)辦法提升性能，一是為卷管理器數(shù)據(jù)條分配2 GB，這樣每個(gè)索引文件均被連續(xù)分配;二是使用另一種文件系統(tǒng)，可以使數(shù)據(jù)進(jìn)行循環(huán)而不是條帶化。循環(huán)狀態(tài)下，每個(gè)開放的系統(tǒng)請求都會(huì)被分配給另一個(gè)LUN，并且被打開的文件中所有數(shù)據(jù)也都會(huì)被分配在那個(gè)LUN上。

當(dāng)我們使用循環(huán)分配方法和讀緩存測試這種配置時(shí)，訪問率從20%上升到80%，性能也超過了當(dāng)時(shí)客戶的要求。