数据库系统概论-系统篇

最新推荐文章于 2024-04-26 08:22:53 发布

阿拉蕾拉

最新推荐文章于 2024-04-26 08:22:53 发布

阅读量239

点赞数

分类专栏：书籍

本文链接：https://blog.csdn.net/lym3lavender/article/details/102565670

版权

书籍专栏收录该内容

9 篇文章 0 订阅

订阅专栏

数据库恢复技术

事务（Transaction）

事务（Transaction）
- 用户定义的一个数据库操作序列，这些操作要么全做要么全不做。
- 是一个不可分割的工作单位。
- 事务的开始与结束可以有用户显示控制。
- 事务通常以BEGIN TRANSACTION开始，以COMMIT或ROLLBACK结束。COMMIT表示提交，ROLLBACK表示回滚。
事务的特性
- 原子性（Atomicity）：事务中的操作要么都做，要么都不做。
- 一致性（Consistency）：事务执行的结果必须是数据库从一个一致性状态变到另一个一致性状态。
- 隔离性（Isolation）：一个事务的执行不能被其他事务干扰。
- 持续性（Durability）：一个事务一旦提交，它对数据库中数据的改变应该是永久的。
- 事务是恢复和并发控制的基本单位。
- 保证事务ACID特性是事务处理的重要任务。
- 事务ACID特性被破坏的因素有：
  - 多个事务并行运行时，不同事务的操作交叉执行
  - 事务在运行过程中被强行停止。

数据库恢复概述

数据库的恢复：数据库管理系统必须具有把数据库从错误状态恢复到某一已知的正确状态的功能
数据库系统采用的恢复技术是否行之有效，不仅对系统的可靠程度起着决定性作用，而且对系统的运行效率也有很大的影响，是衡量系统性能优劣的重要指标。

故障种类

事务内部的故障
- 事务内部的故障是可以通过事务程序本身发现的，有的是非预期的，不能由事务程序处理的。
- 事务撤销（UNDO）：事务没有达到预期的重点，数据库可能处于不正确状态，恢复程序在不影响其他事务运行的情况下，强行回滚该事务，即撤销该事务已经做出的任何对数据库的修改，使得事务好像没有启动一样。
系统故障（软故障 Soft Crash）
- 造成系统停止运转的任何事件，使得系统要重新启动。
- 发生系统故障时，一些尚未完成的事务的结果可能已经送入物理数据库，从而造成数据库可能处于不正确的状态，为保证数据一致性，需要清除这些事务读数据库的所有修改。
- 恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销（UNDO）所有未完成事件。还需要重做（REDO）所有已提交的事务，以将数据库真正恢复到一致状态。
介质故障（Hash Crash）
- 外存故障，破坏性最大
- 破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。
计算机病毒
- 人为的故障或破坏

恢复的实现技术

恢复的基本原理是冗余。
恢复机制设计的两个关键问题
- 建立冗余数据 --> 数据转储和登录日志文件
- 利用冗余数据实施数据库恢复
数据转储
- 数据转储是数据库恢复基本技术。
- 转储是DBA定期将整个数据库复制到磁带或另一磁盘上保存起来的过程，后备副本/后援副本。
- 静态转储：在系统中无法运行事务时进行的转储操作。
- 动态转储：转储期间允许对数据库进行存取或修改。转储和用户事务可以并发执行。
- 海量转储：每次转储全部数据库。
- 增量转储：每次只转储上一次转储后更新过的数据。
登记日志文件（Logging）
- 日志文件的格式和内容
  - 日志文件是用来记录事务对数据库的更新操作的文件。
  - 日志文件格式
    - 以记录为单位的日志文件
      - 登记内容
        各个事务的开始（BEGIN TRANSACTION）标记
        各个事务的结束（COMMIT或ROLLBACK）标记
        各个事务的所有更新操作
      - 日志记录的内容
        事务标识
        操作类型
        操作对象
        更新前数据的旧值
        更新后数据的新值
    - 以数据块为单位的日志文件
      - 日志记录的内容
        事务标识和被更新的数据块
- 日志文件的作用
  - 事务故障恢复和系统故障恢复必须用日志文件。
  - 动态转储方式中必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库。
  - 在静态转储方式中，也可以建立日志文件。
- 登记日志文件
  - 登记的次序严格按并发实物执行的时间次序。
  - 必须先写日志文件，后写数据库。

恢复策略

