DB2 pureScale与Oracle RAC功能对比

　　DB2 pureScale和Oracle RAC是两个类似的技术，两者在数据库领域均占据十分重要的地位。但是相对于Oracle RAC，DB2 pureScale更具优势，尤其是在高可用性、可伸缩性和应用透明性等方面。

　　1.高可用性

　　DB2 pureScale的设计初衷是最大限度地提高在故障恢复处理中的可用性，当数据库成员出现故障时，只有动态(In-Flight)数据仍然保持为锁定，直到成员恢复完成。动态数据在线恢复的目标时间小于20秒。

　　因此DB2 pureScale 成员故障中所涉及的两个步骤包括故障检测和数据恢复，而Oracle RAC的节点故障则需要涉及四个步骤，即节点故障检测、Remaster数据块、锁定需要恢复的页面、重做和撤销恢复。与 DB2 pureScale不同，Oracle RAC并不会使锁或数据缓存集中化。

　　▲DB2 pureScale与Oracle RAC高可用性对比

　　具体来说，在Oracle RAC中，每个数据页都由集群中的一个实例来管控。Oracle采用分布式的锁机制，因此集群中的每个实例都需要负责管理和批准对它所管理页的锁请求。当某个节点出现故障时，故障节点所管理的数据页将立即变为孤立的，直到RAC会通过重新分配流程将这些孤立页面的管控权分配给集群中健康的节点。在Global Resource Directory重新配置的过程中，对页面的任何读取和锁请求都会立即被冻结。应用可以继续在健康的节点上处理，但这时它们不能执行任何I/O操作或请求任何新锁。这会造成许多应用被冻结。

　　RAC节点恢复流程的第二步是锁定所有需要恢复的数据页面。这项任务必须在GRD冻结被释放之前完成。如果某个实例在获得适当的页解锁之前被允许读取磁盘中的页面，则故障实例的更新操作可能会丢失。恢复实例将一遍读取故障实例的重做日志文件，并锁定任何需要恢复的页面。这可能需要大量随机的I/O操作，因为日志文件乃至需要恢复的页都可能不在任何健康节点的内存中。

　　仅当恢复实例执行了所有这些I/O操作并锁定适当的页之后，GRD冻结才会被释放，停滞的应用才能继续运行。根据故障节点在出现故障时正在进行的工作量，这一过程可能会花费几十秒到几分钟不等的时间。相比之下，DB2 pureScale环境则不需要在集群中进行全局冻结。CF在任何成员出现故障时始终知道哪些页面需要恢复。如果某个成员出现故障，集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。

　　▲DB2 pureScale与Oracle RAC崩溃恢复比较

　　2. 透明的应用伸缩性

　　DB2 pureScale具有透明的应用伸缩性，管理员可以增加产能，而不需要重新调优或重新测试，开发人员甚至不需要知道增加了更多节点。pureScale支持RDMA访问的集中锁定和全局缓冲池可以带来高可伸缩性，而不会让应用集群感知到，而Oracle RAC中的分布式锁定会增加开销并降低可伸缩性。

　　▲DB2 pureScale集群中的成员测试结果

　　具体来说，DB2 pureScale通过InfiniBand并利用Remote Direct Memory Access (RDMA)直接对远程服务器的内存执行写操作。虽然Oracle也可以将InfiniBand应用于Oracle RAC集群，但是Oracle没有利用RDMA技术，这意味着Oracle通信将使用速度较慢的套接字协议，并且需要一些开销较大的CPU中断，从而影响集群效率。

　　支持RDMA访问的集中锁定和全局缓冲池为DB2 pureScale带来高可伸缩性，在读写比例为80:20的12个成员节点的测试中，DB2 pureScale的性能扩展超过90%。Oracle RAC采用分布式锁，这会增加开销并降低可伸缩性。实际上，4个节点以上的RAC应用并不多，因为其无法通过增加节点而达到更好的性能扩展。

　　总结

　　DB2 pureScale作为IBM破甲行动的突破点，是群集数据库发展史上的一个里程碑。通过本文对DB2 pureScale的介绍，及其与Oracle RAC的功能对比，相信大家对这项技术的认识更加深刻了。如果想了解更多有关DB2特性的解析，请继续关注《IBM DB2关键特性解析：DB2分区特性》。