【核心议题四】OLTP下的DB2 PureScale VS ORACLE RAC对比探讨

我不懂DB2，只从oracle的角度上来说一下吧。

1、实质上，oracle推出RAC（早期叫ops），强调的是其高可用性，而不是可伸缩性。要充分发挥RAC的性能，应用必须针对RAC的特点进行编程（数据分割及数据路由），否则性能反而下降。远的说，01-02年，那时候江西绿卡系统用的是oracle 7 OPS，在结息的时候都是跑单实例；近期的，象双11，我们的某些系统也是单实例在跑（11.2.0.4 rac+asm）

2、在rac环境下，之前在单实例上不是问题的部分也会引起性能问题，最典型的就是gc类等待事件了，等待从行级锁放大到块级等待，象大集中期间的原型性能压测期间，为了规避一个尾箱表引起的gc等待事件，我们把此表的pctfree放大到99以保证一个数据块上只保留一条记录。

3、rac环境中虽然实例是多个，但存储是单点，如果想增加节点来提高性能的话，只适用于cpu密集型的应用（前提是针对rac的特点编程），如果是io密集型的应用，节点越多估计死得越快。

4、无论是单机还是rac，要特别注意lgwr的性能优化，gc类的等待事件中，log file sync是其中的一步，lgwr对gc的影响是指数级的，我们行的某系统在做灾备切换时，主库与备库基本一致，但备库的性能与主库始终差20%，后面是把备库的logfile member去掉就OK了。

我从两个最重要的方面评测：

1.  高可用或者节点故障导致的恢复时间

     PureScale采用独立的CF节点管理全局的缓存，当节点发生故障时只对需要恢复的也没I/O发生阻塞，而RAC采用分布式的缓存管理，所有的请求会被短暂的冻结，在繁忙的OLTP系统中会造成大量SESSION阻塞。

2. ScaleOut水平扩展性

    PureScale支持RDMA快速的访问和更新LOCK,BUFFERPOOL等，100节点性能损耗也就20%左右。而RAC也可以使用IB网，但是不支持RDMA，分布式的缓存/锁，随着节点数的增加，节点间通信的开销将会非常大，这也就是很少看到4节点以上RAC的原因了。

结论：PureScale作为后起之秀，在软件设计架构，各方面性能上都要优于Oracle Rac。

        我认为在选择方案的时候，要根据自己的需要出发，看看自己目前的架构是否有什么不足，有什么无法通过完善现有方案解决的问题，然后考虑新的方案能否解决这个问题。

        DB2 PureScale和Oracle Rac解决的最主要的两个问题：一是解决单个物理服务器的可靠性的问题，即如果单机发生物理故障，不影响系统的可用性；二是物理机器的横向扩展问题，即通过增加物理机器的数量来提升系统的处理能力。

       这个架构没有解决的问题，存储的单点故障问题。当然这个可以通过方案扩展来解决，比如DB2 GDPC，HADR，GPFS复制等。

      这个架构的缺点是什么呢？首先是是架构更加复杂，增加了成本和运维的复杂性；其次损失了部分性能。

     我觉得比较这两个方案的优劣意义不大。因为选型上技术因素不大。传统的关系型数据库发展到今天，都是成熟的解决方案。不用太纠结。

同意楼上，总结一下：

DB2 PS相比ORACLE RAC主要有三个方面的优势：

1.性能扩展上：与Oracle RAC所不同的是，DB2 Purescale采用了CF来提供集中化的锁管理和全局缓存，而Oracle RAC采用的分布式锁管理和分布式缓存。由于分布式管理，RAC随着集群节点的增多，在极端情况下，多节点间的的通讯协调复杂性将指数型增长，虽然Oracle也可以将InfiniBand应用于Oracle RAC集群的多节点通信，但是 Oracle RAC没有利用 RDMA技术，那么意味着 Oracle RAC节点通信将使用速度较慢的套接字协议，并且需要一些开销较大的 CPU 中断，这样会大大降低通信处理效率。而DB2 PS采用RMDA技术，成员通过INFINIBAND直接访问CF的内存。大大提高通信效率。

2.应用透明性上：为了保持Oracle RAC的性能，通常是通过数据库分区的方式来避免热页面，通过业务分割的方式将不同的应用分布在不同的节点上的方式来减少缓存融合的频度。这样对应用来说，应用跑的Oracle节点固定化了，Oracle节点的伸缩，应用的配置也需要相应变更，所有这些都会造成管理和开发成本增加。而DB2 Purescale不需要通过应用或数据分区来实现可伸缩性，增加或减少成员节点时，不会让应用集群感知到，也无需对应用进行修改，同时这也极大地降低了管理和应用开发成本。

3.持续可用性上：ORACLE在成员故障时候，处理过程复杂，并且所有页面将冻结，而DB2 PureScale数据库成员出现故障时，不需要在集群中进行全局冻结，只有动态数据保持锁定，直到成员恢复完成。集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。另外故障恢复时，由于Oracle RAC是日志恢复，根据故障节点在出现故障时正在进行的工作量，整个恢复过程可能会花费几十秒到几分钟不等的时间；而DB2 pureScale是内存恢复，所以DB2 PureScale恢复时间比RAC短很多，动态数据在线恢复的目标时间小于20秒。

ORACLE RAC的优势：

Oracle RAC也有自身强大之处，自从发布之后，Oracle RAC同时解决了客户对于性能扩展和高可靠性的要求，多年来没有匹配的对手，成熟度和稳定性高，功能强大，可运行的环境多样，兼容性强，架构相对简单等；

DB2 PureScale也存在一定的不足和缺陷，如DB2 Purescale需要独立的两个CF节点资源；为了保证足够的性能，需要独立的InfiniBand卡和相应的交换机，并且目前只能通过GPFS才能实现磁盘共享，整体软硬件要求较高；整体架构的复杂度也较高；虽然说现在也可以运行在X86的Linux平台上，但对Linux平台操作系统版本的兼容性不够，更多的是定位于高端数据库，采用UNIX平台居多，而IBM的Power平台是Unix中的第一选择，存在一定的局限性；DB2 PureScale的CF重要性太高，即使DB2成员节点的数量很多，但CF故障一个就会造成一小段时间的中断，故障两个就会造成数据库集群全部中断。

如果18摸的db2想赶超oracle rac请去掉许可证的约束

谢谢

懂ORACLE的也可以结合ORACLE的设计机制，谈一谈优势，比如说redo和undo日志的机制。

rac商业上更成功

再好的技术没有市场也不行.

从搭建、维护角度来看，purescale要比RAC简单