数据库容量和内存测算的一些想法

参考于：http://blog.itpub.net/12679300/viewspace-1443818/

参考于：http://blog.sina.com.cn/s/blog_1533f3fb90102wktx.html

一、数据库容量估算

总体来说数据库容量核心分析对象还是数据库表，以及围绕数据库表的视图、索引、日志等相关附属信息。汇总这些信息后，再加上3–5年业务增长量给出数据库容量的评估。
1、单表单行数据库容量分析：
分析单表单行数据容量，就要分析各种数据库和各种数据类型占用字节的情况，比如Oracle数据库：
char类型多长就多少字节，Number类型最多按22个字节计算，平均按10个字节计算足够，varchar类型按长度2/3计算，date型占有7个字节。
按如上假设，如果一个客户表，有30个varchar（100），则一条客户记录是2k，10万客户信息则将近200M,每年30%的增长，则每年增加空间约60M。
 
2、索引空间评估：
一张表的索引空间一般是表空间的1/3，可以按照1/2表空间评估该表的索引存储空间。
 
3、数据库缓存容量：
数据库缓存（内存空间）一般为数据库空间的5%时性能较好。
 
4、内存容量空间需求分析：
首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。
 
5、机器系能：一般机器CPU达到70%系能较好，超出为过渡饱和，有系能隐患，低于的话，机器资源没有达到合理利用。
 
除此之外，分析数据库空间还有表日志空间、rollback空间、redo空间、临时空间等。

6、另外一种计算的方法

当系统运行一段时间之后（比如三个月），这时候已经很清楚当前的数据总量和占用的总空间大小，通过对未来的业务估算可以很容易的计算出未来1年、3年的整体数据库容量大小；

比如一个系统上线3个月后，数据库的大小达到了300GB，如果这三个月的业务属于正常范围，那么很容易计算出每个月差不多增长100个Gb，但是行业之间总是有差异的，比我鞋服行业就有分春夏和秋冬的区别，一件衣服夏天的和冬天的主数据量是不一样的，按这种方式会有比较大的误差，但是数据量级别应该是正确的，对于这种系统运行完一年之后进行容量的评估将会比较正确；

这种方法计算容量有一个很明显的弊端：需要在系统运行一段时间之后才能计算出来，但是这个时候相应的硬件和存储都已经采购完毕了，只能在一段时间之后进行扩容。

7、参考同行业同系统之间的数据容量

这是一个最便捷的办法，在上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、多少内存、多少存储，这些都是凭着系统的重要性和领导的重视程度、预算的多少，供应商当然也会提供相应的参考方案，但是他们提的方案肯定是越高越好的。

附：基本类型长度

（1）数值类型

（2）日期和时间类型

（3）字符串类型