走近大型数据库

数据库故障的分析及解决变得更加困难，这导致即使专业技能再高的DBA也可能束手无策。

大型IT系统因其应用和数据库、以及数据库和数据库之间错综复杂的关系，使得数据库故障的分析及解决变得非常困难，这导致即使专业技能再高的数据库管理员(即DBA)也可能束手无策。

现在，数据库已经不再是个独立的个体，这在大型IT系统环境中显得尤其突出。

一个典型的大型IT系统，按照目前占主流的B/S三层结构，前端客户端使用者可能数以十万计，而中间的应用服务器可能几十台，使用F5等硬件进行负载平衡和分流。

但数据库只有一个，一般还只有1台服务器挂1个磁盘阵列；顶多用个双机，两台服务器共享1个磁盘阵列(但需要注意的是，即使这样，也就Oracle的实现机制被数据库用户大量使用，Microsoft SQL Server和IBM DB2都相对很不成熟，一般是上一个死一个，至于开源数据库MySQL更是其最薄弱的地方之一)。

问题不仅如此，数据库一般需要同时支持多个系统，且数据库之间存在复杂的数据集成。在当前的中大型企业中，往往需要多个系统，而这多个系统所需要的关键业务数据和基础数据却又往往只能集中存储在单一的数据库中。另外就是数据库的访问者，不仅仅来自外网，还有内网。

大型IT系统中一般是多个OLTP系统和多个OLAP系统的组合，数据库之间的数据集成链路好几十条，并且情况复杂：有些对时效性要求很高，要求1分钟内传送到目标数据库；有些执行时间很长，甚至12个小时的时间都不一定足够；有些链路需要并发执行。

如果复杂的一个环境，无疑大大增加了数据库故障分析和解决的难度。在如此复杂的IT环境下，一旦其中的某个系统出现问题，前台无法使用，往往大家的第一反应就是，数据库出问题了，是数据库故障导致这个系统无法访问。

于是大家的矛头都指向了DBA。DBA这时就成为了众矢之的，或者说背黑锅的(关于这个说法，下文有详细描述)。笔者曾经任职于中国数一数二的电脑集团，当时新客服项目上线的第一天，突然呼叫中心所有电话都无法接通、派单，维修站无法开单、接单和处理，经理让我上机房去处理，过一会儿总监、高级总监、集团副总裁全都静静地站我后面，猛一回头当时差点吓出心脏病(这时DBA或者成为救世主，成为万众瞩目的英雄，或者准备卷起铺盖拍拍屁股走人)。

数据库优化的思路

但这真的是DBA的错么?DBA又能解决所有问题么?多年的DBA经验告诉我，很多时候DBA只是充当了冤大头和替死鬼。

数据库只是一个平台，从最严格意义上讲，数据库很少出故障，或者说仅数据库软件bug导致的故障才叫数据库故障；很多数据库故障都只是由外界因素所引起的。

外界因素包括最主要的三个：数据库所在服务器，网络环境及应用程序。数据库服务器硬件不稳定，或者操作系统有问题，这属于先天缺陷，是系统设计首先应考虑的。

笔者原先工作过的那家电脑集团，其最早的全国呼叫中心系统用的是Oracle 8i双机，Windows服务器。当时只能开一台服务器，另一台服务器运行不到一小时，肯定自动重启，想了很多办法，把这台服务器的内存、主板都换了还不行，最后就这么生生扛了两年。

网络故障容易导致数据库故障，这个道理显而易见，皮之不存，毛将焉附。在数据库所在服务器和网络都确定没有问题之后，导致数据库故障的就是应用程序了，这个占据了数据库故障的至少60％。

在大型IT系统中，应用程序是个广义的概念，不仅仅包括公司终端客户和自己内部员工使用的IT系统程序，还包括数据库之间的数据集成链路，数据库自身的任务。

普通IT系统程序是造成数据库故障的主要源头，但对大型IT系统而言，后两者同样绝不可忽视。

数据集成链路在图1中也有简单示意，实际的情况往往比这复杂得多，为满足业务需要，十几条数据集成链路是很正常的事情。事实上，通常对一个7×12的大型IT系统而言，晚上的12个小时会被各种集成链路排满，甚至出现时间重叠的情况。

数据库自身的任务包括运行于所在服务器的CRONTAB，数据库内部运行的JOB(那些利用生产数据库自身数据就能完成的业务查询统计，往往借助于这种形式)。而数据集成链路和数据库自身任务都一般在非业务时间运行，如何保证他们的时间不重叠，是DBA的任务之一，也能体现DBA的业务价值，但安排不当，也是导致故障的源头。

从全局的高度俯视整个IT系统，将上述各种因素综合起来分析，是解决现在错综复杂甚至诡异的数据库故障的关键所在。下面将举两个真实的案例予以说明。

从数据库任务着手

下面我将要提到的这个案例是一个综合分析数据集成链路和数据库任务，并解决数据库故障的案例。

某公司的一个内网员工使用的业务系统在周六早晨6点起，突然不可用，两个小时后，运维人员联系到DBA，DBA远程试图连接到数据库所在服务器，报连接超时，无奈之下，授权机房值班人员重启服务器后，恢复正常。第二天周日又发生同样的故障(但在随后的工作日未出现故障)。

这是一起典型的数据库故障，至少对公司领导和业务人员而言如此，他们很清楚地看到，业务系统无法连接到数据库，于是页面红屏业务无法正常开展。但DBA事后反复检查了周六、周日数据库当时的情况，分析了各种数据库日志，并未发现数据库有任何问题。

