系统集成
有奖讨论: 如何进行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同行回答
适合应用最好收起
浏览1525
如果记忆不错的话DPF已经是DWE缺省的一部分。就是说只要买了DWE就可以免费使用该功能。从这种搭配来看，也说明了DPF更适用于DWE。而且ibm也提供BCU（现在是isas)以备企业的未来扩展。对于DPF,有一些规则可以作为系统设计的start point。而这些规则都以active raw data 的大小为起点
CPU: 200-300G raw data per CPU
Memory: 4-8G per CPU
Logical Partition: 250G per db partition, at least 1 CPU per partition
Disk: 8-10 disks per CPU
主要优点在于并行和可扩展性，缺点是成本比单机要高。而且无法使用HADR, 只能用TSA提高High availability.
对于DPF database, 除系统level之外, DBA要考虑以下内容:
1) database partition group
2) bufferpool 和 db partition group的关系
3) tablespace 和 db partition group的关系
4) table distribution key定义
5) database partition backup收起
CPU: 200-300G raw data per CPU
Memory: 4-8G per CPU
Logical Partition: 250G per db partition, at least 1 CPU per partition
Disk: 8-10 disks per CPU
主要优点在于并行和可扩展性，缺点是成本比单机要高。而且无法使用HADR, 只能用TSA提高High availability.
对于DPF database, 除系统level之外, DBA要考虑以下内容:
1) database partition group
2) bufferpool 和 db partition group的关系
3) tablespace 和 db partition group的关系
4) table distribution key定义
5) database partition backup收起
浏览1500
浏览1487
在这里给大家推荐一本书:
Database Partitioning, Table Partitioning, and MDC for DB2 9
其中对DBF的创建、应用和性能特点讲的比较完整，且这3个特性对于olap应用的优势也有详细的论述
http://www.db2china.net/club/thread-2197-1-1.html收起
Database Partitioning, Table Partitioning, and MDC for DB2 9
其中对DBF的创建、应用和性能特点讲的比较完整，且这3个特性对于olap应用的优势也有详细的论述
http://www.db2china.net/club/thread-2197-1-1.html收起
浏览1490
感谢大家的积极讨论, 显然大家可能对dpf实际操作和使用经验不多, 我会及时总结, 将dbf最基础的操作和应用反馈给大家，
按照老规矩，本次对以下几名同学提出表扬，并奖励200米
fantasygod
kt563
fyhlove
最终书将颁给 飞天 老师！收起
按照老规矩，本次对以下几名同学提出表扬，并奖励200米
fantasygod
kt563
fyhlove
最终书将颁给 飞天 老师！收起
浏览1487
感谢大家的积极讨论, 显然大家可能对dpf实际操作和使用经验不多, 我会及时总结, 将dbf最基础的操作和应用反馈给大家，
按照老规矩，本次对以下几名同学提出表扬，并奖励200米
fantasygod
kt563
fyhlove
最终书将颁给 飞天 老师！收起
按照老规矩，本次对以下几名同学提出表扬，并奖励200米
fantasygod
kt563
fyhlove
最终书将颁给 飞天 老师！收起
浏览1541
数据库dpf的设计比较复杂，牵涉到很多存储，网络，操作系统方面的知识，例如光纤卡的吞吐量，每一个lv所跨的盘的数量， 存储是使用raid5 还是raid0+1，条带花怎么做等等。
经常遇到的dpf问题各种各样，分析起来要每一个节点的数据对比着看，收集数据的时候一定要每一个节点的都进行收集，否则找不到问题的rootcause收起
经常遇到的dpf问题各种各样，分析起来要每一个节点的数据对比着看，收集数据的时候一定要每一个节点的都进行收集，否则找不到问题的rootcause收起
浏览1546
DB2 数据库分区是 DB2 企业版 DPF(Data Partitioning Feature)选件提供的，它主要用来为大规模数据处理、高并发数据访问提供支持。DB2 数据库分区采用 Share-nothing 体系结构，数据库在一个非共享的环境中被分解为独立的分区，每个分区都具有自己的资源，例如内存，CPU 和磁盘以及自己的数据、索引、配置文件和事务日志。
数据通过 Hash 算法均允地散列到不同的分区内，每个分区只负责处理自己的数据。当用户发出 SQL 操作后，被连接的分区被称为 Coordinate Node，它负责处理用户的请求，并根据 Partition key 将用户的请求分解成多个子任务交由不同分区并行处理，最后将不同分区的执行结果经过汇总返回给用户，分区对应用来说是透明的。
在 DB2 中，数据库分区可以部署在集群或 MPP 环境下，也就是说数据库分区分布在不同的机器上;数据库分区也可以部署在同一台 SMP 机器上，在同一台机器上的分区我们称为逻辑分区。同时，我们还可以在集群或 MPP 环境下部署多个分区，在集群或 MPP 每一个节点上部署多个逻辑分区。
在规划 DB2 数据库分区时，我们需要考虑是通过增加逻辑分区还是物理分区来实现扩展能力。如果一台物理机器上有多个 CPU，其物理资源可以允许多个分区共享该资源，我们可以通过增加逻辑分区来实现扩展;如果一台物理机器上的物理资源不能满足应用需求，我们就需要通过增加机器，也就是物理分区来实现扩展能力。
设计数据库分区的基本原则是，尽量将大表分布在所有的分区上，提高并行处理能力;将小表放置在尽量少的分区上，一般是建议放在单一分区上;尽量减少分区间的通信。收起
数据通过 Hash 算法均允地散列到不同的分区内，每个分区只负责处理自己的数据。当用户发出 SQL 操作后，被连接的分区被称为 Coordinate Node，它负责处理用户的请求，并根据 Partition key 将用户的请求分解成多个子任务交由不同分区并行处理，最后将不同分区的执行结果经过汇总返回给用户，分区对应用来说是透明的。
在 DB2 中，数据库分区可以部署在集群或 MPP 环境下，也就是说数据库分区分布在不同的机器上;数据库分区也可以部署在同一台 SMP 机器上，在同一台机器上的分区我们称为逻辑分区。同时，我们还可以在集群或 MPP 环境下部署多个分区，在集群或 MPP 每一个节点上部署多个逻辑分区。
在规划 DB2 数据库分区时，我们需要考虑是通过增加逻辑分区还是物理分区来实现扩展能力。如果一台物理机器上有多个 CPU，其物理资源可以允许多个分区共享该资源，我们可以通过增加逻辑分区来实现扩展;如果一台物理机器上的物理资源不能满足应用需求，我们就需要通过增加机器，也就是物理分区来实现扩展能力。
设计数据库分区的基本原则是，尽量将大表分布在所有的分区上，提高并行处理能力;将小表放置在尽量少的分区上，一般是建议放在单一分区上;尽量减少分区间的通信。收起
浏览1552
一 确定数据库需求:
需要分析的内容包括:
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.需要根据测试及应用情况进行调整.收起
浏览1580