全程回放：100T核心数据库升级历险记
|
这是方案大致的流程.首先要走基础的硬件上架和基准的测试,比如说,存储的IO能力能不能达到我的要求,虽然理论上闪存是要比以前高端SAN要强很多,但没有经过实际测试过,也是无法确定的,所以需要自己做一遍测试.主机呢,我们也是把真正的生产系统切换到新的主机上进行试运行一次,看T5-4到底是不是要比M9000要好,避免发生我们预期不到的事情.经过这样一轮测试,我们才有信心、郑重地做硬件架构升级后的生产运行平台.接下来,一方面是做性能测试,一方面是要做功能方面的回归测试,最后还要联调再做一次终极的性能验证.做完之后,用户接受、开发接受,然后再做系统真实的投产上线和运行. 首先我们碰到的第一个难题就是DB Replay,用过Oracle的都知道,它是RAT (Oracle Real Application Testing)的一个组件,它可以把一个数据库的负载在做一些变更之后,在另外一个的数据库或平台上去负载重演,看这负载在你升级前后或者硬件更换前后有什么差别.在这里,第一个难题就是DB Replay是11g的一个新特性,而目前我们的库版本为9i的,所以需要打上一个patch,因此我们要求Oracle全球研发帮我们出一个9i版本的patch,经分析这个patch跟我们目前数据库补丁有冲突,所以我们花了很长时间去做这种补丁冲突的分析,一层层的抽丝剥茧,最终找到那些产生冲突的patch,把这些不重要的冲突patch拿走. 2、软件补丁方案设计第二个难题就是我们要在新的11g版本上去安装patch,这又是另一套原则.大家可以看到,我们先是做了一个补丁列表的筛选,是Oracle发布的Patch Set Update(PSU),还有一些Critical Patch Update(CPU),都作为我们的待选.待选patch的会和已有的、已打的patch做一些补丁冲突分析,如果有冲突的话,那就看它是否关键.两个相比较,看到底哪一个更关键一些,我们会留下更为关键的一个.如果没有冲突,直接加入到我们的补丁列表,做成一整套补丁实施方案,这样我们就能知道未来的系统是什么样的数据库版本以及需要打上什么样的补丁集信息. 3、功能测试方案设计第二个选择比努力更重要的是功能测试.系统每一次的功能版本变更都有一个定型期,因为我们这个事情差不多进行了半年,定型期里面,每发一次版本变更都要同时在9i和11g的平台上功能验证通过,我们才能去发布,这是为了保证整个升级运行期软件版本的一致性,也是为了让它升级以后不会出问题. 4、性能测试方案设计
第三个就是性能测试,这是最复杂的地方.我们利用DB Replay抓取9i的负载在11g的环境去重现,那性能的好坏怎么判断呢?我们先在11g的环境里面去回放这个负载,看它的性能是否下降,如果没有下降,我们就会把这些Top SQL抓起来,用11g的另外一个新特性,叫SQL plan management(简称SPM),去把它的执行计划固化下来. 固化之后,我们会将这些SQL的执行计划导入到11g的生产环境中,保证在系统升级前后生产计划是没有改变的.如果是性能下降,假如不需要通过代码改变就可以进行优化的,我们会通过DBA、开发人员等人工优化,把它也用SPM固化下来,同样导入到生产环境.对于那些没有办法简单地加Hint或通过改变关键字次序等进行调优的代码,就需要开发参与进行代码的改造.当开发修改代码时,也是要两边调度,同时在9i和11g的版本上进行性能验证,两边都验证通过之后才能导入生产. 5、投产上线架构设计这是整个投产方案的架构设计,看起来比较复杂.我们提用了两套完全一样的架构,9i里面有同城的DG,也有远程的DG,因为这个数据库太核心,太重要了.同样的,在升级过程中,我们不允许出一点差错,所以在11g的投产环境中也有完整的一套11g的预投产、预生产环境,它的同城DG、远程DG是完全一样的. 这里面用了三种不同的存储技术.第一种存储技术就是11g新生产环境是和原来9i的同城容灾是做存储层面的同步,即存储LUN级别的同步；第二种存储技术是利用HDS的一种GAD存储同步技术,使11g新生产和11g新同城容灾不断地在做数据同步,第三种存储技术是9i远程容灾与11g新同城容灾之间通过SVC实现存储同步,而这11g新同城容灾也就是用于将来的11g的远程容灾环境. 我们还有MIS COW以及DEP COW的补充,用于获取一些数据采集产生一些报表,所以这里面用了很多种技术,目的就是不去在一个完整的环境中去做升级,也就是说我们不会先去升生产再去搭建一套同城容灾、远程容灾,因为这样的过程中产生的一些RPO、RTO和风险是无法规避的. 6、投产实现方案设计（编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
