收到一個(gè)命題，2TB容量的數(shù)據(jù)，1000并發(fā)，7*24的系統(tǒng)，如果就可維護(hù)性，可擴(kuò)展性和系統(tǒng)性能幾方面考慮，該如何進(jìn)行系統(tǒng)設(shè)計(jì)。

這是一個(gè)很大的題目，牽涉到從硬件到軟件，從應(yīng)用設(shè)計(jì)到數(shù)據(jù)庫(kù)設(shè)計(jì)的方方面面，足夠?qū)懸槐竞窈竦臅?，其?shí)，我們的夢(mèng)想不就是有一個(gè)維護(hù)簡(jiǎn)單，擴(kuò)展性良好，性能優(yōu)秀的系統(tǒng)嗎?

7*24意味著對(duì)于高可用性的要求嚴(yán)格，那么Oracle數(shù)據(jù)庫(kù)在高可用性方面的選項(xiàng)包括哪些呢?

1. RAC

也許很多人仍然對(duì)于RAC抱有懷疑，就跟很多人對(duì)于RAC抱有迷信一樣，持有RAC的性能還不如單節(jié)點(diǎn)這樣論調(diào)的人跟持有性能不好實(shí)施RAC就能解決這樣論調(diào)的人恐怕人數(shù)不相伯仲。

其實(shí)RAC在性能因素上對(duì)于應(yīng)用的提升僅僅是一個(gè)方面，RAC對(duì)于高可用性的貢獻(xiàn)才是真正無(wú)可替代的，目前我還不知道有任何其它一種技術(shù)可以當(dāng)Oracle數(shù)據(jù)庫(kù)的一個(gè)實(shí)例損壞的時(shí)候(比如主機(jī)的網(wǎng)卡出現(xiàn)故障或者主機(jī)根文件系統(tǒng)被充滿導(dǎo)致機(jī)器沒(méi)有響應(yīng)等等)另外一個(gè)實(shí)例可以立刻頂上并提供服務(wù)。普通的HA做不到，Data Guard做不到，Streams也同樣做不到。

RAC多節(jié)點(diǎn)能夠提供數(shù)據(jù)庫(kù)軟件滾動(dòng)升級(jí)，對(duì)于Oracle11g之前的數(shù)據(jù)庫(kù)來(lái)說(shuō)這個(gè)功能大大減少了系統(tǒng)down機(jī)時(shí)間，當(dāng)然實(shí)際上Data Guard也可以做到這點(diǎn)，不過(guò)即使是Data Guard也仍然有一個(gè)Switchover的過(guò)程，這仍然需要更多一些的down機(jī)時(shí)間。

2. Data Guard

RAC的所有節(jié)點(diǎn)持有同樣一份數(shù)據(jù)文件，那么對(duì)于RAC來(lái)說(shuō)，致命的故障可能發(fā)生在盤陣的損壞或者連接盤陣的光纖交換機(jī)損壞，這種情況下有多少個(gè)節(jié)點(diǎn)也無(wú)濟(jì)于事，因?yàn)閿?shù)據(jù)文件出問(wèn)題了。而Data Guard彌補(bǔ)的是這方面的需求，兩個(gè)或者多個(gè)實(shí)例，兩份或者多份存儲(chǔ)，在一個(gè)實(shí)例一份存儲(chǔ)壞掉的情況下，可以通過(guò)Failover或者Switchover命令來(lái)進(jìn)行主備角色的互換。同時(shí)延時(shí)Apply功能在Oracle還沒(méi)有大大增強(qiáng)Flashback的前幾個(gè)版本中也同樣有很大的實(shí)用價(jià)值。

3. Streams

個(gè)人認(rèn)為Streams終將取代Advanced Replication，即使不提及Streams使用AQ技術(shù)而AR使用數(shù)據(jù)字典表來(lái)做延遲隊(duì)列這兩種技術(shù)的孰優(yōu)孰劣，僅僅從最近幾個(gè)版本的Oracle數(shù)據(jù)庫(kù)對(duì)AR沒(méi)有做任何加強(qiáng)這一點(diǎn)上也可以求得佐證。當(dāng)然，物化視圖的刷新由于其操作的簡(jiǎn)單性以及技術(shù)的成熟性在今后很長(zhǎng)一段時(shí)間內(nèi)應(yīng)該還會(huì)繼續(xù)成為多個(gè)數(shù)據(jù)庫(kù)實(shí)例之間同步數(shù)據(jù)的有效手段。

4. Partition

