分析数据库系统中容易出错的部分以及出错时所产生的症状

1. 人为的假信号（用户错误或者管理错误）
这一类型的错误通常比其他错误更为常见。人为错误通常可以分为两类：用户错误与管
理错误。用户错误常常表现为用户具有过多的权限，从而可以访问没有被授权的一些数据。
如果贵公司的数据库系统曾经有过被未授权的用户“偶然地”访问过的经历，那么就很容易
理解笔者的意思。另一方面，管理错误常常是由于贵公司的计算机系统的网络或者数据库管
理人员过度劳累或者其他错误所导致。如果读者曾经见过某个 CIO (首席顾问) 对一个新聘请
的系统管理员进行呵斥，骂他在管理网络的过程中所带来的错误而导致服务的丢失时，就会
理解笔者的意思。
需要说明的是，这一种错误也可以归纳为“缺乏安全性”。发生以上错误的最终结果就有
可能使新聘请的D B A被认为非常懒惰，从而被解雇。
2. 硬件/软件出错
正如前面所述，数据库系统中的每个组件要么是由可能会出现 b u g的软件构成的（如操作
系统、数据库），要么是由可能会导致失败的硬件构成。无论在哪种情况下，软件 b u g或者硬
件失败都有可能会导致整个系统的崩溃。无论何时，只要出现了软件 b u g，就必须使用适当的
补丁来进行修复，从而最终需要重新启动计算机系统。事实上，即使是出现软件 b u g，许多操
作系统（例如U N I X和N T）也必须由于内存/页面错误、核转储、内存交换、内存出错等等的
原因而重新启动。许多普通的系统管理员或者 D B A都习惯于在这种情况下直接进行系统重新
启动。但是，在一个高可用性环境中，这种做法是不可思议的。
在购买硬件之前，还有必要进行充分的需求评估。对于许多高可用性站点，他们在购买
新硬件之前都会利用自己所开发的测试程序利用真实的数据对此硬件进行测试。数据库系统
操作人员必须对每个硬件的技术指标有充分的了解，并且对硬件的理论 M T B F（Mean Ti m
Between Failure，失败平均间隔时间；详情请见后面关于 M T B F的讨论）与实际M T B F非常熟
悉。例如，如果某个硬盘驱动器的理论 M T B F（这是导致硬件失败的常见原因）为 500 000小
时，这就表示从理论上来说，硬盘驱动器可以连续地在 2 4×7方式下工作5 7年。同时，许多公
司也利用非常真实的模拟环境去对产品进行测试。它们首先测试的是环境的改变（包括操作
系统补丁、操作系统发布以及新环境）。并且只有在那些新的改变经过充分的认证之后，才能
将它们加入到数据库系统应用中。所有为建立这些测试环境所花费的开销都应该算作为了获
取数据库系统高可用性而花费的开销中的一部分。
3. 环境失败
读者也许曾经有过接收到住房管理部门关于在星期六将要断电的通知（这种情况一年中
也许总会发生几次）。碰到这种情况，用户也不用过于担心，这是因为后备的电源仍然可以保
证使用至少六个小时。除了电源方面的问题之外，其他环境因素包括工人罢工等等也会影响
数据库系统正常工作。几年前，当笔者还是一个化工厂的全职 D B A时，工厂内部的工人举行
了一次罢工，那时笔者无法进入工厂内部。这样，笔者就不能启动数据库系统并且实现远程
控制。甚至是连进行数据库系统的备份动作也不行，因为根本就不能对磁带驱动器中的磁带
进行更换。
4. 自然灾害与人为灾害
这些情况包括地震、水灾、火灾、战争、暴乱等等。
这些事情在任何时候都有可能会发生，关键问题在于：是否为此作好了准备？如果明天
就发生这些情况，该怎么办？是否需要为所有这些情况都进行防范，或者仅仅需要防范软件、
硬件以及用户错误等问题？这些也是笔者常常问客户的一些问题。可以说，在平时需要 2 4×7
正常工作时间的客户，在战争或者地震时也许就不需要这种方式。当然，存在许多跨国公司，
他们要求即使是出现了这些情况也要实现数据库系统的 2 4×7方式，特别是对于电子商务更是
如此。但是，如果贵公司的规模并不那么庞大，虽然也许会要求对这些突然事件进行防护，
但没有必要为此支付高额的代价来实现 2 4×7方式（在这些突发事件下）。那么，什么才是最
佳的解决方案？必须在实现某个解决方案之前花费充分的时间来理解公司的商业目标，然后
再拟出一个解决方案的草案。如果这个解决方案与公司的商业目标相一致，那么就有可能得
到一个非常成功而且容易被接受的解决方案。