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

在抓取了这些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生产环境同步的,并且存储技术已跟厂商确认过没有问题,而且我们还怕影响白天的业务,专门计划存储层数据同步在第一天先做一半,等到第二天过了白天业务的高峰后,晚上再拉起来,用两个晚上完成存储同步,这也和厂商确认过,他们也觉得没问题,但还是发生了问题.后来临时改变方案,我觉得这也是敏捷运维的一个思想,改为从同城容灾进行存储全量数据同步,这样就对生产环境没有影响,但我们的方案就变得更加复杂.这是第一个小插曲.

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!