【kamus】Oracle系統設計兩三言

收到一個命題，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員工了，抱歉)。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/1384/viewspace-330940/，如需轉載，請註明出處，否則將追究法律責任。