作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

本文永久地址：https://www.askmac.cn/archives/oracle视角：旁观某电信客户升级迁移项目.html

1. 不得已而为之的数据库升级和迁移项目

多年来，某省电信运营商虽然对其核心CRM系统进行了持续优化工作，但仍然满足不了业务高速发展需求，尤其是每月出账期系统压力越来越大，故障频频，以至于每当账期来临，局方各级领导、各业务部门和技术人员，以及应用开商和维护保障公司人员都是如坐针毡，甚至如临大敌。

在2015年下半年连续几个月账期均出现不稳定状况之后，各方一致认为数据库系统和应用软件优化工作已经持续了几年，优化空间已经非常有限了，是到了系统软硬件平台升级换代的时候了。

该系统现有硬件平台为HP PA-RISC小型机，数据库版本为10g R2，可见无论硬件还是系统软件都已经属于落后淘汰的技术了，现有硬件配置和性能甚至低于当下最新的X86服务器。作为Oracle公司服务部门，我们更是喋喋不休地讲述数据库升级到11g R2的必要性、可行性、方法论和风险控制策略等，特别是介绍了大量成功案例的实施经验。于是，领导终于下决心了！升级到11g R2并迁移到最高配置的X86服务器！项目实施周期确定为2个月，而且还横跨2016年春节！

本人无意点评领导决策的欠科学，甚至拍脑袋，其实我们深深理解领导的苦衷：已经连续优化这么长时间了，还是艰难度日，万一下个月账期系统彻底瘫痪，怎么办？

于是，尽管各方技术人员向领导和各业务部门力陈升级和迁移的难度和风险，但最后大家还是迫于业务压力，决定赶鸭子上架了！

2. 麻雀虽小，五脏俱全

虽然项目实施周期非常短暂，但局方还是组建了由业务部门、应用开发商、运维团队等多方组成的项目组。在数据库迁移方面决定采用DSG公司的相关产品和技术，在应用测试方面也决定进行全面的功能和压力测试。喏，这就是该项目实施计划表的部分内容：

上述计划表由应用开发商主要从应用整体角度提出，尽管我们省略了原有表格中局方负责人、厂商负责人、预计完成时间等敏感信息，但大家还是一定能感受到升级/迁移项目的复杂性：硬件、网络、系统软件、数据库软件、应用软件… …面面俱到，一个也不能少，真是个庞大的系统工程。

数据由DSG迁移了，应用开发商负责应用功能和压力测试，作为Oracle服务团队的我们还能做什么呢？难道就是安装一下Linux平台的11g R2 RAC，然后提供一些现场技术支持吗？喏，这就是我们制定的Oracle服务计划：

可见，作为Oracle服务实施团队，我们的优势主要发挥在两个方面：第一就是在Oracle数据库环境安装和确保稳定性方面，包括11g R2 RAC专业化的安装、补丁分析和实施、初始化参数和隐含参数的设置等。第二个方面则是Oracle服务团队的另一个独特优势，因为我们深知升级和迁移项目最大的风险其实是来自于应用软件的性能衰减，而Oracle从11g开始推出了SPA工具，即通过该工具，可进行升级前后的应用性能对比分析，这样在测试阶段就能提前诊断出执行计划变化和性能衰减的SQL语句，并加以优化和改造，从而降低升级之后性能问题的出现概率，确保整个升级项目实施的成功。

各方不乏经验、方法论和人力资源投入，局方也提供了测试环境，但是大家都痛感最缺乏的只有一样东西：时间！时间！时间！在两个月的项目实施周期中，刨去春节假期，还有DSG的两次数据同步时间窗口（一次是将现有生产系统数据同步到测试环境，一次是正式割接前的数据同步），有效测试时间连一个月都不到！

3. 艰难的测试过程

就在这一个月不到的时间里，各方要开展应用功能测试、应用压力测试，还有SPA测试。由于工期和项目计划组织问题，各项应用测试还与DSG的数据同步测试出现了时间上的重叠和冲突。于是，数据同步尚未完成，索引还未同步过去呢，压力测试和SPA测试就开始了，这些测试哪能跑得下去？于是，测试初期各方在不断磨合，尤其是解决各类数据同步问题，宝贵的测试时间又一点点流失掉了，真是欲速不达。经验啊！

测试期间正好横跨2016年春节，各方人员依然以饱满的工作激情、可贵的职业精神，协同作战，每天大家几乎都统一加班到晚上11：00，基本圆满完成了各类测试任务。作为Oracle服务团队，我们也第一次为该客户展现了SPA工具的价值：通过SPA测试，我们发现了若干条SQL语句出现了性能衰减，并加以有效解决，防止了这些问题在正式割接上线时爆发。

