大型資料庫(T level)管理

litterbaby發表於2007-11-10
大型資料庫(T level)管理[@more@]

大型資料庫T管理

談談自己的想法:
在分析這個問題的時候,需要看這個資料庫是OLTP,OLAP還是DSS,不同的型別管理的側重應該是不一樣的。

資料庫的規劃:

對於大多數資料庫來說,之所以這個資料庫能夠上T,是因為一個或者多個表的資料量比較大,而資料量比較大的表的數量一般不是很多,這是因為在資料庫開始規劃的時候就應該考慮到這些問題。一般來說會根據功能,IO,或者表的大小等將資料庫split。

在資料庫的規劃階段還需要注意的問題是有可能成為大表的兩個或者幾個大表之間的連線問題,一般來說系統出現效能問題很大程度上是兩個大表之間的jion產生的,所以表尤其是大表,在OLTP的環境下應該儘量的簡單,不能將這個表的業務層面上設計的過於複雜,這個一方面建立的索引會比較多,影響DML操作。另一方面過於複雜在jion的時候會影響效能的提高。

大表的分割槽:
將大表進行分割槽應該是一個不錯的選擇,但是分割槽表是一個雙刃劍,需要注意分割槽鍵的選擇,因為表的分割槽是需要一定的技巧,選擇不適當的分割槽鍵會對效能產生不好的影響,更甚的是有可能不能實現Oracle所說的分割槽表的好處:易於管理,高可用性,高效能,因此分割槽表使用的技巧是能否使用好分割槽表這個功能的關鍵。

IO的分配:
T級的資料庫一般來說是使用SAN來實現,這裡面牽涉到RAID型別的選擇,一般來說使用RAID01比RAID5有更好的效能,但是開銷也隨之增大,同時SAN的配置問題也是一個比較重要的問題,例如cache上讀和寫之間比例的問題在不同的OLTP和DSS資料庫上是不一樣的。還有就是條帶化,條帶的寬度大小的選擇需要資料庫上的塊的大小,exent大小相關。
還有資料檔案,日誌檔案和臨時,回滾檔案的物理磁碟分配的問題,儘量做到物理IO的均衡。

資料庫的備份與恢復
T級的資料庫一般來說由於資料量比較大,全資料庫的備份的頻率比較低,一般採用增量備份,需要一個合理,安全,完整,易行的備份策略來保證備份的完成,這裡面需要重要注意的問題有兩個:1、備份檔案的可用性,需要檢查備份集是否可用。2、增量備份的速度,合理利用Oracle的新特性來提高備份速度。

備份資料庫的建立和資料庫的容災也應該是大型資料庫需要考慮的問題之一。

日常操作:
T級資料庫的日常操作和平常的資料庫的操作實現上,需要注意的問題就是,由於資料量很大,一個操作可能小資料量的資料庫上幾分鐘就能夠完成的事情,但是在T級的資料庫上可能要幾十甚至幾個小時,幾天的時間,由於時間過長會引起過長共享資源的佔用和鎖的產生,這樣會影響其他事務的執行,所以在進行日常操作的時候,需要事先預見一下這個操作可能產生的影響,如果會對其他會話產生較大影響的話,可以考慮分階段執行這個命令,儘量不要對系統的允許產生較大的影響。

資料的遷移:
可以將大表上不使用的資料刪除,或者遷移到其他的備用資料庫上,但是這一點還是需要根據業務的需要來實際操作,如果分割槽表使用的恰當的話,這些應該就不是問題。

SQL最佳化
這一部分應該是比較重要的,尤其是牽涉到大表,做一些統計之類的SQL最佳化,將是你資料庫效能重要表現之一,有幾個原則,1、儘量減少對大表的訪問次數,尤其是全表掃描。2、可以使用Oracle的一些特性,例如分析函式的使用。3、一些不常使用,但是執行時間較長的SQL可以考慮不使用繫結變數。4、業務上的考慮。

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

相關文章