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

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

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

1. RAC

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

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

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

2. Data Guard

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

3. Streams

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

4. Partition

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

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

更加Detail的一些設計和維護準則：

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

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

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

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

5. 如果分區(qū)表Local Index能夠滿足性能需求，那么首選Local Index，即使Global Index可能帶來更少的Consistent Gets。因為Global Index最大的問題是分區(qū)操作時候必須rebuild index，通常這在性能和可維護性上都無法接受。

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

更多信息請查看IT技術專欄