有奖讨论: 如何进行DPF(多分区数据库)数据库的规划与设计？

目前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主管，不要在这方面省钱，存侥幸心理不可取。