目录
一、事务的基本概念
- 事务：用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位（恢复和并发控制的基本单位）
- 事务与程序：在关系数据库中，一个事务可以是一条或多条sql语句，也可以包含一个或多个程序；一个程序通常包含多个事务
- 事务定义
- 显式定义（start transaction 或者begin---commit或者rollback）
- 隐式定义DBMS按缺省规定自动划分事务
- 事务结束
- Commit
- 事务正常结束
- 提交事务的所有操作（读+更新）
- 事务中所有对数据库的更新写回到磁盘上的物理数据库中
- Rollback
- 事务异常终止
- 事务运行的过程中发生了故障，不能继续执行
- 系统将事务中对数据库的所有已完成的更新操作全部撤销
- 事务滚回到开始时的状态
- Commit
二、事务的ACID特性
1. 原子性
- 事务是数据库的逻辑工作单位
- 事务中包括的诸操作要么都做，要么都不做（简单来说就是事务是一个整体）
2. 一致性
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
- 一致性状态（数据正确的状态）：在事务间没有干扰的情况下，数据库中只包含成功事务提交的结果；
- 不一致状态：数据库中包含未完成事务的结果。
注：一致性和原子性密切相关，为什么？看下图
原子性就说明了要么都做要么都不做，但是你只做一个操作，那这个事务就没有完成，就可能保证不了事务的一致性了。
3. 隔离性
一个事务的执行不能被其他事务干扰
- 一个事务内部的操作及使用的数据对其他并发事务是隔离的
- 并发执行的各个事务之间不能互相干扰
4. 持续性
- 一个事务一旦提交，它对数据库中数据的改变就应该是永久性的
- 即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作
5. 事务的特性——（重要）
- 保证事务ACID特性是事务处理的任务
- 破坏事务ACID特性的因素
- 多个事务并行运行时，不同事务的操作交叉执行；
- 事务在运行过程中被强行停止。
三、数据库恢复概述
- 系统故障：计算机软、硬件故障
- 人为故障：操作员的失误、恶意的破坏等
故障的影响：事务的非正常中断，影响数据库的正确性；破坏数据库，导致全部或部分数据丢失。
- DBMS提供恢复子系统
- 数据库恢复：把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）
- 恢复子系统是数据库管理系统的一个重要组成部分
- 恢复技术是衡量数据库管理系统优劣的重要指标
四、故障的种类
1. 事务内部的故障
某个事务在运行过程中由于种种原因未运行至正常终止点就夭折了（非正常终止）
- 可预期的，可以通过事务程序本身发现，及时回滚保证数据库的一致性；
- 非预期的，不能由事务程序处理的，比如求阶乘，导致数据外溢。
事务内部更多的故障是非预期的，是不能由应用程序处理的，比如：
- 输入数据有误
- 运算溢出
- 并发事务发生死锁而被选中撤销该事务
- 违反了某些完整性限制等
事务故障意味着事务没有达到预期的终点（COMMIT或者显式的ROLLBACK），数据库可能处于不正确的状态！！！
事务故障的恢复：事务撤销（UNDO）
- 强行回滚该事务
- 撤销该事务已经做出的任何对数据库的修改，使得该事务像根本没有启动
2. 系统故障——软故障
- 是指造成系统停止运转的任何事件，使得系统重新启动。影响正在运行的所有事务，但不破坏数据库；
- 所有正在运行的事务都非正常终止；
- 内存中数据库缓冲区的信息全部丢失；
- 部分尚未完成的事务的结果可能已送入物理数据库，从而造成数据库可能处于不正确的状态；
1. 系统故障的原因
- 特定类型的硬件错误（如CPU故障）
- 操作系统故障
- DBMS代码错误
- 系统断电
- 导致系统崩溃的计算机病毒
2. 系统故障的恢复
- 发生系统故障时，事务未提交，直接强行撤销（UNDO）所有没有完成的事务；
- 发生系统故障时，事务已提交，但是缓冲区的信息尚未完全写回磁盘，直接重做（REDO）所有已提交的事务。
3. 介质故障——硬故障
指外存故障，破坏性最大
1. 介质故障的原因
- 磁盘损坏
- 磁头碰撞
- 操作系统的某种潜在错误
- 瞬时强磁场干扰
- 破坏硬盘数据的计算机病毒
2. 介质故障的恢复
- 需要借助存储在其他地方的数据备份来恢复数据库；
- 装入数据库发生介质故障前某个时刻的数据副本；
- 重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库；
总结：各类故障，对数据库的影响有两种可能性：
- 数据库本身被破坏：介质故障，计算机病毒
- 数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的：事务内部故障，系统故障，计算机病毒
五、恢复的实现技术
- 恢复操作的基本原理：（冗余）利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据；
- 恢复机制涉及的关键问题
- 如何利用冗余数据进行恢复：数据转储+登记日志文件
- 如何建立冗余数据
- 数据转储
DBA将整个数据库复制到其他存储介质上保存起来的过程，备用的数据称为后备副本或后援副本。
如何使用：
- 数据库遭到破坏后可以将后备副本重新装入；
- 重装后备副本只能将数据库恢复到转储时的状态；（原始状态，回到解放前）
- 要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务；
1. 静态转储与动态转储
1. 静态转储
实现简单，但降低了数据库的可用性
1. 得到的一定是一个数据一致性的副本
2. 转储期间不允许对数据库的任何存取、修改活动
3. 转储开始时数据库处于一致性状态
4. 在系统中无运行事务时进行的转储操作
转储必须等待正在运行的用户事务结束，新的事物必须等转储结束！
2. 动态转储
1. 转储操作与用户事务并发进行
2. 转储期间允许对数据库进行存取或修改（这里就能反应副本中的数据可能不正确）
优点：1. 不用等待正在运行的用户事务结束 2. 不会影响新事务的运行
缺点：不能保证副本中的数据正确有效
注：利用动态转储得到的副本进行故障恢复，需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件！！！
后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态。
动态转储+日志文件
2. 海量转储与增量转储
1. 海量转储
每次转储全部数据库；
2. 增量转储
只转储上次转储后更新过的数据；
3. 登记日志文件
日志文件是用来记录事务对数据库的更新操作的文件。
1. 日志文件的格式和内容
1. 以记录为单位的日志文件：记录各个事务的开始标记，结束标记以及所有更新操作；
2. 以数据块为单位的日志文件：记录事务的标识和被更新的数块；
2. 日志文件的作用
1. 事务故障恢复和系统故障恢复，必须用日志文件；
2. 静态转储后的后备副本进行介质故障恢复，也可用日志文件；
3. 动态转储后的后备副本进行介质故障恢复，必须用日志文件；
3. 登记日志文件
基本原则：
1. 登记的次序严格按并行事务执行的时间次序
2. 必须先写日志文件，后写数据库（就是说你要做操作了就先写入日志文件中，写完之后在对数据修改到数据库中）
先写日志文件的原因：
六、恢复策略
1. 事务故障的恢复
由恢复子系统利用日志文件撤销（UNDO）此事务已对数据库进行的修改；（由系统自动完成，对用户透明，不需要用户干预）
解决方式：
1. 反向扫描日志文件（从最后开始向前扫描）；
2. 对事务的更新操作执行逆操作，直到读到此事务的开始标记；
2. 系统故障的恢复
在系统重启时自动完成，不需要用户干预
解决方式：
正向扫描日志文件（从头开始扫描日志文件），划分一下两类：
1. REDO队列，故障发生前已经提交的事务T1，T3，T8……；
2. UNDO队列，故障发生前尚未完成的事务T2，T4，T5……；
这里有点不一样了！！！
1. 对UNDO队列的事务进行UNDO处理： 反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作；
2. 对REDO队列的事务进行REDO处理：正向扫描日志文件，对每个REDO事务重新执行登记的操作；
3. 介质故障恢复
需要DBA介入，具体的恢复操作仍由DBMS完成
解决方式：利用数据库后备副本和日志文件进行恢复
DBA的工作：
- 重装最近转储的数据库副本和有关的各日志文件副本；
- 执行系统提供的恢复命令；
恢复步骤：
- 装入最新的后备数据库副本(离故障发生时刻最近的转储副本) ，使数据库恢复到最近一次转储时的一致性状态；
注：
- 对于静态转储的数据库副本，装入后数据库即处于一致性状态；
- 装入有关的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务。
- 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。
总结：
七、具有检查点的恢复技术
提高系统故障的恢复效率
针对以上问题提出的解决方案：
- 在日志文件中增加检查点记录；
- 恢复子系统在登录日志文件期间动态地维护日志；
- 增加重新开始文件；
下面的内容请好好理解，很容易混乱！！！
1. 检查点记录
检查点记录是记录什么的？
- 建立检查点时刻所有正在执行的事务清单；
- 建立这些事务最近的一个日志记录的地址；（根据检查点更快的找到事务）
2. 重新开始文件
重新开始文件是记录什么的？
记录各个检查点记录在日志文件中的地址；（理解了吗？看看下面这个图）
理解就是日志文件中有检查点记录，但是具体这个检查点在哪由重新开始文件记录，这样就可以知道具体的检查点在哪，明确那些事务不用重做了。
3. 动态维护日志文件
周期性建立检查点并保存数据库的状态，步骤如下：
- 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件中；
- 在日志文件中写入一个检查点记录；
- 将当前数据缓冲区的所有数据记录写入磁盘的数据库中；
- 把检查点记录在日志文件中的地址写入一个重新开始文件；
从上往下执行，当检查点记录写入重新开始文件中，就说明前面已经提交的事务不用重做了
4. 恢复子系统的恢复策略
定期或不定期建立检查点，保存数据库状态
检查点的作用——改善系统故障的恢复效率
REDO重做的起点可以是检查点Tc 时刻！
脏页：指缓冲池中已被修改的数据页，但尚未写回到磁盘中。
八、数据库镜像
提高介质故障的恢复效率，很高级的一个东西
1. 起因
- 预防介质故障DBA就必须得周期性转储数据库；
- 介质故障恢复耗时；
- 解决方案：利用数据库镜像
2. 数据库镜像
- DBMS 自动把整个数据库或其中的关键数据复制到另一个磁盘上；
- DBMS自动保证镜像数据与主数据库的一致性，每当主数据库更新时，DBMS自动把更新后的数据复制过去；
3. 用途
- 出现介质故障
- 可由镜像磁盘继续提供使用；
- 同时DBMS自动利用镜像磁盘数据进行数据库的恢复；
- 不需要关闭系统和重装数据库副本；
- 没有出现故障
- 可用于并发操作；
- 一个用户对数据加排他锁修改数据，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁；
- 频繁地复制数据自然会降低系统运行效率，因此：
在实际应用中用户往往只选择对关键数据和日志文件镜像，而不是对整个数据库进行镜像；
九、总结
- 保证数据一致性是对数据库的最基本的要求；
- DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性；
- DBMS必须对事务故障、系统故障和介质故障进行恢复；
- 恢复中最经常使用的技术：数据库转储和登记日志文件；
- 恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库；