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

《全程回放：100T核心数据库升级历险记》要点：
本文介绍了全程回放：100T核心数据库升级历险记，希望对您有用。如果有疑问，可以联系我们。

本文根据汪洋老师在〖2016 Gdevops全球敏捷运维峰会广州站〗现场演讲内容整理而成.

讲师介绍

汪洋,从事Oracle相关开发运维工作20年.现任平安科技数据库技术部总监,负责数据库技术引入,数据库产品选型、架构设计、规范制定,开发、测试、生产环境运维等工作.近年,对开源数据库技术以及DBaaS产生浓厚兴趣,一直致力于相关的研究和引入工作.

本次分享大纲：

• 我们的困境和挑战
• 选择比努力更重要
• 十月磨一剑
• 最终的决战时刻今天给大家带来的分享为《平安产险核心DB升级记》,为什么选择“数据库升级”这个主题来分享呢?首先,一方面我是做数据库出身的,另一方面,我认为数据库的升级是一个相对复杂的系统化工程.在这中间,它几乎要运用到数据库领域的所有知识,包括管理、备份恢复、容灾、监控等,而且这个过程中,该怎么做升级的准备,如何保证真正的实施方案的顺利进行,实施之后如何对它进行监控,以及万一有预想不到的风险,怎么去顺利回退等等.不单单这样,它还包括主机的一些存储、配置,整个流程的东西都需要考虑.这是我选择这个主题的第一个原因.第二个原因,为什么是“平安产险”这个数据库?因为这个9i版本的数据库在当时可以说是全世界最大的,它有达100多TB的数据容量.它不光是产险最核心的数据库,并且几乎产险之外的所有子系统也都在这个数据库里面.综合以上这些因素,构成了这个系统的复杂性.第三个原因,就是五年前我们曾经失败过一次,所以这个数据库一直是我们心中的一根刺,心口上永远的痛,我们一直想把它拔掉.最后,它是从9i升级到11g,可能大家会觉得这是个老生常谈的问题,都谈了很多年了,而且它也不是升级到最新的版本12c.但它是我从业以来最复杂的一次数据库升级,里面用到的一些思想和方法能够提炼出来,用到不光是Oracle数据库,也可以用到其他数据库,甚至不单是数据库里面的,也可以运用到其他领域.所以借此机会分享出来,希望能够给大家一些借鉴.

一、我们的困境和挑战

1、业务系统特点介绍

正如前面提到的,它是全球最大的Oracle 9i OLTP数据库,甚至连原厂的工程师都不敢碰它,觉得这个任务似乎不可能完成.刚刚也说了,五年前我们曾经失败过一次,那时它才只有10个TB,五年之后,业务数据量变成了110个TB,现在每个月仍在以3TB的速度往上增长,而且是9i版本.众所周知,9i是个非常老的产品,它可能在设计的时候就没想过去运行这么大的一个在线数据库.

我们看到,它的业务数据量有110TB+,每秒的事务量是2000+,大家可能觉得这事务量不是很高,因为现在都是一万或十几万事务量,但我想告诉大家的是,保险不同于其他行业,它的每个事务都需要涉及到非常复杂的计算后才能提交,所以不同系统的TPS事务量代表的意义是不一样的.对于产险数据库来说,它已有的数据量已经是非常高的了,五年前只是现在的1/7,五年后翻了7倍.此外,它每天处理的SQL量有50多万,基本上支撑着平安产险95%以上的业务.如果万一发生问题,造成的影响与损失可想而知.

2、当前面临的问题??

• 获得Oracle产品的Premier Support支持

首先,Oracle 9i版本的延展服务在2011年的7月已经到期了,所以出了问题会怎样?如果大家用Oracle的话,出了问题,还是可以通过请求GCS (Oracle 全球技术支持)来帮你解决,但如果是新Bug的话,它是不会让O染成了研发介入开发新patch的,它只能有一些Workaround去帮你规避.如果连Workaround都没有,那你就只能像踩着钢丝一样,天天担心自己会不会遇到这些新的Bug.假如真的遇到了,也得自己想办法如何去规避.其实运行这么多年,我们也通过一些已知的办法去规避,但这始终不是长久之计.基于这些原因,必须要去升级.

• 解决硬件扩展的瓶颈

第二个是硬件扩展的瓶颈.它不光是数据库本身厂商的不支持,更是强调一个生产圈的不支持,包括它的主机、操作系统都不再服务支持.如现在我们这个新购的主机上只能运行Solaris 11,而Solaris 11 又只认证Oralce 11g以后版本的数据库,所以不及时升级的话,新采购回来的硬件只能认证比它高的版本,你仍继续用9i,发生问题时,厂商是没有办法解决的,甚至你要冒风险去运行在一个不被认证的操作系统上.还有就是刚才提到的硬件的存储,我们的数据库有110TB,而数据量每个月仍在以3T的速度往上增长,而旧的整个存储最大的容量也就130TB,很快就会达到它的瓶颈.

• 缓解DB性能不稳定的风险

我们在2013-2014年出现了三次UIOC(ugency incident office center),相当于一个作战史,一共发生了三次,而且每次都与latch: cache buffers chains等待事件相关.其实在9i里面我们感觉已经没有一个很有效的办法可以解决这个问题了,而在更早之前,从2009-2014年间更出现了12次重大事件,其中5次与执行计划突变有关,这些都是我们用9i时遇到过的问题,急需把它升级为11g.

• 提升技术人力的价值投入

维护9i所投入的人力成本是非常大的.为什么这么说呢?因为9i是一个比较旧的技术,很多时候我们的解决手段都必须在更高的版本上去实现,而在9i上做一个技术的变更非常复杂,你要考虑得非常细致,很多变更不能通过在线操作.如果升级到11g,不光可以释放一部分的人力,还能把这部分的人力投入到更有价值的事情上去.

3、系统变更要求

（编辑：ASP站长网）