10.1 事务的基本概念：
- 什么是事务？事务是用户定义的一个数据库操作序列，该操作要么全做，要么全不做，是一个不可分割的工作单位，是恢复(知识点)和并发控制(知识点)的基本单位
- 事务和程序的区别：
- 在关系数据库中，一个事务可以是一条SQL语句，或多条SQL语句，或整个程序
- 一个程序可以有多个事务
- 事务定义：- 正常结束和异常结束
- 正常结束： -- 正常执行后，SQL的操作就写回到磁盘中
- BEGIN TRANSCTION; -- 事务开始
- SQL 语句;
- COMMIT; -- 事务提交
- 异常结束：--异常结束，SQL的所以操作都撤销，回到事务开始前
- BEGIN TRANSCTION; -- 事务开始
- SQL 语句;
- ROLLBACK; -- 事务回滚
- 事务的特性： -- 考试考
- 特征：原子性、一致性、隔离性、持续性
- 原子性：
- 事务是数据库的逻辑工作单位，事务中包括的诸操作要么不做，要么全做
- 一致性：
- 先理解什么是一致性？就是用户A读学生表数据为99，用户B读取就不能是100，必须是99一致的
- 事务的执行结果必须是使数据库从一个一致性状态到另一个一致性状态
- 一致状态：数据库中只包含成功事务提交结果
- 不一致状态：数据库系统运行在发生故障，有些事务被迫中断过(如断了),这些未完成的事务对数据库做了一部分修改，写入了物理数据库，这时候数据库就处于不正确的状态 -- 解决办法事务回滚，数据恢复
- 原子性和一致性的举例：
- 银行转账，那些就必须定义为一个事务，两个操作全做，如用户A给用户B转1万，用户A减少一万，突然断电，那么用户减少1万，用户B要没有加上1万，这就是不一致状态，如果成功就是一致状态
- 隔离性：
- 一个事务执行不能被其它事务干扰(如交叉执行事务)，即一个事务的内部操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间都不能相互干扰
- 持久性：-- 也叫永久性
- 一个事务一旦提交，对数据库中数据的改本就是永久性的，接下来的操作或故障对其执行结果没有影响
- 事务是恢复和并发控制的基本单位，保证事务ACID特征是事务管理的重要任务
- 事务ACID日志可能遭到破坏的因素有：
- 多个事务并发运行，不同事务的操作交叉执行
- 数据库管理系统必须保证多个事务的交叉运行不影响这些事务的隔离性
- 事务在运行过程中被强行停止
- 数据库管理系统必须保证被强行终止的事务对数据库和其他事务没有任何影响
10.2 数据库的恢复概述：
- 故障是不可避免的，故障主要包括：计算机硬盘故障、软件的错误、操作员的失误、恶意的破坏等
- 故障对数据的影响主要表现为：运行事务非正常中断，影响数据库中的数据正确性、数据库全部或部分丢失数据等
- 数据库恢复作用：把数据库从错误状态恢复到某一已知的正确状态的功能
- 数据库恢复子系统是数据库管理系统的一个重要组成部分，而且还相当庞大，常常占整个数据库系统代码的10%以上。恢复技术是衡量系统的性能优劣的重要指标，以为对系统的可靠程度起到决定因素
10.3 故障的种类：
- 故障的种类大致分为四类： 事务内部的故障、系统故障、介质故障(介质==硬件)、计算机病毒
- 1.事务内部的故障：
- 事务内部的故障有的是可以通过事务程序本身发现的(如转账的例子)有的是非预期的，不能由事务程序处理的
- 细节1：事务的内部更多的故障的是非预期的，是不能由应用程序处理的。如算法溢出、死锁
- 细节2：事务的故障意味着事务没有达到预期的终点，数据库可能处于不正确状态。撤销该事务已经作出任何对数据库的修改，使得该事务好像根本没有启动一样，这类恢复操作称为：事务撤销
- 2.系统故障：
- 系统故障又称软故障，是指系统正常运行突然被破坏，内存在的缓冲区信息全部丢失去，所有正在运行的事务都非正确终止
- 常见原因：CPU故障，操作系统故障、数据库系统代码错误、系统断电
- 系统故障的恢复：
- 常见问题1：系统发生故障，一些未完成的事务结果已经写入到物理数据库(磁盘),造成数据库处于不正确状态
- 恢复办法：系统重新启动，恢复程序重新让所有的非正常终止的事务回滚，强行撤销所有未完成事务
- 常见问题2：系统发生故障，某些已经完成的事务可能还留在缓冲区，没有写到物理数据库中，因为没有写入，导致执行事务的操作(如：增删改查),全部丢失，导致数据库数据不一致
- 恢复办法：系统重新启动，撤销所有未完成的事务，还需要重做，所有提交的事务，将数据库恢复到一致状态
- 3.介质故障：
- 介质故障又硬故障，是指外存故障，如磁盘损坏、磁头碰撞，强磁干扰等
- 故障表现：破坏数据库或部分数据库
- 4.计算机病毒：
- 计算机病毒是一种可繁殖、传播并对计算机造成破坏
- 计算机病毒特点：隐蔽性、潜伏性、传染性、破坏性、寄生性
- 数据库本病毒破坏时，仍要用恢复技术来恢复
- 小结：
- 1.故障对数据库的影响主要是数据库本身被破坏和，数据没有被破坏，但数据不正确
- 2.恢复操作的基本原理就是冗余(就是备份)，符合子系统的代码一般要占到全部代码的10%以上
10.4 恢复的实现实现技术：
- 恢复数据的关键就是创建冗余(备份)数据，然后利用执行冗余数据进行数据库恢复
- 建立冗余数据的常见方法：
数据转储：就是把数据建立一个备份，然后存储在另外一台设备上
日志文件：就是事务对数据库进行了什么操作都记录下来
- 通过数据转存和日志文件就可以把数据库符合到某一个正确的结点
如：7月15号到9月20号，9月20号发生错误，7月15号进行了数据转储，在通过日志文件把数据库恢复到9月20号没有发生故障的状态
10.4.1 数据转储：
- 什么是数据转储？就是把数据建立一个备份，然后存储在另外一台设备上，这些备份的数据文本称为后备副本或后援副本
- 注意：后备副本只是把数据库恢复到转储的状态，要想符合到故障发生的状态，还需要进行转储后的所有更新事务
- 转储状态：静态转储与动态转储
- 静态转储：需要中系统无任何事务进行时进行转储操作，转储期间不允许对数据库进行增删改查
例子：如游戏服务器正在维护，玩家都不能进入，就没有新的事务发生，那么就可以进行静态转储
优点：实现方便
缺点：降低了数据库的可用性，以为需要等转储结束，新的事务才能开始
- 动态转储：事务和转储并发进行，转储期间允许对数据库进行增删改查
例子：转储期间，刚把事务A的100记录到磁盘上，某一事务就将A改成了200，后备副本上的A数据就过时了
优点：不用等正在运行的用户事务结束，不会影响新事务的运行
缺点：不能保证副本中的数据真时有效(看上面例子就知道为什么了)
- 细节1：利用动态转储得到副本，还需要把各事务(就是并发的事务)对数据库的修改记录下来，建立成日志文件。通跟后备副本和日志文件就能把数据库恢复到某人正确的结点
- 细节2：利用静态转储得到副本，就不需要把事务记录下来，以为静态记录的就是正确的，而且它转储也不可能有事务进行
- 转储方式：
- 海量转储：每次转储全部数据库
增量转储：转储上一次转储后更新过的数据
海量和增量比较：
从恢复角度看，使用海量转储得到的后备副本进行恢复更加方便，因为转储的是全部数据库，
如果数据库较大，事务处理频繁，增量就更实用更有效，因为事务多数据老是在变化，就不可能每次都海量转储
- 转储分类：
- 通过转储状态和转储方式可以分为4类：动态海量转储、静态海量转储、动态增量转储、静态增量转储
10.4.2 登记日志文件：
- 日志的主要目的：记录事务等数据库的更新操作的文件(注意是更新操作，因为查询没有影响)
- 记录日志的两种格式，单位的日志文件和数据块单位的日志文件：(这些操作都是由于数据库自动来完成)
- 单位的日志文件需要登记的内容：
- 1.各事务开始的标签
2.个事务结束的标准(正确结束，的还是非正常结束的标签)
3.各事务的所有更新操作
以上3条记录的操作记录为一个日志记录
- 每条日志记录的内容：
- 事务标识(标明是哪各事务)
操作类型(插入、删除或修改)
操作对象(如操作是哪个表，哪条数据)
更新前数据的旧值(如果是插入，该项就是空值)
更新后数据的新值(如果是删除，该项就是空值)
- 数据块为单位的日志文件需要登记的内容：
- 1.事务标识
2.被更新的数据块 - 就是以一整个事务为一个单位
- 日志文件的作用：
- 1.事务故障恢复
2.系统故障恢复
3.配合后备副本进行介质故障恢复
- 1.登录的次序严格按并发事务执行的时间次序
2.必须先写日志文件，后写数据库（如果先写数据库，如果突然断电，数据库写了日志没写，恢复时就会有影响）
10.5 恢复策略:
10.5.1 事务故障的恢复:
- 事务的故障是指事务在正常运行至正常终点前被终止
- 事务故障的恢复是由系统自动完成的，系统的恢复步骤是：
- 1.反向扫描，查找事务的更新操作
2.对事务进行撤销
3.继续反向扫描，查找该事务其它的更新查找，并做同样的处理
4.直到事务读到事务开始标识，事务故障符合就完成
10.5.2 系统的故障
10.5.2 系统的故障:
- 系统的故障会造成数据库不一致状态，原因：
- 1.未完成的事务的更新操作可能已经写入数据库 -- 解决办法撤销未完成的事务
2.已提交的事务可能还停留在缓冲区，没有写到数据库 -- 解决办法重做已完成的事务
- 系统故障的恢复由系统在重新启动时自动完成
10.5.3 介质故障:
- 介质故障指的是物理数据和日志文件被破坏
- 恢复办法是重装数据库，然重做已完成的事务
- 介质的恢复需要数据库管理员的介入，数据库管理员只需要重装最近转储的数据库副本和有关的日志文件，然后执行系统提供的恢复命令即可
10.6 具有检查点的恢复技术:
- 为什么需要检查点技术：
- 在利用日志恢复数据库恢复时，恢复子系统的时候必须搜索日志，确定哪些事务需要重新做，哪些事务要撤销
- 问题1：搜索整个日志需要大量时间
问题2：重做处理、重新执行，浪费大量时间
- 解决方案：
- 1.在日志文件中增加检查点记录
2.增加重新开始的文件 - 和日志文件是并列的，不在日志文件里面
3.恢复子系统在登录日志文件期间动态地维护日志
- 检查点记录的内容：
- 1.所有正在执行的事务清单
2.这些事务最近一个日志记录地址
- 重新开始文件内容:
- 动态维护日志文件的方法：
- 周期性地执行如下操作：建立检查点、保持数据库状态
- 具体步骤：
- 1.将当前日志缓冲区的所有日志写入磁盘的日志文件
2.在日志文件中写入一个检查点记录
3.将当前的数据缓冲区的所有数据记录写入磁盘的数据库中
4.把检查点记录在日志文件中的地址写入重新开始文件
- 说明：
- 恢复子系统可以定期或不定期地建立检查点，保存数据库状态
检查点可以按照预定的一个时间来间隔来建立，如一个小时记录一个检查点
也可以按照某种规则建立检查点。如日志文件写到一半建立
- 利用检查点恢复策略：
- 所有检查点方法可以改善恢复效率
1.T1在检查点之前提交，对数据库的修改已经写到数据库
2.T2在检查点之后，故障之前，所有需要重做
3.T3在故障之后需要撤销
4.T4在故障点之前提交，需要重做
5.T5在检查点之后，故障之前，需要撤销
- 系统使用检查点的恢复步骤：
- 1.从重新开始文件找到最后一个检测点，在日志文件中的地址，由该地址在日志文件中找到最后一个检测点记录
- 2.检查建立后得到所有正在执行的事务清单ACTIVE-LIST(活跃的),分成两个事务对列：
- 1.UNNDO-LIST：需要执行撤销操作的的事务集合
- 2.REDO-LIST：需要执行重做操作的事务集合
ACTIVE-LIST暂时放入UNNDO-LIST，只是暂时(要看该事务是在说明时候提交的，如T4就先放程序队列，但发现它是在故障发前提交就放到重做队列)
- 3.从检查点扫描日志文件
- 1.有新的事务就暂时放到UNNDO-LIST
2.有提交就从UNNDO-LIST放到REDO-LIST - T4案例
- 4.UNNDO-LIST的每个事务要执行UNNDO操作，REDO-LIST的每个事务要执行REDO操作
10.7 数据库镜像:
- 目的：预防介质故障，提高数据库可能性
- 什么是数据库镜像：
- 数据库管理系统自动把整个数据或其中关键数据复杂到另一个磁盘，主数据库数据更新，数据库管理系统把更新后的数据复制过去，保证镜像数据库与主数据的一致
- 如果介质出现故障怎么办：
- 所有应用去访问镜像数据库，镜像数据库有去恢复主数据库，如果没有发生故障可以并发操作
10.8 总结：
- 1.保证数据库的一致性是对数据库的基本要求
2.事务是数据库的逻辑工作单位
3.事务的ACID特征：一致性、隔离性、原子性、持久性
4.保证了事务ACID特征就是保证了，数据库的一致性
5.故障的恢复是，保证事务的，一致性、隔离性、原子性
6.恢复的基本原理就是利用后备副本、日志文件、数据库镜像中的冗余数据来重构数据库
7.事务不仅是恢复的基本单位，也是并发控制的单位
8.保证事务的一致性、隔离性，数据库隔离系统需要对并发操作操作进行控制
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