為什么這里要提到分區(qū)?因?yàn)榇蠖鄶?shù)人認(rèn)為分區(qū)帶來(lái)的是性能提升，但是實(shí)際上我們認(rèn)為分區(qū)帶來(lái)的最大好處是高可用性的提升，誠(chéng)然，正確地使用分區(qū)以及分區(qū)索引會(huì)帶來(lái)性能上的提升，帶來(lái)擴(kuò)展性的提升，但是即使這些不是我們考慮的問(wèn)題，為了一個(gè)系統(tǒng)能夠有優(yōu)越的高可用性，仍然強(qiáng)烈建議使用分區(qū)技術(shù)來(lái)規(guī)劃數(shù)據(jù)庫(kù)。舉一個(gè)最簡(jiǎn)單的例子，當(dāng)我們要卸載歷史數(shù)據(jù)的時(shí)候，分區(qū)的DDL操作比起對(duì)于整表數(shù)據(jù)的DML操作而言帶來(lái)的高可用性的提升無(wú)疑是巨大的。

那么對(duì)于上面那樣一個(gè)系統(tǒng)，我的建議數(shù)據(jù)庫(kù)架構(gòu)是雙節(jié)點(diǎn)RAC + Physical Standby + Partition，也許應(yīng)用只會(huì)使用到RAC中的一個(gè)節(jié)點(diǎn)，但是仍然需要RAC;也許這份健壯的存儲(chǔ)永遠(yuǎn)不會(huì)壞，我們?nèi)匀恍枰狣ata Guard，至少RMAN備份不用占據(jù)產(chǎn)品數(shù)據(jù)庫(kù)的資源;也許單表數(shù)據(jù)只有幾G，即使索引全掃描也仍然可以接受，我們?nèi)匀灰謪^(qū)。

更加Detail的一些設(shè)計(jì)和維護(hù)準(zhǔn)則：

1. 并發(fā)度1000，這并不代表會(huì)有1000進(jìn)程同時(shí)操作同一個(gè)data block，所以對(duì)于表和索引的inittrans設(shè)計(jì)可以參考V$SEGMENT_STATISTICS視圖中的ITL waits值，V$SEGMENT_STATISTICS是Oracle9i之后很有用的但是經(jīng)常被大家忽略掉的性能視圖。

2. Segment使用LMT且uniform size，避免system automatic size可能產(chǎn)生的空間碎片，這要求我們能夠?qū)τ赟egment的可能大小在設(shè)計(jì)階段就又預(yù)估，大小相差懸殊的Segment分配到uniform size不同的表空間中去。

3. 對(duì)于高并發(fā)的操作在應(yīng)用層面予以控制，詳細(xì)的文章可以參見Piner的這篇 - 并發(fā)容易出現(xiàn)的問(wèn)題和并發(fā)的控制。

4. 注意約束和索引之間的互相影響，對(duì)于一個(gè)業(yè)務(wù)繁忙，任何維護(hù)操作都可能是在業(yè)務(wù)繁忙期進(jìn)行的系統(tǒng)，盡量避免約束和索引之間的相互影響。比如創(chuàng)建唯一性約束，我們可以先創(chuàng)建普通索引，再創(chuàng)建唯一性約束using index，這樣操作的好處在于刪除約束的時(shí)候不會(huì)影響索引，這里的關(guān)鍵思想是，約束用于控制商業(yè)邏輯，索引用于控制系統(tǒng)性能，邏輯和性能是要分開的，商業(yè)邏輯可能發(fā)生變化，然后性能不能因?yàn)樯虡I(yè)邏輯的變化而受到影響。這小小的一點(diǎn)考慮卻涵蓋了可維護(hù)性，可擴(kuò)展性和系統(tǒng)性能三個(gè)方面。

5. 如果分區(qū)表Local Index能夠滿足性能需求，那么首選Local Index，即使Global Index可能帶來(lái)更少的Consistent Gets。因?yàn)镚lobal Index最大的問(wèn)題是分區(qū)操作時(shí)候必須rebuild index，通常這在性能和可維護(hù)性上都無(wú)法接受。

6. 使用Oracle 10g吧，從Oracle 10g到Oracle 11g，高可用性的提升有目共睹，各種online操作增強(qiáng)，各種阻塞的影響面減少，各種性能診斷工具的易用性，不是說(shuō)9i不好，而是10g更強(qiáng)(這句話說(shuō)的太像Oracle員工了，抱歉)。

更多信息請(qǐng)查看IT技術(shù)專欄