工商银行数据库：DB2 核心年代的技术和案例

工商银行数据库：DB2 核心年代的技术和案例

这是一个历史问题：

2013 年 6 月 23 日工行系统大规模瘫痪具体情况有多严重？为什么中国最大银行会出现这么大的故障？今天早晨起来听工行的朋友说他们的系统大规模瘫痪了，有知道内情的人来解释一下是啥情况嘛？

第一个回复是匿名的：

先来介绍下工商银行的数据中心，工行包括两个数据中心，北京一个，上海一个，还有一个容灾中心，在珠海。北京的称为北数，在西三旗建材城；上海的称为南数，在外高桥台南西路。

其中南数是工行绝大部分数据库核心所在，北数大多数是周边业务居多。和其它大型国有银行一样，工行的核心业务系统运行在IBM db2 for zos， 非核心大部分是oracle，还有少量sql server。

上面有人提到，工行的运维和研发是分开的，跟其它大型银行一样，核心业务系统bancs并非自主研发，而是在国外成熟的银行核心业务系统之上改的。（中行曾经花了很大力气自主研发核心系统，但是最终还是流产，现在用的是印度tata consulting services的系统）。

银行，电信行业的核心数据库都是严重依赖IBM和Oracle的，而这两两种数据库非常庞大与复杂，事实绝对超出了大多数人的想象，我敢说数据库管理rdbms远比Linux内核复杂n倍。数据库的升级复杂性和windows/linux的升级根本不是一个概念，在核心数据库中打一个非常小的补丁都需要经过反复测试验证才能应用上线，更何况是升级？

正是因为不可控的因素太多，所以有时候出问题甚至是不可避免的。中国特色的系统往往都有一个特点： 用户并发数大的出奇，各种奇葩业务，新的业务需求源源不断。所以对于开发以及运维人员来说都是非常大的挑战，开发的工作就是天天改需求，运维的工作很大一部分都是耗费在高并发高压力系统的维护。（同样一段代码，一个人使用与一千万人同时使用，结果截然不同）。你以为工行会没有高可用，没有容灾，没有备份，没有测试？ 高可用，容灾系统的建设多数厂商多少专家废了多少时间和心血？如果真的可以迅速切换他们不会切？

测试是不可能测试到所有的场景的，有一些潜在的问题因为用户数量多会被无限放大。例如一条sql需要运行1s出结果，结果由于某种因素例如升级变慢了最后需要2s，全国几百万用户同时使用，瞬间就被放大了几百万倍，接着雪崩效应出现，骆驼被一个稻草压死。同样数据库升级完以后，并不意味着立马就能发现问题，很多问题只有到第二天正常业务时间才有可能发现。不要以为工行的人运维的水平差，很多都是技术背景很资深的，犯低级错误的可能性很小。如果你有机会看过工行数据库升级的文档你就会发现一个事实：细致的程度令人发指。即使IBM/Oracle这样的厂商的资深工程师都很容易被一些细节问得哑口无言，事实也是如此，IBM/Oracle没有任何一名工程师很乐意去工行处理问题。工行内部实行的是问责制，问题最终追究责任到人，俗称“拍板子”。像这次这样的故障，估计最终被板子拍到的部门会“生不如死“。

工”行运维人员很少，并且没有引入外包，所以每个人劳动强度非常大，几乎是天天加班，碰到重大的系统割接上线更是没日没夜，工作劳动强度大，压力责任大，所以私底下里骂娘的人一大片。为了把可能的影响降到最低，维护工作基本都是放在半夜或者周末，这些工程师的牺牲是非常大的。银行业务会发生故障几乎是无法避免的，相对其它银行而言，工行的故障率已经是非常低了。

后面关于这个问题的回复是：

IBM DB2 V9升V10故障回退的时候数据库挂了，无法开启备份，经查为IBM原因

原文：https://zhihu.com/question/21242803