1个月的测试时间不知不觉就这么过去了。真是成也萧何，败也萧何。不久之后的正式割接期间的事实证明：大量的测试付出，的确有效地防范了各类问题的发生，但也正是因为测试时间太短，导致测试工作的不充分，尤其是当时对测试期间发现的问题没有深入探究，为正式割接埋下了深深的隐患！

4. 惊心动魄的正式上线割接

大家在倾情投入了近两个月之后，终于以兴奋同时也是忐忑不安的心情，迎来了正式升级/迁移的割接上线日子。于是，各路神仙云集客户现场，本人作为旁观者也亲眼目睹了整个割接上线过程的跌宕起伏和惊心动魄。兴奋、刺激、纠结、无奈、痛苦、开心、喜悦、感慨，无数情感和心境在短短的2天多时间内不断变换，实乃精彩的人生写照！且听下面的娓娓到来。

上线第一天上午业务刚开始，似乎总体还算正常，但作为Oracle服务团队，包括我自己在内还是发现了一些SQL语句出现了性能衰减，好在我们已经有预案，例如多数语句的性能衰减是由于优化器改变为CBO之后出现的执行计划变化，于是我们采取了删除相关表统计数据，暂时回退到RBO的策略，留待事后再解决。事实证明，相比后面将要表述的系统层面问题，SQL语句问题仅仅是局部性问题而已。

就在第一天上午10：00多业务压力逐渐增加之后，我们首先获悉了前台应用反应非常慢的投诉，其次我们发现数据库服务器压力并不大，而在数据库和中间件层面均发现了网络问题，例如数据库服务器的公网延时居然达到了50ms！而私网也出现了丢包问题。由于硬件厂商网络工程师第一天晚上才能赶到现场，大家只能在等待、无奈、无助，甚至煎熬的心情中度过第一个白天，业务更是缓慢爬行了一整天。

事后我们回想起来，其实在压力测试阶段，大家已经发现了公网延时和私网丢包问题，甚至还导致了RAC宕机，但的确由于测试周期太短，这些问题都没有深入探究其根本原因，就这么带病上岗了。经验教训啊！

好在网络工程师第一天晚上赶到现场之后，很快诊断出网络问题，在调整、配置了几个网络参数之后，网络延时和丢包问题解决了。于是，大家又以轻松、期盼的心情迎来了第二天的业务。可是，这种愉悦的心情几乎是稍纵即逝，第二天上午随着业务高峰的来临，数据库服务器不堪重负，Top显示的Load居然达到500以上，IO Wait更是高达50%！经验告诉我们，IO Wait超过10%就不正常了，难道I/O压力很大，抑或存储系统I/O能力不够、配置不当？大家很快就否定了这些判断，而事实上数据库服务器中最消耗资源的根本不是Oracle进程，而是root用户下的CPU调度程序，这属于主机或操作系统层面问题，硬件厂商工程师在倾力分析和解决中，而第二天的业务比第一天更加艰难，全省CRM系统前端几乎完全瘫痪！

到了第二天日终，问题依然如故，领导终于做出了最简单，事后也证明是最有效的决策：换机器！于是，各方又开始通宵达旦地协同工作了，Oracle服务团队具体负责RAC环境下的删除节点、增加节点操作。我们的同事事后自我调侃道：我已经成了RAC增删节点的高手了！

第三天立竿见影了：一切都恢复正常！原来的数据库服务器硬件或操作系统到底出现了什么问题？我们作为旁观者，无权评述。但听局方系统工程师介绍，这是由于Linux处理中断机制跟UNIX不一样，大部分资源都消耗在处理中断上了，并发越大、处理越慢、越来越恶化。测试阶段是否出现过该问题呢？据了解，还真没有出现过，原因就是测试环境的硬件条件有限，没有模拟出生产系统的真实压力。经验啊！真实模拟测试的重要性！

5. 更多的感慨

本人讲述完这个刚刚发生的惊心动魄的升级/迁移故事，无意渲染升级/迁移项目的高风险和难度，更不是要吓退那些对升级操作本来就心存疑虑和担忧的决策者们，而是试图通过这个真实案例的总结，大家来共同来感悟如下的经验教训：

• Oracle数据库系统升级和迁移的确是一项机遇和风险并存的系统工程，战略上藐视，战术上重视是基本策略。也就是说升级/迁移项目肯定是能成功的，但科学的升级/迁移方法论指导、需求的全面分析、完备的技术方案和全面测试是项目成功的重要保障。
• 我们虽然一直强调应用性能问题是升级过程中需要特别关注的问题，但相比主机、操作系统、网络等层面而言，SQL语句问题只是局部性问题，而系统层面问题却是全局性问题。任何一个全局性问题的爆发，都将是灾难性的。
• 真实模拟测试、测试方法、测试手段的重要性，不要放过测试中出现的每一个问题。最后再重复一句名言：无论如何强调测试工作的重要性都不为过。

2016年3月27日于高铁上