系统集成
有奖讨论: 如何进行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 同行回答
在当今IT界，磁盘的读写速度还是赶不上内存和CPU读写的速度
使用DB2 dpf 就是减少磁盘的读写速度的瓶颈，在海量数据当中，这点体现的很明显。
Oracle RAC 是共享磁盘的方式，在高可用性方面，比较突出，
构建一个数据仓库,首要的条件必须对目前的现状进行详细的分析,对应用需求进行了解,
以及未来的发展做一个预估,这些决定了你选择哪种架构，要建立怎么样的一个数据库.系统可支撑的时
间?
构建经验
数据库需求
每天新增数据量，数据期限，系统的并发用户最大连接数，扩展性等等
硬件的选型及规划考虑
根据数据库需求和用户的情况，确定使用什么存储及存储的划分等。
数据库的规划及设计考虑
数据库设计成多少分区?每个分区几个CPU、内存等
数据库的日志使用情况及大小设置 收起
使用DB2 dpf 就是减少磁盘的读写速度的瓶颈，在海量数据当中，这点体现的很明显。
Oracle RAC 是共享磁盘的方式，在高可用性方面，比较突出，
构建一个数据仓库,首要的条件必须对目前的现状进行详细的分析,对应用需求进行了解,
以及未来的发展做一个预估,这些决定了你选择哪种架构，要建立怎么样的一个数据库.系统可支撑的时
间?
构建经验
数据库需求
每天新增数据量，数据期限，系统的并发用户最大连接数，扩展性等等
硬件的选型及规划考虑
根据数据库需求和用户的情况，确定使用什么存储及存储的划分等。
数据库的规划及设计考虑
数据库设计成多少分区?每个分区几个CPU、内存等
数据库的日志使用情况及大小设置 收起
我也来说两句。
抛开技术的问题，其实国内用户对新技术和新架构的使用主要是事件推动型的。特别是核心系统，在没有可能出现责任事故前，基本是较少动的，除非能论证风险是完全可控的，并且BOSS是言听计从的。 题外话，呵呵。
关于适用场景，设计，性能，备份，故障应急处置等各个方面前面大大们都提到了。
个人对多节点通讯问题比较关注（具体机制与原理方面有资料的建议贴个上来），这个问题目前最好的解决方案是不是通过硬件集成INFINIBAND网络，并通过RDMA访问来解决。
DB2 的PURESCALE方案（V9.8）从架构和原理上，个人认为不错，不知有谁用过， 能不能谈谈使用的心得？ 收起
抛开技术的问题，其实国内用户对新技术和新架构的使用主要是事件推动型的。特别是核心系统，在没有可能出现责任事故前，基本是较少动的，除非能论证风险是完全可控的，并且BOSS是言听计从的。 题外话，呵呵。
关于适用场景，设计，性能，备份，故障应急处置等各个方面前面大大们都提到了。
个人对多节点通讯问题比较关注（具体机制与原理方面有资料的建议贴个上来），这个问题目前最好的解决方案是不是通过硬件集成INFINIBAND网络，并通过RDMA访问来解决。
DB2 的PURESCALE方案（V9.8）从架构和原理上，个人认为不错，不知有谁用过， 能不能谈谈使用的心得？ 收起
以前，32bit limit, large db 不得不走DPF.
Nowadays, 64bit + Compression + Table Partition, 很多大系统都不必走DPF了。
不过DPF是DB2特有的， 有pro 有con， 值得保持：） 收起
Nowadays, 64bit + Compression + Table Partition, 很多大系统都不必走DPF了。
不过DPF是DB2特有的， 有pro 有con， 值得保持：） 收起
歇几天不看，好多大牛留言啊。见识增长不少。
分区间通信确实头疼，这个和原业务系统的数据有很大的关系。我们现在因为是在一台LPAR上的分区库，性能虽有所下降，但比网络间的要好很多。不过做多机器节点的肯定是个趋势，要不这么大数据量怎么弄。
我们目前8core+64G，4个分区，3T左右的数据，压力有点大啊。随着数据量增长，优化也是个问题。 收起
分区间通信确实头疼，这个和原业务系统的数据有很大的关系。我们现在因为是在一台LPAR上的分区库，性能虽有所下降，但比网络间的要好很多。不过做多机器节点的肯定是个趋势，要不这么大数据量怎么弄。
我们目前8core+64G，4个分区，3T左右的数据，压力有点大啊。随着数据量增长，优化也是个问题。 收起
这个，第一个应该是应用场景吧，OLTP的基本不会用DPF。
第二个数数据量
OLAP数据量不大的（比如1TB以下，单表最大在千万级左右的）也不会考虑DPF。
一般考虑DPF的是数据量比较大的。
第三个应该是应用需求。
需要做复杂分析，或者进行大数据量批处理的（加载，ETL）等会选择DPF。
其实DPF最好的应用场景在于那些OLAP与OLTP混合负载的应用。
分区数量，这个没有固定规则，基本上就是根据数据量和并发用户量估一估CPU和内存，再做一点
压力测试。CPU与内存的配比一般1：4或1：8。1个CORE划一个逻辑分区。
不知道你有没有什么更好的规则可以分享一下。 收起
第二个数数据量
OLAP数据量不大的（比如1TB以下，单表最大在千万级左右的）也不会考虑DPF。
一般考虑DPF的是数据量比较大的。
第三个应该是应用需求。
需要做复杂分析，或者进行大数据量批处理的（加载，ETL）等会选择DPF。
其实DPF最好的应用场景在于那些OLAP与OLTP混合负载的应用。
分区数量，这个没有固定规则，基本上就是根据数据量和并发用户量估一估CPU和内存，再做一点
压力测试。CPU与内存的配比一般1：4或1：8。1个CORE划一个逻辑分区。
不知道你有没有什么更好的规则可以分享一下。 收起
第一回差点抢了沙发，leo老兄手蛮快的。
dpf特性运用在lpar上是不得以了，国内客户的后台模型设计，特别是分布键的选择优劣与否直接带给分区数据库的分区间通信量大小，要是通过网络，估计网络开销还是蛮大的。
其实分区数据库和非分区数据库的一些操作都差不多，网络上面也不乏一些操作分区数据库的资料。想办法搭建个，实践把就熟练了。
:) 收起
dpf特性运用在lpar上是不得以了，国内客户的后台模型设计，特别是分布键的选择优劣与否直接带给分区数据库的分区间通信量大小，要是通过网络，估计网络开销还是蛮大的。
其实分区数据库和非分区数据库的一些操作都差不多，网络上面也不乏一些操作分区数据库的资料。想办法搭建个，实践把就熟练了。
:) 收起
目前我们数据仓库的架构是SMP Cluster（3台服务器集群），外围数据集市架构是SMP。仓库的数据量超过8个T（大表全部为压缩表），外围的数据集市在去年做了一次压缩操作，目前的数据量在3.5T左右。采用的都是P570服务器，目前的应用性能还可以，没有太大的瓶颈问题。但随着时间的推移，数据量的不断加大，存储和性能调优问题应该会不断涌现，这也是目前必须要考虑的。还有一点正如飞天老师说到的备份问题，目前不管是仓库还是外围数据集市都没有做数据库级的备份，因此一旦出现灾难性事故，问题将非常严重，在跟客户不断的沟通和讨论之后，上周开始准备做HA，以防万一。 收起
目前DB2的DPF特性，我所接触的几乎全是海量数据仓库系统，数据量基本都是10T以上的，所在行业主要是移动、联通、电信的仓库分析系统，以及部分银行仓库系统，还有几家电力公司。最大的广东移动，数据量突破800T了，10台小机。
从工作以来，参与了大概5套DPF数据仓库的规划、设计，DPF性能调优和故障处理就更多了（不下于15个）。有一点体会，与大家分享，希望对各位有所帮助。也希望有越来越多的系统使用DPF。
1. 物理规划极其关键。比如节点数的选择，CPU/Memory硬件资源，以及HBA卡容量，存储规划设计等。不同的存储设备，规划有所不同，所以不能完全按照IBM红皮书的最佳实践，而是遵循着让存储性能发挥最佳的角度考虑。我们去年参与了一个200T的数据仓库设计，开始的方案按照IBM红皮书，每个节点分配独立的VG（包含独立的盘组），性能不佳；后来让一组节点共享底层的更多盘组，这样数据在磁盘上的分布更均匀，性能比以前提升了1倍（Load性能由80MB/s提升到170MB/s）。
2. 性能调优。多分区的系统，通常数据量巨大，性能往往是瓶颈，因此需要从多个角度考虑性能。比如分区键选择很关键，能有效避免分区间数据传输，减少网络和资源消耗。另外，还有很多优化技术，比如压缩、索引、MQT，MDC等。不同的问题，尝试不同的方法，依赖这些技术，还是解决了很多性能问题。
3. 问题处理。多分区系统的问题处理比较麻烦，因此思路很关键。通常是要先定位到哪个分区的问题，然后再不停的细化，最终定位。去年在某通信行业客户遇到的load hang问题，最终定位到是pre-partition节点问题。还有，某客户网络出现问题后，重启DB2实例起不来，最终确定是第2台机器包含的节点，主机名没有加到/etc/hosts。多分区的问题，除了遇到的DB2自身的bug，很多是由于网络问题引起。分析的思路很关键，db2trc/db2 stack都是分析问题的好东西。
4. 备份很关键。通信行业，几乎每年都会遇到大的故障，最终导致要导数据/重建库的情况。比如，磁盘损坏，日志破坏，日志lsn到达上限，以及人为造成的失误等。由于数据量巨大，很多客户不对仓库做数据库级备份，一旦出现问题，将是无比可怕。因此，强烈呼吁IT主管，不要在这方面省钱，存侥幸心理不可取。 收起
从工作以来，参与了大概5套DPF数据仓库的规划、设计，DPF性能调优和故障处理就更多了（不下于15个）。有一点体会，与大家分享，希望对各位有所帮助。也希望有越来越多的系统使用DPF。
1. 物理规划极其关键。比如节点数的选择，CPU/Memory硬件资源，以及HBA卡容量，存储规划设计等。不同的存储设备，规划有所不同，所以不能完全按照IBM红皮书的最佳实践，而是遵循着让存储性能发挥最佳的角度考虑。我们去年参与了一个200T的数据仓库设计，开始的方案按照IBM红皮书，每个节点分配独立的VG（包含独立的盘组），性能不佳；后来让一组节点共享底层的更多盘组，这样数据在磁盘上的分布更均匀，性能比以前提升了1倍（Load性能由80MB/s提升到170MB/s）。
2. 性能调优。多分区的系统，通常数据量巨大，性能往往是瓶颈，因此需要从多个角度考虑性能。比如分区键选择很关键，能有效避免分区间数据传输，减少网络和资源消耗。另外，还有很多优化技术，比如压缩、索引、MQT，MDC等。不同的问题，尝试不同的方法，依赖这些技术，还是解决了很多性能问题。
3. 问题处理。多分区系统的问题处理比较麻烦，因此思路很关键。通常是要先定位到哪个分区的问题，然后再不停的细化，最终定位。去年在某通信行业客户遇到的load hang问题，最终定位到是pre-partition节点问题。还有，某客户网络出现问题后，重启DB2实例起不来，最终确定是第2台机器包含的节点，主机名没有加到/etc/hosts。多分区的问题，除了遇到的DB2自身的bug，很多是由于网络问题引起。分析的思路很关键，db2trc/db2 stack都是分析问题的好东西。
4. 备份很关键。通信行业，几乎每年都会遇到大的故障，最终导致要导数据/重建库的情况。比如，磁盘损坏，日志破坏，日志lsn到达上限，以及人为造成的失误等。由于数据量巨大，很多客户不对仓库做数据库级备份，一旦出现问题，将是无比可怕。因此，强烈呼吁IT主管，不要在这方面省钱，存侥幸心理不可取。 收起