案例分析总结连载：第十章

案例分析总结

 

2010年8月11日   笔记整理                                    地点：杭州

在一次航空系统数据库性能诊断中，我发现他们所使用的4节点的Oracle RAC集群性能已经到达极限，无力满足上层应用海量事务吞吐的需要。客户希望将以前淘汰的8台服务器重新利用起来，与现在的4个服务器合并，把Oracle RAC集群扩展到12个。但经过测试后发现，12节点的Oracle RAC受其分布式架构的限制，其伸缩范围极其狭小。面对这种挑战，客户不得不开始讨论是否需要购买一台大型主机了。

在技术讨论会上，我对大家讲：“现实情况是，目前Oracle RAC系统性能已经到达极限，我们需要换个思路来低成本地解决这个性能问题。”我在投影仪上打出PAT树，接着讲道，“大家看看PAT树，当发现系统性能达到极限时，可以考虑采取新技术优化。今天给大家介绍的就是DB2 pureScale海量事务处理机制。不同于Oracle RAC的分布式架构，DB2 pureScale采用集中式架构，具有业界排名第一的集群伸缩能力，可以满足持续可用性的需求，而且对上层应用完全透明。通过这种方式，客户就不必购入一台新的大型机，这意味着节省了上百万美金。”

经过激烈的技术讨论，优化小组决定重新启用那8台已经“下岗”的服务器。我们指导客户分两个小组来实施：一个小组负责使用8台服务器来搭建DB2 pureScale集群，随后进行测试；另外一个小组负责将上次Oracle应用迁移到DB2 V9.7。由于DB2 V9.7提供了非常好的Oracle兼容性支持，所以应用迁移小组很快就完成了数据库迁移。

最终测试结果显示，8节点的DB2 pureScale集群达到了95%的伸缩性。一个月后，重新“上岗”的8台服务器不负众望，成功满足了应用处理海量事务的需要。

我读着记载这次经历的PPT，正停留在美好的回忆中，突然收到了一封邮件，通知我下周回北京，为那家移动通信老客户再做一次咨询。“上次就说做咨询，结果深夜被拉过去拆定时炸弹”，小小地抱怨了一下，随即就紧张了起来，想象着这次行程将会遇到什么样的冒险行动，脑海中开始浮现一幕幕的情节。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714482/viewspace-708186/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-708186/