问题出在哪里?大家达成的共识是，数据库出了很严重的问题，导致业务系统无法使用。可DBA的检查结果是，数据库没有问题。这时不可能去质疑DBA的专业技术能力了，只能再深入一步的去分析。

笔者当时发现数据库所在服务器的性能日志记载，在6点10分时，服务器空闲CPU平均为0，用于iowait的CPU达40，且磁盘io和虚拟内存都有较平常大了很多。而通过专业工具分析，当时数据库本身并未消耗太多的这些资源，因此需要找出额外多消耗的资源去哪里了。

于是开始分析数据集成链路和数据库任务，分析发现，数据集成链路未出现大的问题，但每天6点都会开始数据库的逻辑备份，而在每周六和每月1号(这次轮到本周日)会运行一个很耗资源的统计类CRONTAB任务。

两者刚好在这个周六和周日的运行时间重叠在一起，偏偏数据库服务器的硬件配置很一般。所以解决方案是，把数据库逻辑备份提前到凌晨3点执行，把统计类CRONTAB任务从Java改写为数据库存储过程再调度执行，问题解决。

从应用程序着手

这是一个综合分析应用程序特征，并解决数据库故障的案例。

某大型网游公司的一个关键业务突然出现严重异常，终端客户的页面请求平均每10秒报一次错，该IT程序的十多台应用服务器被迫每10分钟轮流重启一次，这对公司收入造成严重影响。

当时DBA从后台查看数据库情况，发现CPU利用率平均99％，CPU的负载极高，磁盘和内存的使用未见明显异常。这是个很重要的生产数据库，上面运行了多个IT程序。但DBA发现仅这个IT程序出现如此严重问题，而其他的IT程序从使用者的反馈来看，未出现异常。DBA于是和领导报告，说数据库没问题，领导显然不同意这个观点：数据库没问题，那CPU利用率怎么这么高呢，那这个IT程序为什么不可用了呢。

问题出在哪里?DBA被迫和领导、以及出问题的IT程序负责人达成共识，数据库故障导致此类问题。可DBA从后台数据库日志未发现问题，分析抓取的程序SQL语句，都很快能执行完，关键的单条SQL执行时间0.094秒。

数据库是Oracle 10g的，DBA于是做awrrpt、ashrpt、addmrpt，也未发现数据库本身的异常，但从中得到的唯一有价值的结论是，从数据库统计值来看，业务压力应该比平时增加了50％。应该就是这新增的50％业务压力导致对应IT系统故障，这样就更加困扰DBA了，为什么新增的50％业务压力没压垮别的IT程序，而单单只是这个IT程序呢?

大家共享访问同一个数据库，访问同样的数据表，DBA也没有做数据库资源优先级设置。显然这个问题。也无法用常规的DBA技能来解决。这样的问题，在大中型IT系统中并不少见，公司越大，问题的复杂程度往往越高。

笔者当时查看Oracle数据库的监听器日志，定位到问题症结点在于该IT程序的数据库连接方式。这个IT程序的应用服务器较多，且数据库连接特别频繁。于是从系统负责人了解情况，发现该系统的十多台应用服务器，采用类似failover和load balance的机制，以响应众多终端客户的业务请求。

前台展现为单一的网址，当出现类似这种“数据库故障”时，通过轮流重启每台应用服务器来缓解问题，新终端客户的业务请求会自动failover到正常运营的应用服务器，但扛不住业务压力的应用服务器被迫重启时，已有业务请求就得被迫中断，从而严重影响到业务。而为了实现这种failover的机制，数据库的访问方式采用了短连接。

所谓短连接就是，当业务请求数据库操作时，程序触发对数据库的logon，数据库向服务器申请资源，形成一个数据库连接。但一旦获知数据库完成了该业务请求，程序立刻触发对数据库的logoff，退出数据库，关闭数据库连接，数据库释放服务器资源(相反，在业务请求完成后，程序不是急于关闭该数据库连接，而是有了新业务请求再复用之，则此类连接被成为长连接)。

这种短连接，在应用服务器不多，业务压力不大的情况下，数据库还能扛得住。一旦像这样情况突然发生变化，数据库被迫很频繁的logon和logoff，这样会导致数据库所在服务器资源极为紧张，从而让情况更加糟糕，形成恶性循环。服务器资源越紧张，前台报错越多，应用服务器重启得就越频繁，占用数据库服务器资源也就越多。

连接该生产数据库的IT程序，仅这个是短连接，其他众多IT系统都是长连接。这也解释了为什么仅该IT程序出了问题，而其他IT程序并未发生类似问题。

在优化该IT程序的数据库连接方式后，该问题得到解决。当时推动该IT程序负责人修正应用服务器的failover机制，将所有数据库连接方式从短连接改为长连接。

先在单台应用服务器上试点，发现无问题后，逐步推广到所有应用服务器，之后的几天，业务压力仍较平常高出50％，但数据库风平浪也静，其资源使用率反而降低，CPU空闲从0～1％提高到35％，大幅提升了该生产数据库的承载力(程序数据库连接方式的更改占据了优化效果的50％，另有50％从别的方面优化获得)。

随着IT系统越来越复杂，数据库的稳定也变更越来越困难。但如果我们能从全局的高度出发，充分利用这种数据库故障分析和解决的新思路，相信大家也能更加专业，为公司创造更多的价值，为自己创造更好的机会。