其他章节here
梳理
名词解释
- 事务：事务是用户定义的 一个数据操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位
- 事务≠程序
- 事务是恢复和并发控制的基本单位
（事务时数据库应用程序的基本逻辑单元，亦即最小单位） - 定义事务
- 隐式方式
当用户没有显示地定义事务时，dbms按缺省规定自动划分事务 - 显示定义事务
- 隐式方式
- 事务≠程序
- 事务的ACID特性
- 原子性Atomicity
事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做 - 一致性Consistency
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态- 一致性状态：当数据库只包含成功事务提交的结果时，数据库处于一致性状态（否则为不一致的状态）
- 隔离性Isolation
一个事务的执行不能被其他事务干扰。
即一个事务的内部操作及使用的数据对其他并发事务时隔离的，并发执行的各个事务之间不能互相干扰 - 持续性Durability
一个事务一旦提交，它对数据库中数据的改变就应该时永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响
- 原子性Atomicity
- 事务ACID特性可能遭到破坏 的因素
- 多个事务并行运行时，不同事务的操作交叉执行
- 事务在运行过程中被强行停止
（故障恢复可以保障原子性和持续性
并发控制可以保障一致性和隔离性）
- 数据库恢复
数据库管理系统把数据库从错误状态恢复到某一已知的正确状态（也称为一致状态或完整状态）的技术 - 故障种类
- 事务内部的故障
有的是可以通过事务程序本身发现的；
有的是非预期的，不能由事务程序处理- 事务内部更多的故障时非预期的，事务故障仅指这类非预期的故障
- 事务故障意味着没有达到预期的终点，数据库可能处于不正确的状态
- 事务故障的恢复：事务撤销UNDO
强行回滚该事务，即撤销该事务已经作出的任何对数据库的修改，使得该事务如没启动一样
- 系统故障
称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动- 系统故障的影响
- 系统故障的恢复
- 系统重新启动时，让所有非正常终止的事务回滚，强行撤销所有未完成事务（撤销已完成）
- 系统重新启动后，恢复程序重做（REDO）所有已提交的事务（重做已提交）
- 系统故障的影响
- 介质故障（磁盘损坏，磁头碰撞，瞬时强磁场干扰）
称为硬故障，指外存故障- 破坏数据库或部分数据库，并影响正在存取这部分数据的事务
- 发生的可能性比前两类小，但是破坏性大得多
- 计算机病毒
人为的故障或者破坏
- 事务内部的故障
- 恢复
- 基本原理：冗余
数据库中一部分被破坏或不正确的数据可以根据存储在系统别处的冗余数据来重建 - 基本技术：复杂
- 基本原理：冗余
- 恢复机制涉及的两个关键问题
- 如何建立冗余数据
- 如何利用这些冗余数据实施数据库恢复
- 建立冗余常用的技术
-
数据转储
转储即DBA定期地将整个数据库复制到磁带、磁盘或其他介质上保存起来的过程- 备用的数据称为后备副本或后援副本（即备份）
- 重装后备副本只能将数据库恢复到转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务（维持 持续性）
- 按转储时的数据库状态分为：
- 静态转储：在系统中无运行事务时进行转储操作
转储操作开始的时刻数据库处于一致性状态，而转储期间不允许（或不存在）对数据库的任何存取、修改活动。
➠静态转储得到的一定是数据一致性的副本- 优点：简单
- 缺点：降低数据库的可用性
- 动态转储：指转储期间运行对数据库进行存取或修改
转储和用户事务可以并发执行
➠必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件- 优点：不用等待正在运行的用户事务结束，也不会影响新事务的运行
- 缺点：转储结束时后援副本上的数据不能保证正确有效（可能时已过时的数据）
- 静态转储：在系统中无运行事务时进行转储操作
- 按转储方式
- 海量转储：每次转储全部数据库
- 增量转储：每次只转储上一次转储后更新的数据
从恢复角度看，海量转储 恢复一般更方便；若数据库很大，事务处理频繁，则增量转储更实用有效
在数据转储效率、数据库运行效率、故障恢复效率三方面各有利弊（不能简单的说孰优孰劣）。DBA通常会根据数据库使用情况，确定一个适合的转储周期，并配合使用这四类方法
-
登记日志文件
日志文件是用来记录事务对数据库的更新操作的文件- 日志文件的作用
- 进行事务故障恢复
事务故障恢复和系统故障恢复必须用日志文件 - 进行系统故障恢复
在动态转储方式中必须建立日志文件。后备副本和日志文件结合起来才能有效地恢复数据库 - 协助后备副本进行介质故障恢复
在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时 尚未完成的事务 进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态
- 进行事务故障恢复
- 登记日志文件的两条原则
- 登记的次序严格按并发事务执行的时间次序
- 必须先写日志文件，后写数据库
- 先写日志文件原因
- 把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。
- 如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO操作，并不会影响数据库的正确性。所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。
- 先写日志文件原因
- 日志文件的作用
-
- 事务故障的恢复
- 事务故障： 事务在运行至正常终止点前被终止
- 恢复方法：恢复子系统应利用日志文件撤销(UNDO)此事务已对数据库进行的修改。
- 事务故障的恢复是由系统自动完成的，对用户是透明的（事务故障&系统故障 透明，介质故障需要DBA介入）
- 系统的恢复步骤
- 反向扫描日志文件，查找该事务的更新操作
- 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。（当记录中是插入操作，则相当于做删除操作（“更新前的值”为空）；若记录中是删除操作，则做插入操作；若是修改操作，则相当于用修改前值代替修改后值）直至读到此事务的开始标记，该事务故障的恢复就完成了。
- 系统故障的恢复
- 系统故障造成数据库不一致状态的两个原因：
- 未完成事务对数据的更新 可能已写入数据库（破坏原子性）
- 已提交事务对数据库的更新 可能还留在缓冲区还没来得及写入数据库（破坏持久性）
- 恢复操作：撤销Undo故障发生时未完成的事务，重做Redo已完成的事务
- 系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预
- 系统的恢复步骤
- 正向扫描日志文件，找出在故障发生前已经提交的事务，将其事务标识记入重做队列；找出故障发生时 尚未完成的事务，将其事务标识记入撤销队列
- 对撤销队列中的各个事务进行撤销处理
- 对重做队列中的各个事务进行重做处理
- 系统故障造成数据库不一致状态的两个原因：
- 介质故障的恢复
- 恢复方法：重装数据库，重做已完成的事务
- 介质故障的恢复需要DBA介入，但DBA只需重装最近转储的数据库副本和有关的个日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS完成
- 系统的恢复步骤
- 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到转 储时的一致性状态。
- 装入转储结束时刻的日志文件副本
- 启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。
- 检查点记录：一类新的日志记录
- 检查点记录的内容
- 建立检查点时刻所用正在执行的事务清单
- 这些事务最近一个日志记录的地址
- 动态维护日志文件的方法：周期性地执行建立检查点、保存数据库状态的操作
- 具体步骤：
（1）将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
（2）在日志文件中写入一个检查点记录
（3）将当前数据缓冲区的所有数据记录写入磁盘的数据库中
（4）把检查点记录在日志文件中的地址写入一个重新开始文件
- 具体步骤：
- 使用检查点方法可以改善恢复效率
- 系统使用检查点方法进行恢复的步骤是
（1）从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
（2）由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
建立两个事务队列
UNDO-LIST
REDO-LIST
把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
（3）从检查点开始正向扫描日志文件，直到日志文件结束
如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列;直到日志文件结束
（4）对UNDO-LIST中的每个事务执行UNDO操作
对REDO-LIST中的每个事务执行REDO操作
- 检查点记录的内容
- 数据库镜像
数据库管理系统自动把数据库或者其中的关键数据复制到另一个磁盘上
数据库系统自动保证镜像数据和主数据的一致性，每当主数据更新时，数据库管理系统自动把更新后的数据复制过去。 - 数据镜像作用
- 出现介质故障时：
- 可由镜像磁盘继续提供使用
- 同时数据库管理系统自动利用镜像磁盘数据进行数据的恢复
- 不需要关闭系统和重装数据库副本
- 没出现介质故障时：
- 可用于并发操作
- 一个用户加排它锁修改数据，其他用户可以读镜像数据库上的数据而不必等待该用户释放锁
- 出现介质故障时：
课后题
1.试述事务的概念及事务的四个特性，恢复技术能保证事务那些特性？
- 事务是指用户定义的数据库操作
- 其具有原子性（事务要么做完，要么不做）、一致性（事务要么处于做前、要么做后的状态）、隔离性（事务之间隔离不打扰）、持续性（事务对数据库中数据改变是永久的）
- 恢复技术可以保证事务的原子性和一致性
2.为什么事务非正常结束时会影响数据库数据的正确性，举例说明
- 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。
- 例如某工厂的库存管理系统中，要把数量为Q的某种零件从仓库1移到仓库2存放。则可以定义一个事务T，T包括两个操作；Q1=Q1-Q，Q2=Q2+Q。如果T非正常终止时只做了第一个操作，则数据库就处于不一致性状态，库存量无缘无故少了Q。
3.登记日志文件时为什么必须先写日志文件，后写数据库？
- 把对数据的修改写到数据库中和把表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。
- 如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO操作，并不会影响数据库的正确性。所以一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。
6.针对不同的故障，试给出恢复的策略和方法（事务故障恢复/系统故障恢复/介质故障恢复）
- 事务故障的恢复步骤
- 反向扫描文件日志，查找该事务的更新操作。
- 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。直至读到此事务的开始标记，该事务故障的恢复就完成了。
- 系统故障的恢复步骤
- 正向扫描日志文件，找出在故障发生前已经提交的事务队列（REDO队列）和未完成的事务队列（UNDO队列）。
- 对未完成的事务队列中的各个事务进行UNDO处理。
- 对已经提交的事务队列中的各个事务进行REDO处理
- 介质故障的恢复步骤
- 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到转储时的一致性状态。
- 装入转储结束时刻的日志文件副本
- 启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。
7.什么是检查点记录，包括哪些内容
- 检查点记录是一类新的日志纪录。它的内容包括
- 建立检查点时刻所有正在执行的事务清单
- 这些事务的最近一个日志记录的地址
8.具有检查点的恢复技术有什么优点？举例
利用日志技术进行数据库恢复时，恢复子系统必须搜索整个日志，这将耗费大量的时间。此外，需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，恢复子系统又重新执行了这些操作，浪费了大量时间。检查点技术就是为了解决这些问题。
9.使用检查点方法进行恢复的步骤。
① 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。
② 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。
这里建立两个事务队列:
UNDO-LIST: 需要执行undo操作的事务集合
REDO-LIST: 需要执行redo操作的事务集合
把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
③ 从检查点开始正向扫描日志文件
如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列，直到日志文件结束
④ 对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作
10.什么是数据库镜像？它有什么用途？
- 数据库镜像即根据DBA的要求，自动把整个数据库或者其中的部分关键数据复制到另一个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。
- 数据库镜像的用途
- 用于数据库恢复。当出现介质故障时，镜像磁盘可继续使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。
- 提高数据库的可用性。在没有出现故障时，当一个用户对某个数据加排它锁进行修改时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。
![[单片机框架][调试功能] 回溯案发现场](https://img-blog.csdnimg.cn/4ad2c43b241046289764ab1727591f86.png)
