系统集成
有奖讨论: 如何进行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 同行回答
一 确定数据库需求:
需要分析的内容包括:
1,系统每日的数据增量,入库多少,汇总生成的中间表以及结果数据量.
2,数据的保存期限,是否分历史库与当前库多个库结合?
2,系统的支撑并发用户最大连接数?系统的及时性要求?
3,系统未来的扩展能力,系统需要支撑的年限?
二 硬件的选型及规划
1,主机的处理能力,通常需要结合应用情况了解主机的TPMC值.确定主机.
2,存储的选型,是否全部选用高端存储,如DSS8000系列,还是采用如DSS4000系统或者SATA盘等中低端相结合的存储以节省硬件投入.
3存储的划分是?采用RAID 5还是RAID10?建议对数据库系统表空间等重要数据采用RAID
的方式,而数据采用RAID5,以节省硬件投入.
4存储能达到的最大的带库及IOPS.这决定了以后数据库能达到的最大的IO吞吐量.尽量保证每个数据库节点的IO带库是一致的.这非常重要,如果不一致的话会导致,由于单个节点的IO带宽比其它节点慢而拖慢了整个数据库.
5 DB2 DPF 不同机器节点间的数据是通过网络进行传输,需要重点考虑网络能达到的最大的传输速度.是否需要多张网络进行绑定.做EtherChannel.需不需要打开Jumbol frame .
三 数据库的规划及设计
1,DB2数据库版本的选择
2,数据库需要设计成多少个分区？每个分区几个cpu,多少内存,多少IO带宽？
按照IBM的官方建议,是二个CPU跑一个分区.如果环境允许的话建议采用这样的方式进行设计
3,确定数据库的日志使用情况,是否需要归档还是循环日志方式.日志的大小需要多大,需要多少个文件?备用的日志文件需要多大?这需要根据应用的情况,评估最大的应用需要的日志量并结合应用的并发情况确定.如果日志设计不当,往往很容易导致数据库事务日志满的故障出现.虽然日志可以在后序修改增加.但建议先做好细致的设计然后在测试前做调整.上线后就可以避免很多的日志方面的故障.
四 表空间设计
1) 确定表空间的分配规划,是否需要多个表空间,数据与索引尽量分开表空间存放.
2) 表空间LV的划分需要结合存储带宽必须保证每个节点是一致的,独立的,系统表空间以及用户临时表空间也需要重点考虑.
3) 建完数据库后系统会自动创建一个TEMPSPACE1和一个USESPACE1.建议把这二个表空间删除.以免以后数据据使用到这二个表空间而导致的报错及文件系统满的故障.根据应用的需求建立系统临时表空间.
4) 表空间的PAGE SIZE大小如何选择?使用4K或者8K,16K.32K.这里要注意在DB2 8中有255条记录一个页面的限制，所以需要结合表的字段大小来决定.在DB2 v9的large table space已经限制已经大大放宽.
5) 表空间container是否选择裸设备还是文件系统,是否选择DMS或者是SMS表空间类型.建议数据表空间容器尽量采用裸设备及DMS表空间类型.至于临时表空间可以考虑使用文件系统及SMS表空间.
6) 在多节点情况下,需要考虑是否建立单节点组的表空间放一些临时汇总用到的维表等小表数据而不用把表打散到多个分区上,加快表的关联速度.同时需要考虑0节点是否放数据,由于0节点会做为协调分区,建议0节点尽量不要放数据.
五 数据库参数调整及应用测试
1) 数据库的bufferpools大小设定,bufferpools的大小需要根据主机配置来设定,建议根据每台主机内存情况尽量多的内存用来做bufferpools.提高数据库性能.
如果系统资源允计的话,建议把接近一半的内存分配用于bufferpools.
2) 应用测试过程中,尽量慢慢把并发的个数压到最高,并收集每台主机的运行情况,IO,CPU,内存使用情况.重点检查每台主机的资源利用情况是否一致.
3) 打开数据库的分区内并行测试以检验系统是否需要打开分区内并行.如果节点比较多的话建议不要打开分区内并行.
4) 数据库相关重要的参数调整,sortheat,locktimeout,locklist.需要根据测试及应用情况进行调整. 收起
需要分析的内容包括:
1,系统每日的数据增量,入库多少,汇总生成的中间表以及结果数据量.
2,数据的保存期限,是否分历史库与当前库多个库结合?
2,系统的支撑并发用户最大连接数?系统的及时性要求?
3,系统未来的扩展能力,系统需要支撑的年限?
二 硬件的选型及规划
1,主机的处理能力,通常需要结合应用情况了解主机的TPMC值.确定主机.
2,存储的选型,是否全部选用高端存储,如DSS8000系列,还是采用如DSS4000系统或者SATA盘等中低端相结合的存储以节省硬件投入.
3存储的划分是?采用RAID 5还是RAID10?建议对数据库系统表空间等重要数据采用RAID
的方式,而数据采用RAID5,以节省硬件投入.
4存储能达到的最大的带库及IOPS.这决定了以后数据库能达到的最大的IO吞吐量.尽量保证每个数据库节点的IO带库是一致的.这非常重要,如果不一致的话会导致,由于单个节点的IO带宽比其它节点慢而拖慢了整个数据库.
5 DB2 DPF 不同机器节点间的数据是通过网络进行传输,需要重点考虑网络能达到的最大的传输速度.是否需要多张网络进行绑定.做EtherChannel.需不需要打开Jumbol frame .
三 数据库的规划及设计
1,DB2数据库版本的选择
2,数据库需要设计成多少个分区？每个分区几个cpu,多少内存,多少IO带宽？
按照IBM的官方建议,是二个CPU跑一个分区.如果环境允许的话建议采用这样的方式进行设计
3,确定数据库的日志使用情况,是否需要归档还是循环日志方式.日志的大小需要多大,需要多少个文件?备用的日志文件需要多大?这需要根据应用的情况,评估最大的应用需要的日志量并结合应用的并发情况确定.如果日志设计不当,往往很容易导致数据库事务日志满的故障出现.虽然日志可以在后序修改增加.但建议先做好细致的设计然后在测试前做调整.上线后就可以避免很多的日志方面的故障.
四 表空间设计
1) 确定表空间的分配规划,是否需要多个表空间,数据与索引尽量分开表空间存放.
2) 表空间LV的划分需要结合存储带宽必须保证每个节点是一致的,独立的,系统表空间以及用户临时表空间也需要重点考虑.
3) 建完数据库后系统会自动创建一个TEMPSPACE1和一个USESPACE1.建议把这二个表空间删除.以免以后数据据使用到这二个表空间而导致的报错及文件系统满的故障.根据应用的需求建立系统临时表空间.
4) 表空间的PAGE SIZE大小如何选择?使用4K或者8K,16K.32K.这里要注意在DB2 8中有255条记录一个页面的限制，所以需要结合表的字段大小来决定.在DB2 v9的large table space已经限制已经大大放宽.
5) 表空间container是否选择裸设备还是文件系统,是否选择DMS或者是SMS表空间类型.建议数据表空间容器尽量采用裸设备及DMS表空间类型.至于临时表空间可以考虑使用文件系统及SMS表空间.
6) 在多节点情况下,需要考虑是否建立单节点组的表空间放一些临时汇总用到的维表等小表数据而不用把表打散到多个分区上,加快表的关联速度.同时需要考虑0节点是否放数据,由于0节点会做为协调分区,建议0节点尽量不要放数据.
五 数据库参数调整及应用测试
1) 数据库的bufferpools大小设定,bufferpools的大小需要根据主机配置来设定,建议根据每台主机内存情况尽量多的内存用来做bufferpools.提高数据库性能.
如果系统资源允计的话,建议把接近一半的内存分配用于bufferpools.
2) 应用测试过程中,尽量慢慢把并发的个数压到最高,并收集每台主机的运行情况,IO,CPU,内存使用情况.重点检查每台主机的资源利用情况是否一致.
3) 打开数据库的分区内并行测试以检验系统是否需要打开分区内并行.如果节点比较多的话建议不要打开分区内并行.
4) 数据库相关重要的参数调整,sortheat,locktimeout,locklist.需要根据测试及应用情况进行调整. 收起
我也来说两句。
抛开技术的问题，其实国内用户对新技术和新架构的使用主要是事件推动型的。特别是核心系统，在没有可能出现责任事故前，基本是较少动的，除非能论证风险是完全可控的，并且BOSS是言听计从的。 题外话，呵呵。
关于适用场景，设计，性能，备份，故障应急处置等各个方面前面大大们都提到了。
个人对多节点通讯问题比较关注（具体机制与原理方面有资料的建议贴个上来），这个问题目前最好的解决方案是不是通过硬件集成INFINIBAND网络，并通过RDMA访问来解决。
DB2 的PURESCALE方案（V9.8）从架构和原理上，个人认为不错，不知有谁用过， 能不能谈谈使用的心得？ 收起
抛开技术的问题，其实国内用户对新技术和新架构的使用主要是事件推动型的。特别是核心系统，在没有可能出现责任事故前，基本是较少动的，除非能论证风险是完全可控的，并且BOSS是言听计从的。 题外话，呵呵。
关于适用场景，设计，性能，备份，故障应急处置等各个方面前面大大们都提到了。
个人对多节点通讯问题比较关注（具体机制与原理方面有资料的建议贴个上来），这个问题目前最好的解决方案是不是通过硬件集成INFINIBAND网络，并通过RDMA访问来解决。
DB2 的PURESCALE方案（V9.8）从架构和原理上，个人认为不错，不知有谁用过， 能不能谈谈使用的心得？ 收起