|
|
|
|
|
|
|
C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到客户机端和服务器端来实现，降低了系统的通信开销。目前大多数应用软件系统都是客户机／服务器形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和客户机／服务器应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
|
|
|
|
|
|
B/S （Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（浏览器）实现，但是主要事务逻辑在服务器端（服务器）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握，成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（如LAN，WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。
|
|
|
|
多层分布式系统（Multi-tier System）
|
|
|
|
|
|
随着中间件与Web技术的发展，三层或多层分布式应用体系越来越流行。在多层体系中，各层次按照以下方式进行划分，实现明确分工：
|
|
|
|
①瘦客户：提供简洁的人机交互界面，完成数据的输入／输出。
|
|
|
|
②业务服务：完成业务逻辑，实现客户与数据库对话的桥梁。同时，在这一层中，还应实现分布式管理、负载均衡、Fail/Recover、安全隔离等。
|
|
|
|
③数据服务：提供数据的存储服务。一般就是数据库系统。
|
|
|
|
|
|
|
|
.安全性。中间层隔离了客户直接对数据服务器的访问，保护了数据库的安全。
|
|
|
|
.稳定性。对于要求24×7工作的业务系统，多层分布式体系提供了更可靠的稳定性。一是中间层缓冲Client与数据库的实际连接，使数据库的实际连接数量远小于Client应用数量。当然，连接数越少，数据库系统就越稳定。二是Fail/Recover机制能够在一台服务器宕机的情况下，透明地把客户端工作转移到其他具有同样业务功能的服务上。
|
|
|
|
.易维护。由于业务逻辑在中间服务器，当业务规则变化后，客户端程序基本不做改动。
|
|
|
|
.快速响应。通过负载均衡以及中间层缓存数据能力，可以提高对客户端的响应速度。
|
|
|
|
.系统扩展灵活。基于多层分布体系，当业务增大时，可以在中间层部署更多的应用服务器，提高对客户端的响应，而所有变化对客户端透明。
|
|
|
|
|
|
目前最为流行的两类多层应用架构为Sun的J2EE和Microsoft.Net，下面简单介绍J2EE的多层架构。
|
|
|
|
|
|
|
|
|
|
客户层用于与企业信息系统的用户进行交互以及显示根据特定商务规则进行计算后的结果。基于J2EE规范的客户端可以是基于Web的，也可以是不基于Web的独立（Stand Alone）应用程序。
|
|
|
|
在基于Web的J2EE客户端应用中，用户在客户端启动浏览器后，从Web服务器中下载Web层中的静态HTML页面或由JSP或Servlets动态生成的HTML页面。
|
|
|
|
在不基于Web的J2EE客户端应用中，独立的客户端应用程序可以运行在一些基于网络的系统中，例如手持设备或汽车电话等。同样，这些独立的应用也可以运行在客户端的Java Applet中。这种类型的客户端应用程序可以在不经过Web层的情况下直接访问部署在EJB容器（EJB Container）中的EJB组件。
|
|
|
|
|
|
J2EE规范定义的Web层由JSP页面、基于Web的Java Applets以及用于动态生成HTML页面的Servlets构成。这些基本元素在组装过程中通过打包来创建Web组件。运行在Web层中的Web组件依赖Web容器来支持诸如响应客户请求以及查询EJB组件等功能。
|
|
|
|
|
|
在基于J2EE规范构建的企业信息系统中，将解决或满足特定业务领域商务规则的代码构建成为业务层中的Enterprise JavaBean （EJB）组件。EJB组件可以完成从客户端应用程序中接收数据、按照商务规则对数据进行处理、将处理结果发送到企业信息系统层进行存储、从存储系统中检索数据以及将数据发送回客户端等功能。
|
|
|
|
部署和运行在业务层中的EJB组件依赖于EJB容器来管理诸如事务、生命期、状态转换、多线程及资源存储等。这样由业务层和Web层构成了多层分布式应用体系中的中间层。
|
|
|
|
|
|
在企业应用系统的逻辑层划分中，企业信息系统层通常包括企业资源规划（ERP）系统、大型机事务处理（Mainframe Transaction Processing）系统、关系数据库系统（RDMS）及其他在构建J2EE分布式应用系统时已有的企业信息管理软件。
|
|
|
|
|
|
企业在计划购买、部署引进高端系统时必须考虑到任何解决方案在计划内外的宕机成本，对于关键应用来说宕机所造成的损失甚至超过系统的直接购买成本！造成系统宕机的原因是多方面的，除了突发性的天灾人祸之外，计划内的维护和升级同样是造成停机时间的主要因素。计划内的停机并不意味着它们不应算作停机时间，任何时候的系统离线，都会使企业由于无法满足客户的要求而产生较大的损失。因此，尽最大可能减少计划内外的停机时间已成为关键业务领域追求的主要目标。研究系统配置的主要目的就是提高系统的可用性、鲁棒性，下面简单介绍几种常用的系统配置方法。
|
|
|
|
|
|
所谓双机热备援就是两台主机均为工作机，在正常情况下，两台工作机均为信息系统提供支持，并互相监视对方的运行情况，如下图所示。当一台主机出现异常时，不能支持信息系统正常运营，另一主机则主动接管（Take Over）异常机的工作，继续主持信息的运营，从而保证信息系统能够不间断的运行，而达到不停机的功能（Non-Stop）,但正常运行主机的负载（Loading）会有所增加。此时必须尽快将异常机修复，以缩短故障时间。
|
|
|
|
|
|
|
|
|
|
|
|
（2）服务器没有宕机，但系统软件或应用软件工作不正常。
|
|
|
|
（3） SCSI卡损坏，造成服务器与磁盘阵列无法存取数据。
|
|
|
|
|
|
|
|
|
|
所谓双机热备份就是一台主机为工作机（Primary Server）,另一台主机为备份机（Standy Server）,如下图所示。在系统正常情况下，工作机为信息系统提供支持，备份机监视工作机的运行情况（工作机也同时监视备份机是否正常，有时备份机因某种原因出现异常，工作机可尽早通知系统管理员解决，确保下一次切换的可靠性）。当工作机出现异常，不能支持信息系统运营时，备份机主动接管（Take Over）工作机的工作，继续支持信息的运营，从而保证信息系统能够不间断地运行（Non-Stop）。宕工作机经过修复正常后，系统管理员通过管理命令或经由以人工或自动的方式将备份机的工作切换回工作机；也可以激活监视程序，监视备份机的运行情况，此时，原来的备份机就成了工作机，而原来的工作机就成了备份机。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对应用程序基础结构进行相应设计，将若干服务器集合为一个独立且统一的群集，可在用户或管理员无需知道群集中有多个服务器的情况下实现对计算负荷的共享，使服务器对用户和应用程序表现为虚拟统一计算资源，如下图所示。
|
|
|
|
|
|
|
|
群集系统中的各个服务器既是其他服务器的主系统，又是其他服务器的热备份系统。在某个服务器由于故障或计划停机而无法使用时，通过确保群集中其他服务器可以承担工作负载，群集服务器可以实现提高可用性的目标。此类群集可避免向访问该群集的用户或应用程序所提供服务的损失，还可透明进行服务器转移而不为用户所知。此外，可以使用群集增强可伸缩性。服务器群集可以在当前性能级别支持更多用户，或通过向多个服务器分散工作负载来提高当前数量的用户的应用程序性能。群集技术不同于双机热备技术，二者本质上的区别是能否实现并行处理和某节点失效后的应用程序的平滑接管。此外，双机热备技术只是在两台服务器上实现的。
|
|
|
|
|
|
①高可用性。使用群集服务，资源的所有权，如磁盘驱动器和IP地址将自动地从有故障的服务器上转到可用的服务器上。当群集中的系统或应用程序出现故障时，群集软件将在可用的服务器上重启失效的应用程序，或将失效节点上的工作分配到剩余的节点上。结果是用户只是觉得服务暂时停顿了一下。
|
|
|
|
②修复返回。当失效的服务器连回来时，群集服务将自动在群集中平衡负荷。
|
|
|
|
③易管理性。可以使用群集管理器来管理群集（如同在同一个群集中），并管理应用程序（就像它们运行在同一个服务器上）。可以通过拖放群集对象，在群集里的不同服务器移动应用程序。也可以通过同样的方式移动数据。可以通过这种方式来手工地平衡服务器负荷，卸载服务器，从而方便地进行维护。可以从网络的任意地方的节点和资源处，监视群集的状态。
|
|
|
|
④可扩展性。群集服务可进行调整，以满足不断增长的需求。当群集的整体负荷超过群集的实际能力时，可以添加额外的节点。
|
|
|
|
|
|
容错服务器目前已经开始大规模渗透到一些对服务器可靠性、可用性要求更为苛刻的行业，具有容错技术，能提供不间断服务的容错服务器正在冲击目前的双机热备和集群技术。
|
|
|
|
容错服务器是通过CPU时钟锁频，通过对系统中所有硬件的备份，包括CPU、内存和I/O总线等的冗余备份，通过系统内所有冗余部件的同步运行，实现真正意义上的容错。系统任何部件的故障都不会造成系统停顿和数据丢失。目前很多容错系统是基于IA架构的服务器，与Windows 2000完全兼容，实现以前只有在RISC系统上才能实现的容错。这种容错技术在IA服务器上的实现，将IA服务器的可靠性提高到了99.999%，同时服务器的运行是不间断的，也就是100%。
|
|
|
|
双机热备份和容错服务器的定位稍微有些不同，这是由两者实现的可用性差别决定的。双机热备份一般可以实现99.9%的可用性，容错服务器可以实现99.999%的可用性。这样，双机热备份大多应用在业务连续性不是很严格的行业，比如说公安系统、部队系统或者个别的制造企业，这些行业的应用允许数据有一小段时间的中断。而如交通、金融证券等要求高的行业则是容错服务器的天下了。
|
|
|
|
容错服务器是趋势，信息数据的爆炸性增长以及业务连续性的需求不断增加，都有力地证明容错服务器会是以后的一个发展趋势。双机备份方式由于需要至少2台服务器，导致在软件采购（操作系统、中间件、双机备份软件等）、软件维护升级、系统硬件升级都需要比单机容错方式多1倍的额外投入，而且在双机备份软件出现故障后，其维修的难度是业界众所周知的，对客户和代理商都会带来很大的困难。因此虽然单机容错服务器的硬件成本高于双机备份方式的硬件投入，其总成本（TCO）却远远低于双机备份方式的成本。
|
|
|
|
|
|
|
|
自上世纪50年代后期开始，人们及各种组织机构以迅速增长的速度使用计算机来管理信息。限于技术条件，早期的计算机都非常庞大且非常昂贵，任何机构都不可能为其成员提供整个计算机的使用，主机一定是共享的，它被用来存储和组织数据，集中控制和管理整个系统。所有用户都是通过系统的终端设备将数据录入到主机中处理，或者是将主机中的处理结果，通过集中控制的输出设备取出来。通过专用的通信服务器，系统也可以构成一个集中式的网络环境，使一台主机可以为多个配有I/O设备的终端用户（包括远程用户）服务。这就是早期的集中式计算机网络，一般也称为集中式计算模式。
|
|
|
|
集中式计算模式最典型的特征是：通过主机系统形成大部分的通信流程，构成系统的所有通信协议都是系统专有的，大型主机在系统中占据着绝对的支配作用，所有控制和管理功能都由主机来完成。
|
|
|
|
随着计算机技术的不断发展，尤其是大量功能先进的个人计算机的问世，使每一个人都可以完全控制自己的计算机，进行所希望的作业处理。以个人计算机（PC）方式呈现的计算能力发展成为独立的平台，导致了一种新的计算结构——分布式计算模式的诞生。
|
|
|
|
分布式计算模式与以前的集中式有很大的区别，它对计算机网络的发展起到了决定性的影响。一般认为，从八十年代到今天，分布式计算经历了三个阶段：
|
|
|
|
第一阶段称为桌上计算（Desktop Computing）。它属于PC分布式计算的初级阶段。几乎所有简单的多用户微机系统和以低版本DOS为核心的共享硬盘系统均为该阶段的内容。
|
|
|
|
第二阶段为工作组计算（Workgroup Computing）。用户在这个网络环境中，可以共享打印机及服务器的硬盘资源，并能够访问多种主机资源，获得各种通信服务。
|
|
|
|
第三阶段为网络计算（Network Computing）。这种网络环境提供了更多的开放性、更高的效能、可靠性、保密性以及对各种标准的支持；它对用户提供了透明的服务，用户可以将各类主机、网络工作站和通信服务器作为一个整体。
|
|
|
|
|
|
批处理（Batch Processing）是定期的周期性的收集源文件，然后进行成批处理。如银行存款处理，白天一天所收到的存款单等到下班后一起交给数据处理部门，由他们进行累加和其他分析。这里处理周期就是一天。
|
|
|
|
批处理的优缺点：当要处理大量的数据时批处理是一种比较经济的方法。每笔业务处理时没有必要翻动主文件。错开白天的时间，计算机可以在晚上处理，能充分利用计算机的资源。计算机的速度不一定很高，计算机档次和设备费用可以大大降低。但批处理确有很多缺点，主文件经常是过时的，打出的报告也是这样，马上查出当前的情况也是不可能的。所以，许多业务转向实时处理。某些实时处理系统中还保留着某些业务的批处理。
|
|
|
|
实时处理在处理业务时是及时的处理完这笔业务后，主文件已经进行了更新，因而这时的统计数据就反映现时的真实情况。实时处理也叫做联机处理（Online Transaction Processing, OLTP）。这时数据只要输入，记录、转换、更新主文件一气呵成，响应顾客的查询也是即时的。
|
|
|
|
实时处理的优点：实时处理能及时处理、及时更新和及时响应顾客。因而在要求及时的情况下，只有实时系统能满足要求。实时处理缺点是由于联机，直接存取必须采取特殊的措施保护数据库，以及时防止病毒和闯入者。在许多实时系统中，也使用磁带来控制日记和恢复文件。因而在设备上要付出高成本。所以实时优点必须和它的成本、安全的问题相平衡，现在由于技术的发展，要更好的满足顾客需求，越来越多的公司欢迎实时处理。
|
|
|
|
|
|
|
|
|
|
|
|
随着Internet的不断普及和技术的进步，使得以浏览器作为用户界面进行分布式计算成为可能，这种基于网络浏览器的分布式计算方式通常被称为Web计算（Web Computing）。作为一种新兴的网络计算方式，Web计算是对分布式计算的一种扩展，它的出现最终将分布式计算扩展到Internet之上。分布式对象和网络技术的集成称为对象Web，由此可以构造分布式系统模型，这已成为现代Web计算的基础。Web作为互联网最普遍的应用，成千上万的个人计算机通过它达到互通互访，这促使科学家们寄望Web计算来将无数闲散的CPU通过Web利用起来，以提供高效且廉价的计算。
|
|
|
|
Web计算也可以视为协同计算的一种形式，在其中广泛分布且为数众多的匿名用户（称为“志愿者”）协作进行由各自独立的小任务组合成的庞大计算集合。一个Web计算项目的执行，本质上这样的：感兴趣的志愿者在特定的Web计算服务器上进行注册。随后，每个注册的志愿者时常访问这个站点来获取需要计算的任务。完成任务后的某时，志愿者返回任务结果并获取一个新的任务。这样的循环一直进行下去直到计算任务完成。
|
|
|
|
作为一种新兴的计算方式，Web计算虽然隶属于分布式计算方式，但与传统的C/S结构的计算方式，以及当前的网格计算、对等计算等概念都具有一定的区别和联系。Web计算的魅力主要体现在以下一些方面：
|
|
|
|
|
|
任何用户只要拥有浏览器，并可以顺利上网，就可以接受Web计算提供的服务，而不用顾及Web计算方式具体实现的细节，因此这种计算方式又被称为B/S结构的计算方式。而对于C/S结构的计算方式来说，则必须要为用户开发定制的用户端系统。统一的用户界面成为Web计算廉价性的基石。
|
|
|
|
|
|
B/S结构是一种瘦客户机模式，因此Web计算对硬件配置的要求比较低，同时，由于系统没有涉及到用户端系统，因此，升级和维护只需要集中于服务器端。B/S结构的升级、维护成本则相对的要低得多，即使是三层C/S结构的瘦客户模式，其升级、维护的成本也无法与之相比。
|
|
|
|
|
|
HTTP协议的应用使得Web计算方式可以同时为更多的用户提供服务，并可以根据需要对系统进行扩展，体现出很好的系统鲁棒性；同时当某台应用服务器发生故障或失效时，分布式系统会自动把该应用服务器正在处理的事务请求移交给另外一台工作正常的服务器。
|
|
|
|
|
|
借用分布式技术，Web计算将复杂的业务处理分割成相互之间可交互调用和通信的若干业务功能部件或对象，并可将其分配到多个网络互联的应用服务器中实现负荷分担。这样一来Web计算方式将全部操作分散到系统的各个部分，最大限度地平衡系统负载，从而可以使系统的运行更加稳定。
|
|
|
|
|
|
由于对象可以建成与现有系统接合的方式，所以分布式对象是可以与现有系统一道工作的。一个对象如果具有现有系统的接口，就可以在分布式系统中调用以前的程序。同时，使用分布式对象时，不必重建传统的应用程序。这样便大大加快了系统的开发速度，也节省了大量资金。
|
|
|
|
|
|
严密的安全管理。Web计算中，对业务处理对象的调用和数据库的存取权限是按层次设置的。即使外部入侵者突破了客户机层的安全防线，若在应用服务器层中备有另外的安全机构，系统也可阻止入侵者进入其他部分。
|
|
|
|
|
|
所有终端的计算都是通过网络浏览器进行的，能跨越多个平台进行，能很好适应网络的异构环境；分布的Web计算对象可访问不同的后台服务器数据库，适合多种异构数据库环境，达到分布数据开放的效果。
|
|
|
|
|
|
|
|
所谓事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。事务和程序是两个概念。一般地讲，一个程序中包含多个事务。例如，在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。
|
|
|
|
事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由DBMS按默认规定自动划分事务。在SQL语言中，定义事务的语句有三条：
|
|
|
|
|
|
|
|
|
|
事务通常是以BEGIN TRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。ROLLBACK表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，滚回到事务开始时的状态。这里的操作指对数据库的更新操作。
|
|
|
|
事务具有4个特性：原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持续性（durability），这四个特性也简称为ACID特性。
|
|
|
|
|
|
事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。
|
|
|
|
|
|
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。
|
|
|
|
|
|
一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
|
|
|
|
|
|
持续性也称永久性（permanence）,指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
|
|
|
|
事务是恢复和并发控制的基本单位。所以下面的讨论均以事务为对象。
|
|
|
|
|
|
事务可以一个一个地串行执行，即每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行。事务在执行过程中需要不同的资源，有时需要CPU，有时需要存取数据库，有时需要I/O，有时需要通信。如果事务串行执行，则许多系统资源将处于空闲状态。因此，为了充分利用系统资源发挥数据库共享资源的特点，应该允许多个事务并行地执行。在单处理机系统中，事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行。这种并行执行方式称为交叉并发方式（Interleaved Concurrency）。当多个用户并发地存取数据库时就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会存取和存储不正确的数据，破坏数据库的一致性。所以数据库管理系统必须提供并发控制机制。并发控制机制是衡量一个数据库管理系统性能的重要标志之一。
|
|
|
|
事务是并发控制的基本单位，保证事务ACID特性是事务处理的重要任务，而事务ACID特性可能遭到破坏的原因之一是多个事务对数据库的并发操作造成的。为了保证事务的隔离性和数据库的一致性，DBMS需要对并发操作进行正确调度。这些就是数据库管理系统中并发控制机制的责任。并发操作带来的数据不一致性包括三类。丢失修改、不可重复读和读“脏”数据。产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性。并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰，从而避免造成数据的不一致性。
|
|
|
|
封锁是实现并发控制的一个非常重要的技术。所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他的事务不能更新此数据对象。
|
|
|
|
确切的控制由封锁的类型决定。基本的封锁类型有两种：排它锁（Exclusive Locks,简称X锁）和共享锁（Share Locks，S锁）。
|
|
|
|
排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
|
|
|
|
共享锁又称为读锁。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
|
|
|
|
尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成部分，而且还相当庞大，常常占整个系统代码的百分之十以上。数据库系统所采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大影响，是衡量系统性能优劣的重要指标。
|
|
|
|
事务内部的故障有的是可以通过事务程序本身发现，有的是非预期的，不能由事务程序处理的。事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制等。以后，事务故障仅指这类非预期的故障。
|
|
|
|
事务故障意味着事务没有达到预期的终点（commit或者显式的rollback），因此，数据库可能处于不正确状态。恢复程序要在不影响其他事务运行的情况下，强行回滚（rollback）该事务，即撤销该事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动一样。这类恢复操作称为事务撤销（undo）。
|
|
|
|
发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，从而造成数据库可能处于不正确的状态。为保证数据一致性，需要清除这些事务对数据库的所有修改。恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销（undo）所有未完成事务。
|
|
|
|
另一方面，发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢失，这也会使数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后，恢复子系统除需要撤销所有未完成事务外，还需要重做（redo）所有已提交的事务，以将数据库真正恢复到一致状态。
|
|
|
