|
|
知识路径： > 信息系统开发和运行管理知识 > 系统运行管理知识 > 系统故障管理（处理步骤、监视、恢复过程、预防措施） > 故障及问题管理 >
|
被考次数：2次
被考频率：低频率
总体答错率：40%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：了解
相关知识点：47个
|
|
|
|
|
本章开头提到，故障包括系统运转过程中出现的系统本身的问题和引起服务中断和服务质量下降的非标准操作事件。对于后者，我们主要利用故障管理的流程对其进行控制，对于系统本身出现的主要问题，下面将介绍处理办法和恢复措施。
|
|
|
|
|
|
如计算机发生故障导致系统不能运行则应停机进行临时性维修。首先要区分是软件故障还是硬件设备故障。软件故障可能是因为系统软件的某个环节在特定组合条件下不能正常运行引起的，也可能是由多种作业在运行中因争夺资源而出现“死锁”等原因造成的。这类故障一般可采用重启系统或者其他人工干预手段予以恢复和排除。如果是设备性能变差引起的硬件故障，则应切换到备用系统，尽快恢复系统服务。然后使用测试程序检测故障机的各个部件，特别是中央处理器和磁盘存储器两个部件（输入输出部件一般不至于影响整个系统的正常运行），尽快进行故障定位，然后针对故障部位进行后续维修。
|
|
|
|
|
|
主机故障时通常需要启用系统备份进行恢复。根据所提供的备份类型不同，主机服务上可分为三种：热重启（Hot Restart）、暖重启（Warm Restart）和冷重启（Cold Restart）。热启动服务专门针对客户暂时的系统故障，提供立即恢复系统可用性的服务，以完成客户某些紧急的任务。冷启动服务提供商专门解决那些长期的系统问题（例如由于一栋大楼的倒塌使得整个系统完全瘫痪等）。
|
|
|
|
|
|
无论是由硬件还是由软件引发的系统故障，其持续时间长短取决于系统的重启动能力。如果系统采用热重启、暖重启或冷重启模式，故障管理中的处理方式将各不相同。重启模式受事件发生之时系统可用信息量的影响，可用的信息越多，重启速度也就越快。
|
|
|
|
|
|
热重启的恢复时间最快，但也最难实现。在热重启模式下，应用程序保存系统当前运行的状态信息，并将该信息传送给备份部件，以实现快速恢复。应用程序要具备利用这些状态信息实现系统的重启动的能力。
|
|
|
|
热重启系统中同样需要在故障管理事件之前预先指定备份部件。这在2N系统中最为明显，因为该系统的部件与备份部件是一一对应的（见下图）。而在N+1系统中，热重启要求备份部件保存多个运行中部件的状态信息，因此备份部件就必须具有额外存储能力，否则就必须采用暖重启模式。
|
|
|
|
|
|
|
|
|
|
暖重启与热重启类似。在该模式下，应用程序保存系统当前运行的状态信息，见下图所示。在执行故障管理时指定备份部件。备份部件需配置必要的应用程序和状态信息，这就增加了重启时间，但降低了备份部件的成本。在备份部件与现行部件不完全相同的系统中，更易实现暖重启。
|
|
|
|
|
|
|
|
|
|
冷重启是最易于实现的，但需要最长的重启动时间。冷重启意味着备份部件对故障部件的运行状态一无所知，备份部件只能从初始化状态开始。
|
|
|
|
实现冷重启几乎无须对系统应用程序做任何修改，由操作系统和服务程序实现高可用性软件的功能。但这是以系统更长的重启时间为代价的，并将丢失系统所有当前的运行状态信息。
|
|
|
|
各种重启模式所需的时间取决于系统及应用软件的实现方法。相对而言，如果热重启模式的时间为T，那么暖重启的时间将会是2～3T，冷重启的时间将接近10～100T。
|
|
|
|
|
|
当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。数据库故障主要分为事务故障、系统故障和介质故障，不同故障的恢复方法也不同。
|
|
|
|
|
|
事务故障是指事务在运行至正常终点前被终止，此时数据库可能处于不正确的状态，恢复程序要在不影响其他事务运行的情况下强行回滚（rollback）该事务，即撤销该事务已经做出的任何对数据库的修改，使得事务好像完全没有启动一样。事务故障的恢复由系统自动完成。恢复的步骤是：
|
|
|
|
（1）反向（从后向前）扫描日志文件，查找该事务的更新操作。
|
|
|
|
（2）对该事务的更新操作执行逆操作，也就是将日志记录更新前的值写入数据库。如果记录中是插入操作，则相当于做删除操作，如果记录中是删除操作则做插入操作，若是修改操作则相当于用修改前的值代替修改后的值。
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
|
|
|
|
（4）如此处理下去，直到读到了此事务的开始标记，事务故障恢复就完成了。
|
|
|
|
|
|
系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不会破坏数据库。此时主存内容（尤其是缓冲区中的内容）都将被丢失，所有运行事务都被非正常终止，有些已完成的事务可能有部分甚至全部留在缓冲区中尚未被写入磁盘，为了保证一致性，应将这些事务已提交的结果重新写入数据库；此外，一些尚未完成的事务结果可能已经被送入物理数据库，为了保证一致性，需要清除这些事务对数据库的所有修改。系统故障的恢复是由系统在重新启动时自动完成的，此时恢复子系统撤销所有未完成的事务并重做（redo）所有已提交的事务。具体的步骤是：
|
|
|
|
（1）正向（从头到尾）扫描日志文件，找出故障发生前已经提交的事务（这些事务既有Begin Transaction记录，也有commit记录），将其事务标识记入重做（redo）队列。同时找出故障发生时尚未完成的事务（这些事务只有Begin Transaction记录，无相应的commit记录），将其事务标识记入撤销（undo）队列。
|
|
|
|
（2）反向扫描日志文件，对每个undo事务的更新操作执行逆操作，也就是将日志记录中更新前的值写入数据库。
|
|
|
|
（3）正向扫描日志文件，对每个redo事务重新执行日志文件登记的操作，也就是将日志记录中更新后的值写入数据库。
|
|
|
|
|
|
系统故障常被称为软故障，介质故障常被称为硬故障。硬故障是指外存故障，例如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务，日志文件也将被破坏。这类故障比前两类故障发生的可能性要小，但是破坏性最大。恢复方法是重装数据库，然后重做已完成的事务，具体的步骤是：
|
|
|
|
（1）装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
|
|
|
|
|
|
介质故障的恢复需要DBA的介入，DBA只需重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令，具体的恢复操作仍由DBMS完成。
|
|
|
|
|
|
当遇到线路故障或者是网络连接问题时，需要利用备用电路或者改变通信路径等恢复方法，具体的途径如下。
|
|
|
|
（1）双主干，当原网络发生故障时，辅助网络就会承担数据传输的任务，两条主干线缆的物理距离应当相距较远，来减少两条线缆同时损坏的概率。
|
|
|
|
（2）开关控制技术，由开关控制的网络可以精确地检测出发生故障的地段，并用辅助路径来分担数据流量，同时，可以通过网络管理控制程序来管理网络，部件故障可以很快显示在控制程序界面上并响应故障。
|
|
|
|
（3）路由器，一些故障导致必须从别的路径访问别的服务器，这时路由器可以为数据指明流动的方向。
|
|
|
|
（4）通信中件，通信中件可以使通信绕过网络中发生故障的电路，通过其他网络连接来传输数据。
|
|
|
