事务处理技术。 事务是数据库操作列中数据库APP应用程序的基本逻辑单元。 事务处理技术主要包括数据库恢复技术和并发控制技术。 数据库恢复机制和并发控制机制是数据库管理系统的重要组成部分
事务的基本概念1、事物
事务是用户定义的数据库操作序列，所有这些操作都是、完全不执行或不可分割的工作单位。 在关系数据库中，事务可以是SQL语句、一组SQL语句或整个程序。
事务和程序是两个概念。 一般来说，一个程序包含多个事务。
事务的开始和结束可以由用户显式控制。 如果用户没有明确定义事务，数据库管理系统将根据默认规定自动拆分事务。 在SQL中，定义事务的语句通常有三个。
Begin传输； //开始办公
Commit； //成功执行并提交
回滚； //执行失败，回滚
事务通常以Begin transaction开始，以Commit或Rollback结束。
Commit将提交，即提交事务的所有操作具体而言，将对事务中所有数据库的更新写回磁盘上的物理数据库，然后事务成功完成。
回滚意味着回滚。 这意味着在事务执行过程中发生了某些故障，事务无法继续。系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态此处的操作是指数据库更新操作。
2、事务的特性
事务有原子性、整合性、隔离性、持续性四个特性。
)1)原子性)事务是数据库的逻辑工作单元，事务中包含的所有操作均已完成或不全部完成。
)2)一致性)事务的执行结果必须将数据库从一个一致性状态更改为另一个一致性状态。 因此，如果数据库仅包含成功事务提交的结果，则数据可以说是一致的。 如果数据库系统在运行时发生故障，则某些事务会保持未完成而中断，并且当未完成事务对数据库所做的某些更改写入数据库时，数据库可能处于不正确的状态，或者数量一致
)3)隔离性)一个事务的执行不能被其他事务干扰。 也就是说，在一个事务内部操作中使用的数据在其他同时事务的情况下被隔离，并且不能在同时执行的每个事务之间相互干扰。
)4)持续性)持久性也称为持久性，这意味着提交事务时，数据库中的数据会发生更改。 后续的其他操作和故障不得影响执行的结果。
数据库恢复概述为了不破坏数据库的安全和完整性，数据库系统采取了各种措施，同时确保事务正常运行，但计算机系统中的硬件故障、软件如果这些故障较轻，执行事务将异常中断，影响数据库中数据的准确性；如果故障较重，数据库将被破坏，数据库中的全部或部分数据将丢失。 因此，数据库管理系统必须能够将数据库从错误状态恢复到已知的正确状态(也称为一致状态或完全状态)。 这就是数据库恢复。 恢复子系统是数据库管理系统的重要组成部分，非常巨大，往往占整个系统代码的10%以上。 数据库管理系统中采用的恢复技术是否有效，不仅对系统的可靠性起着决定性的作用，而且对系统的运行效率有着很大的影响。是衡量系统性能优劣的重要指标
故障类型1、事务内部的故障
事务内部的故障有些是在事务程序本身中发现的，有些是意外的，有些是事务程序无法处理的。
【例】银行转账事务，此事务将金额从一个账户甲转移到另一个账户乙。
begin transaction阅读账户甲余额balance； balance=balance-amount； /*amount打印转账金额*/if (平衡账户) then {“金额不足，不可转账”回滚； (} else { )账户乙方余额balance1； 平衡1=平衡1 amount； 写回banlance1commit； }此示例中的两个更新操作要么全部完成，要么全部不执行。 否则，数据库将处于不匹配状态，例如，只有账户甲的余额减少，账户乙的余额可能不会增加。
如果此程序遇到帐户甲方余额不足的情况，APP应用程序可以发现并回滚事务，撤消更改，并将数据库恢复到正确的状态。
如果事务内部发生更多故障，则APP应用程序无法处理意外情况。 运算溢出、并发事务发生死锁，违反被选择为取消该事务的某些完整性限制而终止等。
事务失败意味着事务未到达预期的端点(commit或显式回滚)，数据库可能不正确。 恢复程序必须强制回滚，而不影响其他事务的执行
事务，即撤销事务已经做出的任何对数据库的修改，使得该事务好像没有启动一样。这类恢复操作称为事务撤销。2、系统故障
系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。。例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误，系统断电等。这类故障影响正在运行的所有事务，但是不破坏数据库。此时主存的内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已经送入物理数据库，从而造成数据库可能处于不正确的状态。为保证数据的一致性，需要清除这些事务对数据库所有的修改。
恢复子系统必须在系统重启时让所有非正常终止的事务回滚，强行撤销所有未完成的事务。
另一方面，发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或者全部丢失，这也会使数据库处于一个不一致状态，因此应将这些事务已提交的结果重新写入数据库。所以系统重新启动后不，恢复子系统除需要撤销所有未完成的事务外，还需要重做所有已提交的事务，以将数据库真正恢复到一致状态。
3、介质故障
系统故障常称为软故障，介质故障称为硬故障。硬故障指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障发生的可能性小得多，但破坏性最大。
4、计算机病毒
计算机病毒是一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序。这种程序与其他程序不同，它向微生物所称的病毒一样可以繁殖和传播，并造成对计算机系统包括数据库的危害。
总结各类故障对数据库的影响有两种可能性，一是数据库本身被破坏，二是数据库没有被破坏但是数据可能不正确，这是事务的运行被非正常终止造成的。
恢复的基本原理十分简单。可以用一个词概括：冗余。这就是说，数据库中任何一部分被破坏或不正确的数据可以根据存储在系统别处的冗余数据来重建。尽管恢复的原理十分简单，但实现技术的细节却相当复杂。
恢复的实现技术恢复机制涉及的两个关键问题是：如何建立冗余数据，以及如何利用这些冗余数据实现数据库恢复。
建立冗余数据最常用的技术是数据转储和登记日志文件。通常在一个数据库系统中，这两种方法是一起实现的。
数据转储（备份）数据转储是数据库恢复中采用的基础技术。所谓转储就是数据库管理员定期的将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备份数据称为后备副本或后援副本。
当数据库遭到破坏后可以将后备版本重新装入，但重装后备版本只能将数据库恢复到转储时的状态。
【例】转储和恢复
系统在Ta时刻停止运行事务，进行数据转储，在Tb时刻转储完毕，得到Tb时刻的数据库一致性副本。系统运行到Tf时刻发生故障。为恢复数据，首先由数据库管理员重装数据库后背版本，将数据库恢复至Tb时刻的状态，重新运行自Tb~Tf时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态。
转储是十分耗费时间和资源的，不能频繁进行。数据库管理员应该根据数据库使用情况确定一个适当的转储周期。
转储可分为静态转储和动态转储。
静态转储是系统在无运行事务时进行的转储操作，即转储操作开始的时刻数据库处于一致性状态，而转储期间不允许对数据库的任何存取、修改活动。显然，静态转储得到的一定是一个数据一致性副本。
静态转储简单，但转储必须等待正运行的用户事务结束才能进行。同样，新的事物必须等待转储结束才能执行，显然这会降低数据库的可用性。
动态转储是指转储期间允许对数据库进行存取或修改，即转储和用户事务并发执行。动态转储可以克服静态转储的缺点，它不用等待正在运行的用户事物结束，也不会影响新事物的执行。但是转储结束时后援版本上的数据并不能保证正确有效。
为此，必须把转储期间各事物对数据库的修改活动登记下来，建立日志文件。这样，后援版本加上日志文件就能把数据库恢复到某一时刻的正确状态。
转储还可以分为海量转储和增量转储两种方式。海量转储是指每次转储全部数据库，增量转储则指每次只转储上一次转储后更新过来的数据。从恢复角度看，海量转储的到的后备副本得到进行恢复一般来说会更方便些。但是如果数据库很大，事务处理又十分频繁，则增量转储方式更实用有效。
数据转储分类 转储方式转储状态动态转储静态转储海量转储动态海量转储静态海量转储增量转储动态增量转储静态增量转储登记日志文件1、日志文件的格式和内容
日志文件是用来记录事务对数据库更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。概括起来日志文件主要有两种格式：以记录为单位的日志文件和以数据块为单位的日志文件。
以记录为单位的日志文件，日志文件中需要登记的内容包括：
各个事务的开始（begintransaction）标记各个事务的结束（commit或rollback）标记各个事务的所有的更新操作这里每个事务的开始标记、每个事务的结束标记和每个更新操作均作为日志文件的一个日志记录（log record）
每个日志记录的内容主要包括：
事务标识（标明是哪个事务）操作的类型（插入、删除、或修改）操作的对象（记录内部标识）更新前数据的旧值（对插入操作而言，此项为空值）更新后数据的新值（对删除操作而言，此项为空值）对于以数据块为单位的日志文件，日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块存放入日志文件中，操作类型和操作对象等信息就不用放入日志记录中了。
2、日志文件的作用
日志文件在数据库恢复中起着非常重要的作用，可以用来进行事务故障的恢复和系统故障的恢复，并协助后备副本进行介质故障恢复，具体作用是：
事务故障恢复和系统故障恢复必须用日志文件。在动态转储方式中必须建立日志文件，后背副本和日志文件结合起来才能有效的恢复数据库。在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时为完成的事务进行撤销处理。利用日志文件恢复
3、登记日志文件
为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：
登记的次序严格按并发事务执行的时间次序必须先写日志文件，后写数据库恢复策略 事务故障的恢复事务故障是指事务在运行至正常终止点前被终止，这时恢复子系统应利用应利用日志文件撤销此事务对数据库进行的修改。事务故障的恢复是由系统自动完成的。，对用户是透明的。系统恢复的步骤是：
反向扫描日志文件，查找该事务的更新操作。对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写进数据库。继续反向扫描日志文件，查找该事务的其他更新操作，并作同样的处理。如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。系统故障的恢复系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新操作可能已经写进数据库，二是已提交事务对数据库的更新可能还留在缓冲区还没来得及写进数据库。因此恢复操作就是要撤销故障发生时未完成的事务，重做已完成的事务。
系统故障的恢复是由系统在重新启动时自动完成的，不需要用户的干预。
系统恢复的步骤是：
正向扫描日志文件，找出故障发生时已经提交的事务（这些事务既有begin transaction记录，也有commit 记录），将其事务标识记入重做队列（redo-list）。同时找出故障发生时尚未完成的事务（这些事务只有begin transaction记录，无相应的commit记录），将其事务标识记入撤销队列（undo-list）对撤销队列中的各个事务进行撤销（undo）处理：进行撤销的方法是反向扫描日志文件，对每个撤销事务的更新操作进行逆操作，即将日志记录中“更新前的值”写入数据库。对重做队列中的各个事务进行重做处理：进行重做的方法是正向扫描日志文件，对每个事务重新执行日志文件登记的操作，即将日志记录中“更新后的值”写入数据库。介质故障的恢复发生介质故障后，磁盘上的物理数据和日志文件被破坏，这时最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。
装入最新的数据库后备副本（离故障发生时刻最近的转储版本），使数据库恢复到最近一次转储时的一致性状态。
对于动态转储的数据库副本，还需要同时装入转储开始时刻的日志文件副本，利用恢复系统的故障的方法（redo+undo）才能将数据库恢复到一致性状态。
装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。
这样就可以将数据库恢复至故障前某一时刻的一致性状态。
介质故障的恢复需要数据库管理员介入，但数据库管理员只需要重装最近转储的数据库副本和有关的各种日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由数据库管理系统完成。
具有检查点的恢复技术利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要重做，哪些事务需要撤销。一般来说，需要检查所有日志记录。这样做有两个问题，一是搜索整个日志将耗费大量的时间，而是很多需要重做处理的事务实际上已经将它们的更新操作结果写到了数据库中，然而恢复子系统又重新执行了这些操作，浪费了大量的时间。为了解决这些问题，又发展了具有检查点的恢复技术。这些技术在日志文件中增加一类新的记录：检查点记录，增加一个重新开始的文件，并让恢复子系统在登录日志文件期间动态的维护日志。
检查点记录的内容包括：
建立检查点的时刻所有正在执行的事务的清单。这些事务最近一个日志记录的地址。重新开始文件用来记录各个检查点记录在日志文件中的地址。
具有检查点的日志文件和重新开始文件动态维护日志文件的方法时，周期性的执行建立检查点、保存数据库状态的操作。具体步骤是：
将日志缓冲区中的所有日志记录写入磁盘上的日志文件上将日志文件写入一个检查点记录将当前数据缓冲区的所有数据记录写入磁盘的数据库中把检查点记录在日志文件中的地址写入一个重新开始文件恢复子系统可以定期或者不定期的建立检查点，保存数据库状态。检查点可以按照预定的时间间隔建立，如每隔一个小时建立一个检查点；也可以按照某种规则建立检查点，如日志文件已写满一半建立一个检查点。
使用检查点方法可以改善恢复效率。当事务T在一个检查点之前提交，T对数据库所作的修改一定都已写进数据库，写入时间是在这个检查点建立之前或在检查点建立之时。这样在进行恢复处理时，没有必要对事物T执行重做操作。
恢复子系统采取的不同策略T1：在检查点之前提交。
T2：在检查点之前开始执行，在检查点之后，故障点之前提交。
T3：在检查点之前开始执行，在故障点时还未完成。
T4：在检查点之后开始执行，在故障点之前提交
T5：在检查点之后开始执行，在故障点时还未完成
T3和T5在故障发生时还未完成，所以予以撤销操作，T2和T4在检查点之后提交，他们对数据库所作的修改在故障发生时可能还在缓冲区中，尚未写入数据库，所以要重做；T1在检查点之前提交所以不必执行重做操作。