ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 案例分析总结连载:第十章

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

原创 Linux操作系统 作者:db2ring 时间:2011-10-07 21:42:21 0 删除 编辑

案例分析总结

 

2010811   笔记整理                                    地点:杭州

在一次航空系统数据库性能诊断中,我发现他们所使用的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/24801454/viewspace-708739/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-04-26

  • 博文量
    21
  • 访问量
    13763