Db2 pureScale GDPC数据库双活技术方案设计中如何规划和设计系统的数据容量、访问容量?

规划和设计系统的数据容量、访问容量也是要和单机环境来比对的。同样资源条件下双活的数据库成员节点与单数据库相比执行事务会慢一些，所以访问容量要降低一些。当多节点访问同样的数据的时候，又会有一定的竞争关系，所以整体容量在单member的估算总和上还要再降低一些。至于这个度，因为业务的工作负载关系会有很大不同。有热点数据降低会明显，没有热点数据则影响很小。所以访问容量的估算要低。双活数据库是共享存储架构，这个访问能力受到整体存储能力的限制。所以要从存储的吞吐量去估算性能容量。

我理解主要有几个原则吧：
1、PureScale的双活技术方案适用于联机交易系统（OLTP），对于分析类的系统(OLAP)并非最优方案，OLAP可以选择多分区（DPF）。因此决定了PureScale不建议运行活动的数据量庞大的业务系统。除非定期归档历史数据。
2、系统数据容量一般包括以下几类：
a)、数据库容量：通常根据业务发展的数据量进行评估，一般至少满足未来三年的业务发展，可与开发团队业务团队一起讨论确定。
b)、数据库日志容量：包括活动日志归档日志等，跟每天的增删改的交易频度相关以及日志清理策略相关。可以通过每天的变化数据计算得到。
c)、数据库管理容量：包括软件安装目录，实例目录，diag目录等，100G够用。
除了软件安装目录，其他目录都是建在GPFS上的。因此对于GPFS的磁盘分配，最好保证三类容量不同时访问一块物理磁盘，以免产生热点盘。同时也需要兼顾后续的GPFS文件系统扩容的性能均衡。
3、对于访问容量，简单粗暴的方式就是计算实例分配到的可用内存除以每连接所需的内存大小算出最大交易并发。但实际上purescacle的性能效率跟应用交易的类型和访问方式有很大的关联性，建议在上线投产前，针对业务交易做压力测试，才是最好的方法，并且做好访问容量扩展的线性度的测试。