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

這是一個很大的題目，牽涉到從硬件到軟件，從應用設計到數據庫設計的方方面面，足夠寫一本厚厚的書，其實，我們的夢想不就是有一個維護簡單，擴展性良好，性能優秀的系統嗎?

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

1. RAC

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

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

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

2. Data Guard

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

3. Streams

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

4. Partition

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

那么對于上面那樣一個系統，我的建議數據庫架構是雙節點RAC + Physical Standby + Partition，也許應用只會使用到RAC中的一個節點，但是仍然需要RAC;也許這份健壯的存儲永遠不會壞，我們仍然需要Data Guard，至少RMAN備份不用占據產品數據庫的資源;也許單表數據只有幾G，即使索引全掃描也仍然可以接受，我們仍然要分區。

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

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

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

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

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

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

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

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