全程回放：100T核心数据库升级历险记(3)

我们刚开始就已经在做存储全量同步,然后也用了HDS GAD在做存储同步,远程容灾用了SVC存储同步,升级中我们会把它进行一个存储的分离,然后本地升级,把刚才提到的一些SPM去导入,然后远程容灾是通过级联升级,这样我就会在升级以后出来两套,一套是9i的环境,一套是11g的环境.升级后我们会把11g产生的数据改变通过OGG同步到9i,所以在任何情况下都可以去回退,而且是完整环境的回退.

三、十月磨一剑

1、性能分析迭代

这个过程中,我们用了半年,在这半年的时间里,我们首先要构造分析基线,也就是刚才提到的——用DB Replay去回放生产压力.第一步,我们是在11g的环境里把它的优化器参数和统计信息仍然保留9i的,那么SQL相当于在运行在9i的环境中产生执行计划及执行情况(因为这是跟当前运行9i的生产环境最接近的),我们会抓取一个基线,并会把它的Top SQL拿下来.

接下来,我们会把11g环境里面的优化器参数和统计信息修改成11g的,再去回放一次负载,比较两方面的差异,也把它的Top SQL抓取下来,我们这时候也用到SPA,即Oracle RAT中的一个组件SPA(sql performance analyze),DB Replay在整个过程中的作用是回放整个负载,可以观察数据库有没有异常的等待事件,有没异常消耗高的SQL等,让你从整体上去判断.而SPA,是帮你逐条分析SQL,执行计划有没有改变,如果有改变,它的buffer gets是升高还是降低,CPU TIMES是升高还是降低等.如果它的性能下降了,是由于什么原因,这些就需要你做进一步深入分析,也就是说Oracle RAT的两个组件SPA和DB Replay在这期间发挥着不一样的功能.

在抓取了这些SQL之后,我们就要逐条、逐条地去看,包括一些去重,因为数据量太大了,最初抓取过来的有50多万条SQL,去重后还有14万条,后面我们把这14万条再去分类,该给开发的就给开发,该给DBA的就给DBA去优化,一层一层的优化,才能保证最后上线投产的顺利进行.当我们非常有把握或者性能非常稳定的时候,才会去投产.也就是说,我们总共分析了14万条.

2、绑定变量改造

关于SQL语句呢,我不细讲,这里提几个点和例子.首先是绑定变量,就像刚刚提到的固化执行计划是需要已使用绑定变量的,否则它每条SQL语句都不一样,这些SQL也就无法共用固化过执行计划,在这过程中我们发现很多这类的SQL语句.尤其在in里面非常多,要么就是跟个数不一样,要么就是值输入不一样,两种情况都可能导致固化过的执行计划发挥不了作用,而这类SQL无法简单地改造成绑定变量,所以我们进行了改写,以保证我们通过SPM固化执行计划达到固化的效果,第一是改写成绑定变量,第二是将IN写法改写成union all这种写法.通过这两种手段,去优化它的SQL语句.

3、隐式转换改造

第二个例子是隐式转换.这是因为ibatis有个类型Timestamp与数据库中的字段类型不一样导致的,我们也是进行了一些优化.通过在应用代码中增加cast函数来降低数据精度,并在长期方案中,针对date类型,应用必须传入string格式,并在XML中使用to_date()函数进行转换.

4、复杂视图改造

第三个例子是复杂视图.在9i的时候,filter条件可以先在VIEW上过滤再和其他表关联,但11g必须先实例化VIEW,再进行filter条件过滤,对此,我们在v$sql中查询VIEW相关的代码,同时将VIEW拆开,分别和VIEW之外的表进行关联查询,最后再合并结果集.

这是几个比较典型的案例.

四、最终的决战时刻

1、投产组织工作

做了这么多,耗时6个月,最终的决战时刻终于到来!这中间涉及到很严密的组织架构.有总指挥,然后运营团队和业务团队怎么去配合,运营团队怎么做好深度监控、怎么通知业务团队准备好升级后的验证,如果发生问题,应该怎样去做回退决策,都有哪些人员当时投产、包括投产后要到场值守,这些都要做好.还有要事先做好升级的序列和决策点,哪些点是必须要决策回退,以及性能监控的指标和频率的提前制定.

2、投产人员架

本次升级变更的总指挥就是我,当时从最早的解决问题到最终的投产成功,我有60个小时没有睡觉.基础架构团队,像刚才提到的,有主机和存储的配合.还有DBA团队、开发测试团队、运营团队、业务验证团队,大家都是“拧住一股绳,心往一处使”,才能让这个“只许成功,不许失败”的项目务必成功.我们只能接受一次失败,不能接受第二次失败.

3、投产前小插曲

然而,即便我们考虑得非常周密,在投产前还是出了小小的插曲.在投产前的72小时,本来我们是想跟生产环境做存储同步的,即11g新环境是跟9i生产环境同步的,并且存储技术已跟厂商确认过没有问题,而且我们还怕影响白天的业务,专门计划存储层数据同步在第一天先做一半,等到第二天过了白天业务的高峰后,晚上再拉起来,用两个晚上完成存储同步,这也和厂商确认过,他们也觉得没问题,但还是发生了问题.后来临时改变方案,我觉得这也是敏捷运维的一个思想,改为从同城容灾进行存储全量数据同步,这样就对生产环境没有影响,但我们的方案就变得更加复杂.这是第一个小插曲.

（编辑：ASP站长网）