事务故障的恢复
- 反向扫描文件日志，查找该事务的更新操作。
- 对该事务的更新操作执行逆操作。
- 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
- 如此处理，直至辅导此事务的开始标记，事务故障恢复完成。
系统故障的恢复
- 正向扫描日志文件，找出在故障发生前已经提交的事务，将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务，将其事务标识记入撤销（UNDO）队列。
- 对撤销队列中的各个事务进行撤销（UNDO）处理。
- 对重做队列中的各个事务进行重做（REDO）处理。
介质故障的恢复（DBA介入）
- 转入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
- 装入相应的日志文件副本，找出故障发生时已提交的事务的标识，将其记入重做队列。
- 正向扫描日志文件，对重做队列中的所有事务进行重做处理。

具有检查点（checkpoint）的恢复技术

检查点记录的内容
- 建立检查点时刻所有正在执行的事务清单
- 这些事务最近一个日志记录的地址。
动态维护日志文件的方法是建立检查点，保存数据库状态。

数据库镜像

数据库关系系统提供数据库镜像功能用于数据库恢复。
整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS自动把恒信后的数据复制过去，一旦出现介质故障，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。没有出现故障时，数据库镜像还可以用于并发操作。

并发控制

并发控制概述

并发操作带来的数据不一致（破坏事务的隔离性）
- 丢失修改
- 不可重复度
- 读“脏”数据
并发控制的主要技术是封锁（Locking）、时间戳（TimeStamp）、乐观控制法、多版本并发控制
封锁（Locking）
- 基本的封锁类型
  - 排他锁/X锁/写锁：事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。
  - 共享锁/S锁/读锁：事务T对数据对象A加上S锁，则T可以读取A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直至T释放A上的S锁。
封锁协议
- 一级封锁协议（读未提交）
  - 事务T在修改数据R之前必须先对其加X锁，直至事务结束才释放。
  - 防止丢失修改，并保证事务T的可恢复性。
- 二级封锁协议（读已提交）
  - 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
  - 防止丢失修改，进一步防止读“脏”数据。
- 三级封锁协议（可重复读）
  - 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。
  - 防止丢失修改和读“脏”数据，进一步防止不可重复度。

活锁和死锁

活锁
- 事务T1封锁了数据R，事务T2又请求封锁R，T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放R上的封锁之后系统又批准了T4的请求…T2可能永远等待。
- 避免活锁的简单方法是采用先来先服务的策略。
死锁
- 事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁，接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁，这样出现了T1在等待T2，T2又在等待T1的局面，T1和T2两个事务永远不能结束，行程死锁。
- 预防死锁
  - 一次封锁法：每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
    - 问题：扩大封锁范围，降低系统并发布；难以事先精确地确定每个事务所要封锁的数据对象。
  - 顺序封锁法：预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。
    - 问题：维护封锁顺序困难，成本很高；难以事先确定每个事务要封锁哪些对象。
- 死锁的诊断与解除
  - 超时法：一个事务的等待时间超过了规定的时限就认为发生了死锁。
    - 问题：有可能误判；时限设置太长，死锁发生后不能及时发现。
  - 等待图法
时间戳（TimeStamp）
- 每个事务分配全局唯一的时间戳
- 特性：唯一性、单调性
- 读时间戳、写时间戳
- 乐观控制
乐观控制法
- 数据库操作大部分不会发生冲突
- 读-> 确认 -> 写
多版本并发控制
- 每次事务操作是数据的一个快照，用一份数据临时保留多版本方式实现并发

并发调度的可串行性

定义：多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同。
可串行性是并发事务正确性的准则。

两段锁协议（2PL）

所有事务必须分两阶段对数据项加锁和解锁。
- 在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁； <扩展阶段>
- 在释放一个封锁之后，事务不再申请和获得任何其他封锁。 <收缩阶段>
事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。
遵守两段锁协议的事务可能发生死锁。

封锁的粒度

多粒度封锁
- 一个系统中同事支持多种封锁粒度供不同的事务选择
- 多粒度树
- 显式封锁：应事务的要求直接加到数据对象上的封锁
- 隐式封锁：该数据对象没有独立加锁，是由于其上级结点加锁而使该数据对象加上了锁。
意向锁
- 意向共享锁（Intent Share Lock，简称IS锁）
- 意向排他锁（Intent Exclusive Lock，简称IX锁）
- 共享意向排他锁（Share Intent Exclusive Lock，简称SIX锁）