100T核心数据库升级历险记

今天给大家带来的分享为《平安产险核心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、系统变更要求

我们平时数据库升级一般遵循的都是一次只做一个变更，但这次情况不同，就像前面提到的受限于硬件、存储等多个瓶颈，我们一次做了四个变动，这也是为什么这次升级如此复杂的原因之一。其中，操作系统是从Solaris 10升级到了Solaris 11，DB版本从9.2.0.5升级到了11.2.0.4，主机硬件从M9000升级到T5-4，存储硬件是从高端SAN变更成了闪存。现在闪存是未来存储的趋势。

以上这些都是我们在做方案时提出的挑战和要求。