移动经分系统DB2 DPF高可用如何实现？

node 0为什么crash？应该是db2自己crash。双机热备主要是预防硬件掉电或者当机，在这个场景感觉没必要。

你说的这种情况确实是目前比较典型和常见的现象，我暂且称它是现象而不是故障。之所以称它为现象而不是故障，这是根据数据仓库的应用特点和DPF的share nothing 架构来说的。

我所见到的数据仓库，大多是在系统层面做了HA，比如AIX的HACMP、Linux的RHCS等，以保证当一台服务器出现故障时的资源切换，然而在实际的生产中貌似是很少切换的，除非是故障的服务器真的不可用了才会去切，因为切换动作比较大，一般需要经过层层审批，需要惊动领导，还有就是切换后真的跑得很慢。

这种做法也是基于数据仓库的应用特点实行的，不像在线交易系统，必须保证7*24小时online。所以个人认为没有必要一发生节点crash，就马上进行切换。实际情况下，一般都有故障处理的级别的，节点切换必然是很高的故障级别才需要做的。

至于您提到的HA实施的方案，例如hacmp，rhcs，网上有很多，官网也有教程，应该不难找到。

一点愚见，分享一下了，希望有帮助吧。

从实际情况来看，部署了DB2 DPF的都没真的做HA，嘿嘿。实施太复杂。所以这样的架构实际中经常被挖苦不论主机还是存储都构成单点。

理论上用GPFS的跨存储复制+TSA+cold standby节点做吧，相对实施简单点，也不会HA failover以后有性能损失。具体参考pure data for operational analytic架构。不过这东西是理论上存在，实际上有谁做过么？高度怀疑。

DPF本身就是share nothing的。你想一个节点crash了，其它节点继续服务？这个目前来说确实做不了。再说，crash后的CR，时间也不会特别长。

DB2 DPF为数据仓库OLAP设计，实时性要求没有OLTP那么严格，也没有很好的高可用方案。

我们有完善的DPF高可用解决方案，通过GPFS文件系统，实现数据共享，同时通过TSAMP配置数据分区的切换。这一套方案已经在客户现场用过了，包括TSAMP脚本和GPFS实施步骤，还可以通过GPFS复制实现数据冗余。整个过程比较复杂，很难几句话描述清楚，如果有需要的话可以联系我们： chenck@newdt.cn, 18601359047, 我们公司核心成员都来自IBM，主要做DB2数据库的咨询服务。

前段时间就是因为一个复杂的SQL导致NODE 0直接crash掉，导致整个库不可用，有没有一种可靠的方案为DPF环境提供高可用

双机互备也解决不了这个问题。

DB2自带的TSAMP就行了。可以双机互备；设置VIP。文件系统推荐GPFS

aix和linux有办法用gpfs的failure group ，hpux不太清楚