系统集成
有奖讨论: 如何进行DPF(多分区数据库)数据库的规划与设计？
目前数据库集群模式在 OLAP / OLTP 方面的高性能、高可靠性和可扩展性特点，已越来越多应用在关键性业务系统数据库架构设计中。
DPF 是 Database Partition Feature的简称, 也就是DB2的多分区数据库. 做为 Share nothing 架构的代表 (Oracle RAC Share Disk 架构的代表)，其在数据库的规划和设计需要重点考虑哪些环节和内容？
作为DBA的我们如何去实际操作和问题的及时应对呢？
本期我们就来讨论这个主题，希望大家有的放矢，各抒己见。
活动时间：2012.7.16-2012.7.23
活动奖励：
1：讨论结束后选出五位讨论最积极的会员赠送 200 米
2：选出一位讨论最认真的会员赠送书籍《DB2重点解析-DBA篇》一本
------------------------------------------------------------------------------------
此次有奖讨论的获奖名单已经出来了，因为此次讨论话题要求参与者对DPF都有一定的了解或者是实际经验，因此限制了一部分人的参与，因此我们从20多项互动中只选出了四位获奖名单。
三位讨论最积极的会员：
fantasygod
kt563
fyhlove
每人获得奖励200大米。
讨论最认真的会员：
飞天
获得《DB2重点解析-DBA篇》一本
后续大家也可以在里面进行互动，继续加分哦。
DPF 是 Database Partition Feature的简称, 也就是DB2的多分区数据库. 做为 Share nothing 架构的代表 (Oracle RAC Share Disk 架构的代表)，其在数据库的规划和设计需要重点考虑哪些环节和内容？
作为DBA的我们如何去实际操作和问题的及时应对呢？
本期我们就来讨论这个主题，希望大家有的放矢，各抒己见。
活动时间：2012.7.16-2012.7.23
活动奖励：
1：讨论结束后选出五位讨论最积极的会员赠送 200 米
2：选出一位讨论最认真的会员赠送书籍《DB2重点解析-DBA篇》一本
------------------------------------------------------------------------------------
此次有奖讨论的获奖名单已经出来了，因为此次讨论话题要求参与者对DPF都有一定的了解或者是实际经验，因此限制了一部分人的参与，因此我们从20多项互动中只选出了四位获奖名单。
三位讨论最积极的会员：
fantasygod
kt563
fyhlove
每人获得奖励200大米。
讨论最认真的会员：
飞天
获得《DB2重点解析-DBA篇》一本
后续大家也可以在里面进行互动，继续加分哦。
28 同行回答
第一回差点抢了沙发，leo老兄手蛮快的。
dpf特性运用在lpar上是不得以了，国内客户的后台模型设计，特别是分布键的选择优劣与否直接带给分区数据库的分区间通信量大小，要是通过网络，估计网络开销还是蛮大的。
其实分区数据库和非分区数据库的一些操作都差不多，网络上面也不乏一些操作分区数据库的资料。想办法搭建个，实践把就熟练了。
:) 收起
dpf特性运用在lpar上是不得以了，国内客户的后台模型设计，特别是分布键的选择优劣与否直接带给分区数据库的分区间通信量大小，要是通过网络，估计网络开销还是蛮大的。
其实分区数据库和非分区数据库的一些操作都差不多，网络上面也不乏一些操作分区数据库的资料。想办法搭建个，实践把就熟练了。
:) 收起
dpf这个特性我们只在olap环境中搭建过，一般还是要根据分配给该数据库的硬件资源来考虑的。新建系统的架构设计，硬件资源比较充裕些，设计方案也可以比较好看，(^-^)，估计集成厂商和ibm原厂商也很喜欢的。
734原版资料上面也有相关介绍，实际工作中也可以借鉴下分配原理，切莫照搬。
上次看到一个资料，主要就是bcu和bpu的思想，最基本的一个物理cpu一个分区即可，cpu：mem=1:4【内存充裕的话可以更多点】，io设计保证每10块磁盘【lun】有个1G的带宽【我们是两块4g的hba卡，基本不用太愁】，当然可以更高些，这样分区数基本就定下来了。
有条件的话，最好编目分区和数据分区区分开来，鉴于share nothing的架构理念，为各个分区设置单独的日志路径【日志存储设备最好独立于数据存储设备】。缓冲池和表空间设计方面，数据表空间在数据节点均匀分布即可，有些作业控制信息表，维表，等其他可能不需要分区表空间，做成单节点表空间即可。临时表空间基本跟着表空间的页大小和数据节点设计，建议使用文件系统并关闭表空间的文件系统缓存。
由于olap系统的数据量可是很大的，做好hsm的规划。最重要的一点就是这点了，高频访问数据【1年内更新＆＆特殊数据】，一般访问数据【1－3年】，较少访问的数据【3-5年】，基本5年以上的数据就要转出备份上带。各类数据划分上有点主观，各个行业特征和监管不一样，不必一概而论。
在数据库备份方案选择上，要想省事就说服你的boss做db全备吧，开循环日志。不然也可以选择开启归档日志，启用表空间备份，重要且比较小的表空间全备就行了，数据量比较大的表空间可以增备或者差备，不怎么更新的表空间【却要提供数据服务】定期全备即可。不需要提供数据服务的历史数据，说服你的boss，导出上带吧，节约空间。
说了一堆废话，前不久在p595上的一个lpar上部了个4个节点的查询库【资源够少的：4C,32G,4T】，查询速度不算很理想，4块盘并发读也只在250M/s左右，写大概是在120M/s。峰值咱就不说了，存储管理员叫好多次了。大家请评论下，是否还有提升的空间。
该p595上有6个lpar，分配到该lpar的有2个hba卡，四块存储【10000转*3,1500*1】 收起
734原版资料上面也有相关介绍，实际工作中也可以借鉴下分配原理，切莫照搬。
上次看到一个资料，主要就是bcu和bpu的思想，最基本的一个物理cpu一个分区即可，cpu：mem=1:4【内存充裕的话可以更多点】，io设计保证每10块磁盘【lun】有个1G的带宽【我们是两块4g的hba卡，基本不用太愁】，当然可以更高些，这样分区数基本就定下来了。
有条件的话，最好编目分区和数据分区区分开来，鉴于share nothing的架构理念，为各个分区设置单独的日志路径【日志存储设备最好独立于数据存储设备】。缓冲池和表空间设计方面，数据表空间在数据节点均匀分布即可，有些作业控制信息表，维表，等其他可能不需要分区表空间，做成单节点表空间即可。临时表空间基本跟着表空间的页大小和数据节点设计，建议使用文件系统并关闭表空间的文件系统缓存。
由于olap系统的数据量可是很大的，做好hsm的规划。最重要的一点就是这点了，高频访问数据【1年内更新＆＆特殊数据】，一般访问数据【1－3年】，较少访问的数据【3-5年】，基本5年以上的数据就要转出备份上带。各类数据划分上有点主观，各个行业特征和监管不一样，不必一概而论。
在数据库备份方案选择上，要想省事就说服你的boss做db全备吧，开循环日志。不然也可以选择开启归档日志，启用表空间备份，重要且比较小的表空间全备就行了，数据量比较大的表空间可以增备或者差备，不怎么更新的表空间【却要提供数据服务】定期全备即可。不需要提供数据服务的历史数据，说服你的boss，导出上带吧，节约空间。
说了一堆废话，前不久在p595上的一个lpar上部了个4个节点的查询库【资源够少的：4C,32G,4T】，查询速度不算很理想，4块盘并发读也只在250M/s左右，写大概是在120M/s。峰值咱就不说了，存储管理员叫好多次了。大家请评论下，是否还有提升的空间。
该p595上有6个lpar，分配到该lpar的有2个hba卡，四块存储【10000转*3,1500*1】 收起