目录
一.事务
1.1事务的概念【重要】
事务：“将一组数据库操作打包起来形成一个逻辑独立的单元，这个工作单元不可分割，其中包含的数据要么全部都发生，要么全部都不发生”。
在SQL中，界定事务的语句有三条：
- BEGIN TRANSCATION //开始一个事务，事务开始标记
- COMMIT //提交当前事务，成功结束标记
- ROLLBACK //撤销(回滚)当前事务，失败结束标记
1.2事务的特性【重要】
一个逻辑独立的工作单元要成为事务，必须满足4个特性：“原子性”、“一致性”、“隔离性”、“持久性”，简称“ACID特性”。
1.2.1原子性(Atomicity)
原子性，指事务的不可分割性，组成事务的所有操作要么全部被执行，要么全部不执行。
1.2.2一致性(Consistency)
一致性，是指在事务执行之前和执行之后数据库都必须处于一致性状态，即事务的执行使得数据库从一个一致性状态转变到另一个一致性状态。
通俗来说就是使数据库满足完整性约束。
例如：“银行的一个账户存款与取款之差应该等于余额，如果存款或者取款时不修改余额，就会造成数据库处于不一致状态”。
1.2.3隔离性(Isolation)
隔离性，是指多个事务并发执行时必须相互独立，不能相互干扰。
并发执行的事务不必关心其它事务执行如何。
1.2.4持久性(Durability)
持久性，也称持续性，是指已经提交的事务对数据库的改变应该是永久的、持续存在的、即便以后系统发生故障，事务的这种影响也不应该丢失。
二.数据库恢复
数据库恢复是指：“把数据库从一个错误状态恢复到某一已知的正确状态(即一致状态或完整状态)”
DBMS的恢复机制根据数据库错误类型，有两种处理方法：
- 未完成事务：撤销未完成事务对数据库的一切影响，保证事务的原子性。
- 已提交事务：恢复事务对数据库的更新影响，保证事务的持久性。
2.1数据库系统的故障
数据库系统中可能发生的故障大致有四类：“事物内部故障”、“系统故障”、“介质故障”、“计算机病毒”。
2.1.1事务内部故障
事物内部故障，指在事务内部操作执行过程中可能发生的故障，可以分为：“预期故障”、“非预期故障”。
- 预期故障，即在程序中程序员应该预先估计到并加以处理的错误。
- 非预期故障，即在程序运行中发生的无法预估并能预处理的错误。
2.1.2系统故障
系统故障，又称软故障，指造成系统停止运转并要求系统重新启动的事件。
造成系统故障的原因可能有：“CPU故障”、“操作系统故障”、“突然断电”等。
2.1.3介质故障
介质故障，又称硬故障，指在数据库系统运行过程中，因“磁盘损坏”、“磁头碰撞”、“强磁场干扰”等导致数据库的数据库部分或全部丢失的一类故障(外力因素/物理层次)。
2.1.4计算机病毒
计算机病毒，指一组能够自我复制传播的计算机指令或者程序代码，能够破坏计算机功能或破坏数据，影响计算机包括数据库系统的使用。
2.2数据库恢复的实现技术
数据库恢复的基本原理是建立“冗余”，即在数据库正常运行时重复存储一些数据和信息，保证有足够的信息用于故障恢复。
通常数据库系统中利用“数据转储”和“日志文件”两种方法来建立冗余数据。
2.2.1通过数据转储建立冗余
数据转储就是由DBA(数据库管理员)定期地将整个数据库复制到磁盘或另一个磁盘上面的过程，转储的数据库叫作“数据库副本”或“后备副本”、“后援副本”。
当数据库发生故障时，就可以将最近的后备副本或重新装入，把数据库恢复起来。
显然，此时数据库只能恢复到最近转储时的状态。
转储按照存储状态可以分为：“静态转储”、“动态转储”。
- 静态转储：静态转储是在系统中没有事务运行的时候进行的转储操作，缺点是效率低。
- 动态转储：动态转储允许对数据库进行存取或更新，即存储和用户事务可以并发执行，缺点是没办法保证副本和数据库的一致性。
转储按照存储方式可以分为：“海量转储”、“增量转储”。
- 海量转储：转出全部数据库内容
- 增量转储：只转储更新过的数据
数据的“增量转储”和“海量转储”也可以分别在“动态”和“静态”两种状态下进行，因此数据转储的方法可以分为4类：“动态海量转储”、“动态增量转储”、“静态海量转储”、“静态增量转储”。
2.2.2通过日志文件建立冗余
日志文件是用来记录事务对数据库所做的每一次更新活动的文件。
每一次更新活动的内容作为一条日志记录，写入日志文件，也成为登记日志。
一条日志记录的主要内容包括：“事务标识”、“操作类型”、“对象标识”、“前像”、“后像”。
- 事务标识：唯一地标识执行更新操作的事务。
- 操作类型：“start”、“commit”、“rollback”、“update”、“insert”、“delete”。
- 对象标识：唯一地标识更新操作所针对的数据对象。
- 前像：数据对象在更新操作执行之前的旧值
- 后像：数据对象在更新操作执行之后的新值
事务执行过程中，如果发生如下事件，或者操作，就在日志文件中写一个日志记录。
- 事务T开始：日志记录为(T,start,,,)
- 事务T修改对象A：日志记录为(T,update,A,前像,后像)
- 事务T插入对象A，日志记录为(T,insert,A,,后像)
- 事务T删除对象A，日志记录为(T,delete,A,前像,)
- 事务T提交，日志记录(T,commit,,,)
- 事务T回滚，日志记录(T,rollback,,,)
登记日志时，必须遵循如下两条原则：
- 登记的次序必须严格按照并发事务执行的时间次序。
- 必须先写日志文件，然后写数据库，并且日志文件不能和数据库放在同一物理磁盘上。
2.3故障恢复
不同的故障需要采用不同的策略恢复：
2.3.1事务内部故障的恢复
事务内部故障，必定发生在当前事务提交之前，这时应撤销(UNDO)事务对数据库的一切更新影响。
故障恢复由DBMS自动完成，步骤如下：
- 反向扫描日志文件，查找该事务的更新操作。
- 若查到是更新操作，则将日志文件“前像”写入数据库；若是插入操作，则将数据对象删去；若是删除操作，则做插入操作，插入数据对象的值为日志记录中的“前像”。
- 继续反向扫描日志文件，找出其他的更新操作，并做同样的处理，直至找到该事务的start标记为止。
2.3.2系统故障的恢复
系统故障会使主存中的数据丢失，此时已提交事务对数据库的更新可能还驻留在内存工作区而未写入数据库，为保证已提交事务的更新不会丢失，需要重做(REDO)已提交事务；
此外，对未提交的事务还必须撤销所有对数据库的更新。
系统故障恢复由DBMS自动完成，步骤如下：
- 从头扫描日志文件，找出在故障发生前已提交的事务(即有satrt记录和commit记录的事务)，将其计入重做(REDO)队列。同时找出尚未完成的事务(即只有start记录，而没有commit或rollback的记录)，将其计入(UNDO)队列。
- 对REDO队列中每个事务进行REDO操作，即正向扫描日志文件，根据登入日志文件中日志记录次序，重新执行登记操作。
- 对UNDO队列中咩个食无进行UNDO操作，即反向扫描日志文件，根据登入日志文件中相反次序，对每个更新操作执行你操作。
2.3.3介质故障的恢复
发生介质故障后，磁盘以及磁盘上的数据均可能被破坏。
这时恢复的方法是“重装数据库”，重做已经完成的事务，具体措施如下：
- 必要时更换磁盘，修复系统，重新启动系统。
- 装入最近的数据库后备副本，使数据库恢复到最近一次转储时的可用状态。
- 装入日志文件副本，根据日志文件重做最近一次转储之后提交的所有事务。
2.3.4检查点技术
如果日志文件很大(几GB)，那么系统在执行恢复操作时，要遍历一个庞大的日志文件，容易造成系统宕机，因此引入“检查点技术”，可减少系统故障恢复时扫描日志记录的数目。
检查点，是数据库的一个内部事件，在系统运行过程中，DBMS按一定时间间隔在日志文件中设置一个检查点。
设置检查点需要执行以下操作：
- 暂停事务的执行，在日志文件中写一条检查点开始记录。
- 将上一个检查点之后已提交的事务留在内存工作区，所有更新的数据写入数据库(即磁盘上)
- 在日志文件中写入一个检查点结束记录。
762
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
