資料庫容量和記憶體測算的一些想法

前言：本文件主要針對資料庫的容量和效能估算，結合網上的一些文章，整理如下：

 

一、資料庫容量的計算

1、資料庫容量核心分析物件是資料庫表，及配合資料庫表的包括檢視、索引、日誌等相關的附屬資訊。

資料庫在計算資料庫容量的時候提供了一個可計算的理論模型：資料庫表是由col組成的，每個col都有相應的長度，可以算出每行的佔用空間，再根據業務的情況，可以算出每個表每月或者每天的增長量。資料庫中所有表的大小總量根據這個模型也就可以計算出來了；

例ORACLE資料庫來說：char型別是多少位元組就多少位元組，而varchar型別可變長可以按2/3長度折算。number型別可變長度最多佔用22位元組，平均按10位元組估算足夠。date型別佔用7位元組。

進行粗略計算的時候可以直接參考ORACLE的資料字典，指令碼如下：

select *　from user_tab_columns where table_name='MSEG';

 

也可以通過資料字典計算的每行的平均長度進行計算

select num_rows,blocks,avg_row_len from dba_tables  where table_name='MSEG';

 

通過以上的辦法可以得出初略的計算出每個表的大小，同時根據經驗值，索引佔用的總大小差不多為表總大小的1/3，這樣大概就可以計算出整個資料庫的總大小了。由於ORACLE資料型別的多樣，表的數量繁多，所以通過這種方式進行空間的計算需要大量的工作，但是這至少提供了一種評估的模型；

 

2、另外一種計算的方法

當系統執行一段時間之後（比如三個月），這時候已經很清楚當前的資料總量和佔用的總空間大小，通過對未來的業務估算可以很容易的計算出未來1年、3年的整體資料庫容量大小；

比如一個系統上線3個月後，資料庫的大小達到了300GB，如果這三個月的業務屬於正常範圍，那麼很容易計算出每個月差不多增長100個Gb，但是行業之間總是有差異的，比我鞋服行業就有分春夏和秋冬的區別，一件衣服夏天的和冬天的主資料量是不一樣的，按這種方式會有比較大的誤差，但是資料量級別應該是正確的，對於這種系統執行完一年之後進行容量的評估將會比較正確；

 

這種方法計算容量有一個很明顯的弊端：需要在系統執行一段時間之後才能計算出來，但是這個時候相應的硬體和儲存都已經採購完畢了，只能在一段時間之後進行擴容。

 

3、參考同行業同系統之間的資料容量

這是一個最便捷的辦法，在上SAP之前公司內部最大的系統資料也才500GB左右，所以在腦子裡面對資料容量的大小也是一直停留在百GB的水平，剛好同行業中的其他公司也上了SAP，經過了解他們上SAP的模組和我們差不多，執行一段時間之後資料量已經達到了TB的水平了，每天資料的增長量是GB級別，這樣一下子對整個系統的資料量級別有了個很明顯的認識。在採購硬體的時候就不會有太大的偏差。

 

二、記憶體需求的計算

涉及到記憶體的快取命中率的關係，資料庫系統的記憶體的分配跟資料庫總容量大小有很大的關係，行業的經驗是當快取容量達到資料庫總容量的5%時效能較好，因此確定了資料庫的大小之後快取的大小也就可以的出來了。

例如在aix平臺下面一個1TB的資料庫

1、作業系統本身所佔用的記憶體 128MB

2、應用程式所佔的記憶體   256MB

3、資料庫快取 50GB

4、合理的記憶體利用率75%

總計 67GB

考慮到資料的儲存時間5年（一般3到5年要做一個資料結轉），因此資料庫最大容量有可能達到5TB，所以該主機的記憶體達到300GB可以滿足未來5年的業務需求。

 

總結：站得高尿得遠，dba主動去考慮一下整體的it架構需求，當這種思考點多了站的高度也就高了。因為整個IT架構裡面dba屬於一個很重要的崗位，效能的規劃、儲存容量的規劃只有dba最清楚，當dba不參與的時候，就變成了“猜”，根據系統的重要性去採買硬體、幾個cpu、多少記憶體、多少儲存，這些都是憑著系統的重要性和領導的重視程度、預算的多少，供應商當然也會提供相應的參考方案，但是他們提的方案肯定是越高越好的。

當it的領導不懂技術的時候，dba的價值有時候就會被低估，當dba自身的高度提升到it的管理層面的時候，這個時候自身的價值才能充分展示出來，因為有些工作除你dba，其他人做的都沒你好。

........................................................................................................................................................................

本文作者：JOHN，某上市公司DBA，業餘時間專注於資料庫的技術管理，從管理的角度去運用技術。

ORACLE技術部落格：ORACLE 獵人筆記               資料庫技術群：367875324 （請備註ORACLE管理 ） 

........................................................................................................................................................................

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